August 2005 Entries etiketi ile ilgili girdiler...

Bu günlerde yeni projelere başlamaktansa, eski projeleri adam etmekle yada yeni sistemlere uydurmakla vakit harcıyoruz. Genelde devir aldığımız projeler zamanın şartlarına göre güzel yazılmış fakat artan veri yığınları ve eskiyen teknolojiler nedeni ile ya performansları düşmüş yada yeni sistemlerle konuşamaz duruma gelmiş oluyor.

Bazende firmaların kısır düşünceleri ve günlük politikaları yüzünden, günü kurtarmak amaçlı alına iki eleman ile eski projeler canlı tutulmaya çalışılıyor. Bazı firmalar, bırakın gelecek seneyi, önümüzdeki haftayı düşünüp planlamazken, bütün iş yükünü bu iki elemana yükleyip bir şeyler bekliyorlar. Bu iki eleman sihirbaz mıdır da sihirli deynekleri ile sistemi ayağa kaldırıp, bir o kadar da hatayı düzeltip programı çalışır hale getirsin.

Diyelim ki böyle bir projeyi Proje Müdürü olarak devir aldınız. İlk yapacaklarınız neler olurdu bir bakalım.

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ı dizaynları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ı dizayn 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.

Kaynak kodu derlenebiliyor mu?

Tüm kodu derlemeye çalışın ve bağımlılık şeması çıkartmaya çalışın. Modül bazında derleme sırasını oluşturmaya çalışın. Kullandığınız UML aracı ile bu derleme sırasını modelleyin. Eksik, kayıp, gereksiz modüller var mı tesbit edin. Kullanılan üçüncü parti modülleri de tesbit edin. Eğer kod sorunsuz olarak derlenebiliyorsa bu sizin başlangıç noktanız olacaktır. Yeni bir VSS veritabanı yaratıp tüm kodu buraya aktarın ama kodun tarihçesini almayın. Eski VSS veritabanını da daha sonra kullanmak üzere yedekleyin. Yeni yarattığınız VSS sanki yeni açılmış bir proje gibi olacak.

Derlenemeyen kod varsa bunlarda risk oluşturacaktır. Raporunuza bu riskleri de ekleyin.

Bir müşteri istekleri 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.

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.

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.

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.

Yazılım iç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.

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.

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?

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.

Genelde sorunlar basit programatik sorunlar mı yoksa iş akışlarında mı?

Gene hata ve istek veritabanından sorunların programatik sorunlar mı (örneğin sıfıra bölme, text box'ların yerlerinin değiştirilmesi, veritabanına kayıt sırasında bir sahanın unutulması vs) yoksa iş akışlarında mı (örneğin bir sipariş alma ve gönderme sırasında geçen olaylar ve kullanılacak fonksiyonlar)? Programatik sorunları çözmek kolaydır fakat iş akışlarındaki hatalar ancak işi bilen birisi tarafından bulunabilir ve çözülebilir. Eğer programatik hatalar çoğunlukta ise işiniz nisbeten daha kolay.

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.

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.

Patronun istekleri 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.

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.

Modül testleri yapabilmek iç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.

Projenin yeni bir teknoloji ile 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.

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.

Na kadar zamanımız var?

"Zaman" her zaman dar olduğumuz bir ihtiyaç. Genelde tam ihtiyacımız olduğu anda biter. Ne kadar zamanınız olduğunu Patrondan öğrenin ve gerçekçi olup olmadığı konusunda; kendi planlarınız ile karşılaştırıp bir rapor halinde patrona sunun. Riskler ve tam olarak belli olmayan müşteri istekleri raporun ana kaynağı olacak ve bu riskleri ortadan kaldırmak için sunacağınız bir kaç yöntem -onaylanırsa- sizin çözüm yolunuz olacaktır. Zamanınızı iyi kullanmak sizin elinizde, eğer iyi bir planlama yaparsanız ve kaynakları iyi kullanırsanız her şey mümkün.

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.

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.

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.

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.

Medya ile 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.

Programın tanıtılacağı bir örütbağ sitesi var mı?

Ürününüzü örütbağ üzerinde tanıtacak, müşterilerin aradıklarında bulmasını sağlayacak, kullanım kılavuzlarının yer aldığı bir site çok işinize yarayabilir. Müşterilerin kullanacağı bir forum, bir e-posta listesi ve bir hata bildirme formu müşteriyi mutlu edecektir.

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.

Buraya kadar yazdıklarıma bir eklemeniz varsa yada benim unuttuğum konular; yorumlarınızı bekliyorum.

Yeni skin pek bir hoş oldu. Bu CSS dünyası başka bir alem canım. Yaptığım yeniliklere birde arama modülü ekleyeceğim. Ekledim hazır fakat testler sırasında bir kaç problem çıktı. Birde blog girdilerini PDF olarak indirebilme özelliği ekleyeceğim. Bunun için SharpPDF bileşenini kullanıyorum. Bu ikisini bitirdikten sonra sitemi güncelleyeceğim.

Diğer eklediğim bir olay ise GEO URL olayı. Sayfanın meta kısmına aşağıdaki gibi enlem ve boylamları yazınca kayıt olabiliyorsunuz. Dikkat ederseniz BlogMap'inde yeri değişti. Bulunduğunuz yerin enlem ve boylamını GoogleEarth ile bulabilirsiniz.

<meta name="ICBM" content="41.077 , 28.947">
<meta name="DC.title" content="Gürkan Yeniçeri's Blog">

Eğer bir ekip içinde yazılım geliştiriyorsak her zaman yeni teknolojilere ayak uydurmak, yarım kalan işleri tamamlamak, müşteri problemleri ile uğraşmak gibi sorunlarla başetmek zorunda kalırız. Analist Yazılım Uzmanı olarak ta kendimizi geliştirmek ve bilgilerimizi çoğaltmak ile yükümlüyüz.

Gelişme eğer temelleri iyi atılmış ise mümkün olur ve izlenen yola göre, faydaları zaman içinde ortaya çıkar. Yıllardan beri izlediğiniz yöntemler (bir işe yaramadığını bile bile), okulda öğretilen metodlar, mühendislik yöntemlerinin yazılım alanında yanlış kullanılması sonucu artık işe yaramaz hale gelmiş, durağan işleyiş modellerinin değiştirilmesi gerekebilir.

Tabii her değişim bir öğrenme evresi ve eğitim zorunluluğu ile birlikte gelir. Fakat belli bir yöntemi firma genelinde oturtmak uzun vadede çok daha faydalı olacaktır. Her yiğidin bir yoğurt yiyişi vardır fakat firmalarında belli bir yoğurt yiyişi olmalıdır. Firmanın sahip olduğu bu "kişilik" ve "kültür" çalışanlar tarafından benimsenmelidir. Firmalar kendi içlerinde küçük sosyal yapılardır ve her sosyal yapının haberleşmeye ve paylaşmaya ihtiyacı vardır. Ayrıca her sosyal yapının bir de karşıtı (rakibi) vardır ki, ayakta kalabilmesi ve gelişebilmesi için bu gereklidir. Yani düşman olmadan ilerleme olmaz.

Firma içindeki yazılım geliştirme kültürü ise bu sosyal yapının bir nevi anayasasıdır. Kurallara uymak ile yükümlü olan çalışanlar anayasa üzerinde değişiklik yapılması için önergede bulunabilir. Tabii bu anayasanın da uluslararası yasalara uygun olması gerekir ki firmanın dışarı ile olan ilişkileri (hem yabancı hemde Türk firmalar) de belli çerçeveler içinde ve anlaşılabilir düzeyde olsun.

Tepeden inme metodlar, aniden değişen kurallar firma çalışanlarını korkutabilir, direnişe veya bölünmelere neden olur. Bunu hepimiz çok iyi biliyoruz sanırım. Fakat sindirilerek ve belirli politikalar uygulanarak yapılan değişiklikler daha kalıcı olur. Ayrıca bu değişikliğin, verimi arttırdığı görüldüğün de kabul edilmesi çok daha hızlı olacaktır. Bir iki dinazor çıkacaktır tabii fakat sebeplerin çok iyi analiz edilmesi ve yeni sistemin öğretilmesi için zaman harcanması gerekir.

Firmaya yeni kişiler alınırken de firma kültürü ve ahlakı da ortaya konulmalı ve görüşmeler sırasında adayın bu kurallara aşina olup olmadığı veya öğrenmeye ve uymaya istekli olup olmadığı, uymazsa sonuçlarının neler olacağı tartışılmalıdır. Bu şekilde aday seçimi aşaması çok daha verimli olacaktır ve firmanın geleceği garanti altına alınmış olacaktır.

Buraya kadar yazdıklarımı lütfen yavaş yavaş ve tekrar okuyun. Bir yazılım firması hayal edip kavramları oturtmaya çalışın.

Bu kadar genel konuşmadan sonra, firma kültürünün nasıl oluşturulacağına, anayasanın nasıl uygulanacağına, dünyada mevcut uluslararası kurallara bir göz atalım.

MÜŞTERİ

Bir firmanın varoluş sebebi müşterileridir. Müşterisi olmayan bir firma düşünebiliyor musunuz? Bu durumda mutlu edilmesi gereken en önemli birim müşteridir. Mutlu müşteri bedava reklam demektir. Bir yazılım projesinde de en önemli unsur müşteri gereksinimleridir. Şimdi bir düşünelim; yaptığınız kaç projede gerçekten müşteri ile yüz yüze geldiniz, müşteriyi dinlediniz veya müşteri ile bir fikir birliğine vardınız yada müşteriyi tam olarak anladığınıza inandınız? E o zaman bu kadar önemli bir unsuru neden proje dışında tuttunuz? Neden müşteriyi iyice dinlemediniz?

Cevap sanırım çok kısa ve klasik, çünkü düşündüğünüz tek şey sonuçta ortaya çıkacak üründü. Ürüne odaklandığınız için müşteri ikinci plana itildi. Oysa ki en önemli unsur müşteriler; firmanızın hayatta olma sebebi.

Ürün odaklı sistemler ile müşteri odaklı sistemlerin en büyük farkı müşteri odaklı sistemlerin devinimsel olmalarıdır. Yani projenin hayat süreci boyunca müşteri yeni bir şeyler ister sizde bunları uygulamakla yükümlü olursunuz. Dinamik yapısından dolayı ürün odaklı sisteme göre daha zor gelebilir fakat işleme modelini bir kere oturttuktan sonra sorun olmayacaktır.

Ürün odaklı sistemlerde ise ürünün ne olacağı, ne yapacağı belirlenmiştir. Belli bir müşteri kitlesi belirlenmiştir fakat müşterinin üründen haberi yoktur. Eğer tutarsa ne ala, kar yapabilir fakat batabilirde.

Görülüyorki müşteri odaklı bir sistemin hayatta kalabilme şansı daha fazla ve riskleri daha az. Müşteri üründen haberdar, ayrıca geliştirme aşamasında katkıda bulunduğu için memnun ve mesut. Demek ki firmamızın işleme modelinde ilk değiştirmemiz gereken şey müşterinin önemini anlamak ve ürün yerine müşteriye odaklanmak. Böylece ortaya çıkacak ürün müşteri gereksinimlerini daha iyi karşılayacak ve kendi kendini satacaktır. İşte size mutluluğun resmi. Abidin Dino gibi ressam olmasakta kendi alanımızda mutluluğun resmini yaptık işte.

KÜLTÜR

Firmanın yazılım geliştirme kültürü, işleme modeli ile yakından ilgilidir. Eğer firmanın işleme modeli genel standartlar içinde ise kalite zaten kendiliğinden gelir. Burada bahsettiğim firma kültürü, yazılım geliştirme metodolojileri ile (waterfall, agile, XP vs.) karıştırılmamalıdır. yazılım geliştirme metodu firmanın işleyiş modeli içine entegre olmuş bir parçadır ve işleme modelindeki kontrol mekanizmaları ile kontrol edilir. Metodolojinin açıkları veya yetmeyen tarafları varsa eklenir veya değiştirilir.

Peki nedir bu işleme modeli?

İşleme modeli bir firmanın yaptığı işi ele alış şeklidir. Aynı sektörde olupta farklı yöntemlerle iş yapan firmalar vardır. Örneğin kimisi tahsilatı aylık yapar, diğeri peşin çalışır, bir başkası bir al bir bedava der v.b. gibi. Yazılım firmalarında ise kimisi paldır küldür kod yazmaya girer, kimisi önce analiz belgelerini yazar, kimisi kalite kontrolü en sona bırakır, kimisi müşteriyi hiç görmek istemez, kimisi de bazı işleri taşeronlara verir yada Open Source modülleri kullanmaya çalışır. Kontrol ve işleme modelini geliştirmek gibi konular üzerinde de fazla durulmaz.

Bir firmanın öncelikle bir organizasyon şemasına ihtiyacı vardır. Bu şemalarda yapılan en büyük yanlış; görevler yerine isimlerin yazılmasıdır. Sadece görevlerin yer aldığı bir şema daha motive edici bir şema olacaktır. Her görevin ne iş yaptığı ayrıntılı olarak açıklanmalıdır. Böylece çeşitli görevler için atanan kişiler ne yapacaklarını önceden bileceklerdir. Ayrıca atamaların karar verilmesi için kişinin bir üst pozisyondan yaptığı işleride rahatça görebiliriz. Problemler için nerelere başvurulacağıda kolayca görünür.

Konumuz yazılım geliştirme olduğuna göre bu konudaki işleme modellerine bakalım.

Çeşitli standart kuruluşları ve Amerikan ordusu bu konuya el atıp bir standarda oturtmaya çalıştılar, zamanına göre de oldukça başarılı oldu. İlk başlarda çıkan pek çok standart ürün odaklı idi fakat bu günlerde artık müşteri odaklılar.

Avrupada ISO (International Standards Organisation) bir standart çıkarınca Amerikada boş durmayıp IEEE (The Institute of Electrical and Electronics Engineers) ile bazı standartlar çıkardılar fakat biraz bölük pörçük ve acele ye gelmiş bir standart. Amerika bu işin devlet eli ile olmayacağını anlayınca Carnegie Mellon - Software Engineering Institue (SEI) ile anlaşıp bu işi üniversite bazında çözmek için girişimde bulundu ve ortaya CMM (Capability Maturity Model) çıktı.

IEEE 12207 çok güzel bir işleme modeli ortaya koyuyor ve yazılım firmaları yada departmanları için ideal. Ayrıca 12207'nin nasıl uygulanacağını anlatan 15504 numaralı bir standartları da var. ISO'da da aynı numaralarla standartlar mevcut. Maalesef lınk veremiyorum çünkü bunlar paralı satılıyor.

SEI ise bir adım daha ileri gidip hem ISO ve IEEE sentezinde hemde EIA/IS (Electronic Industries Alliance Interim Standard), IPD-CMM (Integrated Product Development) ve Capability Maturity Model işleme modellerini aynı potada eritip CMMI (Capability Maturity Model Integrated) modelini ortaya çıkardılar. Amerikan ordusu tarafından desteklenen bu proje şimdiye kadar çıkan tüm IEEE, ISO ve diğer standartların katkısı ve eklenen yeni modüllerle oluştu. Hala da geliştirilmeye devam ediyor.

Destek anlaşmaları gereği üretilen her ürünün halka açılması zorunluluğundan dolayı SEI tüm bu standartları kendi örütbağ sitesinde yayınlıyor. 724 sayfalık CMMI pdf dosyasını indirdiğinizde elinizde hatırı sayılır bir işleme modeli oluyor ki bunu uygulayabilirseniz ne ala. İlk 93 sayfayı okuyup diğer bölümleri yeri geldikçe okuyabilirsiniz.

CMMI'ın iki farklı modeli var. Biri "Continues" yani devinimsel diğer ise "Staged" yani merdiven modeli. (Gene felaket bir çeviri oldu farkındayım :-) ) Merdiven modelinde bir organizasyonun değerlendirilmesi aşağıdan yukarıya her departman için yapılıyor. Yani size bağlı çalışan tüm departmanlar belli kriterleri geçmeden CMMI sertifikası alamıyorsunuz. CMMI sertifika sistemi ilk çıktığında bu model vardı sadece. Genelde insan hayatının söz konusu olduğu sistemlerde bu model kullanılır.

Öte yandan Devinimsel model ise organizasyon departmanlarını tek tek ele alıp değerlendiriyor ve CMMI sertifikası veriyor. Yeri gelmişken bu sertifikalardan da bahsedeyim. 5 adet CMMI sertifikası mevcut, bunlar:

0. Incomplete (Beyaz Kuşak)

1. Performed (Sarı Kuşak)

2. Managed (Turuncu Kuşak)

3. Defined (Mavi Kuşak)

4. Quantitatively Managed (Kahverengi Kuşak)

5. Optimizing (Siyah Kuşak)

Tavsiyem Continues modeli indirip bir göz atmanız ve ilk 93 sayfayı okumanız.

Bir başka modelde SPICE. SPICE size yazılım geliştirme modelinizi tetkik edecek bir sistem sunuyor. Bu tetkikler sırasında da yapılması gerekenleri anlatıyor. ISO ve IEC standartları göz önüne alınarak hazırlanmış. Esas dökümanları olmasada "draft" sürümünü indirip bakabilirsiniz.

Gerekli Linkler:

http://www.sei.cmu.edu/publications/documents/02.reports/02tr011.html CMMI Continues Model

http://www.sei.cmu.edu/cmmi/ CMMI Ana Sayfa

http://www.sei.cmu.edu/cmmi/adoption/iso-mapping.html ISO9001:2001 ve CMMI arasındaki benzerlikler

http://www.sqi.gu.edu.au/spice/ SPICE Ana Sayfa

http://www.psmsc.com/ Practical Software Measurement

http://www.sei.cmu.edu/sema/welcome.html Software Engineering Measurement and Analysis

http://www.sei.cmu.edu/publications/documents/96.reports/96.hb.002.html Goal Driven Software Measurement


 

SOA, Service Oriented Architecture, yani Hizmet Tabanlı Mimari. Yazılım geliştirme sürecinde ilk başlarda analiz yaparken ortaya çıkan "iş senaryolarının" ayrı birimler olarak ele alınması ve kendi başına var olabilecek hizmetler olarak tasarlanması olarak yorumlayabiliriz. Her hizmet kendi başına bir iş halleder. Nesne Yönelimli Analiz metodu olarak ne kullanırsanız kullanın (Shlaer-Mellor, Hatley-Pirbhai, UML vesaire.) sonuçta elinizde bir kaç katmana yayılmış hizmetler olacaktır. Veritabanından, grafik arabirime (sunum katmanı) kadar uzanan bu katmanlar birbirleri arasında veri alışverişi yaparak istenilen operasyonu başarmaya çalışır. SOA mimarisi ile tasarlanmış bir uygulamada bakım ve onarım işleri daha ucuza mal olur diyebiliriz. Arayüzlere dokunmadıkça ve giriş çıkış veri formatını değiştirmedikçe içeride her türlü değişikliği yapabiliriz. Ayrıca SOA ile tekrar kullanımı arttırıyoruz ki bu da tekrar eden işlemler için aynı programın tekrar tekrar yazılmasını ortadan kaldırıyor.

İyi bir SOA tasarımının kalitesi ilk etapta yapılan analizin kalitesine bağlıdır. Benim değinmek istediğim konu bir Analyst Developer'ın gerekli araçları temin ederek bu analiz aşamasından yüzünün akı ile çıkmasıdır. Kalitenin anlaşılabilmesi için bazı ölçülere de burada değineceğim.

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.

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- 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.

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.

5- Veritabanı ve grafik arayüz değişebilir

Yaptığınız tasarımın hedeflerinden biri de zaman içinde veritabanının ve grafik arayüzün değişimlerinden etkilenmemesidir. Tasarım tamamı ile modüler olmalı ve sadece iş kurallarını uyguladığınız katman sizin için önemli olmalıdır. Veritabanı ve Grafik arayüz tümden çöpe atılıp yeniden geliştirilebilmeli ve iş kurallarını uygulayan katmana kolayca eklenebilmelidir. İşte hizmet tabanlı mimarilerin önemi burada ortaya çıkıyor.

Bir işi analiz ederken veritabanı tablolarını ve grafik arayüzü düşünüyorsanız, büyük ihtimalle ortaya çıkacak dizayn 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 Dizayn

Alt başlık: Servisin ismi

Bu alt başlıkta kısaca servisin ne yaptığını yazmak gerekir.

Alt Başlık: Tip

Servislerde kendi aralarında katmanlara ayrılabilir. Eğer bir DFD şeması varsa katmanları görmek kolaylaşır, yada iş ve sistem senaryoları olarak ikiye ayrılmış senaryoları gerçekleyen servisler tiplerine göre isimlendirilebilir.

İş Kuralları

Bu servisde uygulanan iş kurallarının bir listesi yada iş kurallarının bulunduğu dökümana link verilebilir.

Servisin Girdileri

Burada servisin işleyeceği verinin yapısı anlatılır. Ne tür bir girdi olacak tablo halinde yazılmalıdır. Eğer veritabanı şekillenmeye başladı ise verinin tipide belirmeye başlamıştır.

Servisin Çıktıları

Servisten beklenen verinin yapısıda burada yazılır.

Varsayımlar

Eğer servisin çalışması için gerekli varsayımlar varsa burada listelenir. Önceden var olması gereken koşullar yada çalışmış olması gereken servisler burada listelenir.

Oluşabilecek Hatalar

Servisin oluşturacağı hataların listesi (exception yada bir hata listesi olabilir) burada listelenir. İleride servisi kullanacak olan programcı (yada bizzat siz) servisin geriye döndüreceği hataları kontrol etmekle hükümlüdür.

Çağırılan Diğer Servisler

Bu servisden çağırılan diğer servisler burada listelenir ve Servis İçerik belgelerine link verilir. Tabii her çağırılan servisin bir de geriye döndürdüğü hata durumları var ve bunların kontrol edilmesi gerekiyor. Eğer bu servisden 100 adet servis çağırıldıysa kontrol edilecek hata listesi bini geçecektir. Bu durumda oluşan hataların yönetimi için bir sistem oluşturulup her servis de uygulanmalıdır. Hazır hata kontrol modülleri mevcuttur, yada açık kaynak bu tür projeler de var.

Akış Şeması

Firma genelinde kullanılan metoda göre burada bir şema yer almalı ve servisin yaptığı işi anlatmalıdır. Servisi kodlarken kullanılacak en önemli kısımlardan biridir. Bu bölümü yazarken kesinlikle programlama dilinden uzak durmanız gerek, aksi takdirde yanlış yorumlamalara yada iş akışında oluşacak farklı durumlara sebebiyet verilmiş olunur. Eğer yukarıda belirttiğim gibi modelleri oluşturmak için bir araç kullanıyorsanız ve modeller iç-örütbağı üzerinden erişilebilir ise, bu servisin ilişkili olduğu modele bir link te verebilirsiniz. Bakımı daha kolay olur.

Test Senaryoları

Yukarıda bu servisin geriye döndüreceği hata durumlarını yazdınız, şimdide bu hata durumlarını meydana getirecek durumları listelemeniz gerekiyor. Servis kodlanıp test aşamasına geldiği zaman bu test senaryolarında bulunan senaryolar kullanılacaktır. Eğer TDD (Test Driven Development - Test Güdümlü Yazılım Geliştirme (felaket bir çevirim oldu :-)) ) yapıyorsanız kodlamaya bu test modelinden başlayacaksanız demektir. Testler için kullanılacak veriyide tablolar halinde yazın.

Kullanıldığı Yerler

İlerleyen zamanlarda bu servisin çağırıldığı servisler buraya kaydedilir. Yada link verilebilir. Söz konusu servis değişikliğe uğradığında buradaki listede bulunan servisler de bu değişiklikten haberdar edilmelidir. Böylece değişikliklerden kimler etkilenecek sorusunun yanıtını anında alabilirsiniz başımızdaki saçlar da yerinde daha uzun durur.

Görüldüğü gibi bazı kurallara uyarak yazılım geliştirmek gerçekten de hatırı sayılır bir kaliteye ulaşmamızı sağlıyor. Ortaya çıkan belgelerin ve modellerin yönetimi, erişimi, kontrolü ve değişimi ne kadar kolay ve sorunsuz ise yapılan işin kaliteside o kadar artıyor.

Kaliteli günler dilerim.

Hafta sonu oturup bu .Text uygulamasına bir kaç ekleme yapayım dedim. Pek aşikar olmadığım bir kod fakat çözmek pek zaman almadı. İstediğim bir özellik son 10 blog girdisini ve en popüler 10 girdiyi listeleyecek iki modüldü. Diğer blog uygulamalarında var bizde niye olmasın dedim. Ortaya yan taraftaki (RSS okuyucu ile okuyorsanız siteyi ziyaret ederek görebilirsiniz.) "Recent Posts", ve "Popular Post" modülleri çıktı. Burada nasıl yaptığımı anlatıyorum. Bu hafta sonuı verimli geçti diyebiliriz.

Ayrıca VS2005 ve TFS'in kurulu olduğu VPC'yi de nihayet ele geçirdim. Benim kurulumlar pek iyi sonuç vermedi fakat Microsoft'un VPC'si ile benim kurulum arasında hiç fark yok. Sanırım hafıza yetersizliğinden dolayı servisler zaman aşımına uğruyor ve hata çıkarıyordu. MS VPC ile bile aynı hatayı bir kez aldım. Bu olay tüm bilgisayarları yenileme planımı biraz daha erkene çekebilir lakin Vista çıkana kadar bekleyecektim (hatta service pack 1 çıkana kadar).

Of  Manowar'da iyi çalıyor "Hail and Kill". Athena'da çalardı bunu be ne günlerdi. Göztepe'de konserine gitmiştik. Rahmetli Ümit Yılbar'a Allah rahmet eylesin.

Arama



Hakkımda

Merhaba, ben Gürkan Yeniçeri. 10 yılı aşkın süredir özel sektör ve hükümet iştiraklerinde yazılım mühendisliği yapıyorum. Bu sitede 2005 Mart ayından beri genelde yazılım mühendisliği ve hobilerim hakkında yazmaktayım. Profesyonel iş geçmişim hakkında daha fazla bilgiyi aşağıdaki Linkedin.com linkinden alabilirsiniz.
Gürkan Yeniçeri'nin profilini görmek için tıklayın

Kontak

Soru sormak veya öneride bulunmak isterseniz buradaki kontak formunu kullanın. Mesajlarınıza en kısa zaman içinde cevap vermeye çalışacağım. Ayrıca Windows Live Messenger kullanarak gyeniceri {AT} hotmail {DOT} com adresinden bana ulaşabilirsiniz.

Eğer İngilizce blogumu okumak isterseniz buraya buyrun.
Blogumu RSS Bandit gibi bir RSS okuyucusu ile de takip etmek için kullanın.
Ayrıca aşağıdaki linklerden hakkımda ayrıtılı bilgi alabilirsiniz.
Twitter
Friendfeed
Facebook

RSS 2.0

Reklamlar


Vezir

Vezir Proje Danışmanı
Sitede birde Vezir isminde wikimiz var. Bu wikiyi yazmayı düşündüğüm bir kitap için oluşturmuştum daha sonra herkese açmaya karar verdim. Vezir yazılım firması kurmak isteyenlere tavsiyeler vermek için hazırlandı. Ayrıca UML ve Modül Tabanlı Geliştirme hakkında da bilgiler mevcut. Vakit buldukça yeni eklemeler yapıyorum. Değişikliklerden haberdar olmak için RSS çıktısına üye olabilirsiniz.

Tag Bulutu

Tüm taglar...
www.flickr.com
This is a Flickr badge showing public photos from gurkanyeniceri. Make your own badge here.
Bu blogda 265 yazı ve 509 yorum var. Diğer sitelerden 26 adet link gelmiş.

Reklamlar