Yazılım bakımı, software maintenance
Yazılıma Bakalım Mı?
Daha önceki yazılarda sıklıkla, yazılımın değişmek için geliştirildiğini ve değişmenin yazılım için kaçınılmaz olduğunu yazdım. Bu anlamda bu yazı, bu yazının devamı niteliğinde ama başlığını değiştirdim.
Yazılımın bakımı ya da kısaca İngilizcesiyle “maintenance” dediğimiz sürece biraz daha yakından bakalım bu yazıda.
IEEE’nin 1219 nolu standardına göre yazılım bakımı yani software maintenance şöyle tanımlanıyor:
“the modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment.”
“müşteriye teslimden sonra, hataları gidermek, performans ve diğer özellikleri iyileştirmek, ya da farklı bir ortama uyarlamak için yazılım ürününün değiştirilmesidir. ”
Bakım dediğimizde kabaca şu dört çalışmadan birisini anlarız:
Düzeltme ya da iyileştirme (corrective): Bu tür bakımda yazılım sisteminin hataları giderilir, yani “bug fix” dediğimiz çalışmaları içerir. Yazılım sistemindeki hatalar bazen ihtiyaçların yanlış-eksik alınmasından, bazen tasarım hatalarından bazen de her şeye rağmen yanlış kodlamadan kaynaklanır. Belli ki bu hatalar testlerde de yakalanmamış ve müşterinin önüne kadar gelmiştir.
Uyarlama (adaptive): Bu tür bakım yazılım sistemini yeni ortamlara hazırlamak içın yapılır. Yeni donanım, yeni yazılım vb., yazılımın ortamındaki yeniliklere uyum sağlamak için yapılan değişikliklerdir. Sistemi yeni donanım ya da işletim sistemi ortamına taşımak, derleyicinin (compiler) ya da örneğin JVM’in sürümünü değiştirmek bu türden uyarlama çalışmalarıdır.
Yeni geliştirme (ya da zenginleştirme)/mükkemelleştirme (enhancement/perfective): Bu tür bakımda yazılıma yeni davranışlar katılır. Yeni süreçler, yeni iş kuralları, yeni kısıtlar vb. fonksiyonel yapılar yazılıma kazandırılır. Örneğin yeni tür kullanıcılar sisteme yeni ihtiyaçlarla katılırlar.
Önleyici (preventive): Yazılımın zamanla kalitesinin düşmesi karşısında yapılan ve yazılımın kalitesini arttırmaya yönelik bakım çalışmalarıdır. Bu türden çalışmalar “reengineering” olarak da adlandırılır. Mimari iyileştirmeler, sistemin modülerliğini arttırıcı, alt yapıların birbirlerine olan bağımlılıklarını azaltıcı yöndeki çalışmalar hep bu türdendir.
Tabi olarak yazılıma yapılan bir türden değişiklik başka türden bir değişikliği tetikleyebilir. Örneğin bir hatanın giderilmesi bazı mimari iyileştirmeleri gerekli kılabilir. Ya da bazı mimari iyileştirmeler için derleyicinin sürümünü yükseltmek ya da sistemi farklı bir platforma taşımak gerekebilir. P. Grubb ve A. A. Takang’ın “Software Maintenance” isimli kitabında bu ilişkiler şöyle resmedilmektedir:
Yazılımın bakımını etkileyen pek çok faktör vardır. Yazılımın tipi, kullanıcı çeşitliliği ve eğitim seviyesi, yazılımın yerine getirdiği iş süreçlerinin ve kurallarının tabiatı, hep bakımla ilgili belirleyici etkenlerdendir.
Bakımın mahiyetini daha iyi anlamak için Robert L. Glass’ın 2002 yılında basılmış olan “Fact and Fallacies of Software Engineering” isimli kitabındaki gerçeklerden bakım ile ilgili olan beş tanesini aktarmak istiyorum.
Adı geçen kitabın 41 numaralı gerçeği de şudur:
“Maintenance typically consumes 40 to 80 percent (average, 60 percent) of software costs. Therefore, it is probably the most important life cycle phase of software.”
“Bakım yazılımın maliyetinin tipik olarak %40 ila %80’ini (ortalama olarak %60) oluşturur. Bu yüzden muhtemelen yazılımın hayat döngüsündeki en önemli kısımdır.”
Bundan daha önce de bahsetmiştik: “Değiştirmek için geliştirmek.”
Aynı kitabın 42. gerçeği ise şudur:
“Enhancement is responsible for roughly 60 percent of software maintenance costs. Error correction is roughly 17 percent. Therefore, software maintenance is largely about adding new capability to old software, not fixing it.”
“Yeni geliştirmeler yazılım bakım maliyetinin kabaca %60’ını oluşturmaktadır. Hata giderme kabaca %17sini oluşturmaktadır. Dolayısıyla, yazılım bakımı, hataları gidermekten ziyade çoğunlukla yazılıma yeni yetkinlikler kazandırmaktır.”
Glass, kitabında bu son iki gerçeği 60/60 kuralı olarak birleştirir. Yani yazılımın bakımı, tüm maliyetinin %60’ını, yeni geliştirmeler ise bakımın maliyetinin %60’ını oluşturmaktadır. Buna göre eski yazılıma yeni özellikler kazandırmak pahalı bir iştir.
Kitabın 43. gerçeği ise şudur:
“Maintenance is a solution, not a problem.”
“Bakım bir çözümdür, problem değildir.”
Bu madde gerçekten çok bir fikir gibi görünmekle birlikte ciddi bir yanlışımıza parmak basıyor. Yazılım bakımını bir dert olarak görmek sağlıklı bir bakış açısı değildir. Çoğu zaman yazılımın bakımını dert oalrak görme eğiliminde oluruz. Halbuki bakım, yazılımı yaşatan şeydir. Bakımı yapılmayan yazılım muhtemelen kısa süre içinde kullanımdan da kalkacaktır.
Kitabın 44. gerçeği ise şöyle:
“In examining the tasks of software development versus software maintenance, most of the tasks are the same—except for the additional maintenance task of “understanding the existing product.” This task consumes roughly 30 percent of the total maintenance time and is the dominant maintenance activity. Thus it is possible to claim that maintenance is a more difficult task than development.”
“Yazılım geliştirme ve yazılım bakımı işleri incelendiğinde, ‘var olan sistemin anlaşılması’ şeklindeki fazladan bir bakım işi dışında”, pek çok iş aynıdır. Bu fazladan iş ise toplam bakım zamanının yaklaşık olarak %30’unu almaktadır ve en baskın bakım çalışmasıdır. Bu yüzden bakımın, geliştirmeden daha zor bir iş olduğu iddia edilebilir.”
Kitabın 45. ve bakım ile ilgili son gerçeği ise şöyle:
“Better software engineering development leads to more maintenance, not less.”
“Daha iyi yazılım mühendisliği gelişimi daha az değil daha fazla bakıma yol açar.
Bu insana ters gelen bir durum değil mi? İlk etapta “nasıl yani” dedirtiyor insana ama şu gerçeği gözden kaçırmayalım. Daha kaliteli yazılım, daha çok değişme demektir. Çünkü kaliteli yazılımlar değişir, kalitesiz yazılımlar, değişimi zor olduğundan kenara atılırlar, yerlerine daha yeni ve kaliteli olan yazılımlar gelir. Dolayısıyla, modern zamanlarda yazılımın bakım maliyeti, önceki zamanlara göre artmaktadır:
Yukarıda bu durum resmedilmiştir. (Bu diyagramı http://www.omnext.net/downloads/Whitepaper_Omnext.pdf adresindeki “How to save on software maintenance costs” başlıklı Mart 2010 tarihli bir Omnex araştırmasından aldım.) Konu ile ilgili buradaki Schach’in kitabından alınan diyagramlara da bakabilirsiniz.
Konuyla ilgili bazı online kaynaklar şunlardır:
« Yazılım ve Değişim – II	» Programcı Psikolojisi ve Yazılım Kalitesi
27 Ağustos 2014	@ 10:01
Yazılımın bakımı(yeni özellikler katılması, mevcut özelliklerin değiştirilmesi, hataların düzeltilmesi) için harcanan zaman ve paranın, kısaca maliyetin artmasının nedenlerini zaman zaman düşünüyorum. Bunda yazılım geliştirme araç ve metodolojilerinin gelişmesinden ziyade internetin gelişmesi ve yaygınlaşmasının etkisi olduğunu düşünüyorum. İnternetin yaygınlaşmasından önce bir uygulama yapardınız ve bunu sadece o lokasyonda bulunan insanlar kullanırdı. Klasik bir veritabanı yazılımı olurdu çoğu zaman. Şimdi bunu o lokasyonu düşünerek geliştirmiyorsunuz. Yurt çapında ve/veya dünya çapında kullanıcıları olan bir yazılım talep ediliyor. Ve hatta bireysel son kullanıcıya yani direkt müşteriye açıyorsunuz uygulamayı. Ve aynı zamanda web servisler ile bir çok kurumla etkileşimli oluyor. Tabi bir de son yıllarda çok artan mobil kullanım ve bunun getirdiği/getireceği talepler… Bunlar yazılımı da, talepleri de muazzam derecede büyütüyor….
27 Ağustos 2014	@ 11:06
Dediklerinizi soyle ozetleyebiliriz: Artan kullanici cesitliligi ve erisim yonetemleri ile kurumlar arasi entegrasyonlar. Artik ilkokul mezunu insanlarin gunluk yasaminda kullandigi bir kac tane yazilim var. Bankalarin web siteleri, online alis-veris ortamlari, online fatura odeme sistemleri vs. Ayrica, dunya gittikce daha birbirinden haberdar, daha birbirine bagli hale geliyor. Bu hem hukuki duzenlemeler hem de cok girisken ve fark yaratmaya calisan pazarlama politikalari sonucunda ortaya cikiyor. Ve dediginiz gibi, kabak biizm basimiza patliyor 🙂
28 Ağustos 2014	@ 16:39
Evet çok iyi özetlemişsiniz aslında. Bu değişimlerin sonuçları biz yazılımcılar açısından bazen iyi bazen kötü olabiliyor…Ben de teşekkür ederim vermiş olduğunuz bilgiler için…
28 Ağustos 2014	@ 17:34