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ı: 2054

Bir önceki yazıda programcı ve developerdan bahsettik, konumuza devam edelim.

Architect ya da mimar, geliştirilecek olan yazılım sisteminin yüksek seviyeli tasarımını yapan kişidir. Mimar, yazılım bileşenleri ile temel özelliklerini, aralarındaki iş bölümünü ve iletişimi, katmanlar ve aralarındaki ilişkileri, kullanılacak teknolojileri, donanım altyapısı vb. sistem özelliklerini, performans, güvenilirlik (reliability) gibi fonksiyonel olmayan ihtiyaçları yerine getirecek şekilde belirler. Bu açıklamadan da anlaşılacağı gibi mimar, fonksiyonel yapıları, her türlü detayıyla tasarlayan kişi değildir. Bu anlamda yazılım mimarı, mimari olarak kritik olan fonksiyonel yapılar üzerinden hareket eder, sistemin yüksek seviyeli özelliklerini ve haritasını bu kritik fonksiyonel yapıları kullanarak belirler, detaylı fonksiyonel tasarıma girmez.

Böyle bir pozisyon, açıklamasından da anlaşılacağı gibi, öyle pat diye bir-iki senede elde edilecek tecrübe ile doldurulamaz. Kaldı ki sadece tecrübe ile de doldurulacak bir pozisyon değildir yazılım mimarlığı. Soyut ve sistem bazında düşünme becerileri çok önemlidir. Örneğin bileşenlerin API tasarımını yapmak, ön bellek kullanımı (caching) kurgulamak, transactional yapılara karar vermek, kullanılacak teknolojilerin mesela performans açısından en iyi kullanımları (best practices) belirlemek, alınan kararların UML gibi formal bir yolla dokümante etmek ve yaygınlaştırmak vs. bu anlamda mimarın yapması gereken işlerdendir. (İşin açıkcası kurumun ve projenin büyüklüğüne göre, veri, integrasyon, uygulama vb. konularda ayrı ayrı mimarlara ihtiyaç duyulabilir. Bu durumda kurumsal mimarinin (enterprise architecture) farklı vechelerinden bahsediyoruz demektir. Burada ele aldığımız daha çok uygulama ya da çözüm mimarıdır.) Yazılım mimarı, yüksek seviyeli bu gibi kararların alınmasında öncü durumdadır ama muhtemelen etrafındaki developerlarla çalışarak ilerler. Aldığı kararların tüm yazılım geliştirme takımı tarafından benimsenmesi ve sürekli bir şekilde uygulanması için takım ile iletişimini sürekli olarak korur. Bu anlamda yazılım mimarı bürokratik olarak yazılım geliştirme biriminde olmasa bile projede takımın bir parçası olur. Hatta benim gözlemlediğim, ülkemizdeki pek çok yazılım projesinde çalışan mimarlar, yazılım da gelişiren, kritik ve öneli bileşenlerin geliştirme sorumluluğunu üzerinde tutan kişilerdir.

Ülkemizde bildiği iki teknolojiyi bir araya getirip yazılım geliştiren herkes kendini mimar yerine koyuyor. Böyle bir algı, yazılım mimarisi kavramını sadece teknoloji seçimine indirgeme basitliğinin bir sonucudur. Yani örneğin Java EE teknolojilerinden hangilerinin kullanılacağına karar vermek, mesela web tarafında JSF, orta katmanda Spring, arkada, veri tabanı iletişiminde JPA kullanmaya karar vermeyi, yazılım mimarının tek yapacağı iş olarak görmenin sonucudur. Halbuki mimarlık programcılıktan farklıdır ve sadece zamanla elde edilecek bir sıfat da değildir. Sonuçta iyi mimarlar iyi programcılık geçmişine sahip kişilerdir ama her programcı hayatının ilerleyen zamanlarda otomatik olarak mimar olacak demek değildir. Bu anlamda malesef bu ülkede yazılım mimarlığı, programcılığın ya da developerlığın tabi bir uzantısı olarak görülüyor. Bu roller, pek çok ortak yönleri olsa ve birbirlerine çok yakın çalışsalar da sonuçta farklı yetki ve görevleri olan kişiler. Ben senelerce belli teknolojilerde uzmanlaşmış ama soyut düşünce yeteneklerini geliştirmeye ağirlık vermemiş, teknolojsini ve iş alanını çok iyi bilen kişilerle tanıştım ve çalıştım.

Yazılım projelerinde iyi-kötü bir mimari yapının kurgulanması ve tüm takım tarafından uygulanması, o yazılımın daha tutarlı, daha yeknesak, birlikteliğinin (cohesion) daha yüksek olmasını sağlar. Merkezi olarak alınmayan kararlar nihayetinde yazılım sisteminin aynı şeyi pek çok yerde tekrarlayan, bileşenleri arasında kaotik bir iletişime sahip hale getirir. Mimari kararların, farkında bile olmadan sadece developer/programcılar tarafından alındığı bir yerde sistemin sonunda değişemez, performans, scalability gibi açılardan çıkmaza girmiş hale gelmesi kaçınılmazdır.

“No Silver Bullet” isimli makalesinin sonunda F. Brooks, yazılımın asli zorluklarına çözümler ya da “silver bullet” (gümüş kurşun ya da daha anlamlı bir Türkçeyle ifade etmek istersek, sihirli değnek) önerirken “great designers” yani “mükemmel tasarımcılar”dan bahseder. Makalenin yazıldığı 1987 yılında tasarımcı, mimar vb. ayırımların henüz çok farkında değildik, bu yüzden bu ayırıma takılmadan Brooks’un “mükemmel yazılım mimarları”ndan bahsettiğini iddia edebiliriz. Yazılım geliştirmenin yaratıcılık gerektiren bir süreç olduğunu, dolayısıyla en iyi uygulamaları bilen kişilerin, doğru kavramsal modelleri ortaya koyabileceklerini ifade eder Brooks. Sonra da mükemmel mimarların, mükemmel yöneticiler gibi çok az bulunduğunu vurgular. Bu yüzden Brooks, kurumlara, bünyelerindeki “mükemmel tasarımcı” adaylarını erkenden bulup, onları yetiştirmelerini tavsiye eder.

Kariyerine yazılım mimari olarak devam etmek isteyen arkadaşların yazılım mimarisi kitaplarını okumaları, uygulama, veri, entegrasyon vb. konulardaki mimari yaklaşıkmları bilmeleri, farklı seviyelerde tasarım çalışmalarında bulunmaları, tasarım ve mimari kalıpları özümsemeleri, kullandıkları dilleri ve bu dillerdeki bileşen ve çerçeve (framework) yapılarını, bu teknolojilerin en iyi uygulamalarını iyice öğrenmeleri, performans, ölçeklenirlik gibi mimari konular üzerine çalışmaları ve soyut tasarım çalışmalarını ifade etmek için gerekli UML gibi formal yapıları ögrenmeleri gereklidir.

Kaliteli yazılımlar için kaliteli yazılım mimarlarına ihtiyacımız var.

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