İş Analisti mi, İhtiyaç Analisti mi yoksa Sistem Analisti mi?
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ı: 7699
hakan
25 Kasım 2013 @ 09:40
Akın bey deneyimli bir yazılımcı olarak şunu sormak istiyorum: Son derece karmaşık iş süreçlerinin bulunduğu bir sistemde yazılım geliştirmeye çalışıyorsunuz ve iş analisti diye yeni mezun birini getirip onun “yaptığı analiz çalışması” neticesinde kod yazmaya çalışıyorsunuz. Bu duruma ne derseniz? Bu durumda kalsanız ne yaparsınız?
Akin
25 Kasım 2013 @ 11:55
Bir kac alternatif var:
1- 5 sene sure ve $ 10 milyon butce.
2- Deneyimsiz analistleri formal is ve ihtiyac analizi konusunda egitmek ve baslarina yaptiklari analizi denetleyecek cok tecrubeli ve formal oalrak yaptigi is bilen bir lider analist getirmek. Ayrica analiz grubuna is alanini cok iyi bilen bir is danismani getirmek.
3- Istifa etmek 🙂
hakan
26 Kasım 2013 @ 09:33
Evet kesinlikle emin oldum ki büyük yazılım projelerinde çalışmışsınız 🙂 “istifa” kelimesini edecek misiniz merak etmiştim.. Fakat size birşey söyleyeyim. Piyasa yukarıdaki bahsettiğim çalışma modelini normal sayan ve proje süresini aşınca sebebini anlayamayan veya anlamak istemeyen it yöneticileri ve diğer yöneticilerle dolu desem inanır mısınız?
Akin
02 Aralık 2013 @ 00:00
Inanirim Hakan bey, inanirim, inanmanin otesinde bilirim hem de cok iyi 🙂
hakan
02 Aralık 2013 @ 14:12
Yani bu iş bu kadar basit mi? Biz yazılım inşa ediyoruz, proje uzuyor, bazen başarısız oluyor veya binlerce, onbinlerce data pisliğini temizlemek ne kadar zor ve stresli bir iştir? Köprü yapan, baraj yapan mühendisin başında da böyle yöneticiler mi var, böyle karar vericiler mi var ben anlayamıyorum, çözemiyorum…
Akin
02 Aralık 2013 @ 17:35
Zaten bu ulkede BT sektorunun gelismesinin onundeki en temel engel BT yoneticilerinin kendisi ve BT sirketleridir.