Search Results for: iş bulmak

Analist ve İş Bilgisi

İş ve İhtiyaç Analizi, Yazılım Mühendisliği , , ,

Giriş

Soru şu: Analist yani bazen iş analisti, bazen ihtiyaç ya da gereksinim analisti bazen de daha klasik bir isimlendirmeyle sistem analisti dediğimiz rol için iş bilgisi ne kadar önemlidir? “Hoppaaa! Böyle de soru mu olur?” demeyin. Ben de farkındayım, iş bilgisinin, analistin varlık sebebi olduğunun. Analistin en temel sorumluluğudur iş bilgisi, tamam da demek istediğim şeyi açıpa çıkarabilmek için şu soruyu da sorayım: Analistin, benzer şekilde iş bilgisine sahip operasyonel bir kullanıcıdan farkı yok mudur? Vardır deriz ama nedir tam olarak bu fark? Daha analitik olması, daha iyi sorular sorabilmesi, ya da iletişiminin daha güçlü olması mıdır sadece?

Analist Yetkinlikleri

Konuyu biraz açayım. Analistin yetkinlikleri 3 boyutta ele alınabilir:

  1. İş alanı bilgi ve yetkinlikleri (business/application domain knowledge and skills): Analistin çalıştığı sektördeki terimlere, süreçlere, rollere ve çıktılara ne kadar hakim olduğu, onun iş bilgisinin ölçüsüdür. Örneğin bankacılık sektöründeki bir analistin çalıştığı alt alanın krediler olduğunu düşünelim. Bu analist, kredilerle ilgili başvuru ve değerlendirme süreçlerini bilmesi, bunlarla alakalı analiz toplantılarında bulunması vb. yetkinlikler, analistin iş alanı ile ilgili yetkinliklerine örnektir.
  2. İş ve yazılım ihtiyaç analizi bilgi ve yetkinlikleri (business and software requirements analysis knowledge and skills): Analistin, formal olarak bir süreci tanımlayabilme, oradaki adımları, iş kurallarını ve aktörleri detaylarıyla belirleyebilme, detaylar arasındaki benzerlik, farklılık, çelişiklik vb. çıkarımları yapabilme, bu bilgileri bir yazılıma dönüştürebilecek şekilde daha formal ve matematiksel formlara örneğin diyagramlara dökebilme, ihtiyaçlarla alakalı önceliklendirme ve risk analizi yapabilme ve tüm bunları dokümana yansıtma yetkinlikleri.
  3. Bireysel yetkinlikler (individual skills): İletişim, ikna, sorgulama, toplantı yönetimi vb. daha yumuşak yetkinlikler (soft skills). Örneğin bir analistin iyi bir dinleyici olması, iyi not alabilmesi, hızlı ve analitik düşünüp çıkarımlarda bulunarak bir analiz toplantısında geri sorularla muhatabını yönlendirebilmesi, çatışan ihtiyaçlara sahip kullanıcılar arasında inisiyatif alabilmesi, onları yönlendirmesi ve karar verilmesini sağlayacak girdileri sunabilmesi vs. bu türden yetkinliklerdendir.

Yukarıdaki 3 farklı yetkinlik alanından hangisi sizce en önemli olandır? İş bilgisi mi, işi çözümleyebilme yetkinlikleri mi yoksa müşteriyle daha iyi iletişim kurabilme yetkinlikleri mi?

Ülkemizde eğitim ve danışmanlık vesilesiyle gittiğim yerlerde bunu devamlı gözlemliyorum. Hatta ben de, tam zamanlı çalışırken ya da sonrasında danışmanlıklarda, uzun seneler analist işe alımıyla uğraştım ve uğraşıyorum. Dolayısıyla analist işe alma ve seçme süreçlerinden haberdarım. Özellikle eğitimlerde ve seminerlerde katılımcılara soruyorum, sizin kurumunuzda hangisi daha çok öne çıkıyor diye. Örneğin, “siz buraya hangi yetkinliklerinizle alındığınızı düşünüyorsunuz?” diye soruyorum. Elde ettiğim kanı şu: Ülkemizde analist denince akla gelen en temel şey, iş bilgisidir. Tabiri caizse, işi bilmek, o sektörde senelerdir bulunmuş olmak, genel olarak bir kişiyi analist olarak tanımlamada kullanılan en temel etmendir. İkinci sırada gelen, bireysel yetkinliklerdir. Yani iletişimi güçlü mü, müşterilerle konuşurken ne kadar düzgün cümleler kurabiliyor vs. Bu iki yetkinliği bir araya getirdiğimizde, işi bilen ve iletişimi güçlü kişi, ülkemizde mükemmel analist adayıdır. Kurumlar kendi kültürlerine göre bu iki faktörden birisine daha fazla önem verebilirler. Yani örneğin bir kurum, özellikle daha az tecrübe seviyelerinde, iletişim becerileri güçlü bir adayın zekasına da güvenerek, iş bilgisini hızlıca elde edebileceğini düşünerek onu analist olarak işe alabilir.

Bu yazıyı yazdığıma göre benim de kendi fikrimi belirtmem gerekir. Bence bir analistin en temel yetkinliği, rolüne adını veren, iş ve yazılım ihtiyaçları analizi bilgi ve yetkinlikleridir. Bir analist, her şeyden önce, bir süreci nasıl ifade edeceğini, o süreçteki tüm adımları, aktiviteleri, aralarındaki ilişkileri, çıktıları, süreçte yer alan rolleri ya da aktörleri, süreçler arasındaki ilişkileri, süreçleri yönlendiren iş kurallarını vs. ortaya koymakla sorumludur. Bu yetkinlikler, tabi olarak farklı sektörlerde edinilen tecrübeyle kazanılır ama nihayetinde sektörden bağımsızdır. Bir örnek vereyim: Bir süreçte, durumu önemli olan ve farklı durumlar arasında gezen temel bir nesne var. Örneğin bir başvuru sürecinde, başvurunun pek çok duruma sahip olması, buna iyi bir örnektir. Başvuru ilk defa alınmış olabilir, ön elemeyi geçmiş, evrakları bekleniyor, son incelemede, vb. durumların birinde olabilir. Tüm bu durumların, sonlu durumlu bir makina (finite-state machine) olarak ortaya konması, yani durumlar ve aralarındaki geçişlerin detaylı olarak ortaya belirlenmesi yetkinliği, ne bir iş bilgisi ne de iletişim yetkinliğidir. Bu yetkinlik, analisti en temelde analist yapan şeydir. Böyle bir modelleme yetkinliğine sahip bir analist, herhangi bir iş alanında sonlu durum makina modellemesi yapabilir, oluşturduğu modelin tasarımda bir durum tasarım kalıbıyla (state design pattern) tasarlanmasını sağlayabilir ve nihayetinde de developerlar dahil herkes kendisine duacı olur. Çünkü böyle çok durumlu nesneler, kodlamada en problemli nesnelerdir, sebebi ise iş bilgisi çok yüksek olsa bile analistin bu durumları formal bir şekile çözümleyip ifade etmemiş ya da edememiş olması, açıkçası, ne tasarıma ne de programlamaya bir katkı sunmaz.

Nasıl her iş alanı, apayrı süreçleri ve iş kuralları olan bir alan (domain) ise, iş ve yazılım ihtiyaçları mühendisliği (business and software requirements engineering) de apayrı bir iş ve uzmanlık alanıdır. Bu alanın da kendine göre süreçleri, iş kuralları, çalışmaları ve çıktıları vardır. Bu alanın çalışanlarının da kendisine has yetkinlikleri, yaptıkları işleri ve ürettikleri çıktıları vardır.

İş bilgisini çözümleme yetkinliklerine sahip olmayan bir analist ancak postacı olur. Ya da analistlerin kafasına kazındığı şekliyle sadece “köprü” olmaya devam eder, tek yaptığı “al-ver”dir, ne çözümleyici olmak söz konusudur ne de bir katma değer ortaya koymak. Böyle ortamlarda zaten iş bilgisi de malumattan öteye gitmez, bilgi seviyesine çıkamaz çünkü. O ortamda senelerce çalışsanız bile hala aklınızdaki iş bilgisini bir başkasına aktarabilir hale getirmekte güçlük çekersiniz. Aktarsanız bile karşı tarafı zorlarsınız çünkü standart ve verimli yöntemleri kullanmazsınız. Çözümleme süreç ve tekniklerinden haberdar olmayan bir analist iğne oyası gibi malumatla uğraşır, onlar arasında kaybolur. Analistten beklenen, bir soru karşısında “hikmet” (wisdom) seviyesinde katkıda bulunmasıdır ama o ekranın şurasındaki bir arayüz elemanın üzerinden konuşur. Ondan beklenen, iki farklı durumu birbiriyle kıyaslayıp, etki analizi vs. yapmaktır ama o bunu sağlıklı bir şekilde yapamaz çünkü kafasında sistemli ilişkiler değil, malumat bulutları vardır. Ama unutmayın, buradaki temel sorun analistten ziyade, kurumdadır. Analiz çalışmalarında “analitik” olmayan bir kurum, analistinin çözümleme süreç ve tekniklerinden haberdar olmasını da isteyemez çünkü bu konuda fikri yoktur.

İş bilgisi, tabi olarak bir analist için önemlidir, sistemli bilgiyi hazmetmek çok daha kolaydır. İş bilgisine sahip bir analist daha hızlı iş yapar, daha rahat ve doğru davranır. Müşterisiyle daha rahat iletişime geçer ve ona güven verir. Ama iş bilgisi, bilgi olursa işe yarar, değilse, bir malumat yığınından ibaretse, vakit kaybettiren bir stres unsuru olur. Ve analistin yeterince teknik çalışmaması, bu malumatı sadece büyütür, bilgiye çevirmez.

İşte, bir analisti, operasyonel kullanıcıdan temelde farklı kılan şey, formal bir çözümlemeci disipline sahip olmasıdır. Analitik düşünebilen, işini gözlemleyen, baştan sonra kavramaya çalışan operasyonel çalışanların analist olmaları iyi bir şeydir, çözümleme ve modelleme tekniklerini öğrenmeleri kaydıyla.

Ülkemizdeki Durum

Ülkemizde sistemli iş bilgisi biriktiren kurumlar maalesef pek azlar. İşini en detayına kadar anlatabilecek bırakın operasyonel kullanıcıyı, iş birimi sorumlusu, müdürü bulmak bile şanstır bu ülkede. Amerika’dan ilk döndüğüm zamanlardı, ilk projelerimin birinde, sürecin sahibi olan birim müdürüyle analiz amaçlı bir araya gelmiştik. Müdür, daha toplantının başında, süreçlerle ilgili olarak analizi BT’deki programcılarla yapmamızı istemişti bizden! Zaten toplantıda bir de tecrübeli programcı vardı. Aynı kurum agile ödülleri almaya devam ediyor, şatafatlı uluslararası danışmanlık şirketleriyle 3-5 senede bir süreç çalışması yapıyor vs. Ama gidin sorun bakalım, müşteri memnuniyeti artıyor mu? Ya da bugların sayısında azalma olmuş mu? Ya da ya da developerlar, kendilerine gelen analiz dokümanlarından memnunlar mı? Örneğin şöyle tipik durumlar olur ülkemizde: Kurumlar agile metodolojilere geçtiklerini söylerler ama hala hantaldırlar, hala çıktılarının kalitesi kötüdür, hala başarı kişilerin özveriyle çalışmalarına bağlıdır, hala her yeni sürümü canlıya almak çok stresli bir iş olmaya devam eder. Neden? Formal çözümleme teknikleri gibi mühendislik disiplinin gerektirdiği işler yerine “dostlar ‘agile’da görsün” şeklinde, görüntü üzerinden iyileştirmelerle yetindiğimiz için.

Ülkemizde bu durumlardan dolayı mesela “iş analizi danışmanlığı” pek görülen bir durum değildir. Halbuki ABD’de böyle çalışan, 6 ay petrol çıkaran bir organizasyonda çalışıp, süreçlerini analiz eden, sonra bir sigorta şirketinde ürün biriminde analiz danışmanlığı yapan, sonra başka bir yerde örneğin ticari olmayan (non-profit) bir kurumda yine analiz sürecinde çalışan profesyoneller var. Çünkü, PM gibi, programcı gibi, analist olmanın en temel yetkinliklerini kendinde barındırıyor ve her ortamda bunları kullanıyor.

Ve Bir Referans

Bu noktada size, iş ve ihtiyac analizi konusunda çok iyi bir otorite olan Karl Wiegers’ın Software Requirements isimli kitabını tavsiye ederim. Kitabın 3. bölümü “Business Analyst” başlığını taşımaktadır ve bir analistin yetkinliklerini ve sorumluluklarını, kimlerle nasıl iletişimde bulunacağını, hangi geçmişe sahip kişilerin nasıl bir geçiş süreciyle analist olabileceklerini ayrıntılı olarak anlatır. Ayrıca bu kitapla beraber gelen malzemeler arsında, Türkçesini bu yazıda paylaştığım iş analisti görev tanımını da var. O tanımda, bir iş analistinin sahip olması gereken bilgiler anlatılırken, “Gerekli Bilgiler” başlığı altındaki son madde şöyledir:

“Kullanıcı temsilcileri nezdinde güvenilirlik sağlaması ve onlarla etkin çalışabilmek için, zorunlu olmamakla birlikte, uygulama alanı bilgisi bir artıdır.”

Ya da orijinal haliyle:

“Application domain knowledge is a plus, to have credibility with user representatives and be able to work effectively with them.”

Bu yazıyı okuyup da bu cümleye katılmayacak pek çok kişi olacaktır. Ama ben şunu her zaman iddia ediyorum: İş süreçlerini çözümleme formal yetkinliklerine sahip, iletişim yetenekleri iyi bir analist, herhangi bir iş alanını en çok bir senede çok iyi bir şekilde öğrenebilir, o alandaki iş sorunlarını çözebilir, çok etkin analiz toplantıları yapabilir. Yeter ki çalıştığı ortamda iş bilgisi, bölük pörçük, insanların kafalarındaki malumatlardan ibaret olmasın, derli toplu, soyuttan somuta gider şekilde, farklı formal modellerle ifade edilmiş olsun. Ama gelin görün ki, senelerdir aynı iş alanında, hatta aynı kurumda çalışan analistlerin sıklıkla bana, iş alanlarıyla ilgili olarak kaotik bir ortamda olmaktan kaynaklanan rahatsızlıklarını ilettiklerini bilirim. Dahası, böyle bir analist, fırsat verilse, sistemli çalışmasıyla, malumat yığını da olsa bu yığını, çözümleyerek, formal iş bilgisine dönüştürebilir. İş süreçleri mühendisliği (business process engineering) adı verilen böyle bir çalışma, bir kurumun en değerli olan iş bilgisini, rahatça anlaşılacak ve tekrar tekrar kullanılacak bir formata döker. Ve bu bilgi, o kurumun en değerli varlığı olur.

Son bir soruyla yazımı bitireyim: Düşme tehlikesi olan bir uçağın pilotu olarak, uçağı kurtarmak için içeride bulunan sadece 2 kişiden, bir analist ve bir developerdan hangisini aşağıya atarsınız? Bu yazıdan sonra tabi ki “developer” diye cevap vereceksiniz muhtemelen. Ben ise daha ağır olanı atmayı tercih ederdim 🙂

Toplam görüntülenme sayısı: 1636

Programcı, Developer, Architect (Mimar), Bilgisayar Mühendisi ve Yazılım Mühendisi – III

Java, Yazılım Mühendisliği

Bu serinin ilk iki yazısında programcı, developer ve yazılım mimarı pozisyonlarını ele almıştım. Şimdi de yazılım mühendisini ele alalım.

Yazılım mühendisliği, daha önce ele aldığımız programcılık, developerlık ve yazılım mimarlığından çok daha farklı, tüm bu pozisyonlar yanında pek çok diğer pozisyonun da içinde olduğu yazılım geliştirme sürecini tasarlayan ve işletilmesini sağlayan kişidir. Dolayısıyla yazılım mühendisi, yazılım geliştirmedeki, iş ve ihtiyaç analizi, mimari ve fonksiyonel tasarım, kodlama, yazılım kalitesi ve test, bakım, proje yönetimi, değişim ve konfigürasyon yönetimi ve dokümantasyon gibi konularda süreçsel kurgulamalar ve yönlendirmelerden sorumludur. Bu anlamda yazılım mühendisi ne programcıdır, ne developerdır, ne mimardır ne de proje yöneticisidir. Yazılım mühendisi bunlardan hiç birisidir ama tüm bu pozisyonların yaptıklarını, büyük resimde, anlamlı bir süreç olarak kurgulayandır. Bulunduğu ortamda yazılımın, yazılım mühendisliği disiplinine göre geliştirilmesini sağlar. Yazılım mühendisi, yapılan işin “program” olmaktan ne kadar uzaklaşıp, “yazılım” olmaya ne kadar yaklaşacağını, ortaya karışık bir yapı mı yoksa kontrollü bir sistem mi çıkacağını belirleyen, yazılım geliştirmenin kaotik bir aktiviteler zinciri yerine, tanımlı, yinelenebilen ve ölçülebilen bir süreç olarak yerine getirilmesini   sağlayan kişidir.

Pek tabi olarak bir yazılım mühendisinin yukarıda saydığımız konuların hepsinde uzman olmasını bekleyemeyiz. Ama örneğin bir yazılım mühendisi ya iş ve ihtiyaç analizinin nasıl yapılacağını bilir, işin süreçlerini, iş kurallarını, entegrasyon noktalarını, kısıtlarını yani özetle, fonksiyonel olan ve olmayan ihtiyaçlarını ortaya koyar ya da bunları yapan iş ve ihtiyaç analistleriyle yakın çalışır, süreçte bulunur, çıktıları kullanır, yani bir şekilde o sürecin uzmanıyla ortak çalışabilir. Benzer şekilde yazılım mühendisi eğer daha çok modelleme tarafında bulunuyorsa, çıkarılan ihtiyaçların nesne-merkezli programlamaya izin verecek şekilde nesne modellenmesini, veri-merkezli yapılara el verecek şekilde E-R veri modellemesini yapar. Durum diyagramları vb. teknikleri kullanarak farklı mahiyetteki nesneleri modeller, tasarım şablonlarını uygular.

Yazılım mühendisi, literatürde var olan farklı yaklaşımlardan haberdardır ve en az birisini bilir. Örneğin yazılım mühendisi iş ve ihtiyaç analizinin use-caseler kullanılarak nasıl yapıldığını bilir, yapanlarla konu üzerine konuşabilir. Ya da nesne modellemede var olan yaklaşımlardan en az birinden haberdardır ve uygulayabilir. Domain-driven design, aspect-oriented programming, test-driven design vb. yaklaşım ve teknikleri yakınen takip eder ve uygun gördüklerinin bulunduğu ortamda yaygınlaşmasını sağlar.

Yazılım mühendisi, waterfall, extreme programming, Scrum vb. yazılım geliştirme süreci yaklaşımlarından da haberdardır. Tabi olarak hepsinde uzman olmasını bekleyemeyiz ama en azından örneğin iterative ve incremental metodolojilerin temel felsefesini ve tekniklerini bilir ve uygular.

Yukarıda anlatılanlar ışığından bakıldığında ülkemizde yazılım geliştiren kurumlarda bir yazılım mühendisliği yaklaşımının ve kültürünün olduğunu söylemek pek de mümkün değildir. Sektör olarak yazılım geliştirmeyi süreç odaklı bir mühendislik disiplini olarak görmek yerine, programlamadan ibaret ele aldığımız için, kaliteli, öngörülebilir, tekrarlanabilir yazılım geliştirme yaklaşımlarına da sahip değiliz malesef. Yazılım mühendisliği konusunda eğitim veren lisans ve lisans üstü düzeyinde yüksek ögrenim kurumları olmasına rağmen ne bunlar yeterli sayıdalar ne de bu kurumlarda gerçekten, güncel ve uygulanabilir bir yazılım mühendisliği altyapısı ve pratiği öğretilmektedir. (Açıkçası yazılım mühendisliğinin, lisans düzeyinde ögretilmesiyle ilgili şüphelerim de var. Bu kadar kapsamlı ve iş ve ihtiyaç analizi, programlama, yazılım mimarisi, yazılım kalitesi vb. çok yoğun bilgi gerektiren alt disiplinlerden en az birinde ciddi bilgi sahibi olmadan, bir lise mezununun doğrudan yazılım mühendisliği okuması bana çok anlamlı gelmiyor. Ben yazılım muhendisliği eğitiminin lisans üstü seviyesinde verilmesini ve burada eğitim almak isteyenlerin, aynen MBA ya da PMP konularında olduğu gibi, BT dünyasında ilgili pozisyonlarda örneğin minimum 5 sene tecrübeye sahip kişiler olması gerektiğini düşünüyorum.)

Ben uzun süredir yazılım mühendisliği konularında eğitimler hazırlıyorum, veriyorum ve danışmanlık hizmeti sağlıyorum. Eğitimler arasında yazılım geliştirme süreçlerini baştan sona anlatanlar olduğu gibi sadece örneğin iş ve ihtiyaç analizine ya da nesne-merkezli tasarıma odaklı eğitimler de var. Ama bu tür süreç eğitimlerine ilgi malesef o kadar az ki! Aynı şey danışmanlıklar için de geçerli. Sadece bu tür süreç eğitimlerine ve danışmanlıklarına odaklı iş yapmaya kalksam muhtemelen aç kalırdım. Bu yüzden gerek eğitim olsun gerek danışmanlık olsun, vaktimin çoğunu Java teknolojileri ve mimarisiyle ilgil eğitim ve danışmanlıklar alıyor. Malesef gerek toplum gerek ise sektör olarak son derece teknoloji odaklıyız. Teknolojiyi kullanarak nasıl katma değer yaratacağımızı düşünmeden, sanki teknolojinin bizatihi kendisi bir değermiş gibi, ona son derece yüksek harcamalar yaparken, teknolojiyi doğru olarak nasıl kullanmamız gerektiğine ne zaman ne de kaynak ayırıyoruz.

Aslında bu yazıyı yazarken aklıma gelen bir örnek var. Devlet, farklı iş kollarındaki iş yerlerine, o konunun uzmanı olan mühendislerin çalıştırılmasını zorunlu tutuyor. Farklı gıda üreticilerinde gıda mühendislerinin ya da ziraat mühendislerinin çalıştırılması zorunluluğu gibi. Benzer şekilde yazılım geliştiren kurumlarda da sanki, geliştirmeyi daha sağlıklı yapmalarını temin etmek üzere belli sayıda yazılım mühendisi istihdam etmelerini zorunlu tutmak iyi olur diye düşündüm. Bunun naif bir düşünce olduğunun farkındayım 🙂 Ama demek istediğim, kaotik geliştirme kültüründen, öngörülebilen ve kontrol edilebilen bir geliştirme kültürüne geçemediğimiz müddetçe bence bu topraklardan dünya piyasalarına sunulacak yazılım ürünleri ve çözümlerinin çıkması çok zor. Bırakın dünyaya yazılım ürünleri ve hizmetleri ihraç etmeyi, yurt içinde “ürün” yani “product” tanımına uyacak bir yazılım çıktısı bulmak bile güçtür. Bir ülkede güçlü bir iç yazılım pazarı ve üreticileri yoksa, o ülkenin bu sektörünün zaten dünyadaki pazarlarda yer alması mümkün değildir.

Zaman zaman, programcılık dışında herhangi bir yazılım aktivitesinde bulunmayan, kariyerinin başındaki kişilerin kendilerini “yazılım mühendisi” olarak tanıttıklarına ya da kurumların bu kişilere bu ünvanı verdiklerine şahit oluyorum. Yazılım geliştirmeyi bir süreç olarak algılamayan, sadece program geliştirip ve programcılık yaparken, bu şekilde çalışmayan kişi ve kurumların, kartvizitlerinde “Yazılım Mühendisi” ünvanını kullanması bence traji-komik bir durum oluşturuyor.

Yazılım mühendisliğine giriş yapmak, kendini bu alanda geliştirmek isteyen programcı, developer, analist vb. pozisyonlarda çalışan kişiler, bu konuda yüksek lisans eğitimi almayı düşünebilirler. Ya da yazılım mühendisliğini bir süreç olarak ele alıp anlatan kitaplardan faydalanabilirler. Son 10-15 yılda, agile metodolojiler üzerine yazılan tonla kitap, makale, yapılan konferanslar vs. ile çok ciddi bir bilgi birikimi oluştu zaten. Bunları okuyan yazılım projesi çalışanları, yazılım mühendisliğiyle ilgili çok güzel bir anlayışa sahip olabilirler. Yazılım mühendisliğindeki örneğin yazılım kalitesi gibi konulara eğilip, bu alanlarda kendilerini geliştirebilirler. Ben bir yazılım projesinde bulunan herkesin, 3-5 günlük de olsa bir şekilde bir yazılım mühendisliği eğitimi alması gerektiğini düşünüyorum. Aslında, daha doğru düzgün iş yapmak isteyen her yazılım projesi çalışanı yazılım mühendisliği konusunda kendini geliştirmeli. Aksi taktirde herkes eleştiriyor ama kimse doğrunun nasıl olması gerektiğini bilmez durumda oluyor. Örneğin developerlar ve programcılar, hem aşırı yük altında eziliyorlar hem de kalkıp sürecin  aslında nasıl olması gerektiği hakkında ciddi bilgi ve fikirlere sahip olamıyorlar, önerileri noktasal atış düzeyinde kalıyor.

Bu eğitimi bence ülkemizde BT sektörünün yöneticileri almalı. Çünkü kafasında bir yazılım mühendisliği nosyonu olmayan yöneticiler malesef çalışanlarının, özellikle de developer ve analistlerinin ensesinde boza pişiriyor çünkü yazılımın tabiatı, “ne”liği, süreçleri ve örneğin kalitesi ve riskleri hakkında hemen hiç bilgi sahibi değiller. Ve inanın, yazılım projelerinde alt seviyelerde çalışıp da sıkıntı çeken herkesin malesef yazılımı bilmeyen bir yöneticisi var.

Projelerimizi, daha mühendisce geliştirmek umuduyla 🙂

 

Toplam görüntülenme sayısı: 2013

Java Kodunuzun Nesne-Merkezli Olmadığının 10 İşareti – I

Java, Yazılım Mühendisliği

Nesne-merkezli programlamanın “ne”liği konusu pek çok kişi için halen muğlaktır. C++, Java, Python ya da C# gibi nesne-merkezli bir dil kullanıyor olmanın yazdığımız programları doğrudan nesne-merkezli yapmayacağı çok açık. Çünkü bu dillerde hem prosedürel/yordamsal program yazmak için yeterince imkan vardır hem de programcılar daha az nesne-merkezli kod yazmanın yollarını rahatlıkla bulmakta ya da bu yollara düşmektedirler. Java gibi nesne-merkezli diller bize nesne-merkezli kod yazmak için imkanlar sunmaktadır ama örneğin en azından nelerin nesne olacağı ve nesnelerin  aralarındaki ilişkilerin nasıl olacağı gibi kararlar tamamen biz geliştiricilerin/tasarımcıların sorumluluğundadır. Bu sorumluluğu yerine getirmede sıkıntılar yaşadığımız müddetçe Java’nın bize sağlıklı bir nesne-merkezli yapı oluşturmak için yardım etmesi mümkün değildir.

Ben Java ilk çıktığı zamandan bu yana Java’yı kullanmaktayım. Ve hayatımı, son 10 senede zaman zaman, son 6 senede ise tamamen Java ve Yazılım Mühendisliği eğitimleri vererek ve danışmanlıkları yaparak kazanmaktayım. Bu süre zarfında çok farklı tür ve yaklaşımla yazılmış pek çok Java kodu gördüm. Bu Java kodlarının pek çoğu emin olun, Java ile kod geliştirdiği için kodunun doğrudan nesne-merkezli olduğunu düşünen geliştiriciler tarafından yazılmıştı. Halbuki bu hiç bir şekilde doğru değildir. Yani Java’yı kullanarak bir sınıf oluşturup, içine üç-beş tane private nesne değişkeni (instance variables) tanımlayıp, sonra da bu sınıfa set/get metotlarını koymak, kesinlikle kodunuzu nesne-merkezli yapmaz. Nesne-görünümlü yapabilir ama nesne-merkezli programlamanın, bundan daha fazla olduğunu söylememiz gereklidir.

Nesne-merkezli kod yazmak, sınıflar tanımlayıp onlardan nesne oluşturmaktan çok daha fazlasıdır. En önemlisi örneğin, yukarıda da bahsettiğimiz gibi nelerin nesne olacağı ve nesnelerin aralarındaki ilişkiler gibi kararlar tamamen biz geliştiricilerin/tasarımcıların sorumluluğundadır. Doğru nesneleri bulmak ve aralarındaki ilişkileri sağlıklı bir şekilde oluşturmak çoğu zaman bulunan nesneleri Java’da tanımlamaktan çok daha zordur. Gang of Four yani GoF (ya da dörtlü çete) yazdıkları Design Patterns kitabında şöyle demektedirler:

“The hard part about object-oriented design is decomposing a system into objects. The task is difficult because many factors come into play: encapsulation, granularity, dependency, flexibility, performance, evolution, reusability, and on and on. They all influence the decomposition, often in conflicting ways.”

Türkçe olarak bu alıntıyı şöyle kurgulayabiliriz:

“Nesne-merkezli tasarımın zor tarafı sistemi nesnelere parçalamaktır. Bu iş zordur çünkü bunu yaparken pek çok faktör işin içine girer: kapsülleme, nesnenin boyutları (büyüklüğü), bağımlılık, esneklik, performans, gelişim, tekrar kullanım vb. Bütün bu faktörler, çoğu zaman birbirlerine ters düşecek şekilde bu parçalamayı etkilerler. ”

Doğru nesneleri bulmak yeterli değildir. Aslolan doğru nesneleri bulup, onları ve aralarındaki ilişkileri doğru bir şekilde kurgulayabilmektir öyle ki daha az karmaşık ve daha kolay değişebilen yazılımlara sahip olalım.

GoF’un tasarım şablonları bu zor işte bize yardımcı olurlar. Kitaplarındaki şablonlar, doğru nesneleri bulup doğru bir şekilde kurgulamak için farklı tasarım seçenekleri sunar. Bunu da geliştirdiğimiz yazılımın daha rahat değişebilmesi için yaparlar. “Design for change” (degişiklik için tasarla), GoF’un kitabının ilk bölümündeki üç temel prensiptenn birisidir. “Program to an interface, not an implementation” (arayüze program yaz, gerçekleştirmeye değil) ve “favor object composition over class inheritance” (nesne bileşimini sınıf kalıtımına tercih et) kitabın ilk bölümünde savunulan diğer iki prensiptir.

Nesne-merkezli tasarım ve programlama üzerine çalışan bilge kişiler yukarıdaki gibi pek çok prensip ortaya koymuşlardır. “Single responsibility principle” (tek sorumluluk prensibi) ya da “dependency inversion principle” (bağımlılığin ters çevrilmesi prensibi) senelerdir bu konuda duyduklarımız arasındadır. Bu anlamda SOLID kısaltması en temel 5 prensibi anlatmaktadır.

Ben bu yazı dizisinde bu tip prensipleri açıklamak yerine, sıklıkla karşılaştığım ve kodumuzu az ya da çok nesne-merkezli olmaktan çıkaran işaretlere ya da kötü alışkanlıklara değinmek istedim ve bu amaçla bir liste yaptım:  Java Kodunuzun Nesne-Merkezli Olmadığının 10 İşareti (ya da Ingilizce olarak Top Ten Signs That Your Java Code Is not Object-Oriented).

Bu listedeki yanlış uygulamalar (ya da anti-patterns), yazdığımız Java kodunu hem daha karmaşık hem de daha az değişebilir yapmaktadır. Listedeki her maddeyi örneklerle açıklayacağım gibi, nesne-merkezli paradigmanın hangi en temel prensiplerini bozduğunu da ifade edeceğim. Dolayısıyla her madde içın ayrı bir yazı olacak. Sizden de hem bu liste için hem de listede olmayan ama sizin sıklıkla gördüğünüz bu tür yanlış uygulamalar için bana yardım etmenizi rica ediyorum.

İşte liste:

  1. Sınıflarda aşırı miktarda statik metot kullanımı (Excessive use of static methods in classes.)
  2. Yüksek içerik bağımlılığı (high content coupling). Bir başka sınıfın nesne değişkenlerine doğrudan erişim ya da aşırı set ve get metodu çağrısı. (Direct access to the instance variables or excessive number of calls to setters and getters of another class.)
  3. Kodunuzda hiç alan nesnesinin olmaması ya da olsa bile yetersiz olmaları. (No or very thin domain objects in the code.)
  4. Kodunuzda hiç ya da çok az sayıda arayüz olması. (No or very few interfaces in the code.)
  5. Aralarında benzerlik ilişkisi olan nesneleri modellemek için kalıtım kullanmamak. (No inheritance hierarchy to model is-a relationships between objects.)
  6. Çok sayıda metoda sahip olan sınıflar. (Classes with lots of methods.)
  7. Karmaşık metotlar. (Complex methods.)
  8. Demeter prensibini ihlal eden metotlar. (Methods that break the Demeter law.)
  9. Aşırı miktarda karar ifadelerine sahip olan metotlar. (Methods that include excessive number of decision statements.)
  10. Sıra dışı durumları ifade etmek için Exception nesneleri oluşturmamak. (No Exception objects to represent exceptional situations.)

Yanlış uygulamalardan kaçındığımız şiir gibi kodlar yazmak amacıyla…

Toplam görüntülenme sayısı: 2539

Düşünce Azığı: İnsan Bilgisayar Etkileşimi ve Kullanılabilirlik Mühendisliği

Kitaplar , , ,

Çok sık kitapçılara gider, sırf onların arasında bulunmanın hazzını yaşamaya çalışırım. Zaman zaman, Türkçe BT kitaplarına da uğrar var mı yeni ve orijinal bir kitap diye de bakarım. Bu ülkede kitap yazmak, iyi ya da kötü olsun, kesinlikle taktir edilecek birşey. Öte taraftan kitap yazmak bence ülkemizde pek çokları tarafından hafife alınan birşey aynı zamanda, yani konuyu doğru dürüst bilmeyenlerin kitap yazdıklarına çok sık şahit olunan bir ülke, en azından ben ilgim ve bilgim alanına girenlerle ilgili böyle örneklere malesef sahibim. Neyse, yine geçen baharda bir kitapçıda gezinirken, Kürşat Çağıltay‘ın “İnsan Bilgisayar Etkileşimi ve Kullanılabilirlik Mühendisliği: Teoriden Pratiğe” isimli kitabını gördüm. Görünce de tabi ki hem sevindim hem de şaşırdım. Sevinmemin sebebi, yazılım sistemlerinden bahsederken çoğu zaman “program” kelimesini kullanan, dolayısıyla da, yazılım geliştirmek ile program yazmanın eşdeğer tutulduğu bir kültüre sahip olan sektörümüz için, böyle bir kitabın çok faydalı olacağını düşünmem. Şaşırtıcı olan ise, böyle bir düşüncenin malesef çok idealist olacağı aşikarken, bir insanın böyle bir çalışmanın zahmetine katlanıp, bilgi ve tecrübesini güzel bir kitap ile bizim hizmetimize sunması. Sevindirici bir şaşırma bu.

Kürşat Çağıltay, hakkında kendi sayfasından ve kitap ile ilgili bilgi alabildiğim diğer bazı yerlerden öğrendiğime göre, ODTU’de Bilgisayar Mühendsiliği’nde master, ABD’de  Indiana Üniversity’den de “Eğitim Teknolojileri” ile “Bilişsel Bilim” (Congitive Science) alanında doktora yapmış ve şu anda da ODTÜ’de öğretim üyesi. İngilizce literatürde “Human-Computer Interaction” ve “Usability” olarak adlandırılan bilim dalında çalışıyor ve aynı zamanda yine ODTÜ bünyesinde konu ile ilgili bir labaratuvarda araştırmalar yapıyor.

Kitap 2011 Şubat ayında ODTÜ Yayıncılık tarafından basılmış. Beyaz kağıda basılan kitabın başında bir önsöz ve bir teşekkür yazısı var.

Kitap yaklaşık 240 sayfa ve beş bölüm ve beş ekten oluşuyor. Bölümler:

  1. İnsan Bilgisayar Etkileşmi Alanına Genel Bakış
  2. İnsan Bilgisayar Etkileşimi: Fiziksel ve Felsefi Boyutu
  3. İnsan Bilgisayar Etkileşimi: Bilişsel Boyutu
  4. İnsan Bilgisayar Etkileşimi: Kullanılabilirlik
  5. Kullanılabilirlik Çalışması Örnekleri

Kitap hakkında buradan da bilgi alabilirsiniz.

Kitabın ilk bölümünün başında İtiraf.com‘dan alınan bir itiraf var:

“Okul yaşantımda başarılı sayılabilecek bir öğrenciydim, yüksek lisansımı da yaptım, mühendisim fakat X Bankası’ndaki İnternet hesabıma girince kaç param olduğunu anlamıyorum. Allahım, lanet olsun o kredili hesabı açtırdığım güne. Kaç param var benim yaa!”

Benim durumum daha kötü: Ben de mühendisim, yüksek lisansım var, üstüne üstlük yazılımcıyım, ABD’de ve ülkemizde tonla projede vs. bulundum, hayatımı, yazılım geliştirirek, nasıl geliştirileceği konusunda eğitim ve danışmanlık vererek geçiriyorum, IQ seviyem hiç de fena sayılmaz, üç rakamlı olduğuna inanıyorum :). Ama ben de o kurumsal 🙂 firmaların yazılımlarını kullanırken çoğu kez kendimi tek rakamlı IQ’ya sahipmiş gibi hissediyorum abi :). Uzun bir müddet Vodafone’un webden sunduğu MyVodafone isimli arayüzünden, hatlarımın faturalarını bir türlü görememiştim. Aman Allah’ım neler denemedim ki, oraya konmuş “mekik” ya da “shuttle” vari bir web kontrolunu kullanmayı bir türlü beceremedim. Kim nasıl akıl etti, çok mu uğraştılar onu bulmak için bilmiyorum ama ben iyi niyetle n tane farklı tarayıcıda m farklı şekilde denemiştim, taa problemin bende olmadığına inanıncaya kadar. Neyse, sonradan düzelttiler de daha sağlıklı bir hayata kavuştum 🙂

İşte bu kitap, böyle yazılımlar geliştirmek istemeyenler ve ben ve yukarıda itirafı bulunan sefil 🙂 kullanıcılar yaratmak istemeyenler için. Bu tür yazılımlar güya değil bana, benim anneme bile uygun olmalıyken, benim bile kullanamadığım durumda vatandaş n’apsın? Bu kitabın ilk sayfalarında benzer şekilde bir ATM’nin kullanılabilirliğiyle ya da kullanılabilemezliğiyle 🙂 ilgili, yazarın başından geçen güzel bir olay anlatılıyor. (Bu arada bu blogun temasının okunabilirliği dolayısıyla da kullanılabilirliğiyle ilgili problemin de farkındayım :))

Kitapta, en geniş olarak ele alınan konu, kullanılabilirlik. Bu konuda otoritelerden alıntılarla, anlamsal, arayüz özellikleri ve işlevsel (operational) açıdan kullanılabilirlik tanımı yapılıyor ve örnekler veriliyor. Ben, kullanılabilirlik uzmanı değilim ama esas odağı ile hiç ilgisi olmayan tonla bilgi kutucu ile donatılmış, dolayısıyla da kullanılamaz ya da arka arkaya geçilmesi gereken üç-beş web arayüzünden ibaret bir süreçte pek çok tutarsızlığa sahip, nerede ne yapmanız gerektiği konusunda aklınızı karıştıran kurumsal web arayüzüleri ile çok sık karşılaşıyorum. Bu örnekler, kitabın, arayüz özellikleri açısında kullanılabilirlik kategorisine giriyor. Kitapta işlevsel kullanılabilirlik olarak ele alınan nokta ile ilgili şöyle bir anımı da anlatabilirim örneğin: Garanti Bankası’nın internet bankacılığı arayüzü üzerinden bir kredi kartı başvurusu yapmak gibi son derece basit bir tecrübem oldu üç-beş ay önce. Tonla ahiret sorusuna cevap verdiğim ve sonrasında ilerle gibi bir düğmeye basarak geçtiğim sürecin en son sayfasında “başvuruyu gönder” gibi bir son düğmeyi görünce sevinmiştim tabi olarak. Bu düğmeye de basıp, bir kredi kartı başvurusu yapmanın dayanılmaz hafifliğini yaşayacakken, düğmeyi basınca “bir hata oluştu” gibi bir mesajla karşılaştım. Şimdi, hiç yazılım üzerine bir eğitim almamış olsam da eğer IQ seviyem 70-80 üzerindeyse ve hele de iflah olmaz bir “iyi niyet” taşıyıcı ve saçıcıysam, “… değiller ya bu yapanlar, herhalde başvuru bilgilerimi saklamışlardır, 15 dakika vakit harcadım başvururken ve TCKN, bir yakınımın telefonu vs. gibi, bir kısmı aklımda bir kısmı telefonumdan ya da makinamdan bakıp söylediğim, bir sürü bilgi girdim” diye düşündüm hızlıca. Ama sonrasında web uygulamasının menuleri arasında böyle bir şeyi ima eden bir linke bile rastlamadım tabi. Sonra dedim ya ben iflah olmaz bir iyi niyetiliyim, “herhalde sanırım ben hata yaptım, öyle ya ben bir yazılımcıyım ama Garanti Bankası’nın bu web arayüzü için beni cebinden çıkaracak tonla yazılımcı, analist, kullanılabilirlik uzmanı 🙂 çalışıyordur, boru değil ya …” diye düşünüp, güzel bir şekilde, hiçbir şey olmamış gibi, tekrar aynı süreci izledim. Sonuç değişmedi ama, iyi niyetten anlamıyor bu yazılımlar. Ayrıca web arayüzü de tamamen poker face 🙂 ser verir sır vermez cinsten: “Bir hata oluştu” İyi tamam da abi zaten muhtemelen benim bilgilerimi girdiğim üç baş sayfalık süreçte sunucu tarafında bu bilgiler muhtemelen Http oturumunda (session) tutuluyor, varsa bir problem, bu bilgileri yaz bir yere, muhtemelen veri tabanına, bir daha aynı eziyeti çektirme bana. Belli ki, kredi kartı başvuru modülü/sistemi her neyse, o tarafta oluşan bir hatadan dolayı web arayüzü bu mesajı veriyor bana. Ama sonuç şu: İstediği kadar janjanlı bir arayüze sahip olsun, kullanılmaktan uzak bir web uygulaması bu. Kitapta, işlevsel kullanılabilirlik denen şey bu işte. Bu hatanın teknik açıklaması ise şu: Muhtemelen, bu sürecin ya da kullanım şeklinin (use case) analizini yapanlar, sıra dışı bir durum olarak bu yaşadığım senaryoyu atladılar. Ya da analistler yakaladı ama geliştiren developer atladı, test eden tester da atladı. “Atladı” bence bu konuda söylenebilecek en iyi niyetli kelime 🙂 Sonuşta ortada bir Yazılım Mühendisliği yok, olsa olsa yazılımış bir program var. Kullanılabilirlik, “program” ile “yazılım” arasındaki en temel farklardan birisi.

Bence, insan önüne çıkan her yazılımın projesinde bulunan herkesin, ama herkesin okuması gereken bir kitap. Bunu okuyanların büyük bir kısmı, bu konuda sırf bir farkındalığa sahip olsalar bile yeter. Kurumlar ise analistlerine, arayüz tasarımcılarına ve testerlarına Kürşat beyden ya da benzer kişilerden eğitim aldırmalılar diye düşünüyorum.

Rahat kullanılabilir yazılımlar geliştirmek ve karşılaşmak dileğiyle.

Toplam görüntülenme sayısı: 1713

1 2 3 4 5