Yazılım bakımı - Software maintenance
| Yazılım geliştirme |
|---|
Yazılım mühendisliğinde yazılım bakımı , teslimattan sonra hataları düzeltmek, performansı veya diğer özellikleri iyileştirmek için bir yazılım ürününün değiştirilmesidir.
Yaygın bir bakım algısı, yalnızca kusurların düzeltilmesini içerdiği yönündedir . Bununla birlikte, bir çalışma, bakım çabasının %80'inden fazlasının düzeltici olmayan eylemler için kullanıldığını göstermiştir. Bu algı, gerçekte sisteme işlevsellik geliştirmeleri olan sorun raporları gönderen kullanıcılar tarafından sürdürülür. Daha yeni çalışmalar, hata düzeltme oranını %21'e yaklaştırıyor.
Tarih
Yazılım bakımı ve sistemlerin evrimi ilk olarak 1969'da Meir M. Lehman tarafından ele alındı . Yirmi yılı aşkın bir süre boyunca araştırmaları Lehman Kanunlarının formüle edilmesine yol açtı (Lehman 1997). Araştırmasının temel bulguları, bakımın gerçekten evrimsel bir gelişme olduğu ve bakım kararlarının zaman içinde sistemlere (ve yazılımlara) ne olduğunu anlayarak yardımcı olduğu sonucuna varıyor. Lehman, sistemlerin zaman içinde gelişmeye devam ettiğini gösterdi. Geliştikçe , karmaşıklığı azaltmak için kodu yeniden düzenleme gibi bir işlem yapılmadıkça daha karmaşık hale gelirler . 1970'lerin sonlarında, Lientz ve Swanson tarafından yapılan ünlü ve yaygın olarak alıntılanan bir anket çalışması , bakım için harcanan yaşam döngüsü maliyetlerinin çok yüksek bir kısmını ortaya çıkardı .
Anket, bakım çabasının yaklaşık %75'inin ilk iki tipte olduğunu ve hata düzeltmenin yaklaşık %21'ini tükettiğini gösterdi. Daha sonraki birçok çalışma, benzer bir sorun büyüklüğü önermektedir. Araştırmalar, yeni gereksinim verilerinin toplanması ve analizi sırasında son kullanıcıların katkısının çok önemli olduğunu göstermektedir. Yazılım geliştirme ve bakım sırasındaki herhangi bir sorunun ana nedeni budur. Yazılım bakımı önemlidir, çünkü genel yaşam döngüsü maliyetlerinin büyük bir bölümünü tüketir ve ayrıca yazılımın hızlı ve güvenilir bir şekilde değiştirilememesi, iş fırsatlarının kaybedilmesi anlamına gelir.
Yazılım bakımının önemi
Anahtar yazılım bakım sorunları hem yönetimsel hem de tekniktir. Anahtar yönetim konuları şunlardır: müşteri öncelikleriyle uyum, personel alımı, bakımı hangi kuruluşun yaptığı, maliyetlerin tahmin edilmesi. Temel teknik konular şunlardır: sınırlı anlayış, etki analizi , test etme, sürdürülebilirlik ölçümü.
Yazılım bakımı, hata düzeltmeyi, yeteneklerin geliştirilmesini, eski yeteneklerin silinmesini ve optimizasyonu içeren çok geniş bir faaliyettir. Değişim kaçınılmaz olduğu için değerlendirme, kontrol ve değişiklik yapma mekanizmaları geliştirilmelidir.
Bu nedenle, işletime alındıktan sonra yazılımı değiştirmek için yapılan her türlü çalışma bakım işi olarak kabul edilir. Amaç, yazılımın değerini zaman içinde korumaktır. Değer, müşteri tabanını genişleterek, ek gereksinimleri karşılayarak, kullanımı kolaylaşarak, daha verimli hale gelerek ve daha yeni teknolojiler kullanarak artırılabilir. Bakım 20 yıl, geliştirme ise 1-2 yıl sürebilir.
Yazılım bakım planlaması
Yazılımın ayrılmaz bir parçası, yazılım geliştirme sırasında oluşturulacak doğru bir bakım planı gerektiren bakımdır. Kullanıcıların nasıl değişiklik talep edeceğini veya sorunları nasıl bildireceğini belirtmelidir. Bütçe, kaynak ve maliyet tahminlerini içermeli ve her yeni sistem özelliğinin ve kalite hedeflerinin geliştirilmesi için yeni bir karar verilmelidir. Geliştirme sürecinden sonra 5+ yıl (hatta on yıllar) sürebilen yazılım bakımı, yazılım bakımının kapsamını, teslimat/dağıtım sonrası sürecin uygun hale getirilmesini, kimin alacağının belirlenmesini ele alabilen etkili bir plan gerektirir. bakım ve yaşam döngüsü maliyetlerinin bir tahminini sağlar.
Yazılım bakım süreçleri
Bu bölüm altı yazılım bakım sürecini şu şekilde açıklamaktadır:
- Uygulama süreci, bakım planının tasarlanması ve oluşturulması gibi yazılım hazırlama ve geçiş faaliyetlerini içerir; geliştirme sırasında belirlenen sorunların ele alınması için hazırlık; ve ürün konfigürasyon yönetiminin takibi.
- Uygulamanın ardından gerçekleştirilen problem ve modifikasyon analizi süreci bakım grubunun sorumluluğundadır. Bakım programcısı her talebi analiz etmeli, onaylamalı (durumu yeniden üreterek) ve geçerliliğini kontrol etmeli, araştırmalı ve bir çözüm önermeli, talebi ve çözüm önerisini belgelemeli ve son olarak değişiklikleri uygulamak için gerekli tüm yetkileri almalıdır.
- Değişikliğin kendisinin uygulanmasını dikkate alan süreç.
- Değişikliğin bir çözüm sağladığından emin olmak için talebi gönderen kişi ile değiştirilmiş çalışmayı onaylayarak değişikliğin süreç kabulü.
- Geçiş süreci ( örneğin platform geçişi ) olağanüstüdür ve günlük bakım görevlerinin bir parçası değildir. Yazılımın işlevsellikte herhangi bir değişiklik olmaksızın başka bir platforma taşınması gerekiyorsa, bu süreç kullanılacak ve bu göreve muhtemelen bir bakım proje ekibi atanacaktır.
- Son olarak, son bakım süreci, yine günlük olarak gerçekleşmeyen bir olay, bir yazılım parçasının kullanımdan kaldırılmasıdır.
Bakımcılara özgü bir dizi süreç, etkinlik ve uygulama vardır, örneğin:
- Geçiş: bir sistemin geliştiriciden bakımcıya aşamalı olarak aktarıldığı kontrollü ve koordineli faaliyetler dizisi
- Bakımcılar tarafından müzakere edilen Hizmet Düzeyi Anlaşmaları (SLA'lar) ve özel (etki alanına özgü) bakım sözleşmeleri
- Değişiklik Talebi ve Sorun Raporu Yardım Masası: Bakımcılar tarafından aldıkları talepleri önceliklendirmek, belgelemek ve yönlendirmek için kullanılan bir sorun giderme süreci
Yazılım bakım kategorileri
EB Swanson başlangıçta üç bakım kategorisi tanımladı: düzeltici, uyarlanabilir ve tamamlayıcı. IEEE 1219 standardı tarafından Haziran 2010'da yürürlükten P14764 . Bunlar o zamandan beri güncellendi ve ISO/IEC 14764 şunları sunuyor:
- Düzeltici bakım : Tespit edilen sorunları düzeltmek için teslimattan sonra gerçekleştirilen bir yazılım ürününün reaktif modifikasyonu. Düzeltici bakım, otomatik hata düzeltme ile otomatikleştirilebilir .
- Uyarlamalı bakım: Bir yazılım ürününü değişen veya değişen bir ortamda kullanılabilir durumda tutmak için teslimattan sonra gerçekleştirilen modifikasyon.
- Kusursuz bakım: Bir yazılım ürününün teslimattan sonra performansını veya sürdürülebilirliğini artırmak için modifikasyonu .
- Önleyici bakım : Bir yazılım ürününün teslimattan sonra, yazılım ürünündeki gizli hataları, etkin hatalar haline gelmeden önce tespit etmek ve düzeltmek için modifikasyonu.
Ayrıca, yazılımın toplam sahip olma maliyetini düşürmek için yaptığınız tüm iyi şeyler olan teslimat öncesi/sürüm öncesi bakım kavramı da vardır. Yazılım sürdürülebilirlik hedeflerini içeren kodlama standartlarına uygunluk gibi şeyler. Yazılımın kuplaj ve uyum yönetimi. Yazılım desteklenebilirlik hedeflerine ulaşılması (örneğin SAE JA1004, JA1005 ve JA1006). Bazı akademik kurumlar, tasarım belgeleri ve sistem/yazılım anlama eğitimi ve kaynakları gibi kaynakların eksikliğinden dolayı devam eden yazılım bakımının maliyetini ölçmek için araştırmalar yürütüyor (mevcut tasarım verilerinin olmadığı durumlarda maliyetleri yaklaşık 1.5-2.0 ile çarpın) .
Bakım faktörleri
Temel ayarlama faktörlerinin bakım üzerindeki etkisi (maksimum olumlu etki sırasına göre sıralanmıştır)
| Bakım Faktörleri | Artı Aralığı |
|---|---|
| Bakım uzmanları | %35 |
| Yüksek personel deneyimi | %34 |
| Tabloya dayalı değişkenler ve veriler | %33 |
| Temel kodun düşük karmaşıklığı | %32 |
| Y2K ve özel arama motorları | %30 |
| Kod yeniden yapılandırma araçları | %29 |
| Yeniden mühendislik araçları | %27 |
| Üst düzey programlama dilleri | %25 |
| Tersine mühendislik araçları | %23 |
| Karmaşıklık analizi araçları | %20 |
| Kusur izleme araçları | %20 |
| Y2K "toplu güncelleme" uzmanları | %20 |
| Otomatik değişiklik kontrol araçları | %18 |
| ödenmemiş fazla mesai | %18 |
| Kalite ölçümleri | %16 |
| Resmi temel kod denetimleri | %15 |
| Regresyon testi kitaplıkları | %15 |
| Mükemmel tepki süresi | %12 |
| > 10 günlük yıllık eğitim | %12 |
| Yüksek yönetim deneyimi | %12 |
| YARDIM masası otomasyonu | %12 |
| Hataya açık modül yok | %10 |
| Çevrimiçi hata bildirimi | %10 |
| Verimlilik ölçümleri | %8 |
| Mükemmel kullanım kolaylığı | %7 |
| Kullanıcı memnuniyeti ölçümleri | %5 |
| Yüksek takım morali | %5 |
| toplam | %503 |
Yalnızca hataya açık modüller zahmetli olmakla kalmaz, aynı zamanda diğer birçok faktör de performansı düşürebilir. Örneğin, çok karmaşık spagetti kodunun güvenli bir şekilde bakımı oldukça zordur. Performansı sıklıkla düşüren çok yaygın bir durum, kusur izleme yazılımı, değişiklik yönetimi yazılımı ve test kitaplığı yazılımı gibi uygun bakım araçlarının eksikliğidir. Aşağıda, yazılım bakımı üzerindeki bazı faktörleri ve etki aralığını açıklayın.
Temel ayarlama faktörlerinin bakım üzerindeki etkisi (maksimum olumsuz etki sırasına göre sıralanmıştır)
| Bakım Faktörleri | Eksi Aralık |
|---|---|
| Hataya açık modüller | -50% |
| Gömülü değişkenler ve veriler | -%45 |
| Personel deneyimsizliği | -%40 |
| Yüksek kod karmaşıklığı | -%30 |
| Y2K özel arama motorları yok | -%28 |
| Manuel değişiklik kontrol yöntemleri | -%27 |
| Düşük seviyeli programlama dilleri | -%25 |
| Kusur izleme aracı yok | -24% |
| Y2K "toplu güncelleme" uzmanı yok | -%22 |
| Kötü kullanım kolaylığı | -18% |
| Kalite ölçümü yok | -18% |
| Bakım uzmanı yok | -18% |
| Zayıf tepki süresi | -%16 |
| Kod denetimi yok | -%15 |
| Regresyon testi kitaplıkları yok | -%15 |
| Yardım masası otomasyonu yok | -%15 |
| Çevrimiçi hata bildirimi yok | -%12 |
| Yönetim deneyimsizliği | -%15 |
| Kod yeniden yapılandırma aracı yok | -%10 |
| Yıllık eğitim yok | -%10 |
| Değişim mühendisliği araçları yok | -%10 |
| Tersine mühendislik araçları yok | -%10 |
| Karmaşıklık analiz aracı yok | -%10 |
| Verimlilik ölçümü yok | -7% |
| Zayıf takım morali | -6% |
| Kullanıcı memnuniyeti ölçümü yok | -4% |
| Ödenmemiş fazla mesai yok | %0 |
| toplam | -500% |
Bakım borcu
2019'daki 27. Uluslararası Yazılım Kalite Yönetimi Konferansı için bir bildiride John Estdale, bir uygulamanın kütüphaneler, platformlar ve araçlar gibi eskiyen dış BT faktörlerine bağımlılığından kaynaklanan bakım ihtiyaçları için “bakım borcu” terimini tanıttı. Uygulama çalışmaya devam eder ve BT departmanı bu teorik yükümlülüğü unutarak daha acil gereksinimlere ve başka yerlerdeki sorunlara odaklanır. Bu tür borçlar zamanla birikir ve sessizce yazılım varlığının değerini tüketir. Sonunda sistem değişikliğini kaçınılmaz kılan bir şey olur.
Sahibi daha sonra sistemin artık değiştirilemeyeceğini keşfedebilir - kelimenin tam anlamıyla sürdürülemez. Daha az dramatik olarak, bakımın işletme sorununu çözmesi çok uzun sürebilir veya çok maliyetli olabilir ve alternatif bir çözüm bulunmalıdır. Yazılım aniden 0 £ değerine düştü.
Estdale, "Bakım Borcunu" şu şekilde tanımlar: bir uygulamanın mevcut uygulama durumu ile ideal arasındaki boşluk, yalnızca tam olarak korunan ve desteklenen harici bileşenlerin işlevselliğini kullanarak. Bu borç genellikle gizlenir veya tanınmaz. Bir uygulamanın genel sürdürülebilirliği, aşağıdakiler de dahil olmak üzere diğer tedarikçilerden her türden bileşenin sürekli olarak elde edilebilirliğine bağlıdır:
- Geliştirme araçları: kaynak düzenleme, yapılandırma yönetimi, derleme ve oluşturma
- Test araçları: test seçimi, yürütme/doğrulama/raporlama
- Yukarıdakileri yürütecek platformlar: donanım, işletim sistemi ve diğer hizmetler
- Üretim ortamı ve kaynak kodu dilinin Çalışma Zamanı Destek Ortamı dahil olmak üzere herhangi bir bekleme/Felaket Kurtarma tesisi ve daha geniş iş planlama, dosya aktarımı, çoğaltılmış depolama, yedekleme ve arşivleme, çoklu oturum açma vb. ekosistemi.
- Ayrı olarak edinilen paketler, örneğin DBMS, grafikler, iletişimler, ara katman yazılımı
- Kaynak kodunda, nesne kodu kitaplıklarında ve diğer çağrılabilir hizmetlerde satın alındı
- Üretim ortamını paylaşan veya söz konusu uygulama ile birlikte çalışan diğer uygulamalardan kaynaklanan gereksinimler
ve tabi ki
- İlgili becerilerin kurum içinde veya piyasada mevcudiyeti.
Bir bileşenin tamamen ortadan kalkması, uygulamayı yeniden oluşturulamaz veya çok yakında sürdürülemez hale getirebilir.
Ayrıca bakınız
- Uygulama emekliliği
- Yazılım Bakım ve Evrim Dergisi: Araştırma ve Uygulama
- Uzun vadeli destek
- Arama tabanlı yazılım mühendisliği
- yazılım arkeolojisi
- Yazılım sorumlusu
- Yazılım geliştirme
Referanslar
daha fazla okuma
- ISO/IEC 14764 IEEE Std 14764-2006 Yazılım Mühendisliği — Yazılım Yaşam Döngüsü Süreçleri — Bakım . 2006. doi : 10.1109/IEEESTD.2006.235774 . ISBN'si 0-7381-4960-8.
- Pigoski, Thomas M. (1996). Pratik Yazılım Bakımı . New York: John Wiley ve Oğulları. ISBN'si 978-0-471-17001-3.
- Pigoski, Thomas M. Yazılım Evrimi ve Bakımı için Açıklama (sürüm 0.5) . SWEBOK Bilgi Alanı.
- Nisan, Alain; Abran, Alain (2008). Yazılım Bakım Yönetimi . New York: Wiley-IEEE. ISBN'si 978-0-470-14707-8.
- Gopalaswamy Ramesh; Ramesh Bhattiprolu (2006). Yazılım bakımı: coğrafi olarak dağıtılmış ortamlar için etkili uygulamalar . Yeni Delhi: Tata McGraw-Hill. ISBN'si 978-0-07-048345-3.
- Grubb, Penny; Takang, Armstrong (2003). Yazılım Bakımı . New Jersey: Dünya Bilimsel Yayıncılık. ISBN'si 978-981-238-425-6.
- Lehman, MM; Belady, Los Angeles (1985). Program evrimi: yazılım değişikliği süreçleri . Londra: Academic Press Inc. ISBN 0-12-442441-4.
- Page Jones, Meilir (1980). Yapılandırılmış Sistem Tasarımı için Pratik Kılavuz . New York: Yourdon Basın. ISBN'si 0-917072-17-0.