Search Results for: Yazılım Projelerinde İhtiyaç Analizi – I

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

İstek mi İhtiyaç mı Yoksa Problem mi? – II

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

Aynı başlıklı ilk yazıda istek ile ihtiyaç arasındaki ayırımdan bahsetmiş ve yazılımların başarısı açısından istekler yerine ihtiyaçlara yönelmenin gerekliliğini vurgulamıştık. Bu yazıda ihtiyaç kavramına biraz daha odaklanacağız ve “kapsam”ı ele alacağız.

İşin açıkçası ihtiyaçlara odaklanmak da projelerin başarısını garanti etmez ya da kullanıcılarını memnun etmez. Çünkü ihtiyaç, üzerine biraz daha düşünülmesi gereken bir kavramdır. Örneğin ihtiyaç noktasında sorulması gereken bazı sorular vardır. Bu sorulardan ilki, ihtiyacın gerçek olsa bile projenin kapsamında (scope) olup olmadığıdır. İsteklerinin üzerine düşünmeden onları ihtiyaç diye proje ekibine kabul ettirmeğe çalışmakla, aslında kapsam dışı olması gereken ihtiyaçları kapsama sokmak için proje ekibini ikna etmek arasında, projeyi riske sokmak açısından hiç bir fark yoktur.

Proje tanımından, bir projenin kapsamının ve hedeflerinin belli olması gerektiğini biliyoruz. Kapsam yönetimi, proje yönetim metodolojilerinin üzerinde önemle durduğu konulardandır. Proje kapsamından kasıt ise ihtiyaçlar açısından neyin projede ele alınacağı neyin ise proje dışında bırakılacağıdır. Kapsam, projenin sınırlarını belirler. Kapsamın önce belirlenmesi ve sonrasında kontrol edilmesi, yeni isteklerin ve değişikliklerin kapsamın içine girip girmediğine karar verilmesi, giriyorsa önceliklendirilmesi ve maliyetlendirilmesi, bu bağlamda yapılması gereken en temel çalışmalardandır. Bu noktada ihtiyaçlarını belirlerken sistemin kullanıcılarına düşen en temel şey ise ihtiyaçları arasında önce kapsam açısından bir öngörüde bulunmaları sonra da kapsam içinde olduğunu düşünüyorlarsa ihtiyacı önceliklendirmeleridir.

Gerek dünyada yazılım projelerinin başarısızlık sebepleri üzerine yapılan araştırmalar gerek ise benim ülkemizdeki yazılım projelerinden edindiğim tecrübeler, kapsamı düzgün yönetilmeyen projelerin bir süre sonra batağa saplandığını gösteriyor. Kapsam problemi, eğer proje iç BT birimi tarafından yapılıyorsa, yapılan işi proje tanımından çıkaracak noktaya kadar gidebiliyor. Bu durumda zaten hiç bitmeyen projeler ortaya çıkıyor. Yok proje eğer bir dış kuruma yaptırılıyorsa, bu durumda kurumlar arası özellikle finansal menfaatler söz konusu olduğundan, işler daha da sarpa sarabiliyor. Bu ikinci tip durumlarda projelerin ezici çoğunluğunun sabit maliyetle anlaşıldığı gerçeği de göz önüne alınırsa, durumun ne kadar riskli olduğu anlaşılır. Buradaki tek risk proje ekibinin riski değildir aslında. Yani, maliyet sabit tutulurken kapsamın genişlemesi sadece proje için o sabit maliyetin altına imza atan ekip sıkıntıya girmeyecektir. Projenin sahibi olan kurum da, ayırdığı kaynakları boşa sarfetmiş olma ve sonuçta motivasyonel açıdan son derece sıkıntılı bir duruma düşme gibi tehlikelerle karşı karşıya kalacaktır.

Peki bir ihtiyacın kapsam dahilinde olup olmadığına nasıl karar verilir? Aslında bu çok daha teknik bir soru olup farklı teknikler ve yaklaşımlarla halledilebilecek niteliktedir. Tabi olarak projenin stratejisi, iş hedefleri, paydaşların projeden beklentileri, elde etmek istedikleri fonksiyonellik vb. girdiler, projenin kapsamını oluştururken kullanılacak en temel ihtiyaçlardır. Projenin kapsamını belirlerken zaman zaman nelerin içinde olmadığını belirtmek de kafa karışıklıklarını gidermek açısından önemlidir. Kapsam belirlemede en temel problemler, paydaşların gerçekçi olmayan kapsam istekleri, birbiriyle çelişen ihtiyaçlar ve kapsam dahilindeki ihtiyaçların önceliklendirilmesi konusudur.

Paydaşların gerçekçi olmayan isteklere sahip olmalarının en temel sebebi, yöneticilerin sık rastlandığı üzere “ne isterseniz isteyin, yaptırın” tavrı kadar her şeyi “acil” ya da “blocker” statüsünde gören dolayısıyla ihtiyaçlarıyla ilgili herhangi bir önceliklendirme alışkanlığı olmayan kullanıcılardır. Oyuncaklarını paylaşmayan çocuk psikolojisiyle yazılım projelerine girdi sağlanamaz. Ayrıca projelerin pek çok farklı tipte kullanıcıları olduğu gerçeği göz önüne alındığında, her kullanıcı tipinin bu şekilde davranması durumunda projenin çok ciddi riske gireceği aşikardır. Bu tipten önceliklendirme problemlerini çözmek için “Project Champion” rolü ya da Scrum’daki “Product Owner” aslında biçilmiş bir kaftandır. Büyük yazılım projelerinde yukarıdaki bahsettiğim rollerde birden fazla kişi bulunabilir ve belki bu durumda bu rollerin en tepesindeki örneğin “Chief Product Owner” rolü bu noktada karar verici olabilir. Bu iki rolün yer almadığı projelerde iki taraftan yönetsel sorumluluklara sahip kişilerin bir araya gelip, projeyle ilgili karşılıklı özveride bulunarak, projenin yapılabilirliğini ve yetişebilirliğini garanti altına almaları çok sık karşılaştığımız durumlardandır. Burada aslolan, böyle bir noktaya gelmeden projedeki tarafların makul ölçülerde önceliklendirme yaparak anlaşma yoluna gitmeleri ve kapsamı bir kriz durumuna getirmenin sebep olduğu zaman, iş ve motivasyon kaybını önlemeleridir.

Yazılım mühendisliği literatürüne kapsamın yavaş yavaş büyümesi ve bu şekilde kontrolden çıkmasına “scope creep” denir. Bu durumla ilgili son derece komik ve bir o kadar da gerçekçi karikatürler mevcuttur:


Konuyla ilgisi açısından belki şu yazıma da bakabilirsiniz.

Buraya kadar ilk yazı dahil geldiğimiz noktayı şöyle özetleyebiliriz. Yazılım ihtiyaç analizi, adı üzerinde ihtiyaçlar üzerinden ilerler, istekler üzerinden değil. İsteklerini ifade eden kullanıcıların ve diğer paydaşların, bu isteklerin sistemin stratejik hedefleri, müşteri memnuniyeti, paydaş olarak kendi ihtiyaçları vb. girdilerle projenin kapsamını, proje ekibinin de yardımıyla, makul ölçülerde tutmalı ve daima genişleme eğiliminde olan kapsamın projenin başarısızlığına sebep olmasının önüne geçmelidirler.

Bir sonraki yazımızda kapsam dahilindeki ihtiyaçların önceliklendirmesini ele alalım.

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

İş Analisti mi, İhtiyaç Analisti mi yoksa Sistem Analisti mi?

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

2000’li yılların başlarında sıfırdan kurup, hemen her türlü çalışma ve iletişim prensiplerini belirlediğim bir yazılım grubundaki analistlere “requirements analyst”den esinlenerek “ihtiyaç analisti” ünvanını uygun görmüştüm. Daha sonra bir vesileyle farkettim ki ihtiyaç analisti olarak çalışanlardan bir bayan arkadaş, şirket ve proje içi yazışmalardaki emaillerinde isminin altında bu ünvanı kullanırken, dış yazışmalarında, mesela arkadaşlarıyla olan emaillerinde “analist” sıfatını yeterli görüyordu. Bu komik durumun sebebini sorduğumda arkadaşım, “Akın bey zaten kimse ne iş yaptığımıza akıl sır erdiremiyor, bu yüzden “ihtiyaç analisti” deyince hepten komik oluyor, bana “şuna ihtiyacım var, alır mısın?” diyorlar, bu yüzden onlarla olan yazışmalarımda “ihtiyaç” kelimesini çıkardım” şeklinde cevap vermişti 🙂

Evet iş analisti, ihtiyaç analisti ve sistem analisti nedir? Bunlara geçenlerde bir vesile ile duyduğum “fonksiyonel analist” ünvanı da katıldı. Analist-programcı ise zaten çok eskiden bu yana bildiğimiz bir ünvan. Dolayısıyla “nedir bu ünvanlar?” diye sorabiliriz. Aralarında fark var mıdır? Yoksa aynı şeye verilen farklı isimler mi?

Söyle açıklayabiliriz: Evet aslında hepsi az çok farklı roller. Temelde iş analistinin ihtiyaç analistinden farkını bu ve bu yazıda iş analizi-ihtiyaç analizi farkını ele alırken açıklamıştım. Kısaca tekrar edersek iş analisti, herhangi bir yazılım geliştirme söz konusu olmadan bir işin nasıl yapıldığını ortaya koyar, analitik olarak ele alır, sistematik olarak ifade eder ve belgeler. İş analistinin bir işi analitik olarak ele alması, iş süreci ile bu süreçlerdeki iş kurallarını ve kısıtları, süreçlerde yer alan kullanıcıları, entegre olunan, kendisiyle haberleşilen farklı sistemleri ortaya koymasıdır ve işteki

  • Süreçler ve akışları ile kurallar ve aktörler arasındaki ilişkileri,
  • Sebep-sonuç, öncelik-sonralık bağlantılarını, karmaşıklık düzeylerini,
  • Sıra dışı durumları, envai çeşit “what if” senaryolarını,
  • Her türlü girdileri, çıktıları ve raporları,
  • Önemli bilgi öbeklerini (information set) ve ilgili kısıtları

sistemli olarak çıkarıp doğrulaması ve dokümante etmesidir.

Bu anlamda iş analisti bir yazılım uzmanı değildir, işini yapmak için yazılımlardan faydalanan bir iş uzmanıdır!

İş analistinden, var olan süreçlere iyileştirmeler yapabileceği gibi, yeni süreçler de kurgulamasi beklenir. Bu anlamda bir iş analistinin, o işi operasyonel olarak yapandan yani kullanıcıdan temel farkları vardır. Operasyonel çalışanlar, o işin sadece kendine bakan taraflarını, parçalı bir şekilde, senaryo düzeyinde ve kendi bireysel yeteneklerinin izin verdiği ölçüde gözlemlere dayanarak, çoğu zaman gelişi-güzel ifade ederler, muhtemelen dokümante edemezler. İş analisti ise işi bütüncül olarak, her türlü detayıyla, sistemli olarak ele alır, çözümleyici bir şekilde yaklaşır ve formal yöntemlerle tarif edip standart doküman olarak ifade eder. Bu anlamda operasyonel çalışanlar iş süreçleriyle ilgili ufak tefek iyileştirme önerilerinde bulunabilirler ama yeni süreç kurgulayamazlar. Fakat iş analistleri sistematik ölçümlerden faydalanarak iş süreçlerinde iyileştirmeler yapabildiği gibi yeni süreçler de kurgulayabilir.

Bir işin, bir yazılım sistemiyle otomatikleştirilebilecek şekilde detaylandırılmasına yazılım ihtiyaçları analizi (software requirements analysis) ya da kısaca ihtiyaç analizi denir. Bir işin yazılım sistemiyle otomatikleştirilebilmesi için öncelikle o işin iş analizinin yapılmış olması gereklidir. Genel olarak bir işin analizinin sorumluluğu o işi yapan kurumda, yazılım ihtiyaçlarının analizi ise yazılımı geliştirecek kurumda olmalıdır: İster iş bölümü (separation of concerns) deyin ister “kendini bil” (know yourself) deyin, neresinden bakarsanız bakın böyle bir ayırım vardır.

Yazılım ihtiyaçlarını analiz eden kişiye de ihtiyaç analisti (requirements analyst) denir.

İhtiyaç analisti, iş analizi yapılmış bir işin yazılıma konu olacak şekilde detaylarını

  • Bulur ve ortaya koyar (extraction),
  • Çözümler, bileşenlerine ayırır (analysis),
  • Sistemli olarak ifade eder, tanımlar (specification) ve
  • Formal olarak dökümante eder (documentation).

İhtiyaç analizinin, iş analizinden farkı, işin bir yazılıma konu olabilecek şekilde ifade edilmesi, dolayısıyla iş analizinin yazılım ihtiyaçlarıyla donatılmasıdır. Bu farklar şöyle listelenebilir:

  • Performans, ölçeklenirlik, güvenlik, kullanılabilirlik vb. mimari ihtiyaçlar,
  • Kullanıcı arayüzleri, insan-bilgisayar iletişimi (HCI) ihtiyaçları, girilen bilgiler ve kısıtları
  • Bilgi öbeklerinin detayları, tip, doğrulama ve kısıt bilgileri,
  • Artan kullanıcı çeşitliliğinin getirdiği kolay kullanım yetenekleri,
  • Entegrasyonlar, sistemin dışarıdan aldığı ve dışarıya verdiği bilgiler,
  • Sistem ihtiyaçları, gerekli donanım ve yazılım sistemleri,
  • Yazılım standartları, uyulması gerekenler şartlar vs.,
  • Yazılım kalitesi kriterleri, hata sayısı vb.
  • Projenin bütçe, zaman, çalışan, risk vb. faktörleri.

Sistem analizi ise sistemin donanım ve yazılımını geliştirmeye kadar girmese bile, sistemin fonksiyonel çözümlemesi yanında fonksiyonel mimarisini de tasarlanmasına verilen isimdir. Bu anlamda sistem analisti, veri tabanı tasarımı, fonksiyonel bileşenler gibi konularda tasarım yanında sistem testini hatta sistem kurulumunu (deployment) da yapar. Bu sebeple sistem analisti yazılım geliştirme dilleri ve ortamlarına aşina olmalıdır. Bu anlamda sistem analisti 80’li ve 90’li yılların pozisyonudur ve modern zamanlarda sistem analistleri, tasarım sorumluluklarını bırakarak daha fazla müşteri ihtiyacına odaklı analist olmaktadırlar.

Analist programcı ise, geliştireceği iş süreçlerini hem analiz eden hem de kodunu yazan kişidir. Tarihi olarak BT dünyasındaki en eski rollerdendir ve iş süreçlerinin çok karmaşık olmadığı, nispeten daha algoritmik yazılımların geliştirildiği dönemlerde, özellikle de belli büyüklüğü aşmayan projelerde en çok sıklıkla karşımıza çıkan roldür. Ülkemizde malesef hala son derece yaygın olarak kullanılmakta olan bu rol sayesinde iş ve ihtiyaç analizi ile tasarım ve kodlama zaten aynı zihinden çıkmakta ve sonucunda da yazılım çıktısı çok ciddi problemlere sahip olmaktadır.

Dolayısıyla iş analisti, ihtiyaç analisti, sistem analisti ve analist programcı rol olarak farklı oldukları gibi, yazılım geliştirmeye yaklaşım açısından da farklı paradigmaların kavramlarıdır. Aslolan ise iş ve yazılım analizini ayırmak, geçiş noktalarındaki kaçınılmaz durumlar hariç, içlerine tasarım ve kodlama faaliyetlerini olabildiğince sokmamaktır.

Karmaşık olan, gittikçe karmaşıklaşan iş süreçlerini ve kurallarını bilgi yığını olarak ele almak ölümcül bir hatadır. Allah her yazılımcıya, işini bilen müşterilerle, ihtiyacı sağlıklı bir şekilde çıkarılan yazılım projelerinde çalışmayı nasip etsin 🙂 Bir yazılımcı için bundan güzel bir dua olur mu acaba?

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

Genç Yazılımlılar İçin – II: Master yapmak ya da yapmamak.

Kültür, Bilgi ve Düşünce, Yazılım Mühendisliği , , ,

Çok komik… Aslında traji komik… Bakın anlatayım:

Üniversiteli gençlerle hemen her buluşmamda bana sorulan sorulardan birisi de “hocam master yapalım mı?” oluyor. Çocuklarının kafasını daha lisedeyken “doktora yapma” fikriyle yıkamış bir adama sorulacak soru mu bu? Ya da yaşı 40’nı geçmesine rağmen, bir de Felsefe masterı yapsam diye düşünen bir adamın bu soruya cevabı ne olabilir ki? Dolayısıyla bu soruya, “tabi ki yapın” ya da “sadece master değil doktora da yapmalıyız” şeklinde cevaplar veriyorum. Toplumumuzun eğitim seviyesinin yükselmesi, sektörde bilgi birikiminin olması, herşeyden önce bilgi ve bilgi sevgisi kültürünün yaygınlaşması vb. tonla sebepten dolayı master ve doktora yapmanın önemli olduğuna inanıyorum. Tabi ki bu işin bir vechesi. Diğer vechesi ise o kadar da zevkli değil malesef.

Şöyle bir soru sorsam size: Ülkemizdeki BT sektörünün ihtiyacı açısından, ortalama bir BT çalışanının ne kadar eğitime ihtiyacı vardır? Zor soru tabi. Ama cevap kesinlikle “üniversite lisans eğitimi” değil bence.  Ülkemiz BT sektöründe var olan yerleşik yazılım geliştirme kültürü ve pratiği açısından ele alındığında, benim iddiam şudur: Akıllı bir lise mezunu, var olan işlerin ezici çoğunluğunu, makul miktarda iş başı eğitim ve yol gösterme ile başarabilir. Efendim BT sektöründe çalışanlar zaten liselerden gelen en zeki çocuklardanmış, ÖSS’de ilk bilmem kaça girenler bu sektörde çalışıyorlarmış, yok lisedeyken fizik olimpiyatlarına katılmışlarmış ya da yazılım sektörü çok analitik bir zeka istiyormuş, falan filan… Bence hepsi hikaye. Bunun, heyecanlı Bilgisayar Mühendisliği öğrencilerinin canını sıkacak bir iddia olduğunun farkındayım ama bence durum bu kadar vahim. Bence sadece bizim sektörde değil, pek çok mühendislikte durum bu kadar vahim: İnşaat Mühendisliği ve “bina inşa etme” kültürümüzde de durum pek farklı değil. Ya da bakın, ortalık Endüstri Mühendisliği mezunu dolu ama görüyor musunuz süreç tabanlı bir çalışma? Ben görmüyorum…  Kadın, “Endüsti Mühendisliği mezunuyum ve 10 senedir falan bankada iş analisti olarak çalışıyorum” diye tanıtıyor kendini. Soruyorum, “nasıl iş analizi yapıyorsunuz?” diye. Cevap veriyor “işte, müşterimiz iç müşteri oluyor her zaman. Onlardan istek geliyor. Gidip görüşüyorum onlarla, sonra görüşmeden çıkardıklarımdan bir Word dokümanı oluşturuyorum. Ayrıca PowerPoint’de ekran tasarımı yapıyorum.” “Peki” diyorum içimden ve soruyorum kendi kendime: Burada “analiz” nerede?: PowerPoint ile yapılan şeyin analiz olmadığı kesin çünkü zaten adında “tasarım” var. Geriye kalıyor “Word dokümanı”. Oradan birşeyler çıkarmaya çalışıyorum, çünkü kadının anlatımından “Word dokümanına yazılan şey, iş analizidir” ya da “cümleleri, analitik yapan şey, onların bir Word dokümanına yazılmış olmasıdır” (!) şeklinde birşey çıkıyor. Soruyorum,” o Word dokümanındaki temel kısımlar, başlıklar nelerdir?” Ya da “herhangi bir diyagram çiziyor musunuz” diye, ama nafile. Tek derdim, “iş analisti” olarak çalışan Endüstri Mühendisi arkadaşımızın zihninde “iş” ve “analiz” ile ilgili bir kırıntı var mı onu anlamak. Belli ki iş analisti olarak çalışan herkes kendine göre bir “analitik” 🙂 süreç izliyor.Ve Word dokümanına yazılan şeyler bir şekilde “analiz” oluyor ama dokümanda herhangi bir yapısallık bile yok. Peki söyler misiniz bana böyle bir işi akıllı bir lise mezunu niye yapamasın? Bu işin neresinde analitik bir işlem var? Bu işin postacılıktan ya da sekreterlikten ne farkı var? Postacılıktan farkı yok, çünkü analitik bir katma değer olmadan sadece bilgiyi taşıma söz konusu, herhangi bir çözümleme ve dönüştürme yok. Sekreterlikten farkı yok çünkü Word dokümanına geçiriliyor anlatılanlar. Halbuki, işi soyut olarak bir süreç olarak ifade etme, gerçek olaylardan oluşan senaryolarla, bu soyut süreci kurgulama ve doğrulama, iş kurallarını farklı kriterlerle yakalayıp ifade etme, nesne-merkezli bir yaklaşım söz konusuysa bir kavramsal nesne modeli çıkarma vb. yaklaşım ve tekniklerden bahsetmesi gerekirdi. Literatürde ve pratik uygulamada tonla “iş ve ihtiyaç analizi” (business and requirements analysis) yaklaşımı, tekniği, şablonu (patterns), diyagramları (örneğin UML), en iyi uygulamaları (best practices) vs. var. Var mı uygulayan? Olsa, bir Endüstri Mühendisliği disiplininin sağladığı alt yapıya ihtiyaç olurdu. Ve siz de derdiniz ki “bu işi ancak bir Endüsti Mühendisi” yapabilir.

Tonla iş analistine eğitim verdim, bir tanesinin de zihninde “ihtiyaç tipleri” gibi bir ayırım görmedim. Hatta analiz ile tasarım arasındaki farkı bilene bile pek rastlamadım. Her eğitimde ya da danışmanlıkta Karl Wiegers’ın nefis Software Requirements kitaplarını ebook olarak dağıttım, nefis örneklerinden verdim… Çünkü ihtiyacınızı ya da işinizi analitik olarak ele alıp, çözümlemezseniz, ne istediğinizi ya da nasıl iş yaptığınızı tarif edemiyorsunuz demektir. Bunu yapamadığınızda, hangi yazılımı, hangi en ileri teknoloji ile geliştirdiğinizin hiç bir önemi yoktur. Yazılım projelerinde, ne yapacağınızı bilmediğinizde, ne kadar adam-gün, ne zaman, ne kadar maliyet vb. hiçbir soruya yanılma payıyla bile olsa cevap veremezsiniz. Ne proje planı yapabilirseniz ne de test. Yaparsanız, sadece “yaptım oldu” olur. “Dostlar sizi PMP’lerinizle proje planı yaparken görsün”den öteye gidemezsiniz. İşimizi ve ihtiyacımızı tarif etmeyi bu şekilde algıladığımzıda ne master yapmış bir Endüstri Mühendisi’nin katma değer sağlaması mümkündür ne de bu duruma master sahibi olmak tercih sebebidir.

Aynı durum, yazılım geliştiren programcılar için de geçerli. Tonla Bilgisayar, Endüstri, Matematik vb. mühendisin çalıştığı bir yazılım geliştirme ortamında en temel kavram “ekran” nasıl olur? “Ekran aşağı, ekran yukarı”. Her şey sadece ve sadece ekran ile anlatılıyor. O yukarıda bahsettiğim ünlü Word dokumanını, tamamen ekran tasarımı ve üzerindeki arayüz elemanlarının özelliklerini yazarak oluşturan ve buna “iş analizi” diyen iş analistleri de gördüm bu ülkede ben. Herşeyin ekran üzerinden anlatıldığı bir yerde “iş” ve “analiz” nerede Allah aşkına? En önemli soyutlamanın “ekran” olduğu bir iş ortamının anlamlı olması için orasının, CRT ya da LCD ekran geliştiren bir elektronik vb. bir AR-GE birimi olması gerekmez mi? 🙂 Yazılım gibi tamamen süreç odaklı bir işi, “ekran” kavramı etrafında kurgulamamız için ne kadar eğitim almamız gerekiyor? Bunun için ne kadar Matematik, ne kadar differantial equations, ne kadar operating systems, ne kadar algorithms, ne kadar artificial intelligence öğrenmemiz gerekiyor?

Bakın ilanlara, pek çok ilanda Bilgisayar Mühendisi ile başlanır, sonra Elektronik Mühendisliği vb. mühendislikler sıralanır. Yahu BM’in yapacağı iş için niye EM ya da “ilgili bölümler” gibi ortaya karışık bir şey söylenir? Sebebi şu: Aslında aranılan şey, biraz mürekkep yalamış adam. Ne okuduğu çok da önemli değil. Gerçek bu.

Dolayısıyla “master yapalım mı” sorusunun cevabı yine tamamen kendi içinizde yatıyor. Kimse sizden master yapmış olmanızı beklemez bu ülkede, ama siz kendinizden bekliyorsanız ona saygı duyarım. Dolayısıyla bilgi sizin için önemliyse, master da yapın doktora da. Yok “erken kalkan yol alır” derseniz, bir an önce işe girin, nasıl olsa masterlı olmak çok da fazla bir avantaj sağlamayacak.

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

1 2