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