Bir yazılım projesinin en kritik safhası hangisi diye sorsalar, bu yaşta hasta bir Javacı 🙂 olarak her zaman ve kesinlikle “analiz” derim. Çünkü, Brooks babanın da çok isabetli bir şekilde belirttiği gibi bir projenin en zor sorusu “neye ihtiyacımız var?”dır Yani “projemizin çıktısı olacak yazılım sisteminden ne bekliyoruz?”a cevap vermek en kritik ve en zor olandır. En kritik olandır çünkü bu sorunun cevabı, kendinden sonra gelecek her türlü yazılım geliştirme faaliyetinin içeriğini belirler. Dolayısıyla, bu soruya cevap verirken yapılacak bir hatanın, eskiklik ya da yanlışlığın örneğin, büyüyerek, ortaya çıkan yazılım sisteminde nasıl bir fonksiyonel probleme dönüşeceğini tahmin edebilirsiniz. Yazılım Mühendisliği kitapları, analiz safhasında yapılan hatanın aynı safhada düzeltilmesinin maliyetini bir birim alarak yaptıkları kıyaslamalarda, ortaya çıkan hatayı son sistemde düzletmenin maliyetinin yüzlerce kat olabileceğini vurgularlar. Bu soru aynı zamanda en zor olandır çünkü, geliştirilecek yazılım sisteminin bütün iş süreçlerini, iş kurallarını, entegre olacağı diğer sistemlerle olan iletişim detaylarını, bütün kullanıcı arayüzlerini ve diğer tüm standart, kısıntı vb. cinsten ihtiyaçlarını belirlemek çok zordur. Hatta en zordur çünkü, bir yazılım projesindeki bütün diğer faaliyetler, genel olarak üzerine bina edildiği ve önce gelen diğer çalışmalardan faydalanırlar ama işin analizinin ise çoğu zaman böyle bir lüksü yoktur. Eğer projeniniz, zaten var olan ama farklı sebeplerle yeniden yazmayı planladığınız, dolayısıyla da kullanımda olan bir yazılımın yeni versiyonu olacaksa ancak, durum çok daha farklı ve kolay olabilir. Çünkü sadece ve sadece zihinde olan bir ihtiyacı, yukarıda bahsettiğim farklı tipte ihtiyaçlar toplamı olarak ifade etmek aşırı zordur. Hatta Brooks, bunu ilk seferde yapmanın teorik olarak imkansız olduğunu söyler. Ona göre bu detayda bir betimleme, geliştirilen sistemin ancak ilkel de olsa bir versiyonunun çalışır halde görülmesinden sonra yapılabilir.

Analiz safhasının kritikliğini ve zorluğunu hallettikten sonra bir başka soruya geçelim. Yazılım projelerinde en fazla ihmal edilen, en fazla yok sayılan safha hangisidir sizce? Nereye gelmeye çalıştığımı farkettiniz değil mi? Bu sorunun cevabı ile yukarıdaki sorunun cevabı aynı malesef 🙁 Bu durum dünyada da böyle ama ülkemizde bence sanki biraz daha böyle. “Analizin ihmal” edilmesi üzerine biraz daha düşündüğümüzde, aslında bu ihmal kavramının açılması gerektiği aşikar hale gelir. Problem aslında şudur: Bir kurumun işleriyle ilgili olarak bir yazılım sistemine ihtiyacı vardır. Bu sistem ile işinin tamamını ya da bir kısmını daha hızlı ve etkin olarak yapabilecektir, en azından o kurum böyle düşünmektedir. Bu amaçla bir yazılım geliştirecek/geliştirtecek/satın alacaktır. Hangi çözümden yana giderse gitsin, ihtiyacının ne olduğunu çok ciddi bir detay ve kesinlikte belirlemek ve betimlemek zorundadır. Aksi taktirde hayal kırıklığı yaşaması çok büyük bir ihtimaldir. Yani o kurumun o an itibariyle yaptığı işler açısından, var olan iş süreçlerini, bu süreçlerdeki iş kurallarını, varsa form ve doküman gibi girdi ve çıktıları, kullanılan malzemeleri, iş sürecine dahil olan çalışan/insan rollerini ve özelliklerini, süreçlerin birbirleriyle ve diğer sistemlerle olan ilişkilerini vb. daha pek çok detayı, bir yazılım sistemi kullanmıyor olsa bile, iyi biliyor ve bu bilgiyi de formal bir şekilde örneğin bir dokümanda betimlemiş olmalıdır. Yani bir kurum, bütün işlerini tamamen klasik olarak elle, ya da en fazla Word ve Excell gibi yazılım araçlarını kullanarak işletiyor ve bir otomasyon sistemi kullanmıyor olsa bile durum budur. Bunu gerçekleştirdiğinde o kurum, “işini” biliyor ve bunu insandan bağımsız olarak detaylarıyla tarif edebiliyor demektir. Bu durumda o kurum kesinlikle daha etkin çalışır, çünkü en önemlisi kurumsal bir hafızayı çok daha sağlıklı olarak oluşturmuş olur. Bu şekilde, çalışanlarını uzmanlaştırarak, onları daha yanlışsız ve verimli bir çalışmaya sevkeder ki bu durum, çalışan motivasyonunu olumlu yönde etkiler. Böylece aynı pozisyona gelen farklı kişilerin farklı çalışma şekillerinin yarattığı iç ve dış, uyumsuzluk ve memnuniyetsizliklerin sebep olduğu verimsizlikleri ve kayıpları ortadan kaldırır. Bu şekilde oturmuş olan süreçlerin sürekli gözden geçirilmesi ve değişen şartlara uyarlanmasıyla, müthiş bir enerji ortaya çıkar. Dolayısıyla, sisteme yeni girenlerin de üretken hale gelmeleri çok hızlı olur, hatalar kemikleşmez, herkes tekerleği baştan keşfetmez.

Yukarıda bahsettiğim şekilde çalışan şirketler uzmanlaşırlar ve piyasada avantajlı duruma gelirler çünkü, öğrenmenin maliyeti en aza iner ve nihayetinde şirketlerin varlık sebebi olan, sahiplerine kar sağlamak çok daha yüksek oranlarda gerçekleşir. Çalışan seviyesinde yani micro seviyede böyle bir uzmanlaşmanın ve nihayetinde işleri, uzmanların elbirliği ile yaptığı bir akış, bir süreç olarak ele almanın, makro seviyede daha üretken, daha karlı ve verimli bir ortam oluşturduğu da açıktır. Bir şirketin çalışan başına düşen toplam üretim değerinin ya da karlılığının tamamen aynı şartlarda ve aynı sektördeki diğer bir şirketten yukarıda olmasının sebebi, karlı olan şirketin uzmanlaşmış olmasıdır. İster beğenelim ister beğenmeyelim, daha çok üretime ve dolayısıyla da tüketime odaklanmış bir dünyada, daha çok üretmenin en temel yolu, işini iyi bilmektir (ve Adam Smith tarafından kitabı “Wealth of Nations”da çok güzel bir şekilde açıklanmıştır). “İş”in, gittikçe fiziksel olmaktan çıkıp, daha zihni bir hale gelmesi ise “insan sermayesi” (human capital) kavramını daha da öne çıkarıyor tabi olarak.

Neyse, çok fazla dağıtmadan konuya dönersek, eğer bir kurum, yukarıda anlattığım şekilde kendi işini iyi bilmiyorsa, bu işi otomatize etmek amacıyla bir yazılıma sahip olması ne anlama gelir? Tabi ki bu yanlışı betonlaştırmak ya da yanlışı daha “pahalı” bir yanlış haline getirmek demektir. Zaten hantal, bürokratik, verimsiz, insana bağlı olan bir sistemin, daha da kemikleşmesi, pahalı ve değişemez hale gelmesinden başka birşey değildir bu durum. Benim gerek kamu gerek ise özel sektör kurumlarında gördüğüm pek çok “otomasyon” sistemi bu duruma örnektir. Bir devlet dairesinde bulunduğum üç-beş dakikada bile o kadar farkedilebilir bir durum ki bu, inananılmaz…

Peki şimdi bu durumu “yazılım ihtiyaçları” açısından ele alalım. Yani yukarıdaki gibi, işlerini düzgün bir süreç olarak ifade etmemiş bir kurumda yazılım geliştirmek amaçlı olarak yazılım ihtiyaçlarının analizini yapmak ne anlama gelir? Kısaca “yapamamak” anlamına gelir 🙂 Ne yaptığını bilmeyen, neye ihtiyacı olduğunu da bilemez, bu kadar basit. İşte bu yüzden bir yazılım projesinde en kritik ve en zor soru “neye ihtiyacınızın olduğu”dur.

Buraya kadar bahsettiğimiz aslında işin analizidir yani İngilizce’de “business analysis” terimiyle ifade edilen çalışmadır. Yazılım ihtiyaçlarının analizi ise, yani İngilizce’de “software requirements analysis” ile ifade edilen ise, iş analizi yapılmış bir işin otomasyonunun yazılım ile sağlanması amacıyla, geliştirilecek yazılım sisteminin ihtiyaçlarının belirlenmesidir. Bu durumda iş analizinin üzerine, bir yazılıma konu olabilecek seviyede detay girmesi gerekiyor ki “iş” bir yazılımla yerine getirilebilsin. Burada yazılım ihtiyaçları analizinin ya da daha kısaca ihtiyaç analizinin, iş analizinde olmayan bir takım yeni detaylar isteyeceği çok açıktır. Böyle bir ihtiyaç analizi çalışmasının, grafik kullanıcı arayüzü (GUI) gibi, yazılımın yarattığı yeni yapıların belirlenmesi ya da “otomasyon” kavramının getirdiği ve önceki, elle çalışan yapılarda hiçbir şekilde söz konusu olmayan performans, ölçeklenirlik, güvenlik gibi yeni ihtiyaçların ortaya çıkarılması ve detaylandırılması gibi farklı boyutları olacaktır.

Buraya kadar, ister iş amaçlı ister yazılım yazılım amaçlı olsun, ihtiyaçların tarif edilmesinden bahsettik ve burada ikili bir ayrımı kurguladık. Biz yazılımcılar, eğer sağlıklı bir yazılım geliştirmek istiyorsak, bunun için sağlıklı bir yazılım ihtiyaç analizi yapmalıyız. Sağlıklı bir yazılım ihtiyaç analizi ise sağlıklı bir iş analizi üzerine bina edilebilir. İşinin analizini yapmamış ama bir şekilde işini otomatize etmek isteyen kurumun önünde iki seçenek vardır: Ya iş analizini de, geliştirilecek olan yazılım vesilesiyle yazılım projesinde, projenin başında yapmak, ya da hiç yapmayıp, doğrudan yazılıma girişmek. Ülkemizde ikisi de çok sık olarak uygulanan yöntemler ama sanki ikincisi daha fazla oranda yapılıyor gibi geliyor bana. Dolayısıyla bir analiz yapılacaksa bile tamamen yazılım geliştirme amaçlı olarak düşünülüyor çünkü zihnimizde iş analizi ile yazılım ihtiyaç analizi ayırımı yok malesef. Bu durumda da ortaya çıkan yazılım da ezici çoğunlukla, var olan hantal ve verimsiz süreçleri kemikleştirmekten öteye hizmet etmiyor. Hatta daha da temelde, işini bilmeyen ama bir şekilde halleden 🙂 kişilerle, işini ve ihtiyacını tarif etmek amacıyla ihtiyaç analizi çalışması yapmak çok sorunlu hatta şunu da diyeyim, hastalıklı bir hal alıyor. Bu şekilde ortaya çıkan yazılım da tatmin edici olmuyor, aşırı miktarda değişiyor ve bu yazılımı ayakta tutmanın maliyeti aşırı artıyor.

Bu yazıda, iş analizi ile sonrasındaki yazılım ihtiyaçları analizinden ve aralarındaki ilişkiden bahsettik. Bir sonraki yazıda yazılım ihtiyaçlarının analizini daha detaylı olarak ele alacağız.

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