Dil Derneği tarafından yayımlanan sözlükte bilgisayar, “çok sayıda aritmetiksel ya da mantıksal işlemlerden oluşan bir işi, önceden verilmiş bir izlenceye göre yapıp sonuçlandıran elektronik aygıt” olarak tanımlanır. Bilgisayar, donanımdan (hardware) ve yazılımdan (software) oluşur. Yine aynı sözlükte donanım, “bilgisayarı oluşturan gereçlerin tümü” , yazılım ise “bir bilgiişlem dizgesinin işleyişiyle ilgili bilgisayar izlencelerinin, kuralların ve gerektiğinde belgelemenin tümü” şeklinde tanımlanır. Bir diğer deyişle, donanımla bilgisayarın dokunulabilir bileşenlerine, yazılımla ise maddi olmayan bileşenlerine işaret edilir. Buna göre, fare, klavye, monitör, disk vb. donanım kapsamında değerlendirilirken, işletim sistemi, oyunlar, belge biçimleri (jpg, xml, html, mpg vb.), ofis uygulamaları vb. yazılım kapsamında değerlendirilir.
Yazılım terimi ilk kez 1958 yılında, ünlü bir istatistik uzmanı olan John Wilder Tukey tarafından kullanılır. Tukey aynı zamanda 1946 yılında, bilgisayar programlarının temeli olan 1ler ve 0lar için kullanılan binary digit ‘i(ikili sayı) bit olarak kısaltan kişidir. Tukey, yazılım terimini ilk kez kullanırken yazılımın giderek daha fazla önem kazanacağının da altını çizer. Ancak 1960’ların ikinci yarısına kadar yazılım, donanımın bir parçası, bilgisayarların ikincil bir bileşeni olarak görülür. 1960ların sonunda gerçekleşen üç olay, yazılım ve donanım endüstrilerini ayırır. İlk olay, IBM System 360 bilgisayar ailesinin piyasaya girmesi ve farklı yazılım firmalarının değişen kullanıcılara göre yazılım geliştirme olanağı kazanması ve bunu satabilmesidir. İkinci olay, 6 Aralık 1968’de IBM’in artık donanımı ve yazılımı ayrı ayrı fiyatlandıracağını duyurmasıdır. O vakte kadar müşteriler, bilgisayara bir bütün olarak para ödemektedirler. IBM bu hamlesinin yükselen yazılım maliyetlerinin bir neticesi olduğunu söyler. Fakat OECD raporunda (1985), IBM’in bu kararında anti-tröst yasalarının etkin olduğu iddia edilir . Gerekçesi her ne olursa olsun, IBM’in bu hamlesi çeşitli yazılım firmalarına IBM uyumlu yazılımlar geliştirme olanağı sağlar. Üçüncü olay ise mikrobilgisayar endüstrisinin gelişimidir. Mikrobilgisayarlarla beraber, küçük işletmeler de bilgisayar alabilir ve kullanabilir duruma gelirler (Campbell-Kelly, 1995).
Donanım, Intel şirketinin kurucularından Gordon Moore’un 19 Nisan 1965 yılında yayınlanan makalesinde öngördüğü gibi çok hızlı bir şekilde gelişir. Moore, 1965 yılında mikroişlemciler içindeki transistör sayısının her yıl iki katına çıkacağını öngörmüş, 1975 yılında ise bunu “her iki yılda bir iki katına çıkacak” şeklinde düzeltmiştir. Moore, 2005 yılında kendisiyle yapılan bir söyleşide bu öngörüsünün bir süre sonra geçersiz olabileceğini belirtir.
Fakat aynı parlak gelişim çizgisi yazılım alanında görülmez. Yazılım geliştirme ve verimlilik hep sorunlu olagelir. Edsger Dijkstra 1972 yılında şöyle yazmaktadır:
Yazılım krizinin temel nedeni, bilgisayarların birkaç kat daha güçlü hale gelmiş olmasıdır. Açıkça söylersek, bilgisayarlar yokken programlama gibi bir derdimiz yoktu, birkaç zayıf bilgisayarımız olduğunda programlama basit bir sorundu ve şimdi dev gibi bilgisayarlarımız var ve programlamanın kendisi de dev gibi bir sorun.
Dijkstra’nın vurguladığı gibi daha güçlü donanım, daha geniş ve karmaşık yazılımları gündeme getirmiştir ve bunun kendisi başlı başına bir sorundur. Bu sorun, yazılım krizi olarak adlandırılır. Krizin başlıca görünümleri şunlardır:
• Aşılan proje bütçeleri
• Zamanında tamamlanamayan projeler
• Geliştirilen yazılımın verimsiz ve düşük kalitede olması
• Çoğu zaman ihtiyaçları tam karşılayamaması
• Yazılım kodunun yönetilemez (unmanagable) ve desteklenemez (unmaintainable) oluşu
• Yazılımın hiç teslim edilememesi
Günümüzde de kısmen devam eden yazılım krizini aşağıdaki şekilde karikatürize etmek de mümkün:
Yazılım mühendisliği, bu krizi aşma amacıyla, yazılım geliştirmenin bir mühendislik çerçevesinde değerlendirilebileceği iddiasıyla gündeme gelir. Bu doğrultuda, çeşitli yazılım geliştirme metotları geliştirilir. Donanımdaki gelişim hızına hiçbir zaman erişilememiş olmasına karşın önemli başarılar da elde edilir.
Peki yazılım geliştirmeyi zor yapan nedir?
Brooks (1995), ilk kez 1986 yılında yayınlanan ve büyük yankı uyandıran, “Gümüş Kurşun Yok: Yazılım Mühendisliğinde Töz ve İlinek” (No Silver Bullet- Essence and Accident in Software Engineering ) başlıklı makalesinde bu konuyu tartışmakta ve donanımdaki gibi bir gelişimin yazılımda olanaklı olmadığını vurgulamaktadır. Brooks’un yazılım konusundaki temel tezlerine geçmeden önce, makalesinin başlığını açıklığa kavuşturmak gerekiyor. Gümüş kurşun, Avrupa masallarında kurtadamlara, cadılara ya da canavarlara karşı etkili olan tek kurşun tipi. Brooks, töz (essence) ve ilinek (accident) kavramlarını Aristoteles felsefesinden alır. Töz ile bir nesneyi neyse o yapan özellikleri anlatmak ister. İlineğin ise kendi başına bir varlığı yoktur, tözle birlikte var olur ve tözü değiştirmeksizin değişebilen bir niteliktir. Orhan Hançerlioğlu’nun Felsefe Sözlüğü’nde dikkat çektiği gibi ilinek terimini olumsal terimi ile karıştırmamak gerekir. Olumsal, hiçbir şeyle belirlenmemiştir. İlinek ise tözle belirlenir. Örneğin, elmanın rengi bir ilinektir. Elmanın rengi zamanla değişip yeşil, sarı, kırmızı olsa da, elma hep elma olarak kalır.
Brooks, yazılım projelerinin gelişimini, insandan kurda dönüşen kurtadamlara benzetmektedir. Sorunsuz başlayan ve bir süre böyle devam eden masum yazılım projeleri bir süre sonra kurtadam olmaktadır: Zamanında ya da hiç teslim edilemeyen ürünler, bütçe açıkları, kullanıcıların ihtiyacını tam karşılayamama… Bu kurtadamı yok edecek gümüş kurşuna olan ihtiyaç her geçen gün kendini daha çok hissettirmektedir. Donanımların performansı artıp fiyatları düşerken neden yazılımda aynı başarı elde edilememektedir?
Brooks, donanımdaki hızlı gelişimin yazılımda yaşanamayacağını iddia eder. Birincisi, donanımdaki gelişim, iki yılda iki katına çıkma, zaten sıra dışı bir olgudur. İkincisi yazılımın doğası, benzer bir gelişime olanak vermez. Yazılımla beraber, kafa ve kol emeği tartışması daha farklı bir noktaya taşınmaktadır. Yazının başındaki tanımları hatırlarsak, donanım bilgisayarın maddi, yazılım ise maddi olmayan bileşenlerine işaret eder. Dolayısıyla, bir elektronik mühendisinin donanımdaki kafa emeğinin ürünü elle tutulur hale gelirken, yazılım mühendisinin emeği sadece biçim değiştirir ama maddileşemez. Sanat eserlerinde de benzer bir durum söz konusudur. Ama bilişim teknolojilerinin, dolayısıyla yazılımın, dünya ekonomisindeki yeri dikkate alındığında sorun daha kritik hale gelir. Brooks’a göre yazılım geliştirmede harcanan emeği, Aristoteles’ten hareketle, tözsel ve ilineksel olarak ikiye ayırmak gerekir. Tözsel, yazılımın doğasına içsel olan ögeleri, ilineksel ise yazılımın doğasında olmayan ama yine de onun bir parçası olan ögeleri belirtir. Bu bağlamda, yazılımdaki tözsel emek, maddi olan ilişkilerin zihinde algoritmalar, veri kümeleri, ilişkiler vb halde soyutlanmasını, ilineksel emek ise bu soyutlamanın programlama dilleri ve benzeri araçlarla donanım üzerinde somutlanmasını ifade eder. Brooks, yazılım geliştirmedeki asıl zorluğun, programlamada ve testte değil, soyutlamada olduğunu vurgular.
Brooks’s göre yazılımın tözünün temel özellikleri şunlardır: karmaşıklık, uygunluk, değişkenlik, görünmezlik.
Karmaşıklık
Yazılım sistemleri, çok sayıda benzer parçadan oluşan otomobillerden ve binalardan farklıdır. Yazılım, birbirine benzemeyen çok sayıda parçadan oluşur. Bunun yanında, herhangi bir yazılım sisteminin içerdiği olası durumlar maddi sistemlere göre daha fazladır. Doğal olarak bu da yazılım geliştirenlerin göz önünde bulundurması gereken durumları arttırır.
Bir binada yaşayan kişi sayısını iki katına çıkarmak için çoğu zaman kullanılan fiziksel kaynakları iki katına çıkarmak yeterlidir. Ancak bir yazılım, aynı anda 100 kullanıcıya hizmet verebiliyorsa bu sayıyı 200 yapmak için aynı yazılımdan iki tane çalıştırmak yeterli olmayacaktır. Yazılımın kendisine içsel olan bu karmaşıklık, yazılım projelerinin yönetimine de yansır. Proje ekibi genişledikçe, iletişim sorunları nedeniyle soyut olanın içerdiği karmaşıklık daha da büyür.
Uyumluluk
Karmaşıklık, yalnızca yazılıma özgü bir durum değildir. Örneğin fizikte de karmaşık olgular üzerine çalışılır. Fakat bu çalışmalar çoğu zaman belirli bir alana odaklanır ya da belirli bir düzen içinde var olan evrene dair genel açıklamalar geliştirilmeye çalışılır. Evrende bir uyum aranır.
Yazılım sistemleri ise sürekli diğer sistemlerle ilişki halinde var olurlar. Başka sistemlerle uyumlu çalışma zorunluğu, karmaşıklığı daha da arttırır. Ayrıca, yazılımlardan donanım alanındaki gelişmelere ve farklılıklara karşı duyarlı olması ve çalışmasını ona göre devam ettirmesi beklenir.
Değişkenlik
Yazılım somut ihtiyaçların önce kavramsal soyutlanması, sonrasında bu ihtiyaçların programlama dilleri aracılığıyla somutlanmasıdır. İnşa edilen bir binada, binanın mimarisine ait bir değişiklik yapmadan yıllarca oturulabilir. Değişiklik, satılan bir binada ya da otomobilde istisnadır. Fakat sadece, geliştirilen ve kullanılmayan yazılım değişmez. Yazılımlar, kullanılmaya başlandıktan sonra, hiçbir hata içermese bile,
• Kullandıkça, yeni ihtiyaçların farkına varılması
• Donanım teknolojisinin değişmesi
• Farklı sistemlerle entegrasyon ihtiyacı
vb nedenlerle değiştirilir.
Değiştirilen veya genişletilen her yazılımın içerdiği karmaşıklık daha da artar. Bu değişiklikler, önceden dikkate alınıp bir yazılım geliştirilmiş olsa toplam karmaşıklık x değerinde olacaktır. Ama var olan bir yazılıma yeni özelliklerin eklenmesi bu karmaşıklığı x’ten çok daha büyük yapar. Bu nedenle, yazılıma daha sonradan eklenen her özellik yazılımı daha karmaşık hale getireceğinden bir müddet sonra yazılım bu karmaşıklığı kaldıramayacak noktaya gelebilir ve yazılım yeniden yazılabilir.
Görünmezlik
Yazılımın yukarıdaki özellikleri, bir modele aktarılmasını da zorlaştırır. İçerdiği ilişkilerin karmaşıklığı yanında bunların dinamik ilişkiselliği modellenmesini problemli hale getirir. Bu durum, özellikle birden fazla kişinin geliştirdiği yazılımlarda ortak bir kavrayışın oluşturulmasında önemli bir engel haline gelir.
Brooks, son yıllarda yazılım mühendisliğindeki gelişmelerin yazılımın tözünden çok, ilineksel özelliklerine yoğunlaştığını ve bu alandaki sorunları gidermek için çalışmalar yaptığını belirtir. Örneğin, yüksek düzeyli (high level) programlama dilleri, işletim sistemlerinin aynı anda birden fazla işi yapabilmesi (time-sharing) ve bütünleşik programlama ortamlarının oluşturulması (Unified programming environments) yalnızca yazılımın donanım üzerinde ifadesinde karşılaşılan sorunları azaltabilmiş fakat tözsel sorunlarda herhangi bir değişiklik olmamıştır.
Buna karşın, çok sayıda gümüş kurşun önerileri de gelmiştir. Örneğin bunların en önemlisi olan nesne yönelimli programlama, gerçek ilişkilerin soyutlanması ve bunların bilgisayar üzerindeki temsili arasındaki arasındaki uçurumu kapatmış, farklı bileşenlerin birbirleriyle uyumunu arayüzler aracılığıyla arttırmıştır. Yazılımın modellenmesi ve görünür hale getirilmesi için çeşitli öneriler getirilmiştir. Ayrıca, gelişmiş geliştirme ortamlarının kullanılmasının yazılım geliştirmedeki tözsel zorlukların üstesinden gelebileceği iddia edilmiştir. Fakat Brooks, önerilen bu gümüş kurşunların kurtadamı tam anlamıyla alt edemediğini belirtmektedir.
Brooks’un makalesinin ilk kez 1986 yılında yayınlandığını bir kez daha hatırlatıp, yazılımın tözsel sorunların aşılmasına yönelik önerilerine göz atmakta fayda var. Brooks’un önerilerinin günümüzde çeşitli yazılım metotlarında somutlandığını görüyoruz:
Geliştirmek yerine satın almak: Herhangi bir yazılımı sıfırdan geliştirmek yerine tasarlanan sistemin bazı bileşenlerini satın almak daha uygun olabilir. Bunun için öncelikle, çeşitli paketlerin satılabildiği bir yazılım piyasasına gereksinim vardır. Günümüzde, Brooks’un bu önerisi olağan hale geldiği gibi özellikle özgür ve açık kaynak kodlu yazılım depoları (bkz. http://sourceforge.net) yazılım mühendislerine eşsiz olanaklar sunmaktadır. Tasarlanan herhangi bir sistemde kullanılması planlanan özelleşmiş bileşenler ya da uygulamalar, bu depolardan bulunup, gerektiğinde kaynak kodları değiştirilerek sisteme entegre edilebilirler.
Gereksinimleri belirleme ve prototip oluşturma: Yazının başında yer alan karikatürde gösterilmek istendiği gibi yazılım geliştirmenin en zor aşamalarından biri kullanıcı isteklerinin belirlenmesidir. Kullanıcı çoğu zaman ne istediğin bilmez, bilse bile bu isteğin programcılara aktarılması yazılımın tözsel özelliklerinden dolayı zordur. Kullanıcı gereksinimlerini belirlemek için prototipler oluşturulması ve kullanıcıya sunulması, ihtiyaçların kavramsal inşasına yardımcı olacaktır.
Artımlı Geliştirme: Klasik mühendislik projelerinde analiz, tasarım, gerçekleştirim ve test birbirini takip eden aşamalardır. Ancak yazılım mühendisliği, nesnesinin soyut olmasıyla diğer mühendisliklerden ayrılır. Brooks’un belirttiği yazılım özsel niteliklerini de anımsarsak, yazılımı bir bina gibi inşa edip sonlandırmak mümkün değildir. Yazılım yazılmaz veya inşa edilmez; geliştirilir ve büyür. Hedef, bir son ürünün inşa edilip kullanıcıya teslim edilmesinden çok karmaşıklığın kontrol altına alınabildiği, diğer sistemlerle uyumlu çalışan ve istenen değişikliklere cevap verebilecek bir yazılım geliştirmektir. Brooks’un artımlı geliştirme önerisi, günümüzde bir çok yazılım geliştirme metodunda içselleştirilmiştir.
Brooks’un makalesinin üzerinden 25 yıldan fazla bir zaman geçti. Töz ve ilinek ayrımı felsefede eski bir tartışma konusu. Fakat, yazılım mühendisliğinin 1980lerdeki, hatta 1990lardaki düzeyi değerlendirildiğinde soyut kavramlar oluşturma ve bu kavramların programlama dilleri aracılığıyla bilgisayar üzerinde somutlanması arasındaki ayrım anlamlıdır. Fakat, Brooks’un da değindiği, nesne yönelimli programlama ile başlayan süreç ve yeni yazılım geliştirme metotları günümüzde soyutlama ve somutlama arasındaki uçurumu da büyük oranda kapatmıştır. Nesne yönelimli programlama, nesne yönelimli analizi ve tasarımı da olanaklı hale getirmiştir.
1960ların sonunda, yazılım kriziyle beraber vurgulandığı gibi yazılım üretiminin mühendisliğe ihtiyacı vardır. Fakat yazılım mühendisliği, yeni bir mühendisliktir ve diğer mühendisliklerde olduğu gibi arkasında yüzyılların fizik ve kimya birikimi yoktur. Zaman zaman, soyutla daha içli dışlı olan felsefeden ve matematikten kendisine bir şeyler arar. Yazılımların grafiksel kullanıcı arayüzlerinin hazırlanmasında bilişsel psikolojinin tespitlerinden faydalanırlar.
Ancak hala yazılım mühendislerinin ellerinde klasik mühendisliklerin formülleri ve T cetvelleri yok. Kurtadamla mücadele devam ediyor. Yazılım geliştiriciler karşılaştıkları sorunları analiz ediyorlar, çözümler üretiyorlar ve bu çözümlerini pratikte sınıyorlar. Tüm sorunlar aşılamamış olmasına rağmen yazılım mühendisliği, yazılıma içsel olan sorunların farkında olması ve metotlarıyla adım adım kendini oluşturuyor.
Kaynaklar
Brooks, Fred P. (1995). The Mythical Man-Month, Addison-Wesley, s 180-226
Campbell-Kelly, M. (1995). Development and structure of the international software industry, 1950-1990. BUSINESS AND ECONOMIC HISTORY, Volume 24, no. 2, Winter.
OECD (1985). Software: An Emerging Industry. Information Computer Communucations Policy, Paris.
* Bu yazı Bilim ve Gelecek Dergisinin Eylül 2012 tarihli sayısında yayınlanmıştır.