Yazılım Bakımına Genel Bakış

Yazılım bakımı artık bir gün SDLC'nin bir parçası olarak kabul edilmektedir. Yazılım ürününün tesliminden sonra yapılan tüm değişiklik ve güncellemeleri ifade eder. Değişikliklerin gerekli olmasının birkaç nedeni vardır, bunlardan bazıları aşağıda kısaca belirtilmiştir:

Market Conditions - Vergilendirme gibi zamanla değişen politikalar ve muhasebenin nasıl sürdürüleceği gibi yeni getirilen kısıtlamalar değişiklik ihtiyacını tetikleyebilir.
Client Requirements - Zamanla, müşteri yazılımda yeni özellikler veya işlevler isteyebilir.
Host Modifications - Hedef ana bilgisayarın herhangi bir donanımı ve / veya platformu (işletim sistemi gibi) değişirse, uyarlanabilirliği korumak için yazılım değişiklikleri gerekir.
Organization Changes - Müşteri tarafında organizasyon gücünün azaltılması, başka bir şirketin satın alınması, yeni bir işe girişme girişiminde bulunulması gibi herhangi bir iş düzeyinde değişiklik varsa, orijinal yazılımda değişiklik yapma ihtiyacı ortaya çıkabilir.

Bakım türleri

Bir yazılım ömrü boyunca bakım türü, doğasına göre değişebilir. Bazı kullanıcılar tarafından keşfedilen bazı hatalar gibi sadece rutin bir bakım görevi olabilir veya bakım boyutuna veya doğasına bağlı olarak başlı başına büyük bir olay olabilir. Aşağıda, özelliklerine göre bazı bakım türleri verilmiştir:

Corrective Maintenance - Bu, kullanıcı tarafından keşfedilen veya kullanıcı hata raporları ile sonuçlanan sorunları düzeltmek veya düzeltmek için yapılan değişiklikleri ve güncellemeleri içerir.
Adaptive Maintenance - Bu, yazılım ürününü güncel tutmak ve sürekli değişen teknoloji ve iş ortamına uygun hale getirmek için uygulanan değişiklikleri ve güncellemeleri içerir.
Perfective Maintenance- Bu, yazılımın uzun süre kullanılabilir durumda kalması için yapılan değişiklikleri ve güncellemeleri içerir. Yazılımın iyileştirilmesi ve güvenilirliği ile performansını iyileştirmek için yeni özellikler, yeni kullanıcı gereksinimleri içerir.
Preventive Maintenance- Bu, yazılımın gelecekteki sorunlarını önlemek için değişiklikleri ve güncellemeleri içerir. Şu anda önemli olmayan ancak ileride ciddi sorunlara yol açabilecek sorunlara katılmayı hedefler.

Bakım Maliyeti

Raporlar, bakım maliyetinin yüksek olduğunu gösteriyor. Yazılım bakımını tahmin etme üzerine yapılan bir araştırma, bakım maliyetinin tüm yazılım süreci döngüsünün maliyetinin% 67'si kadar yüksek olduğunu buldu.

Ortalama olarak, yazılım bakım maliyeti tüm SDLC aşamalarının% 50'sinden fazladır. Bakım maliyetinin yükselmesine neden olan çeşitli faktörler vardır, örneğin:

Bakım Maliyetini etkileyen gerçek dünya faktörleri

Herhangi bir yazılımın standart yaşı 10 ila 15 yıla kadar kabul edilir.
Daha az bellek ve depolama kapasitesine sahip yavaş makinelerde çalışması amaçlanan eski yazılımlar, modern donanımda yeni gelen geliştirilmiş yazılımlara karşı kendilerini zorlayamazlar.
Teknoloji ilerledikçe, eski yazılımı korumak maliyetli hale gelir.
Çoğu bakım mühendisi acemidir ve sorunu gidermek için deneme yanılma yöntemini kullanır.
Çoğu zaman, yapılan değişiklikler yazılımın orijinal yapısına kolayca zarar verebilir ve bu da sonraki değişiklikler için zorlaşır.
Değişiklikler genellikle belgelenmemiş olarak bırakılır ve bu da gelecekte daha fazla çatışmaya neden olabilir.

Bakım Maliyetini etkileyen yazılım sonu faktörler

Yazılım Programının Yapısı
Programlama dili
Dış ortama bağımlılık
Personel güvenilirliği ve kullanılabilirliği

Bakım Faaliyetleri

IEEE, sıralı bakım süreci etkinlikleri için bir çerçeve sağlar. Yinelemeli şekilde kullanılabilir ve özelleştirilmiş öğeler ve süreçlerin dahil edilebilmesi için genişletilebilir.

Bu faaliyetler, aşağıdaki aşamaların her biri ile el ele gider:

Identification & Tracing- Modifikasyon veya bakım gerekliliğinin belirlenmesi ile ilgili faaliyetleri içerir. Kullanıcı tarafından üretilir veya sistem günlükler veya hata mesajları ile raporlayabilir.Burada bakım türü de sınıflandırılır.
Analysis- Değişiklik, güvenlik ve güvenlik sonuçları dahil olmak üzere sistem üzerindeki etkisi açısından analiz edilir. Olası etki şiddetli ise alternatif çözüm aranır. Daha sonra, bir dizi gerekli değişiklik, gereksinim spesifikasyonlarında gerçekleştirilir. Modifikasyon / bakım maliyeti analiz edilir ve tahmin sonuçlandırılır.
Design- Değiştirilmesi veya değiştirilmesi gereken yeni modüller, önceki aşamada belirlenen gereksinim özelliklerine göre tasarlanır. Doğrulama ve doğrulama için test senaryoları oluşturulur.
Implementation - Tasarım aşamasında oluşturulan yapılandırılmış tasarım yardımı ile yeni modüller kodlanır.Her programcının paralel olarak birim testi yapması beklenir.
System Testing- Yeni oluşturulan modüller arasında entegrasyon testi yapılır. Yeni modüller ve sistem arasında entegrasyon testi de yapılır. Son olarak sistem, gerileyen test prosedürleri izlenerek bir bütün olarak test edilir.
Acceptance Testing- Sistem dahili olarak test edildikten sonra kullanıcılar yardımı ile kabulü test edilir. Bu durumda, kullanıcı ele alınan veya bir sonraki yinelemede ele almaları gereken bazı sorunları şikayet ederse.
Delivery- Kabul testinden sonra, sistem ya küçük güncelleme paketi ya da sistemin yeni kurulumu ile tüm organizasyona dağıtılır. Son test, yazılım teslim edildikten sonra istemci tarafında gerçekleştirilir.

Kullanım kılavuzunun basılı kopyasına ek olarak gerekirse eğitim olanağı sağlanır.
Maintenance management- Konfigürasyon yönetimi, sistem bakımının önemli bir parçasıdır. Sürümleri, yarı sürümü veya yama yönetimini kontrol etmek için sürüm kontrol araçlarıyla desteklenir.

Yazılım Yeniden Mühendislik

Yazılımı, işlevselliğini etkilemeden mevcut pazarda tutmak için güncellememiz gerektiğinde, buna yazılım yeniden mühendisliği denir. Yazılım tasarımının değiştirildiği ve programların yeniden yazıldığı kapsamlı bir süreçtir.

Eski yazılımlar, piyasadaki en son teknolojiye ayak uydurmaya devam edemez. Donanımın modası geçmiş hale geldikçe, yazılımın güncellenmesi bir baş ağrısına dönüşür. Yazılım zamanla eskiyse bile işlevselliği yaşlanmaz.

Örneğin, başlangıçta Unix, assembly dilinde geliştirildi. C dili ortaya çıktığında, Unix C'de yeniden tasarlandı çünkü assembly dilinde çalışmak zordu.

Bunun dışında bazen programcılar, yazılımın birkaç parçasının diğerlerinden daha fazla bakıma ihtiyaç duyduğunu ve ayrıca yeniden mühendisliğe ihtiyaç duyduklarını fark ederler.

Yeniden Mühendislik Süreci

Decideneyin yeniden tasarlanacağı. Yazılımın tamamı mı yoksa bir parçası mı?
Perform Mevcut yazılımların özelliklerini elde etmek için Tersine Mühendislik.
Restructure ProgramEğer istenirse. Örneğin, işleve yönelik programları nesneye yönelik programlara dönüştürmek.
Re-structure data gereğince, gerektiği gibi.
Apply Forward engineering yeniden tasarlanmış yazılım elde etmek için kavramlar.

Yazılım yeniden mühendisliğinde kullanılan birkaç önemli terim vardır

Tersine mühendislik

Mevcut sistemi derinlemesine analiz ederek, anlayarak sistem spesifikasyonuna ulaşma sürecidir. Bu süreç ters SDLC modeli olarak görülebilir, yani daha düşük soyutlama seviyelerini analiz ederek daha yüksek soyutlama seviyesi elde etmeye çalışıyoruz.

Var olan bir sistem, hakkında hiçbir şey bilmediğimiz daha önce uygulanan tasarımdır. Tasarımcılar daha sonra koda bakarak tersine mühendislik yapar ve tasarımı elde etmeye çalışır. Ellerinde tasarımla, şartnameleri tamamlamaya çalışırlar. Böylece, koddan sistem belirtimine tersine gidiliyor.

Programın Yeniden Yapılandırılması

Mevcut yazılımın yeniden yapılandırılması ve yeniden yapılandırılması sürecidir. Her şey, aynı programlama dilinde veya bir programlama dilinden farklı bir programlama dilinde kaynak kodunu yeniden düzenlemekle ilgilidir. Yeniden yapılandırma, kaynak kodu yeniden yapılandırmasına ve veri yeniden yapılandırmasına veya her ikisine birden sahip olabilir.

Yeniden yapılandırma, yazılımın işlevselliğini etkilemez, ancak güvenilirliği ve sürdürülebilirliği artırır. Çok sık hatalara neden olan program bileşenleri değiştirilebilir veya yeniden yapılandırma ile güncellenebilir.

Yazılımın eski donanım platformuna olan güvenilirliği, yeniden yapılanma yoluyla ortadan kaldırılabilir.

İleri Mühendislik

İleri mühendislik, tersine mühendislik yoluyla indirgenmiş, eldeki şartnamelerden istenen yazılımın elde edilmesi sürecidir. Geçmişte zaten yapılmış bazı yazılım mühendisliği olduğunu varsayar.

İleri mühendislik, yalnızca tek bir farkla yazılım mühendisliği süreciyle aynıdır - her zaman tersine mühendislikten sonra gerçekleştirilir.

Bileşenin yeniden kullanılabilirliği

Bir bileşen, sistemde bağımsız bir görevi yürüten yazılım programı kodunun bir parçasıdır. Küçük bir modül veya alt sistem olabilir.

Misal

Web'de kullanılan oturum açma prosedürleri bileşenler olarak değerlendirilebilir, yazılımdaki yazdırma sistemi yazılımın bir bileşeni olarak görülebilir.

Bileşenler yüksek işlevsellik uyumuna ve daha düşük bağlantı oranına sahiptir, yani bağımsız olarak çalışırlar ve diğer modüllere bağlı olmadan görevleri yerine getirebilirler.

OOP'de nesneler, endişelerine çok özel tasarlanmıştır ve diğer bazı yazılımlarda kullanılma şansı daha azdır.

Modüler programlamada, modüller, diğer birçok yazılım programında kullanılabilen belirli görevleri gerçekleştirmek için kodlanır.

Yazılım bileşeninin yeniden kullanımına dayanan ve Bileşen Tabanlı Yazılım Mühendisliği (CBSE) olarak bilinen yepyeni bir dikey var.

Yeniden kullanım çeşitli seviyelerde yapılabilir

Application level - Tüm bir uygulamanın yeni yazılımın alt sistemi olarak kullanıldığı yer.
Component level - Bir uygulamanın alt sisteminin kullanıldığı yerlerde.
Modules level - İşlevsel modüllerin yeniden kullanıldığı yerler.

Yazılım bileşenleri, farklı bileşenler arasında iletişim kurmak için kullanılabilen arayüzler sağlar.

Yeniden Kullanım Süreci

İki tür yöntem benimsenebilir: ya gereksinimleri aynı tutarak ve bileşenleri ayarlayarak ya da bileşenleri aynı tutarak ve gereksinimleri değiştirerek.

Requirement Specification - Mevcut sistem, kullanıcı girdisi veya her ikisi yardımıyla bir yazılım ürününün uyması gereken işlevsel ve işlevsel olmayan gereksinimler belirlenir.
Design- Bu aynı zamanda, gereksinimlerin yazılım dili açısından tanımlandığı standart bir SDLC işlem adımıdır. Bir bütün olarak sistemin temel mimarisi ve alt sistemleri oluşturulur.
Specify Components - Yazılım tasarımını inceleyerek, tasarımcılar tüm sistemi daha küçük bileşenlere veya alt sistemlere ayırır. Eksiksiz bir yazılım tasarımı, birlikte çalışan çok sayıda bileşenden oluşan bir koleksiyona dönüşür.
Search Suitable Components - Yazılım bileşeni deposu, işlevsellik ve amaçlanan yazılım gereksinimleri temelinde eşleşen bileşeni aramak için tasarımcılar tarafından yönlendirilir.
Incorporate Components - Tüm eşleşen bileşenler, eksiksiz bir yazılım olarak şekillendirmek için bir araya getirilmiştir.