Tuesday, January 25th, 2022

Neden Yazılım Mühendisliğine İhtiyaç Duyarız?

Yazılım mühendisliğinin gerekliliğini anlamak için, bilişimin yakın tarihine bakmak için kısaca durmalıyız. Bu tarih, altmışlı yılların sonlarında ve yetmişlerin başlarında belirginleşmeye başlayan sorunları ve yazılım mühendisliği alanının yaratılmasına yol açan çözümleri anlamamıza yardımcı olacaktır. Bu sorunlara bazıları tarafından “Yazılım Krizi” adı verildi ve bu nedenle sorunun belirtilerinden dolayı adlandırıldı. Durum, sorunların birincil nedeni olarak adlandırılan “Karmaşıklık Bariyeri” olarak da adlandırılabilir. Bazıları geçmiş zamandaki yazılım krizine atıfta bulunur. Kriz sona ermedi, ancak artık yazılım mühendisliği başlığı altında yer alan birçok yeni tekniğin geliştirilmesi sayesinde ilerleme kaydettik ve ilerlemeye devam ediyoruz.

Bilgisayarın ilk günlerinde birincil endişe, donanımı oluşturmak veya satın almaktı. Yazılımın neredeyse kendi başının çaresine bakması bekleniyordu. Konsensüs, “donanımın” değiştirilmesinin “zor” olduğu, “yazılımın” ise “yumuşak” veya değiştirilmesinin kolay olduğu yönündeydi. Buna göre, sektördeki çoğu insan donanım geliştirmeyi dikkatli bir şekilde planladı, ancak yazılıma önemli ölçüde daha az öngörü verdi. Yazılım işe yaramadıysa, çalışana kadar değiştirmenin yeterince kolay olacağına inanıyorlardı. Bu durumda, neden plan yapmak için çaba gösterelim?

Yazılımın maliyeti, donanım maliyetinin o kadar küçük bir parçasıydı ki, hiç kimse geliştirmeyi yönetmeyi çok önemli görmedi. Ancak herkes, verimli ve hızlı çalışan programlar üretmenin önemini gördü çünkü bu, pahalı donanımlarda zaman kazandırdı. İnsanların zamanının makine zamanından tasarruf ettiği varsayılmıştır. İnsanları verimli hale getirmek çok az öncelik aldı.

Bu yaklaşım, yazılımın basit olduğu hesaplamanın ilk günlerinde tatmin ediciydi. Bununla birlikte, bilgisayar olgunlaştıkça, programlar daha karmaşık hale geldi ve projeler büyüdükçe, programlar rutin olarak aynı kişi tarafından belirlenir, yazılır, çalıştırılır ve sürdürülürken, programlar başka birinin beklentilerini karşılamak için programcı ekipleri tarafından geliştirilmeye başlandı.

Bireysel çaba yerini takım çalışmasına bıraktı. Bir zamanlar bir kişinin kafasında devam eden iletişim ve koordinasyon, birçok kişinin kafaları arasında gerçekleşmek zorunda kaldı ve tüm süreci çok daha karmaşık hale getirdi. Sonuç olarak, iletişim, yönetim, planlama ve dokümantasyon kritik hale geldi.

Şu benzetmeyi düşünün: Bir marangoz, genel bir plan kavramından daha fazlası olmaksızın, kendisi için basit bir ev inşa etmek için tek başına çalışabilir. İş ilerledikçe işleri çözebilir veya ayarlamalar yapabilir. Erken programlar böyle yazıldı. Ancak ev daha ayrıntılıysa veya başkası için yapılmışsa, marangoz evin nasıl inşa edileceğini daha dikkatli planlamak zorundadır. İnşaat başlamadan önce planların gelecekteki mal sahibi ile gözden geçirilmesi gerekir. Ve eğer ev birçok marangoz tarafından yapılacaksa, tüm proje kesinlikle işe başlamadan önce planlanmalıdır, böylece bir marangoz evin bir bölümünü inşa ederken, diğeri farklı bir evin diğer tarafını inşa etmesin. Planlama, çimento müteahhitlerinin marangozlar çerçevelemeye başlamadan önce bodrum duvarlarını dökmesi için kilit bir unsur haline gelir. Ev daha karmaşık hale geldikçe ve daha fazla insanın işi koordine edildiğinden, planlar ve yönetim planları gereklidir.

Programlar daha karmaşık hale geldikçe, planlar (akış şemaları) yapmak için kullanılan erken yöntemler, bu daha büyük karmaşıklığı temsil etmek için artık tatmin edici değildi. Ve böylece yazılı bir programa ihtiyaç duyan bir kişinin bir başka kişiye, programcıya tam olarak ne istediğini iletmesi veya programcıların yaptıklarını birbirlerine iletmesi zorlaştı. Aslında, daha iyi temsil yöntemleri olmadan, bir programcının bile ne yaptığını takip etmesi zorlaştı.

Programları yazmak için gereken süreler ve maliyetleri tüm tahminleri aşmaya başladı. Sistemlerin tahmin edilenin iki katından fazlaya mal olması ve tamamlanması beklenenden haftalar, aylar veya yıllar daha uzun sürmesi alışılmadık bir durum değildi. İstemciye devredilen sistemler, programların başlangıçta amaçlandığı gibi çalışması için para veya zaman tükendiği için sık sık düzgün çalışmıyordu. Ya da program o kadar karmaşıktı ki, bir sorunu çözmeye yönelik her girişim, çözdüğünden daha fazla sorun üretti. Müşteriler sonunda ne elde ettiklerini gördükçe, genellikle ne istediklerine dair fikirlerini değiştirdiler. Birkaç yüz milyon dolara mal olan en az bir çok büyük askeri yazılım sistemleri projesi, hiçbir zaman gerektiği gibi çalıştırılamadığından terk edildi.

Programların kalitesi de büyük bir endişe haline geldi. Bilgisayarlar ve programları, yaşam destek ekipmanlarını izlemek gibi daha hayati görevler için kullanıldığından, program kalitesi yeni bir anlam kazandı. Bilgisayarlara olan bağımlılığımızı artırdığımız ve çoğu durumda artık onlarsız geçinemeyeceğimiz için, bilgisayarların doğru çalışmasının ne kadar önemli olduğunu keşfettik.

Karmaşık bir program içinde değişiklik yapmanın çok pahalı olduğu ortaya çıktı. Çoğu zaman programın biraz farklı bir şey yapmasını sağlamak bile o kadar zordu ki eski programı atıp baştan başlamak daha kolaydı. Bu, elbette, maliyetli oldu. Yazılım mühendisliği yaklaşımındaki evrimin bir kısmı, basit değişikliklerin kolayca yapılabilmesi için ilk seferde yeterince iyi oluşturulmuş sistemler geliştirmeyi öğrenmekti.

Aynı zamanda, donanım giderek daha ucuz hale geliyordu. Üç bin dolardan daha az maliyetli mikro bilgisayarlar birkaç milyon dolar olana kadar tüplerin yerini transistörler ve transistörlerin yerini entegre devreler aldı. Değişimin ne kadar hızlı gerçekleştiğinin bir göstergesi olarak, belirli bir miktardaki hesaplamanın maliyeti her iki yılda bir yarı yarıya azalır. Bu yeniden düzenleme göz önüne alındığında, yazılımı geliştirme süreleri ve maliyetleri, donanıma kıyasla artık göz ardı edilebilecek kadar küçük değildi.

Donanım maliyeti düşerken, yazılım ücretleri yükselen insanlar tarafından yazılmaya devam etti. Birleştiriciler, derleyiciler ve veri tabanı yönetim sistemlerinin kullanımından yazılım geliştirmedeki üretkenlik iyileştirmelerinden elde edilen tasarruflar, donanım maliyetlerindeki tasarruflar kadar hızlı ilerlemedi. Gerçekten de, bugün yazılım maliyetleri artık göz ardı edilemez, aynı zamanda donanım maliyetlerinden daha büyük hale gelmiştir. Prosedürel olmayan (dördüncü nesil) diller ve yapay zekanın (beşinci nesil) kullanımı gibi bazı güncel gelişmeler, yazılım geliştirme üretkenliğini artırma vaadini gösteriyor, ancak bunların potansiyellerini daha yeni görmeye başlıyoruz.

Bir başka sorun da, geçmişteki programların çoğu zaman programın ne yapması gerektiği tam olarak anlaşılmadan önce olmasıydı. Program yazıldıktan sonra müşteri memnuniyetsizliğini ifade etmeye başladı. Ve müşteri memnun değilse, sonuçta yapımcı da mutsuzdu. Zaman geçtikçe, yazılım geliştiriciler, başlamadan önce tam olarak yapmak istediklerini kağıt ve kalemle düzenlemeyi öğrendiler. Ardından, müşterinin beklentilerini karşılayıp karşılamadıklarını görmek için müşteriyle birlikte planları gözden geçirebilirler. Bu kağıt-kalem versiyonunda değişiklik yapmak, sistem kurulduktan sonra yapmaktan daha basit ve daha ucuzdur. İyi bir planlama kullanmak, program bittiğinde değişiklik yapılması olasılığını azaltır.

Ne yazık ki, birkaç yıl öncesine kadar, bugün geliştirilenler kadar karmaşık sistemleri tatmin edici bir şekilde tanımlamak için iyi bir temsil yöntemi yoktu. Ürünün nasıl görüneceğinin tek iyi temsili, bitmiş ürünün kendisiydi. Geliştiriciler, müşterilere ne planladıklarını gösteremedi. Ve müşteriler, nihayet inşa edilene kadar yazılımın istedikleri şey olup olmadığını göremediler. Sonra değiştirmek çok pahalıydı.

Yine, bina inşaatı benzetmesini düşünün. Bir mimar bir kat planı çizebilir. Müşteri genellikle mimarın ne planladığını biraz anlayabilir ve uygun olup olmadığı konusunda geri bildirimde bulunabilir. Kat planları, sıradan bir kişinin anlaması için oldukça kolaydır çünkü çoğu insan geometrik nesneleri temsil eden çizimlere aşinadır. Mimar ve müşteri, uzay ve geometri hakkında ortak kavramları paylaşır. Ancak yazılım mühendisi, müşteri için mantık ve bilgi işlemeyi içeren bir sistemi temsil etmelidir. Halihazırda ortak kavramların bir diline sahip olmadıkları için, yazılım mühendisi iletişim kurmadan önce müşteriye yeni bir dil öğretmelidir.

Ayrıca bu dilin basit olması hızlı öğrenilebilmesi için önemlidir.

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir