Yazılım Uzmanlığı Üzerine
Transkript
Yazılım Uzmanlığı Üzerine
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 Yazılım Uzmanlığı Üzerine 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 1.2 1.3 2 PROJE EKİBİNİN OLUŞTURULMASI ......................................................................... 13 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 3 PROJE ALT YAPISININ HAZIRLANMASI ................................................................................................................................... 1 İŞ ORTAMI VE SAĞLIKLI ÇALIŞMA......................................................................................................................................... 9 SONUÇLAR .................................................................................................................................................................... 12 SİSTEM SORUMLUSU ....................................................................................................................................................... 14 PROJE LİDERİ ................................................................................................................................................................. 14 ANALİZ EKİBİ ................................................................................................................................................................. 16 TASARIM EKİBİ............................................................................................................................................................... 17 YAZILIM EKİBİ ................................................................................................................................................................ 18 MÜŞTERİ TEMSİLCİSİ ....................................................................................................................................................... 19 TEST EKİBİ .................................................................................................................................................................... 20 EĞİTİM EKİBİ ................................................................................................................................................................. 22 PAZARLAMA EKİBİ .......................................................................................................................................................... 23 KURULUM YÖNETİMİ EKİBİ ............................................................................................................................................... 24 DEĞİŞİM VE İSTEKLERİN YÖNETİMİ..................................................................................................................................... 25 PİLOT FİRMA ................................................................................................................................................................. 25 ŞEFFAF MUHASEBE ......................................................................................................................................................... 26 YAPILAN YANLIŞLAR ........................................................................................................................................................ 26 BLOGDAN SEÇMELER ............................................................................................. 31 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17 3.18 3.19 3.20 3.21 3.22 3.23 3.24 3.25 3.26 3.27 3.28 ÜTOPYALARIM, AŞKIM VE BEN .......................................................................................................................................... 31 AGİLE MODELLEME DEĞERLERİ ......................................................................................................................................... 35 DÜŞÜNCELERİM ............................................................................................................................................................. 39 PROGRAMLAMAYA YENİ BAŞLAYACAKLARA.......................................................................................................................... 41 EXTREME PROGRAMLAMA ............................................................................................................................................... 46 YAZILIM UZMANI VE SAĞLIK ............................................................................................................................................. 51 EKİP TOPLANTILARI ......................................................................................................................................................... 52 ESKİ PROJELER ............................................................................................................................................................... 57 CMMI, ISO, SPICE, IEEE .............................................................................................................................................. 64 SOA VE PROJE ANALİZİ ................................................................................................................................................... 68 ANALİST YAZILIM UZMANI ............................................................................................................................................... 72 NASIL DAHA İYİ KOD YAZARIZ ........................................................................................................................................... 76 EĞER TEST EDİLMEMİŞSE ÇALIŞMIYOR DEMEKTİR ................................................................................................................. 82 GEREKSİNİM YÖNETİMİ VE KALİTE...................................................................................................................................... 84 DİĞER GEREKSİNİM YÖNETİMİ YAZISI ................................................................................................................................. 87 SERBEST YAZILIM............................................................................................................................................................ 89 REUSİNG VE REFACTORİNG ............................................................................................................................................... 91 KARİYER OLAYI .............................................................................................................................................................. 93 İSPANYOL TEORİSİ........................................................................................................................................................... 95 İŞ BAŞVURUSU VE DİKKAT EDİLECEKLER .............................................................................................................................. 97 YENİ İŞ KURACAKLARA BİR TEST ........................................................................................................................................ 99 TESTİN CEVAPLARI ........................................................................................................................................................101 PROGRAMLAMA ÖĞRENCİSİNİN DERDİ .............................................................................................................................103 BANA RAKİBİNİ SÖYLE ...................................................................................................................................................106 YAZILIM UZMANLIĞINDAN YÖNETİCİLİĞE...........................................................................................................................107 ISVLER İÇİN 25 KURAL ..................................................................................................................................................114 SÜRÜM YÖNETİMİ ........................................................................................................................................................117 FİRMANIZI KORUMAK ....................................................................................................................................................120 3.29 3.30 3.31 3.32 3.33 3.34 4 YAZILIM VE KİŞİLİK ........................................................................................................................................................124 YAZILIM SÜRECİNDE KALİTE ............................................................................................................................................126 YAZILIM UZMANI OLAMAYACAĞINIZIN 10 KANITI ...............................................................................................................130 STRES VE YAZILIM SEKTÖRÜ............................................................................................................................................133 YURTDIŞINA YAZILIM ÜRETELİM ......................................................................................................................................135 BİR BAŞKA GÖZLEM ......................................................................................................................................................142 UML VE CBD İLE YAZILIM GELİŞTİRME ................................................................. 145 4.1 4.2 4.3 4.4 4.5 İŞ GEREKSİNİMLERİNİ MODELLEME AŞAMASI .....................................................................................................................145 KULLANICI ARAYÜZÜ GEREKSİNİMLERİ VE TASARIMI BELGESİ ................................................................................................148 SİSTEM MODELLEME AŞAMASI .......................................................................................................................................149 PROTOTİPLEME AŞAMASI ...............................................................................................................................................153 Ö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. Yönetim Ve Yapılanma 2 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 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. çıkarılı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 Yönetim Ve Yapılanma 3 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. Yönetim Ve Yapılanma 4 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 Ü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ı mi? biliyorlar mı? Yazılım aracı/dili için eğitim verecek kuruluş var mı? Diploma, sertifika veriliyor Dünyada başka kimler kullanıyor? örütbağında arama yaptığınızda kaç tane sonuç mu? dönüyor? İş bulma sitelerinde, sizin düşündügünüz yazılım aracı/dili ile ilgili ne kadar iş ilanı Ürününüzü Dünya genelinde satmayı düşünüyor musunuz? Araç/dil bu tasarıma var. izin veriyor mu? Yazılım aracı/dili üreten firma ile birlikte başka hangi firmalar bu araca/dile destek Ne kadar para harcamayı düşünüyorsunuz? veriyor. 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? Yönetim Ve Yapılanma 5 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 Yönetim Ve Yapılanma 6 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. Yönetim Ve Yapılanma 7 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ş Yönetim Ve Yapılanma 8 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. Yönetim Ve Yapılanma 1.2 9 İş 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 Yönetim Ve Yapılanma 10 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ı. Emektup 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. Yönetim Ve Yapılanma 11 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. Yönetim Ve Yapılanma 12 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. Proje Ekibinin Oluşturulması 13 2 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ı 2.1 14 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 Proje Ekibinin Oluşturulması 15 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 Proje Ekibinin Oluşturulması 16 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. Proje Ekibinin Oluşturulması 17 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 Proje Ekibinin Oluşturulması 18 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. Proje Ekibinin Oluşturulması 19 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 Proje Ekibinin Oluşturulması 20 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 Proje Ekibinin Oluşturulması 21 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 Proje Ekibinin Oluşturulması 22 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. Proje Ekibinin Oluşturulması 23 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 Proje Ekibinin Oluşturulması 24 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 Proje Ekibinin Oluşturulması 25 (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. Proje Ekibinin Oluşturulması 26 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 Proje Ekibinin Oluşturulması 27 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 Proje Ekibinin Oluşturulması 28 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 Proje Ekibinin Oluşturulması 29 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. Proje Ekibinin Oluşturulması 30 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. Blogdan Seçmeler 31 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 Blogdan Seçmeler 33 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 Blogdan Seçmeler 34 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. Blogdan Seçmeler 35 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. Blogdan Seçmeler 36 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 hatayakalama 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 Blogdan Seçmeler 37 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 Blogdan Seçmeler 38 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. Blogdan Seçmeler 39 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 webservice’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 Blogdan Seçmeler 40 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. Blogdan Seçmeler 41 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 13. Ne kadar para harcamayı düşünüyorsunuz? veriyor. 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 Blogdan Seçmeler 42 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 denemeyanı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. Blogdan Seçmeler 43 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. Blogdan Seçmeler 44 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 Blogdan Seçmeler 45 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. Blogdan Seçmeler 3.5 46 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 Blogdan Seçmeler 47 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 Blogdan Seçmeler 48 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 Blogdan Seçmeler 49 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. Blogdan Seçmeler 50 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. Blogdan Seçmeler 51 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. Blogdan Seçmeler 52 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. Blogdan Seçmeler 53 İş 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* Blogdan Seçmeler 54 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. Blogdan Seçmeler 55 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. Blogdan Seçmeler 56 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: Blogdan Seçmeler 57 Ö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 Blogdan Seçmeler 58 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, Blogdan Seçmeler 59 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. Blogdan Seçmeler 60 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 Blogdan Seçmeler 61 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. Blogdan Seçmeler 3.8.17 62 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ırsasizin çö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. Blogdan Seçmeler 63 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. Blogdan Seçmeler 3.8.25 64 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 eposta 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 Blogdan Seçmeler 65 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. Blogdan Seçmeler 66 Ü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 Blogdan Seçmeler 67 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. Blogdan Seçmeler 68 Ö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. Blogdan Seçmeler 69 İ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. Blogdan Seçmeler 3.10.5 70 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 Blogdan Seçmeler 71 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ı Blogdan Seçmeler 72 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. 73 Blogdan Seçmeler 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 Blogdan Seçmeler 74 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 Blogdan Seçmeler 75 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ı Blogdan Seçmeler 76 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 Blogdan Seçmeler 77 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. Blogdan Seçmeler 78 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. Blogdan Seçmeler 79 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. Blogdan Seçmeler 3.12.7 80 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 Refactoring Nedir Öğrenin 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 :-). Blogdan Seçmeler 81 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 Blogdan Seçmeler 82 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 Blogdan Seçmeler 83 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... Blogdan Seçmeler 84 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. Blogdan Seçmeler 85 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 Blogdan Seçmeler 86 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: Blogdan Seçmeler 87 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ı Blogdan Seçmeler 88 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. Blogdan Seçmeler 89 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. Blogdan Seçmeler 90 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 Blogdan Seçmeler 91 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. Blogdan Seçmeler 92 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. Blogdan Seçmeler 93 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 Blogdan Seçmeler 94 ö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ü eposta 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 Blogdan Seçmeler 95 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 Blogdan Seçmeler 96 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. Blogdan Seçmeler 97 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 Blogdan Seçmeler 98 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. Blogdan Seçmeler 99 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ı? Blogdan Seçmeler 100 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 Blogdan Seçmeler 101 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. Blogdan Seçmeler 102 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. Blogdan Seçmeler 103 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. Blogdan Seçmeler 104 -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 Blogdan Seçmeler 105 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????? Blogdan Seçmeler 106 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. Blogdan Seçmeler 107 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 Blogdan Seçmeler 108 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. Blogdan Seçmeler 109 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/ Blogdan Seçmeler 110 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) Blogdan Seçmeler 111 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. Blogdan Seçmeler 112 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 Blogdan Seçmeler 113 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 Blogdan Seçmeler 114 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. Blogdan Seçmeler 115 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. Blogdan Seçmeler 7. 116 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. Blogdan Seçmeler 117 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 Blogdan Seçmeler 118 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. Blogdan Seçmeler 119 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. Blogdan Seçmeler 120 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 Blogdan Seçmeler 121 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 Blogdan Seçmeler 122 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 Blogdan Seçmeler 123 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. Blogdan Seçmeler 124 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 Blogdan Seçmeler 125 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. Blogdan Seçmeler 126 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. Blogdan Seçmeler 127 İ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 Blogdan Seçmeler 128 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. Blogdan Seçmeler 129 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ç Blogdan Seçmeler 130 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 Blogdan Seçmeler 131 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. Blogdan Seçmeler 132 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 Blogdan Seçmeler 133 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 Blogdan Seçmeler 134 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. Blogdan Seçmeler 135 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. Blogdan Seçmeler 136 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 Blogdan Seçmeler 137 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ı? Blogdan Seçmeler 138 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ı Blogdan Seçmeler 139 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. Blogdan Seçmeler 140 Ş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 Blogdan Seçmeler 141 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, Blogdan Seçmeler 142 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 Blogdan Seçmeler 143 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 Blogdan Seçmeler 144 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. UML ve CBD ile yazılım geliştirme 145 4 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 Yazılım Uzmanlığı Üzerine 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 Yazılım Uzmanlığı Üzerine UML ve CBD ile yazılım geliştirme 147 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. Yazılım Uzmanlığı Üzerine UML ve CBD ile yazılım geliştirme 148 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 Yazılım Uzmanlığı Üzerine UML ve CBD ile yazılım geliştirme 149 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 Hizmetin yada modülün genel Hizmet/Modül ismi API Uygulama/RDBMS Diğer Bağlantı Bu hizmet yada modülü anlatan belgeye bağlantı. 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: Yazılım Uzmanlığı Üzerine UML ve CBD ile yazılım geliştirme 150 v0.4 28/4/2003 Boundary Layer Email DRAFT only Complaints User Interface • see preliminary dialogue map for an outline of proposed web pages / screens… Complaints Dashboard • operational monitoring and management information for complaints • to receive alerts and notifications… (No data access allowed only access to solutions or infrastructure components) (No user interface allowed - only business and control logic, data encapsulated in components) • tied to user interface • handles transaction, session / state • no business data • minimal business logic (just calls to lower components) Complaints Orchestration Solution Layer Security Services Case Reporting • fill in case plan template Complaints Process Mgmt Complaint Details • record/update a complaint • get previous complaints • search (by type, text, status etc) • basic statistics (current day only) • Allocate complaint • Send complaint for Authorisation • Accept / Reject complaint Client Mgmt • Get Client details • Add New client • Create Work item • allocate / reallocate • Allocate • escalate • Accept / authorise • Reject Enterprise Business Component Layer (No user interface allowed - minimal business logic and only COMMON rules, no control logic, no knowledge of other components or direct calls, data encapsulated in components) Client Registration Using Staff information available through SAP services (contact name and phone etc) Profiles • maintain organisation hierarchy (until available in SAP…) • positions within teams • officers occupying positions Authoring Tool Complaints Op Reporting • provide dashboard facilities Staff Provide name and address information Organisation • draft a letter to the client / contact Generic Case Management Generic Process Mgmt Reference Data (codes) Letter Constructor • provide view of profile hierarchy (for work allocation purposes) • maintain profile hierarchy Inwards Channels • manage all inwards communication from fax, scanning, email etc Audit Trail Document Management Case & Work Management • Create Case • Create Work Item (& connect to case) • Allocate & Re-allocate work • Manage generic case/work status • Close / complete work or case Event Notifier Outwards Correspondence • Send and archive letter • retrieve and re-edit… Client Relationship Management • record all contact with client • provide a list of all recent contacts (regardless of channel or purpose…) Applications Infrastructure Layer 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: Yazılım Uzmanlığı Üzerine UML ve CBD ile yazılım geliştirme 151 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 External Web Server(s) All external clients & agents (via browser) ATO Portal May use Complaints services One or several midrange servers… Mainframe internet Complaints Orchestration Complaints Op Reporting CRM (CP) * = could also be replaced by Change Program capabilities Internal Web Server(s) Client Registration Generic Case Mgmt Case Reporting * Complaints Process Mgmt * Generic Process Mgmt Complaint Details * Case & Work Mgmt Client Mgmt Staff Profiles Organisation Internal user Complaints UI COLA (message based middleware) Complaints Dashboard Security Email (Outlook) Authoring Tool (MS Word) Audit Trail = New or altered facility this phase Yazılım Uzmanlığı Üzerine UML ve CBD ile yazılım geliştirme 152 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. Yazılım Uzmanlığı Üzerine UML ve CBD ile yazılım geliştirme 153 Component XYZ interface 1 COMPONENT SPECIFICATION interface 2 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 Yazılım Uzmanlığı Üzerine UML ve CBD ile yazılım geliştirme 154 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. Yazılım Uzmanlığı Üzerine UML ve CBD ile yazılım geliştirme 155 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 Yazılım Uzmanlığı Üzerine UML ve CBD ile yazılım geliştirme 156 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, Yazılım Uzmanlığı Üzerine 157 UML ve CBD ile yazılım geliştirme 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. Yazılım Uzmanlığı Üzerine UML ve CBD ile yazılım geliştirme 158 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. Yazılım Uzmanlığı Üzerine UML ve CBD ile yazılım geliştirme 159 ATOS.SN1 Araç Yönetimi Senaryo # Use Case Name Kapsam Hedef Seviye Aktör(ler) Hedef Amaç Olgunluk Varsayımlar Sorular Öndurumlar 1 Araç Yönetimi İş Süreci (Şeffaf-Kutu) Genel Senaryo Son Kullanıcı (birincil) 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. 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. Kırmızı 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. 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ışı 1Yok İş kuralları Araç son bakım tarihi 6 aydan geri olmamalıdır Notlar İlişkili Şemalar Belge Tarihçesi Tarih Sürüm 6/Mart/2003 0,1 10/Mart/2003 0,1 Açıklama İlk sürüm oluşturuldu İş akışına 6. madde eklendi Yazılım Uzmanlığı Üzerine İsim/Soyisim İlker Dağıstanlı İlker Dağıstanlı UML ve CBD ile yazılım geliştirme 160 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 (blackbox) 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. Yazılım Uzmanlığı Üzerine UML ve CBD ile yazılım geliştirme 161 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 Yazılım Uzmanlığı Üzerine UML ve CBD ile yazılım geliştirme 162 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. Yazılım Uzmanlığı Üzerine UML ve CBD ile yazılım geliştirme 163 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. Yazılım Uzmanlığı Üzerine UML ve CBD ile yazılım geliştirme 164 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. Yazılım Uzmanlığı Üzerine UML ve CBD ile yazılım geliştirme 165 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 Yazılım Uzmanlığı Üzerine UML ve CBD ile yazılım geliştirme 4.5.1.22 166 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 ) Sofor Yonetimi <<include>> (from Sofor Yonetimi ) Odeme Belirle (from Sofor Yonetimi ) 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. Yazılım Uzmanlığı Üzerine UML ve CBD ile yazılım geliştirme 167 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>> Operator (from Aktor) Guzergah Olustur (from Servis Yonetimi) 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. Yazılım Uzmanlığı Üzerine UML ve CBD ile yazılım geliştirme 168 İş 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. Yazılım Uzmanlığı Üzerine UML ve CBD ile yazılım geliştirme 169 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. Yazılım Uzmanlığı Üzerine UML ve CBD ile yazılım geliştirme 170 İ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 Yazılım Uzmanlığı Üzerine UML ve CBD ile yazılım geliştirme 171 Ihale Servis Firma n 1 1 1 1 1 FirmaPersonel 1..n TicariFirma OzelMusteri n n Arac 1 n 1..n 0..1 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 Yazılım Uzmanlığı Üzerine UML ve CBD ile yazılım geliştirme 172 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. Yazılım Uzmanlığı Üzerine UML ve CBD ile yazılım geliştirme 173 Servis ServisNo AracPlaka : Arac Arac AracPlaka : String n SonBakimTarihi KoltukSayisi Model Notlar 1 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) Yazılım Uzmanlığı Üzerine UML ve CBD ile yazılım geliştirme 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 174 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ı Yazılım Uzmanlığı Üzerine UML ve CBD ile yazılım geliştirme 175 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. Yazılım Uzmanlığı Üzerine