May 2006 Entries etiketi ile ilgili girdiler...

100. yazımdan sonra Gürol Beyden aşağıdaki e-postayı aldım. Birilerinin bu tür konulara kafa yorduğunu görmek sevindirici.

SAYIN GÜRKAN BEY,

Yeni yaşınızı kutlar, nice güzel yaşları sevdiklerinizle geçirmenizi temenni ediyorum.

100.yazınızla ilgili bir sorum olacaktı. Burada bahsi geçen "gereksinim yönetimi", yazılım kalite güvencesi içerisinde bir parça olarak mı algılanmalı yoksa, yazılım çalışmaları yapan kişilerin oluşturacakları bir kontrol mekanizması olarak mı algılanması gerekmektedir?

Böyle bir yönetim kavramı veya bunun geliştirilmesi şirketlerin hangi birimi tarafından uygulanmalıdır? Bir sorumda, önereceğiz bir kitap varmı bunlarla ilgili olarak? Daha önce vermiş olduğunuz öneriler için de teşekkür ederim.

İYİ ÇALIŞMALAR

SEVGİ VE SAYGILARIMLA

GÜROL GÜRSES

Kutlaman için teşekkür ederim.

Gereksinim Analizi basit olarak müşterinin ihtiyaçlarını analiz ettiğimiz adım diyebiliriz. Projenin başında müşteri gelir ve problemlerini anlatır sende oturup bunları analiz edersin. Yönetimini ise Business Analyst yada Analist Yazılım Uzmanı yapar. Üretilen her türlü döküman belli onay kademelerinden geçeceği ve zaman içinde değişikliğe uğrayacağı için bu şarttır.

Bunun kalite kontrolü içinse üretilen her türlü senaryonun müşteri tarafından onaylanması gerekir. Böylece ortaya çıkardığımız her gereksinimin müşterinin ihtiyacı olan gereksinimler olduğunu söyleyebiliriz. Boşuna ürettiğimiz bir şey olmaması gerekir. Gereksinim Yönetimi Yazılım Kalite Güvencesi içinde bir parça olarak algılanabilir. Örneğin IEEE 829 (Yazılım testi dökümantasyonu) gibi bir standardı uyguluyorsak birde bunların doğru kullanılıp kullanılmadığını tetkik edecek denetleme mekanizmaları oluşturmamız gerekir. Bu mekanizmalar Yazılım Kalite Güvencesi kapsamına girer. Yani bir uyguladığımız metod var birde bu metodun doğru uygulanıp uygulanmadığını test edecek başka bir metod var. Örneğin çeşitli dökümanlar için belli şablonlar var ve bunlar kullanılarak dökümantasyon oluşturmanız gerekiyor. Ama tabii zaman içinde ekibin yada kişilerin karşı koyması ile bazılarını değiştirdiniz yada tamamı ile ortadan kaldırdınız. İşte o zaman metodoloji polisi gelip size hesap sorar.

Yazılım Geliştirme süreci içinde hangi metodu kullanırsak kullanalım, her adımdan sonra bir test koyarak üretilen materyallerin doğruluğunu ölçebiliriz. Kimi zaman müşteri, kimi zaman test ekipleri yada genel konuşmak gerekirse projede payı olan herkes bir nevi test yapmalıdır ki sonuçta üretilecek yazılım hem müşterinin ihtiyaçlarına tam olarak vecap verebilsin hemde yazılım olarak doğru çalışsın.

Örneğin Master of Software Engineering okurken Verification & Validation diye bir ders gördük. Bu derste V&V programlarını mevcut metodoloji içine nasıl entegre edeceğimizi, Risk yönetimini, Inspection yöntemlerini ve IEEE 829 kurallarını gördük. TQM konularına da girdik. Sonuçta elde ettiğim pratik yöntemleri günlük hayatımda kullanıyorum. Okuduğumuz kitaplardan bir tanesi “V&V of Modern Software Systems” yazarlar SchulmeyerveMacKenzie. Alıp okumanı tavsiye ederim.

Projenin boyutuna ve firmanın finansman yeterliliğine göre bence bir Quality Assurance uzmanı muhakkak gerekli. Firma içinde kullanılan yazılım geliştirme metodolojisini çok iyi bilmelidirler ki kalite kontrol aşamalarını entegre edebilsinler. Ayrıca projeya katkısı olan herkes ile doğrudan konuşurlar. Bu işin outsource (taşeron) edilmesi düşünülemeyecek bir konu. Hem fikirleriniz çalınabilir hemde taşeronun kalitesinden emin olamayabilirsiniz. QA uzmanı birden fazla projeye de bakıyor olabilir. QA uzmanını her türlü testleri yapacak kişi olarak görmemek lazım. Örneğin oturup kullanılabilirlik testlerini yapmaz. bunun için HCI uzmanları vardır. Ama kullanılabilirlik testlerinin sonuçlarını değerlendirmek kesinlikle işleri arasındadır.

Gereksinim Yönetimi için yazılımlar da mevcuttur. Gartner raporlarından "Agile Requirements Definition and Management Will Benefit Application Development" raporunda belirtilen yazılımları aynen listeliyorum.

En çok bilinen/kullanılan gereksinim yönetimi araçları

  1. IBM Rational Requisite Pro (Bunu kullandım fakat Rational SoDA olmadan raporlamak çok güç)
  2. Borland CaliberRM (Bunun bir de VS Team System eklentisi var, trial indirip kurdum harika bir şey)
  3. Serana Requirements / Traceability Management
  4. Telelogic DOORS

Daha az bilinen araçlar ise:

  1. Apptero 2004
  2. Axure Software Solutions Rapid Prototyper
  3. Compuware Reconcile (QA Center ve DevPartner ile kullanılıyor)
  4. Goda Software Analyst Pro
  5. iRise Application Simulator
  6. MKS Requirements 2005 (Integrity Manager ile)
  7. Sofea Profesy
  8. SpeeDev RM
  9. SteelTrace Catalyze
  10. TCP Integral Requisite Analyzer

Sistem Mühendisliği üzerine gereksinim yönetimi araçları:

  1. 3SL Cradle
  2. UGS Teamcenter
  3. ViewSet Pace
  4. 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 Smile. İsteyen olursa raporu e-posta ile gönderebilirim.

Gereksinimlerin toplanması ve yönetimindeki esneklik, yazılım geliştirme sürecinin ne kadar disiplinli olduğunu gösterir. Gereksinim toplama ve yönetme işlerini otomatize etmiş yazılım geliştirme firmaları değişiklik kontrolünü daha iyi destekler, testlerde verimlilik kazanır ve gelecekte ortaya çıkacak bakım ve değişiklik işlerinin yükünü azaltırlar.

Öte yandan kalite subjektif bir olgudur. Kişiden kişiye değişir. Bir kişinin sevdiğini diğeri beğenmez. Pirsig ikilemlerinde şöyle laflar geçer:

Eğer bir nesne kaliteli ise neden bilimsel araçlar ile kaliteyi ölçemiyoruz?

Eğer kalite subjektif ise ve sadece gözlemcinin kanısı ise o zaman kalite sadece neyi beğendiğinize verilecek şık bir sıfattır.

IEEE ise olaya biraz daha açıklık getirmiş:

Bir sistemin, modülün yada sürecin tanımlanmış gereksinimlere yada müşteri veya kullanıcı ihtiyaç ve beklentilerine uyma derecesidir.

Weinberg ise hataların bulunmadığı durumları kaliteli olarak varsaymıştır.

Umarım anlattıklarım yararlı olur yada daha fazla soru sormanız için zemin hazırlar.

Bugün benim doğum günüm. Tam 32 sene önce bugün dünyaya geldim. Türkçe blogumda da 100. yazım. Ç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.

  1. Senaryolar
  2. İş akışı diyagramları
  3. İş kuralları
  4. Hedef ve Kapsam belgesi
  5. Data definition diyagramları
  6. Dahili ve harici arayüz gereksinimleri
  7. Çeşitli UML diyagramları
  8. Sistem gereksinimleri spesifikasyonları
  9. Test senaryoları
  10. Prototipler
  11. Sürüm politikası
  12. Değişiklik istek belgesi
  13. Güvenlik politikası
  14. Risk dökümanı

Bu listeyi daha uzatmak mümkün. Bunlar ilk etapta aklıma gelen şeyler. Daha kod yazmaya geçmeden elimizde bir sürü döküman oluşuyor. Müşteri isteklerini değiştirebilir, yenilerini ekleyebilir veya bazı gereksiz gördüğü kısımları silebilir. Bu kadar fazla ürünün yönetilmesi kesinlikle mecburidir. Aksi takdirde ipin ucunu kaçırırsak ve bazı gereksinimleri müşterinin istediği gibi değiştirmezsek bu proje salıncak hikayesine döner.

Müşteri odaklı bir yazılım firmasının en büyük bilgi kaynağı müşteridir. Çünkü işi bilen ve her türlü girdi çıktısını tanımlayabilecek tek kişidir. Programı hatasız yazabilmek için müşteriyi sürecin her türlü aşamasına sokmanız gerekir ve müşterinin ağzından çıkan her türlü bilgi kayıt edilmeli ve iyi yönetilmelidir.

Bunlar yazılı döküman olduğuna göre rahatça bir kelime işlem programı (Word, wiki, Open Offıce vs.) ile hazırlayacağınız şablonları kullanarak belli bir biçimde kayıt edilmelerini sağlayabilirsiniz. Her türlü dökümanın bir şablonu olunca işler biraz daha kolaylaşır.

İkinci aşamada bunların sürüm kontrolünü yapmalısınız. Böylece kim ne değiştirmiş görmek mümkün olur. Örneğin wiki ortamında kimin ne değiştirdiğini görmek kolay olur yada Subversion gibi bir program ile sürüm kontrolünü yapabilirsiniz.

Değişikliklerin onaylanması içinde bir iş akışı düzenleyip belgelere uygulanacak değişikliklerin onaylanmasını sağlayabilirsiniz. Onay ya müşteriden yada bu iş ile ilgili firma içindeki birimden gelecektir. Değişiklik ancak onaylanırsa (değişiklik istek belgesi bu iş içindir) esas belge içine gömülür.

Son hali onaylanan belgeler üzerinde değişiklik istenirse; bu değişikliğin etkilediği diğer alanlar çok iyi tanımlanmalıdır. Eğer maliyeti ve zamanı arttıran bir değişiklik ise başka bir sürüme bırakılabilir. Bu da sürüm politikası belgesinde belirtilmelidir.

Her yazılan fonksiyonun hangi senaryoda nasıl kullanıldığını gösterecek akış şemaları ile koddan gereksinimlere doğru takibi kolaştıracak UML diyagramları oluşturmalısınız. İlk sürüm verildiğinde boşuna yazılmış kod var mı yada boşuna üretilmiş bir senaryo var mı analiz edebilirsiniz. Bu size ürettiğiniz ürünün gereksinimleri ne kadar kapsadığı hakkında bilgi verir.

Evet, toparlamak gerekirse gereksinim yönetimi çok önemli bir konu ve önümüzü görerek kod yazmak istiyorsak şart. Düşünün petrol yüklü bir tankeri yönetiyorsunuz ve sis içinde yol alıyorsunuz. Bir yere çarpsanız hem çevre kirliliğine hemde para kaybına neden olacaksınız. Ayrıca kaybedeceğiniz itibar da cabası. Böyle bir riski almaktansa bir iki radar sistemine yatırım yapmak yada sisin kaybolması için beklemek en akıllıca iş olur. Gereksinimleri akıllıca yönetirsek üstesinden gelemeyeceğimiz proje yok değil mi?

Açık kaynak yazılım üzerine podcasting yapan IT Conversations sitesinden bir kaç şovu dinliyordum. Şovların kalitesi çok iyi. Bilindiği gibi sitemde genelde Microsoft teknolojilerine üzerine yazıyorum fakat yazılım mühendisi olmamın verdiği sorumluluk ile her alandan bir şeyler burada göreceksiniz. IT Convesations sitesinden dinlediğim Larry Augustin'in "The Next Wave of Open Source : Applications - Açık Kaynak Dünyasında Bir Sonraki Dalga : Uygulamalar" isimli şovda serbest yazılım dünyasında önümüzdeki yıllarda karşımıza çıkacak ve mevcut ticari yazılım paketlerinden bahsediliyor. Serbest yazılım dünyasında işletim sistemi, derleyici gibi altyapıların artık oturduğu bir dönemde ticari yazılımların üretimine doğru kayılması oldukça normal bir durum.

Yazılım satın alacak bir firma için en önemli unsur bence mevcut sistemlere na kadar entegre olacağıdır. Burada sistem olarak bahsettiğim mevcut bilgisayar sistemleri yada işin işleyiş modelidir. Satış sonrası destek, fiyat, kullanılabilirlik daha sonra gelir. Bir firmanın Linux ortamında mevcut olan ticari yazılımları kullanabilmesi için tabii ki tüm alt yapısının Linux olması ve gerekli desteği ya içerden yada dışarıdan alıyor olması gerekir. Ne tür alt yapı kullanırsak kullanalım genede bir sistem yönetcisine ihtiyaç var nasıl olsa değil mi.

Pek çok yazılım -ticari veya serbest yazılım- ihtiyaçlardan doğar. Daha sonra kullanıcıların gereksinimlerine göre şekillenir. Ticari yazılımlarda gerçek kullanıcı ile yazılım arasında bazı bariyerler vardır. Her isteyen kurup deneyemez, gerekli eğitim, dökümantasyon serbest olarak mevcut değildir, çevrede kullanan bilgi alabileceğiniz fazla firma yoktur yada firmalar bu bilgileri açıklamaktan çekinirler. Bu günümüzde değişmeye başlayan bir model ama aşılması gereken pek çok bariyer daha mevcut. Serbest yazılım dünyasında ise yukarıda saydığımız bariyerler yok fakat bu seferde fonksiyonellik açısından bir fazlalık var ve buda kullanılabilirliği azaltan bir faktör. Ayrıca geliştirme platformlarının çokluğu gene kullanıcının kafasını karıştıran bir etken. Diğer bir etkende açık kaynak yazılımların birlikte çalışabilmesi için harcanacak zaman ve naktin miktarı.

Bence çeşitli standartlar oluşturulmalı ve verinin bütünlülüğü sağlanmalıdır. Örneğin müşteri tablosu her yazılımda aynı isimle ve aynı sahalar ile tanımlanmalıdır. Tabii ki böyle bir standardı yazılım dünyasında oturtmak pek mümkün değil. Her yazılım kendi içinde küçük bir dünya ve kendi kurallarına göre yönetiliyor. Neyse konuyu dağıtmayalım...

Bir kaç serbest yazılımı birleştirip ortaya çıkaracağınız biri ürünü satabilir ve desteğini verebilirsiniz. Güzel bir iş modeli ama başlangıç aşamasında biraz zorlanabilirsiniz. Biraz dikkat ve koyacağınız kurallar ile bunları aşmak mümkün. Nedir bu zorluklar:

  1. Türkçe döküman eksikliği
  2. Entegrasyon
  3. Sürüm kontrolü
  4. Kurulum zorlukları
  5. Marka eksikliği
  6. Fonksiyon fazlalılığı
  7. Müşteri güveni oluşturma

Genelde serbest yazılım projelerinde Türkçe döküman bulmak zordur yada arayüzleri Türkçeleştirmek gerekir. Sıkı ve temiz bir çalışma gerektirecek bir alan. Özellikle bu alanda üretilen çıktının çok iyi test edilmesi ve yazım, imla vs. hataların giderilmesi gerekir. Yardım dosyalarının da Türkçeleştirilmesi ve kullanıcıya sunulması şarttır. Bir diğer konuda eğitim dökümanları ve kullanıcıya verilecek eğitimlerin şekillendirilmesi.

Entegrasyon pek çok açıdan ele alınabilir. Kullandığınız açık kaynak yazılımların entegrasyonu, mevcut sistemlerle entegrasyon, işleme modeli ile entegrasyon vb. gibi. Sistemler arası veri alışverişinin çok iyi analiz edilmesi ve her türlü senaryonun test edilmesi gerekir.

Kullandığınız açık kaynak yazılımlar yeni sürümler verdikçe sizinde bunları uygulamanız gerekiyor mu araştırmanız lazım. Örneğin bir kere entegrasyon ile ilgili kodu yazdıktan sonra sürümleri değiştirmek istemeyebilirsiniz (aslında bu olay modüler bir yapıda kod yazmadığınızı gösterir). Kendi içinizde de bu sürüm kontrolünü Subversion gibi bir programla çözebilirsiniz.

Kurulum için gerekecek programı sizin yazmanız gerekecektir. Bir kaç açık kaynak programı birleştirdiğiniz için kurulum da size özel olacaktır. Mümkün olduğu kadar kurulum olayını otomatikleştirmek ve sistemin çalışması için elle müdahale edilecek adımları azaltmanız gerekir. Kurulum aşaması bir açık kaynak proje için çok önemlidir çünkü kullanıcı ilk kurulum ile başlar ve ilk izlenimler burada ortaya çıkar. Sistem destek uzmanları için de ne kadar az müdahale edilirse o kadar iyidir.

Gereksiz fonksiyonları kırparak müşteriye tam istediği çözümü vermeliyiz. Zaten fazla fonksiyon olması sizinde başınızı ağrıtır. Zaman ilerledikçe bu fonksiyonları işleme koyabilir

Bazı potansiyel müşterilerin programı pilot olarak kurup denemelerini sağlayın. Böylece programın kendi işlerine yaradığını daha net görürler ve açık kaynak yazılımlara karşı şüphelerini giderebilirler. Bir iki satıştan sonra müşterileri bir araya toplayacak toplantılar düzenleyip fikir alışverişinde bulunmalarını sağlayabilirsiniz. Sizin hiç ummadığınız bir özelliği farklı şekillerde kullanan müşteriler çıkabilir.

İşte size mis gibi iş modeli. Yazılacak minimum kod ile bir ürüne sahip olmak ve bunu pazarlamak ne kadar kolay değil mi? Satış sonrası destek ve eğitim konularınıda hallettiniz mi piyasada uzun yıllar kalacak bir firma sahibi oldunuz demektir.




Microsoft sanırım Sourceforge'un sonunu getirmeye yemin etmiş. Son bir kaç aydır bir mağarada yaşamıyorsanız Team Foundation Server platformunu duymuşsunuzdur. Projelerin başından sonuna kadar her türlü ürettiği materyali bir arada tutacak ve ekip içinde birlikte çalışmayı sağlayacak bir platform.

CodePlex ise bu platformu arkasına alarak C# ve .NET2.0 ile yazılmış bir açık kaynak proje barındırma sitesi. Tabii ki kullanabilmek için en azından VS2005 ve Team Explorer kurulu olması gerekiyor. Team Explorer siteden indirilebilsede VS2005 zor. Denemedim ama belki express sürümleri ile bu indireceğiniz Team Explorer beraber çalışıyor olabilir. Entegre olmasada ayrı ayrı kullanabilirsiniz. Express sürümleri artık tamamı ile ücretsiz. İstediğinizi indirip hemen kullanmaya ve ticari programlar geliştirmeye başlayabilirsiniz.

Şimdiye kadar Sourceforge'u kullanmış olanlar bunu da bir deneyebilir.
Şu http://www.myheritage.com sitesini duydunuz mu? Epeyden beri şöyle güzel bir resmimi çekip denemek istiyordum. Dandik bir iki resmim vardı, onlar pek iyi sonuç vermemişti.

Son yaptığım denemede Patrcik Swayze ile Gallerin Prensi William arası bir şey çıktım. İşte sonuçlar. Gidip mirastan payımı isteyeyim bare.



Birde http://www.email2face.com sitesi var. Bunlar email adreslerini fotolar ile birleştiriyor. Sitede gurkan DOT yeniceri AT gmail DOT com adresi ile aratırsanız benim resmimi bulabilirsiniz. Subtext yakın zamanda bunların web servisini kullanarak yorum bırakan kişilerin resimlerinin görüntülenmesini sağlayacak bir eklentiye sahip olacak. Böylece kimlerin yorum bıraktığını daha iyi göreceğiz. Sizde muhakkak ekleyin resminizi bu servise.


Google Reader ile bir araya topladığım bloglara sitenin sağ tarafındaki menülerden ulaşabilirsiniz (RSS'den okuyanlar için).

Kimler var:

  1. Barbaros Yeniceri
  2. Cem SISMAN
  3. Cengiz HAN
  4. Dinçer Özturan
  5. Elifnur Güner
  6. Kıvanç Özüölmez
  7. Mehmet EMRE
  8. Mustafa Acungil
  9. Mehmet Nuri Çankaya
  10. Tamer Öz
  11. Ferruh Mavituna
  12. Hus Weblog
  13. Sefer Algan'ın Günlüğü
  14. PPM-Türkiye Proje ve Süreç Yönetimi
  15. Proje Yönetimi
  16. sanalBellek
  17. Fahrettin Mehmet Öztürk
  18. TeknoTurk
  19. .NET Developer
  20. Volkan Uzun
  21. BİLGİ GÜVENLİĞİ
  22. Burhanmt
  23. Yilmaz
  24. Tarık Bağrıyanık
  25. ve ben
Eklememi istediğiniz bloglar varsa bana RSS ve adresini gönderin lütfen. Google Reader kullanarak şu adresten okuyabilir yada opml dosyasını indirebilirsiniz.

Aşağıdaki kodu kullanarak sitenize de ekleyebilirsiniz.


<script type="text/javascript" src="http://www.google.com/reader/ui/publisher.js"></script>
<script type="text/javascript" src="http://www.google.com/reader/public/javascript/user/05324011784812826084/label/turk?n=10&callback=GRC_p(%7Bc%3A'slate'%2Ct%3A'Bir A&#287;&#305;zdan'%2Cs%3A'true'%7D)%3Bnew%20GRC"></script>


Not: Sitenin dizaynından Google reader kutusunu çıkarmak zorunda kaldım. Firefox kabul etti ama IE kabul etmedi.

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 dizaynları, bazı iş akışları, web temaları vardır. Tüm bu malzeme proje daha ortada yokken hazırdır. Mesela kek yaparken yumurta kullanıyoruz ama oturup yumurtayı yeni baştan üretmiyoruz di mi? Zaten çok zor olurdu, önce tavuk mu üreticez yoksa yumurta mı?

Öncelikle refactoring olayından başlayalım. Sadece yazılan kod için değil, projenin her aşamasında kullanılabilecek bir yöntem. Refactoring üretilen parçanın daha kolay anlaşılması, bakımının kolaylaştırılması, hızlandırılması, gereksiz yerlerinin kırpılması, dökümantasyonunun iyileştirilmesi adına yapılacak bir dizi işlemdir. Tek düşünmeniz gereken bu parçayı sizden sonra başka projelerde kullanacak kişilerin yardıma ihitiyacı olmadan (ve size küfür etmeden) rahatça kullanabilmesi ve performansının düşmemesidir.

Örneğin bir döküman şablonunu ele alalım. Projenin başında senaryoları yazarken Word'ü açıp Allah ne verdiyse yazıyordunuz. Sonradan farkettiniz ki aslında her senaryo için belli başlıklar var ve hepsinde ortak kullanılıyor (farklı isimlerde olsa bile). Bir Word şablonu oluşturup herkesin bunu kullanmasını sağlarsanız, firma içi iletişim 10 kaplan gücünde olacaktır ki Agile programlama yapanlar için baş kurallardan bir tanesidir.

Yada yazdığınız bir fonksiyonu düşünün. Hani yapmazsınız ama; ilk yazdığınızda çok uzun ve karmaşık bir algoritma kullanmış olun. Sizden sonra gelen programcılar şöyle diyecektir. "Ağbi NASA'da rocket science üzerine çalıştım, fezaya 10 tane roket gönderdim, ama böyle karmaşık bir algoritma ne gördüm nede duydum". Böyle konuşmalar duymak istemiyorsanız yazdığınız fonksiyonu parçalara bölüp yeniden düzenlemeniz, belki bir kaç pattern kullanmanız, bir arayüzde çeşitli fonksiyonları toplamanız, algoritmaları hızlandırmanız ve ünite testlerini genişletmeniz gerekir.

Refactoring genelde sürümleri verdikten sonra yapılır. İlk sürümü verip müşteriyi memnun ettikten sonra oturup daha iyi nasıl yapabilirim diye düşünmek, biraz kafa patlatmak ve ünite testlerini bozmadan yeniden yapılandırmaya gidebilirsiniz. Böylece ürün daha kolay anlaşılır, bakımı kolay ve yeni özelliklerin rahatça eklenebileceği bir hal alır ki hem sizin için hemde sizden sonra gelecekler için sağlam bir alt yapı olur. Bir sonraki projenizi yaparken bu alt yapıları kullanır, üretim zamanını yarıya indirebilirsiniz.

İşte Reusing bu aşamada devreye giriyor. Dizayn Pattern'leri, hazır modüller, temalar, şablonlar, program parçaları, fonksiyonlar, testler ve aklınıza gelebilecek daha pek çok şey tekrar kullanılabilir. Oturup koca bir güvenlik modülünü tekrardan yazmaktansa bir önceki projede yazdığınız güvenlik modülünü refactoring yaparak yeniden kullanılabilir hale getirmek daha kısa sürecektir.

Kural olarak; yazdığınız bir fonksiyonun tekrar kullanılabileceğini tahmin ediyorsanız, refactoring yapmanız şarttır. Böylece üretim maliyetlerini azaltmış oluruz. Firmanın büyüklüğü yada projelerin sayısıda sizin için bir kıstas olmasın. Zaten topu topu iki projemiz var refactoring ile zaman harcamaya gerek yok diye düşünebilirsiniz. Fakat daha fazla projeler almak, projeleri zamanında teslim etmek, büyümek ve uzun süreli bir firma olma vizyonumuz varsa bu yöntemleri muhakkak kullanmamız gerekir. Böylece piyasada adından iyi söz edilen, köklü bir firma olursunuz.

Ben her zaman değişimden ve yenilikten yanayım. 10 senedir kullanılan iş süreçlerini değiştirmekten kaçınmam. Tabii ki öncesinde bir analiz ve maliyet-fayda analizi yaparım. Bir heykeltıraş gibi olanı yontmayı veya yeni şeyler ekleyerek geliştirmeyi her zaman düşünürüm. Biraz sanat biraz da mühendislik ile daha iyisini daha kısa zamanda üretmek için yollar ararım. Örneğin açık kaynak projelerde sizin kullanabileceğiniz bir sürü modül olabilir. Birileri sizin yaşadığınız problemleri zaten yaşamış ve çözmüşdür. Hatta o çözümleri refactoring yaparak herkesin kullanabileceği hale bile getirmiştir. Arayıp bulmak size kalıyor.

Yazılım Uzmanı olarak sizin kariyeriniz için de iyi olan tarafları var. Öncelikle yöntemleri öğreniyorsunuz, bunları tekrar uygulamak sizin için çocuk oyuncağı olacaktır. Özgeçmişinize refactoring ve reusing sonucu firmanıza ne kadar yarar sağladığınızı yazabilirsiniz. Örneğin "Falan projede uyguladığım refactoring ve reusing yöntemleri ile görevlerimi %30 daha az zamanda bitirdim. Projenin tamamlanma sürecini de %15 hızlandırdım" gibi. Bu tür başarılar yazacağınız ön kapakta çok yararlı olur. Bold yazılmış kelimelerde dikkati çekmek için iyi bir yöntemdir. Ama lütfen dürüst olmaya özen gösterin.

Hepinize bu yolda kolay gelsin.



Şu SlickRun programını duydunuz mu bilmiyorum. Örneğin Outlook'u çalıştırmak istiyorsanız "mail" yazıp enter'a basmanız yeterli. Ayrıca MagicWord paketleri hazırlayıp istediğiniz programları herhangi bir isimle çağırmanız mümkün.


Bana yararlı bir programcık gibi geldi. Belki sizinde işinize yarar.
Proje geliştirme sürecinde analistlerin yazdığı spesifikasyonları kodlamaya geçtiğimizde bir sürü hata meydana çıkar. Genelde hatalar da komünikasyon eksikliklerinden oluşur. Bunu önlemek için tüm proje ekibinizi bir UML ve iş süreci eğitimine gönderebilirsiniz. Böylece herkes aynı dili konuşuyor olur ve birbirlerini anlarlar. Tabii başlarına bir de denetçi dikip bu standartların uygulanıp uygulanmadığından da emin olmanız gerekir.

Microsoft biraz daha ileri giderek bu işleyiş mekanizmasını sürecin içine yerleştirmeye çalışmış. Şu adresten indireceğiniz VS2005 eklentisi ile analistlerin yada iş mimarlarının sistemi inşa ederken oluşturacakları her türlü yeniden kullanılabilir modülü (framework, component ve hatta patternler) hazırlayabiliyorsunuz. Yazılım mühendisleri bu oluşturulan modülleri kullanarak yazılıma geçeceği için süreç tamamı ile uygulanmış oluyor. Böylece CMMI sertifikası alma yolunda biraz daha ilerlemiş oluyoruz. Ayrıca sanırım test aşamalarında da süper kolaylık sağlıyordur.

Ayrıca GAT ile çeşitli yazılım geliştirme süreçleri hazırlayıp bunların GAE ile kullanabilir ve proje ekibi içinde daha akışkan bir haberleşme sağlayabilirsiniz. TFS alacak kadar finansmanı olmayan yada proje ekibi küçük olan yerler için ideal bir yöntem. Ayrıca tamamı ile VS2005 içine entegre olmuş olması çok güzel.

Şu anda Mainframe üzerinde bir kaç program yazıyorum. Standartlar dahilinde program yazmak için bir Word dosyası, iki adet Excel dosyası, programı yazdığım IDE, Mainframe konsolu, derleme programı, DB2 erişim konsolu bir kaç text dosya ve debugger açık durumda. Bazıları sadece süreci takip etmek için açık ve hafızada kapladığı alanı siz tahmin edin artık. Her türlü aracın (süreç platformu dahil) bir IDE içinde olması sanırım erişilebilirlik açısında büyük zaman kazandıracaktır.

Bende bu araçları yeni indirdim. Anlattığım şeylerde eksik yada yanlış olabilir. Yakın zamanda GAT ve GAE ile ilgili bir kaç uygulamayı siteye koyacağım.
Microsoft Consolas font paketini Visual Studio kullanıcıları için bedava indirime sundu. Vakit kaybetmeden bu linkden indirin. Ben daha evvel Trebuchet kullanıyordum ama sonradan anladım ki aslında gözlerim normalden fazla yoruluyor. 6 ay kullanım sonunda göz muayenesinden geçemedim. Consolas biraz daha okuması kolay ve gözü yormuyor yada bana öyle geliyor.

Laptopa XP kurduğumdan beri Clear Type olayından daha fazla verim alıyorum sanki. Şu adresden Clear Type appletini indirebilirsiniz. Consolas kullanmaya karar verirseniz muhakkak Clear Type ayarlarını yapın.

MBS Bilişimde çalışırken şunlardan bir tane olsaydı projeyi belkide zamanında bitirirdik. puhahahahaha

When your company installs one of these babies for you.

A Desk that converts into a bed

Via Boing Boing

Come to think of it, I could have used that in the past.

[Via you've been HAACKED]

Bilig Teknolojileri alanında kariyer yapmak isteyen gençlere bir kaç öğüt. Diğer okuduğum bloglardan ve kendi deneyimlerimden derledim.

Rahatlık kariyerinizi öldürür. Eğer zorlanmadığınız bir alanda uzun zamandır çalışıyorsanız her üç ayda bir özgeçmişinize yeni bir hüner ekleyebilmeye dikkat edin. Eğer ilk üç ayda yeni bir şey ekleyemezseniz ikinci üç ayda mutlaka yeni bir şeyler ekleyebilin. Eğer çalıştığınız yerde yeni şeyler öğrenmeye fırsat yoksa açık kaynak projelere katılabilir ve boş durmadığınızı kanıtlayabilirsiniz. Ben bazen eğitimlere katılıyorum bazende açık kaynak projelere yardımda bulunuyorum. Yada yeni bir ürünün kurulum konfigürasyon adımlarını araştırıyorum.

Kariyerinize karar verin. Hedeflerin belirlenmesi bu hedeflere ulaşılabilmesi için atılacak ilk adımdır. Hangi projeye girersem benim için en iyisi olur, o projeden neler öğreneceğim ve proje sonunda özgeçmişime neler ekleyebilirim gibi soruları kendinize sorun. Eğer firma içindeki kaymalardan dolayı, size hiç bir şey katmayacak bir projeye katıldıysanız artık o firmadan ayrılmanın vakti gelmiş demektir. Genelde bu durumlarda firma sahipleri çeşitli teşvik veya vaatlerle sizi projede tutmaya çalışabilirler fakat kariyeriniz daha önemlidir. Ben Türkiye’de çalışırken yurt dışında çalışmak aklımın ucundan bile geçmezdi. Ya tutarsa diye özgeçmişimi gönderdiğim bir firma beni cepten arayınca epey bir şok olmuştum. 1 ay sonra yeni işimde başladım ve kariyerim için çok iyi oldu.

Taşeron işler hayatın bir gerçeğidir. Kapitalist sistemlerde işler yüksek maliyetli bölgelerden düşük maliyetli bölgelere doğru kayar. Tabii ki taşeronun kalitesi yönetim açısından kabul edilebilir ise. Bir firma için kabul edilebilir olan kalite seviyesi diğer bir firma için kabul edilmeyebilir. Eğer işlerin taşeron firmalara kayacağını sezinlerseniz o işten hemen ayrılın. Yada kendinizin başka bir firmaya kiralanacağını sezinlediğiniz zaman vakit gelmiş demektir.

İşe girerken imzaladığınız anlaşmalara dikkat edin. Piyasada elinizi kolunuzu bağlayacak anlaşmaları imzalamaktan çekinin. Sizin özgürlüğünüze saygı duymayan bir firmada nasıl çalışabilirsinizki. Eminim o firma e-postaları ve messenger loglarınıda okuyordur.

Hayatınızı tamamı ile iş bulma ajanslarına bağlamayın. İş bulma ajanslarının her zaman iyi bağlantıları olmayabilir. Sadece özgeçmişleri gönderecekleri birer e-posta adresleri vardır. İş değiştirmede en büyük yardımcı bence fuar ve toplantılardır. İnsanlarla yüz yüze konuşup iyi izlenimler bırakma olanağı en çok bu tür organizasyonlarda ortaya çıkar. Ayrıca kişisel bir kart bastırıp kontak bilgilerinizi dağıtmanız da iyi olur. Ürünleri görüp deneyebileceğiniz, deneme sürümlerini alabileceğiniz ve bilgiyi ilk ağızdan duyacağınız yegane yer fuarlardır.

E-posta çok ucuz bir yöntem. Kariyer.net gibi sitelerde iş ilanı veren kuruluşlar geriye çok fazla e-posta alırlar ve sizin e-postanızın okunma şansı yok denecek kadar azdır. Ayrıca iş başvurusu yapan kişiler iş için gerekli yeteneklere sahip olmasalar dahi özgeçmiş gönderirler. Buda okunacak bir sürü e-posta anlamına geliyor. İş başvurularında eski yöntemleri denemek iyi sonuç verebilir. Önce özgeçmişinizi güzel bir kağıda basın ve dosyalayın. Bir ön yazı yazıp neden o firmada çalışmak istediğinizi anlatın. Takım elbisenizi giyip saçınızı düzeltin ve firmanın yolunu tutun. Böylece insan kaynakları ile doğrudan görüşmüş ve belkide iyi bir izlenim uyandırmış olursunuz. İşe alınmasanız bile akılda kalacağınız garantidir. Ben 98 yılında ilk mezun olduğunda gelen ilk Bilişim fuarına gittim. Amaç katılan firmalar kitapçığını almaktı. Fuarı bile gezmedim. Eve gelip fax programımı açtım ve sanıyorum 75 tane firmanın fax numarasını tek tek kaydettim. Birde Word’de özgeçmiş hazırlamıştım. Programın Auto-Send özelliği ile 70 kadar firmaya özgeçmiş gönderdim. Ertesi gün sanırım 20-25 kadar telefon aldım, Hepside görüşmek istiyordu. Tabii bunları organize etmek için bir ajanda kullanmam gerekti. Aynı semtte olanları aynı günlere peş peşe koymaya çalışmıştım. Sonuçta bir tanesine girdim ve başladım çalışmaya. O yıllarda önemli olan para değildi sadece deneyim yapmamın gerektiğini biliyordum bu yüzden maaşı önemsemedim. 2 sene sonra ise artık ben Bilişim fuarında görevli olarak yer almaktaydım.

Çevre oluşturmak için blog yazmak ve kullanıcı grubu toplantılarına katılmakta çok önemlidir. Eğer çevrenizde belli bir kullanıcı grubu yoksa bir tane siz başlatabilirsiniz. Çevre oluşturmak için her türlü fırsatı değerlendirmeye bakın.

Sevdiğiniz işi yapın, para arkasından gelecektir. Piyasada çok insan gördüm sırf programcılık iyi para veriyor diye programcı olan. Tabii zaman içinde kaybolup gittiler bu kişiler. Programcılık yapamasanızda IT alanında yapılacak pek çok iş seçeneği var. Örneğin sistem analisti, modelleme uzmanı, sistem yöneticisi, proje yöneticisi vs. Herhangi birini seçip kariyerinize o yönde şekil vermelisiniz.

Beta ve deneme sürümleri ile yeni şeyler öğrenmeye başlayabilirsiniz. Eğer eski teknolojilerde bir şeyler yazıyorsanız (ASP, VB6, COBOL vs.) yeni teknolojileri takip edin ve bir sonraki trendin ne olacağını önceden sezinlemeye çalışın. Böylece yeni teknolojiler piyasaya çıktığında sizde en az diğerleri kadar bilgili olacaksınız. Tabii bu durum eski firmanızı bırakmanıza neden olabilir ama zaten siz o firmada eski teknolojileri bilen kişi olarak tanınıyorsunuz ve bu önyargıyı kırmak biraz zor en iyisi ayrılmak ve yeniden başlamak. Tek dezavantajı yeni teknolojiyi öğrenmek için iş saatleri dışında zaman harcamanız gerekliliği fakat kariyerinizin bir atlama yapması için sanıyorum bu gerekli. Eski teknolojileri bilmek bir avantajda olabilir. Eğer sizden başka tamir edecek kimse yoksa kısa kontrat usulü çalışabilirsiniz. Ürünü tamir eder, ücretinizi tahsil eder ve olaydan çekilirsiniz.

Kariyer için daha söyleyecek çok şeyim var. Başka bir yazıda onlarıda yazacağım.


Colin kardeşin bu yazdığı fıstık gibi program ile Subversion kod kütüphanesinden RSS çıktıları üretmek mümkün. Ben niye daha önce düşünemedim dedirtiyor insana valla.

RSS ile coğrafik olarak dağılmış proje ekibinize daha hızlı biligi ulaştırabilirsiniz. Fırefox'unda bir Cruise Control eklentisi var biliyorsunuz ama direk Subversion'dan değişiklikleri görmek çok daha hızlı olur.

Sanırım bu Colin'in yaptığı programı Sourceforge üzerinde de kullanabilmek mümkün. Bizim proje yöneticisi Phil bunu yapmayı deneyecek. Bakalım göreceğiz olacak mı?

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