TEST AŞAMASI ÖZET Kara Kutu Saydam Kutu (Birim testi, Deyim Kapsama, Dal Kapsama, Yol Kapsama) Gri Kutu

TEST AŞAMASI ÖZET Statik Kod Analizleri ( Fonksiyon Analizi, Veri Akış Analizi, İşaretçi Analizi, Yanlış Yol Budama, Kodlama Standardı Analizi) Dinamik Test: Performans, Uyumluluk, Yükleme, Zorlama, Uygunluk, Yineleme, Duman, Geri Alma Testleri

İÇERİK Bakım Bakım Aşamaları Raporlama Bakım Sorunları Düzeltici, Uyarlayıcı, İyileştirici,Önleyici Bakım Bakım Aşamaları Raporlama Değişiklik Önerisi, Yazılım Sorun Raporu Bakım Sorunları Bakım için Kurallar Bakımın Yan Etkileri Kodlama, Veri, Belgelendirme, Başarım Etkilenmesi Tersine Mühendislik Yeniden Yapılanma

BAKIM Test işlemleri bitirilen yazılımın kullanıcı alanına yüklenmesi ve uygulamanın başlatılması gerekmektedir. Yazılım kullanıma geçtikten sonra, yaşam döngüsünün en önemli ve hiç bitmeyecek aşaması olan "bakım" aşaması başlar.

BAKIM Yazılım gelistirme çabasının amacı, yazılım kullanıcılarının gereksinimlerini karsılayarak ve sistemi sürdürülebilir, güvenli ve güvenilir kılmaktır. Yazılım, yazılım ortamının veya uygulama alanının değismesi, yeni gereksinimlerin belirmesi, yazılımdaki mevcut kusur ve eksikliklerin giderilmesine yönelik değisim isteklerinden dolayı, sürekli değisim baskısı altında tutulmaktadır. Yazılım bakımı için harcanan kaynaklar ve giderler, yazılımın yasam döngüsüne ait tüm kaynak ve giderlerin yaklasık %40 ila %70’ini olusturmaktadır [

Bakım Yazılım bakımına olan gereksinim, yazılım kullanıldığı sürece devam etmektedir. Bakımına gerek duyulmasının temel nedenleri asağıdaki sekilde belirtilmektedir : Hizmet sürekliliğini sağlamak. Zorunlu güncellestirme desteğini sağlama Kullanıcı gereksinimlerindeki değisim isteklerini sağlamak

BAKIM-Tanım Bakım, işletime alınan yazılımın sağlıklı olarak çalışması ve ayakta tutulabilmesi için yapılması gereken çalışmalar bütünüdür. Bakım yazılım yaşam döngüsünün en önemli ve en maliyetli aşamalarından biridir. Bakım süreci, yazılım yaşam döngüsünde "buzdağının görünmeyen kısmı" olarak adlandırılır. Uygulamada çalışan bir yazılımın üç tür bakım gereksinimi bulunmaktadır: Düzeltici Bakım Uyarlayıcı Bakım İyileştirici Bakım Önleyici Bakım

Düzeltici Bakım Çalışan bir yazılımda her an hata ile karşılaşma olasılığı vardır. Bundan dolayı zaman zaman, çalışan yazılımda ortaya çıkan yazılımların düzeltilmesi gerekir. Bir kısım yazılım kusuru ancak kullanım sırasında ortaya çıkar. Bu kusurlar giderilmesi için geliştiriciye bildirilir. Kusurun kaynaklama sebebini araştırmaya ve gidermeye yönelik işlere düzeltici (corrective) bakım adı verilir. Kullanım sırasında bulunan ve raporlanan yazılım kusurlarının giderilmesi, hatanın önemine bağlı olarak, ya hemen yapılır ya da birkaç tanesi ile beraberce ele alınıp düzeltmeler uygulanır ve yeni bir sürüm çıkarılır. .

Uyarlayıcı Bakım Her kuruluş yada işletme canlı bir varlık gibi düşünülebilir. İşletme yada kuruluşlarda değişiklik, yapılan işlerin yapılma tarzının değişmesi, yeni iş türlerinin ortaya çıkması biçiminde kendini gösterebilir. İşletme yada kuruluşlarda yaşanan değişikliklerin, o kuruluşun işlerini bilgisayar yardımı ile yapmalarını sağlayan uygulama yazılımlarına da yansıtılması gerekir. Bu yansıtma işlemi “Uyarlayıcı Bakım” olarak tanımlanır.

Uyarlayıcı Bakım Bilgi işleme dünyasındaki hızlı değişmeler ve teknolojik gelişmeler nedeniyle yazılımın yeni donanıma, işletim sistemlerine, bunların yeni sürümlerinegöre uyarlanması, sürümünün yükseltilmesi ve güncelleştirilmesi işlerine de uyarlayıcı (adaptive) bakım denmektedir. Yazılım kullanan işletmeler zaman içinde çeşitli nedenlerle işlerin yürütülme şeklinde, kullanılan yöntemlerde (örneğin yazıcıdan alınan kağıt baskının biçiminde değişiklik gerekmesi) değişiklikler yapma gereksinimi duyabilirler. Son yıllardaki gelişmelere bakarak, bir yazılım ın ortalama ömrünün 10 yıl olduğunu. Fakat donanım birimlerinin yürürlükte kalma sürelerinin 1 ya da 2 yıl olduğunu görmekteyiz.

İyileştirici Bakım En İyileyici Bakım: Zaman zaman uygulama yazılımlarının çalışma performanslarının iyileştirilmesi amacıyla yapılan çalışmalar “En İyileyici Bakım” olarak tanımlanır. Yazılım geliştirip test edilerek başarılı bir şekilde kullanıcıya sunulduktan sonra yeni işlevler eklemek, var olanlara başarımı ve verimi artırıcı düzenlemelerıleri yapmak, iyileştirici (perfective) bakım işleri içinde yer alır. Bu şekilde yazılımın yeni sürüm ortaya çıkar ve kullanıcının hizmetine sunulur. Örneğin, veritabanı erişimi ortalama 5 saniye olan bir yazılımda yeni bir arama algoritmasının kullanımı ile 3 saniyeye indirilebiliyorsa bu değişikliğin uygulanması bir iyileştirici bakımdır.

Önleyici Bakım Yazılımın gelecekte uygulanabilecek değişikliklere daha iyi bir temel oluşturulması, bakılabilirliği ve güvenilirliğinin arttırılması için ön tedbir niteliğindeki işlemler önleyici (preventive) bakım kapsamına girmektedir. Bu tür bakım geliştiricinin uzun süreli bakım anlaşması kapsamında yer alabilir.

Değişiklik Önerisi Sistem veya altsistem adı, öge adı Değişikliğin tanımı Değişikliğin yapılacağı öge, bileşen veya birim Yapılan degişiklikten etkilenmesi olası diğer öge, bileşen veya birimler Değişiklikleri yapabilmek için harcanması gereken tahmini işgücü İsteğin öncelik derecesi İsteğin numarası (takip edebilmek için) Öneriyi inceleyen makamların imzaları ve tarihler Karar (inceleme sonunda oluşturulur)

Yazılım Sorun Raporu Sistem veya altsistem adı, öge adı Sorunun açık tanımı Hatalı duruma düşülmesine neden olan giriş veriler Hatalı duruma düşüldügünde sistemin ya da birimin içinde bulunduğu durum Varsa raporlama sisteminin yarattığı kayıtlar (log data) Sorunu rapor eden kişiye ait erişim bilgileri Sorun Raporu numarası (takip edebilmek için) Karar (inceleme sonunda oluşturulur)

Bakım Sorunları Bakım sırasında karşılaşılan sorunları bilmek ona karşı hazırlıklı olabilmek için yarar sağlayacaktır. Genellikle, geliştirilen yazılımın bakılabilirlik özelliğinin eksikliği, bir disiplin içinde geliştirilmiş olmaması sorunların asıl kaynağını oluşturur. Bu sorunları şu şekilde listeleyebiliriz:

Bakım Sorunları Yazılımın çok fazla sürümü ortaya çıkarsa, bakımı da o derece güçleşir. Bir başkasının yazdığı kodu anlamak genellikle çok zaman alır. Eğer belgelendirme ve kod içindeki açıklamalar yetersiz ise ciddi sorunlar ortaya çıkar. Belgelendirme yetersiz, eksik, hatalı olabilir ya da hiç olmayabilir. Bu durumda yalnızca kodu okuyup anlamak gerekecektir. Yazılımların çoğunun üzerinde değişiklik yapılabilecek şekilde tasarlanmadıkları bir gerçektir. Eğer yazılım işlevsel olarak modüllere ayrılmamışsa veya belirli nesnelerden oluşmuyorsa sonradan bir değişiklik yapmak yeniden geliştirmekten daha zor olabilir.

Bakım Sorunları Personel devamlılığı her zaman karşılaşılan yaygın bir sorundur. Bakım işiyle görevlendirilmiş kişilerden hiç değilse bir kısmı geliştirme sırasında çalışmış olmalıdır. Tamamen yeni personelin konuyu anlayıp değişiklikleri uygulayabilmesi fazla zaman alabilir.

Bakım İçin Kurallar Yüksek nitelikli yazılım üretmeyi amaçlayan geliştiricilerin bakım evresinde uyması gerekli kurallar arasında şunları sayabiliriz: Bakım istekleri her zaman resmi bir Değişiklik Denetim Süreci kapsamında ele alınmalıdır. Bakım istekleri için süre ve maliyet kestirimi doğru olarak yapılabilmelidir.

Bakım İçin Kurallar Bakım projeleri tanımlanmalı ve yönetilmelidir. Diğer bir deyişle, bakım istekleri belirli bir şekilde toplanarak bir proje haline getirilmeli ve yönetilmelidir. Bakım sırasında da geliştirme sürecinin belgelendirme standartlarına uyulmalıdır. Uygun nitelikte teknik personel kullanılmalıdır.

Bakımın Yan Etkileri Yazılımın bakımı genellikle biraz "tehlike" içerir. Zira, test edilmiş ve kullanıma sunulmuş bir üründe yapılacak küçük sayılabilen bir değişiklik iyi çözümlenmez ve etkileri iyi takip edilmezse daha büyük yan etkilere yol açabilir. Karmaşık bir algoritma içinde yer alan bir tek değişkenin değerinin değiştirilmesi ya da yeni bir deyim eklenmesi gibi küçük sayılabilecek bir değişiklik, tüm yazılımın çalışmasına veya çökmesine yol açabilir. Tasarımın ve kodun iyi belgelendirilmesi dikkatli bir test bu tür sonuçları azaltabilir. Genellikle, kod içinde, verilerde, belgelemede ve başarımda ortaya çıkan bu istenmeyen sonuçlara bakımın yan denmektedir.

Tersine mühendislik (reverse engineering) Temel olarak elektronik ya da mekanik, mühendisliğinde uygulanmaya başlamıştır. Üreticisi dışında başka geliştiriciler ticari casusluk için, bir elektronik sistem donanımının veya mekanik parçaların nasıl çalıştığını, bu ürünün nasıl üretildiğini anlamak üzere inceleme ve testler yaparlar üretim sırlarını ortaya çıkarmaya çalışırlar. Bu şekilde bir ürünün kopyasını elde etmeye veya benzerini geliştirmeye gayret ederler.

Tersine mühendislik Yazılımda uygulanan tersine mühendislik de aynı sayılır. Üzerinde çalışılan ürün başka bir geliştiriciye ait veya aynı geliştiriciye ait daha önceden üretilmiş yazılımlar da olabilir. Ancak, herhangi bir tanımlayıcı belge bulunmamaktadır Böyle durumlarda uygulanan tersine mühendislik. yazılımı kaynak kod dan daha üst düzeyde bir soyutlama ile yeniden tanımlamaya çalışma sürecidir

Tersine mühendislik Tersine mühendislikte amaç, kaynak kodu girdi olarak alıp tam tasarım belgelendirmesini çıktı olarak elde etmektir. Tersine mühendisliğin uygulandığı bir başka alan da kaynak kodu hiç bulunmayan çalışır durumdaki programlardan tasarımı elde etmektir.

Yeniden Yapılanma (re-engineering) Yeniden yapılanma (re-engineering) süreci, var olan yazılımı daha iyi bir nitelige ulaştırmak, yeni işlevler eklemek üzere yeniden tasarlamak ve gerçekleştirmektir. Bunun ana nedeni geliştiricinin o alanda daha fazla deneyim kazanması nedeniyle mevcut yazılımlarını daha iyi hale getirme arzusudur. Önleyici bakım için geliştiricinin yapması gereken işte bu yeniden yapılanmadır. Değişikliğe uğraması olası olan yazılımlar seçilmeli ve ona göre işgücü ve maddi yatırım yapılmalıdır.