Neden yazılım mühendisliğine ihtiyacımız var?

Kodlama kuralları! PHP geliştirmeyi hızlandırmak için bunları takip edin

Yazılım mühendisliğine duyulan ihtiyacı anlamak için, yakın zamandaki bilgi işlem tarihini gözden geçirmek için kısa bir ara vermeliyiz. Bu hikaye, 1960’ların sonlarında ve 1970’lerin başlarında ortaya çıkmaya 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ı olacak. Bazıları bu sorunlardan, sorunun belirtilerinden dolayı adlandırılan “Yazılım Krizi” olarak bahsetti. Durum aynı zamanda sorunların temel nedeni olarak adlandırılan “Karmaşıklık Engeli” olarak da adlandırılabilir. Bazıları geçmiş zamanda yazılım krizine atıfta bulunur. Kriz sona ermedi ama artık yazılım mühendisliği başlığı altında yer alan birçok yeni tekniğin geliştirilmesi sayesinde başardık ve ilerlemeye devam ediyoruz.

Bilgi işlemin ilk günlerinde asıl endişe, donanımı oluşturmak veya satın almaktı. Yazılımın neredeyse kendi kendine bakması bekleniyordu. Fikir birliği, “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ünde. Göre, sektördeki çoğu insan donanım geliştirmeyi dikkatlice planladı, ancak yazılıma çok daha az öngörü verdi. Yazılım çalışmazsa, çalışana kadar değiştirmenin yeterince kolay olacağına inanıyorlardı. O halde neden planlama zahmetine girelim?

Yazılımın maliyeti, donanım maliyetinin o kadar küçük bir kısmını oluşturuyordu ki, hiç kimse, geliştirmeyi yönetmenin çok önemli olduğunu düşünmüyordu. Ancak herkes, verimli ve hızlı çalışan programlar üretmenin önemini gördü çünkü bu, pahalı donanımlarda zaman kazandırdı. İnsanların zamanından makinelere zaman kazandırması gerekiyordu. İnsan sürecini verimli kılmak düşük öncelik aldı.

Bu yaklaşım, yazılımın basit olduğu bilgi işlemin ilk günlerinde başarılı oldu. Ancak, bilgi işlem olgunlaştıkça programlar daha karmaşık hale geldi ve projeler büyüdü, oysa o zamandan beri programlar rutin olarak aynı kişi tarafından belirleniyor, yazılıyor, işletiliyor ve sürdürülüyordu, programlar başka birinin beklentilerini karşılamak için programcı ekipleri tarafından geliştirilmiştir.

Bireysel çaba, ekip çalışmasına yol açtı. Bir zamanlar bir kişinin kafasında meydana gelen iletişim ve koordinasyon, birçok insanın kafası arasında gerçekleşmeli ve tüm süreci çok daha karmaşık hale getirmeliydi. Sonuç olarak, iletişim, yönetim, planlama ve dokümantasyon gerekli hale geldi.

Şu benzetmeyi düşünün: Bir marangoz, kendisi için basit bir ev inşa etmek için tek başına çalışabilir ve genel bir plan konseptinden başka bir şey olmayabilir. İş ilerledikçe işleri halledebilir veya ayarlamalar yapabilir. İlk programlar böyle yazılmıştır. 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 olası mal sahibi ile birlikte gözden geçirilmelidir. Ve ev birçok marangoz tarafından inşa edilecekse, tüm projenin kesinlikle iş başlamadan önce planlanması gerekir, böylece bir marangoz evin bir bölümünü inşa ederken, diğeri farklı bir evin diğer tarafını inşa etmez. Planlama, çimento müteahhitlerinin marangozlar çerçevelemeye başlamadan önce bodrum duvarlarını dökmeleri için kilit bir unsur haline geliyor. Ev daha karmaşık hale geldikçe ve daha fazla insanın çalışmasının koordine edilmesi gerektiğinden, planlar ve yönetim planları gerekir.

Programlar daha karmaşık hale geldikçe, planlar (akış şemaları) yapmak için kullanılan ilk yöntemler, bu artan karmaşıklığı temsil etmek için artık tatmin edici değildi. Ve böylece, yazılı bir programa ihtiyaç duyan bir kişinin başka bir kişiye, programcıya tam olarak ne istendiğini iletmesi veya programcıların yaptıklarını birbirleriyle iletişim kurmaları zorlaştı. Aslında, daha iyi oluşturma 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 fazlasına mal olması ve tamamlanmasının haftalar, aylar veya yıllar sürmesi alışılmadık bir durum değildi. Müşteriye teslim edilen sistemler genellikle düzgün çalışmıyordu çünkü programlar başlangıçta amaçlandığı gibi çalışmadan önce para veya zaman tükenmişti. Ya da program o kadar karmaşıktı ki, bir sorunu çözmeye yönelik her girişim, çözdüğünden daha fazla sorun üretiyordu. Müşteriler nihayet ne aldıklarını gördüklerinde, 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 terk edildi çünkü hiçbir zaman düzgün çalışması sağlanamadı.

Programların kalitesi de önemli bir sorun haline geldi. Bilgisayarlar ve programları, yaşam destek ekipmanlarının izlenmesi gibi daha hayati görevler için kullanıldıkça, programın kalitesi yeni bir anlam kazandı. Bilgisayarlara bağımlılığımızı artırdığımız ve çoğu durumda artık onlarsız baş edemediğimiz için, düzgün çalışmasının ne kadar önemli olduğunu keşfettik.

Karmaşık bir program içinde değişiklik yapmak çok pahalıydı. Çoğu zaman, programa biraz farklı bir şey yaptırmak bile o kadar zordu ki, eski programı terk edip yeniden başlamak daha kolay oluyordu. Bu tabii ki pahalıydı. Yazılım mühendisliği yaklaşımındaki evrimin bir kısmı, ilk seferinde yeterince iyi inşa eden sistemler geliştirmeyi öğrenmekti, böylece basit değişiklikler kolayca yapılabilir.

Aynı zamanda, donanım daha ucuz hale geliyordu. Tüpler transistörlerle değiştirildi ve transistörler, üç bin dolardan daha düşük maliyetli mikro bilgisayarlar birkaç milyon dolar oluncaya kadar entegre devrelerle değiştirildi. Değişikliklerin ne kadar hızlı gerçekleştiğinin bir göstergesi olarak, her iki yılda bir belirli bir hesaplama miktarının maliyeti yarı yarıya azaltılı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ı edilecek kadar küçük değildi.

Donanım maliyeti düştükçe, yazılımı maaşları artan insanlar tarafından yazılmaya devam edildi. Derleyiciler, derleyiciler ve veritabanı yönetim sistemlerini kullanarak yazılım geliştirmede üretkenlik iyileştirmelerinden elde edilen tasarruf, donanım maliyetlerindeki tasarruf kadar hızlı gelmedi. Aslında günümüzde artık sadece yazılım maliyetleri göz ardı edilememekle kalmıyor, aynı zamanda donanım maliyetlerinden de daha yüksek hale geldi. Prosedürel olmayan diller (dördüncü nesil) ve yapay zeka kullanımı (beşinci nesil) gibi bazı güncel gelişmeler, yazılım geliştirmenin üretkenliğini artırmayı vaat ediyor, ancak bunların potansiyelini yeni yeni görmeye başlıyoruz.

Diğer bir sorun da, geçmişte programların genellikle programın ne yapması gerektiği tam olarak anlaşılmadan önce gerçekleşmesiydi. Program yazıldıktan sonra müşteri memnuniyetsizliğini ifade etmeye başladı. Ve müşteri memnun değilse, sonuçta üretici de memnun değildi. Zamanla, yazılım geliştiriciler başlamadan önce tam olarak ne yapmak istediklerini kalem ve kağıtla izlemeyi öğrendiler. Daha sonra müşterinin beklentilerini karşılayıp karşılamadığını görmek için müşteriyle birlikte planları gözden geçirebilirler. Bu kağıt ve kalem sürümünde değişiklik yapmak, sistem kurulduktan sonra olduğundan daha basit ve daha ucuzdur. İyi bir planlama kullanmak, program tamamlandıktan sonra değişikliklerin yapılması gerekliliğini azaltır.

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

Yine bina inşaatı benzetmesini düşünün. Bir mimar bir kat planı çizebilir. Genellikle müşteri, mimarın planladığı şeyi biraz anlayabilir ve uygun olup olmadığı konusunda geri bildirim verebilir. Kat planları, meslekten olmayanların 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. Henüz ortak bir kavram diline sahip olmadıkları için, yazılım mühendisinin müşteriye iletişim kurmadan önce yeni bir dil öğretmesi gerekir.

Ek olarak, bu dilin hızlı öğrenilebilmesi için basit olması önemlidir.



KaynakEdeh Chijioke

Bir cevap yazın

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