YAZILIM BAKIM METODOLOJİLERİMİZ

Yazılım bakım projeleri kapsamında IEEE 12207 standardına uygun olarak Artırımsal Geliştirme Süreç Modeli yaklaşımı kullanılmaktadır. Artırımsal Geliştirme Süreç Modeli, bakım hizmeti alan müşterinin yazılım bakım sürecinde daha etkin yer almasına olanak vermektedir. Müşteri, sistem gereklerinin yerine getirildiğini ara fazlarla görebilmekte, varsa değişiklik önerisini ve açıklanacak noktaları proje bakım sürecinde bildirebilmektedir.

Zaman içerisinde değişim ihtiyacı duyulmayacak bir yazılım sistemi düşünülemez. Kullanıcı ya da müşterilerin ihtiyaçlarındaki değişimlerin sisteme yansıtılması gerekir. Ayrıca, yeni bir donanım ya da yazılım altyapısı nedeniyle sistemin çalışma koşulları değişebilir. Tabi ki testler sırasında fark edilmeyen hatalar tespit edilebilir ve giderilmesi gerekir.

Yazılımın dağıtılması ve kullanıma başlanmasından sonra yazılımda yapılacak değişiklikler yazılımın bakımı (software maintenance) olarak adlandırılır. Bu değişiklikler basit kodlama hatalarının düzeltilmesi (bug-fixes) şeklinde olabileceği gibi tasarımdan kaynaklanan hataların giderilmesi gibi daha kapsamlı değişiklikler şeklinde de olabilir. Yazılımın bakımı aslında yazılımın evrimleşmesidir. Yazılımın yaşamına devam edebilmesi için gerekli değişikliklerin uygulanmasıdır. Genel hatlarıyla 3 bakım türü vardır:

1. Düzeltici bakım:

Tespit edilen hataların giderilmesi işlemidir. Kodlama hatalarını düzeltmek genelde az maliyetlidir. Tasarımdan kaynaklı hataların giderilmesi ise bazı sistem bileşenlerinin baştan yazılmasını vb. gerektirebilir ve nispeten yüksek maliyetlidir.

2. Uyarlayıcı (Adaptif) bakım:

Yazılımın yeni bir çalışma ortamına uyarlanmasıdır. Bu bir donanım platformu değişikliği olabileceği gibi (32 bitten 64 bite geçiş gibi) farklı bir işletim sistemine uyarlama şeklinde de olabilir (kodun Windows'dan Linux'a taşınması gibi). Ayrıca, veritabanı sistemi değişikliği de bu türden bir bakım olarak görülebilir (MS SQL Server bağımlı kodların Oracle'a uyarlanması gibi).

3. İyileştirici bakım:

Sisteme yeni işlev ve özelliklerin eklenmesi, performansın arttırılması gibi bakım çalışmalarıdır.

80'li ve 90'lı yıllarda yapılan araştırmalar göstermiştir ki bakım çalışmalarının %65'i iyileştirici, %18'i uyarlayıcı ve %17'si düzeltici bakım şeklinde gerçekleşmektedir. Bu rakamları günümüzde de doğru kabul edebiliriz.

Genellikle bir sisteme çalışmaya başladıktan sonra yeni bir işlev eklemek, aynı işlevin henüz geliştirme sürecindeyken eklenmesine göre çok daha maliyetlidir.

DEĞİŞİKLİK VE YAPILANDIRMA YÖNETİMİ

Yazılım geliştirilirken olası hataları en aza indirmek, elde edilen verilerden maksimum kazanımı sağlamak için kalite standartları mevcuttur. Ancak, standartlara göre tanımlanmış kalite süreçlerine bağlı kalınıp, gerekli tüm dokümantasyon hazırlansa ve gözden geçirmeler yapılıp, Müşteri/Kullanıcı onayları alınsa da, süreç içinde değişiklik ihtiyaçları ile karşılaşılması kaçınılmazdır. Değişiklik ihtiyaçlarına rağmen riskin minimumda tutulması için proje yaşamı boyunca karşılaşılan değişikliklerin de kontrol altında olması, değişikliğe sebep olan hataların analiz edilerek tekrarlanmaması için ölçümlerinin ve kayıtları tutulmaktadır.

Değişiklik Yönetimi, bütün değişiklikler için standartlaştırılmış metotların, süreçlerin ve prosedürlerin kullanıldığını temin eder ve değişikliğe olan ihtiyaçla değişimin getirdiği potansiyel etkilerin uygun bir dengede kalmasını sağlar.

Değişiklik yönetimini gerçekleştirmek için aşağıdaki yazılım araçları kullanılmaktadır:

  • Atlassian Jira Talep Takip (Issue Tracking) Yazılımı – Değişiklik taleplerinin girilerek yapılabilirlik analizinin başlatılması, değişiklik yönetim süreçlerinin izlenmesi ve proje ekibi üzerindeki görevlerin takibi için kullanılacak web tabanlı yazılım aracıdır,
  • Atlassian Confluence (Wiki) Yazılımı – Değişiklik ve Yapılandırma yönetim süreçlerindeki tüm dokümantasyonların hazırlanması, saklanması ve erişilmesi için kullanılacak web tabanlı yazılım aracıdır,
  • Atlassian Fisheye + Crucible Yazılımı – Kaynak kod deposu üzerinde gezinmek, kaynak kod dosyalarını görüntülemek ve sürümleri arasındaki değişiklikleri izlemek için Fisheye, proje ekibindeki yazılım geliştiricilerin yapacakları değişiklikleri gözden geçirmek, yorumlamak ve gerekirse yönlendirmek amacı ile Crucible yazılımı kullanılmaktadır. Her iki yazılım da web tabanlıdır.

Ürünün, kendisine özgü olarak teknik dokümanlarında tanımlanan ve istendiğinde ulaşılabilen işlevsel ve fiziksel özelliklerine Konfigürasyon veya Yapılandırma denir. Yazılım Yapılandırma Öğesi ise Müşteri tarafından yapılandırma yönetimi için tanımlanmış ve kullanım işlevlerini yerine getirebilen yazılım parçalarıdır.

Yapılandırma yönetimini gerçekleştirmek için aşağıdaki yazılım araçları kullanılmaktadır:

  • Collabnet Subversion (SVN) ve SubversionEdge yazılımları – Kaynak kod deposu ve depo yönetimi olarak kullanılacak web tabanlı yazılım araçlarıdır. SVN ile yazılım yapılandırma öğelerinin (ör: kaynak kod dosyaları) sürümleri takip edilir.

SÜRÜM NUMARALANDIRMA ŞEMASI

<major>.<minor>.<micro>[-M<milestone numarası> veya -RC<release candidate numarası>]

Bu şema 3 adet bileşen içerir:

  1. major” numarsı yazılımdaki köklü değişiklikler, yeni bir ortama uyarlamalar sonrası artırılır,
  2. minor” numarası yeni bir özellik eklendiğinde arttırılır,
  3. micro” numarası ise bir hata giderildiğinde veya önemsiz bir değişiklik yapıldığında arıtırılır.

Bu numaralar sonrası opsiyonel bir etiket de sürümün olgunluğunu belirtmek için kullanılır:

M (Milestone), değişiklik listesi bir sonraki milestone (M) sürümüne kadar güncellenebilir, sürüme yeni özellik eklenebilir veya çıkarılabilir anlamına gelmektedir. Yapılacak oylama sonuncu milestone (M) sürümü ilk release candidate (RC) sürümü olarak seçilebilir.

RC (Release Candidate), değişilik listesi kilitlenmiştir, tasarımda ciddi bir sorun tespit edilmedikçe bu sürüm için artık yeni bir özellik eklenemez veya çıkartılamaz. Bu etiket sürümün sadece var olan yazılım hatalarını gidermek üzere odaklandığını belirtir. Yapılacak oylama sonucu sonuncu release candidate (RC) sürümü ile general availability (GA) sürümü olarak seçilebilir.

Herhangi bir ek etiketin olmaması GA (General Availability) anlamına gelir. GA, sürümün yeterince kararlı olduğunu ve production ortamına yüklenebileceğini bildirir. GA etiketini yazmaya gerek yoktur. Ek etiket olmayan sürüm numarası kararlı sürüm olarak değerlendirilir.

Sürüm numaralandırma şeması ile ilgili örnekler aşağıda verilmiştir:

2.0.0-M1 -> 2.0.0-M3 -> 2.0.0-M3 -> 2.0.0-M4 - 2.0.0-RC1 -> 2.0.0-RC2 -> 2.0.0-RC3 - 2.0.0 -> 2.0.1 -> 2.0.2 -> 2.1.0-M1 ...

Değişiklik Yönetimi Süreci, değişiklik talebi, yapılabilirliğin belirlenmesi, planlama, gerçekleştirme ve değişikliklerin değerlendirilmesi işlemlerini kapsamaktadır.

1. DEĞİŞİKLİK TALEBİ

Değişiklik talepleri aşağıdaki kategorilere göre takip edilmektedir. Farklı kategorilerdeki değişikliklerin metrikleri ayrı ayrı tutularak değişik analizler yapılır. “Hata takibi” kategorisi kapsamındaki metrikler yazılımı geliştiren proje personelinin performans ölçümlerinde kullanılıp “değişiklik isteğindeki” metrikler sistem analizi ve tasarımından sorumlu personelin performans değerlendirmelerinde kullanılmaktadır.

1.1. Değişiklik Kategorileri

1.1.1.  Hata takibi (Uymazlık):

Yazılım yapılandırma öğesinin tanımlı gereksinimlere uygunsuzluğu sebebiyle yapılması gereken değişikliklerdir. Bu tip hatalar, sistemin ya da yazılımın gereksinim veya tasarımında değişiklik gerektirmemektedir.

1.1.2. Değişiklik İstekleri:

Müşteri isteği, yazılım bakım sırasında ortaya çıkan ihtiyaçlar, testler sırasında tespit edilen gerekler, vb. sebeplerle daha önceden onaylanmış kavramsal model, sistem/yazılım gereksinimleri ve/veya tasarımda değişiklik yapılması gerekebilir. Bu tip değişiklikler, müşteri tarafından gerekli onay alındıktan sonra yapılmaktadır.

1.1.3. İyileştirme Önerileri:

Bir hata olarak kabul edilmeyen ve/veya kavramsal model/gereksinim/tasarım değişikliği gerektirmeyen, ancak kullanım kolaylığı sağlayacak, görselliği zenginleştirecek vb. iyileştirme önerileri bu kategori kapsamında ele alınmaktadır. Bu sınıfa ait değişikliklerin, hata takibi sürecinden ayrı olarak takip edilmesinin sebebi, bu değişikliklerin sistemin mevcut çalışmasını engellememesi, sistemin hatalı çalışmasına sebep olmaması, hata takibi sınıfı kapsamına giren değişikliklere göre öncelik ve önemlerinin daha az olması ve hata sınıfındaki değişikliklerin analiz ve değerlendirmesinin ayrı olarak yapılması gerekliliğidir.

1.1.4. İşlem maddeleri:

Müşteri ile yapılacak ve/veya proje grubu toplantılarında ortaya çıkabilecek işlem maddeleri, gerekse şirket/grup kapsamında yapılması gereken idari/teknik her türlü aktivitenin planlanması ve takip edilmesi kapsamında bu süreç tanımlanmıştır. Bu kapsama dahil olan istekler, diğer kategorilerden farklı olarak, proje kapsamında ihtiyaç duyulan araştırma, mukayese etüdü, idari yazışmalar, vb. sistemin dokümantasyonunda ve/veya yazılımın kaynak kodunda değişikliğe sebep olmayan isteklerdir.

2. DEĞİŞİKLİĞİN YAPILABİLİRLİK ANALİZİ

Proje ekibi tarafından değişiklik talebinin analizi yapılmaktadır, değişikliğin uygulanabilirliği incelenmekte, talep edilen değişiklik için yapılması gereken çalışmalar belirlenmektedir. Bu sürecin çıktısı olan analiz dokümanı müşteri yönetimine iletilerek analiz sonuçlarının değerlendirilmesi sağlanmaktadır.

3. PLANLAMA

Değişikliğin yapılabilirlik analizinin müşteri tarafından değerlendirmesi sonucu ilgili değişikliğin yapılması kararı alınmış ise proje ekibi yapılacak çalışmalar ile ilgili planlama yapacak ve çalışma takvimi çıkararak iş planında güncelleme yapmaktadır.

4. GERÇEKLEME

Gerçekleştirilmesi için karar alınmış değişiklik talepleri, planlama sürecinde belirlenen takvime sadık kalınarak belirlenen başlangıç ve bitiş süreleri arasında tamamlanır, bu süreç içinde birim testleri ile de gerçekleştirilen yazılım değişikliğin test ortamına yüklenmeden önce geliştiricilerin bilgisayarları üzerinde ilgili yazılım modülü açısından, modüllerin birbiri ile etkileşimi açısından bir sıkıntı olmadan çalışması sağlanmaktadır.

5. DEĞİŞİKLİĞİN DEĞERLENDİRİLMESİ

Yapılan değişikliği içeren ve birim testlerini başarı ile geçen yazılımın test ortamına yüklenmesinden hemen önce müşteri ile proje ekibinin birlikte toplanarak gerçekleştirilen değişikliğin talep edilen değişiklik ile karşılaştırılması ve değerlendirilmesi yapılmaktadır. Böylece talep ile yapılan isteklerin tam anlamı ile karşılanıp karşılanmadığını belirlenmektedir. Talep edilen değişiklik ile gerçekleştirilmiş değişiklik bire bir uyuşmuyorsa yazılımın sürüm numarası sonundaki milestone (M) etiketi bir artırılarak tekrar tespit edilen eksikliğin veya hatanın girildiği “Değişiklik Talebi” adımına dönülür. Bu süreç olumlu olarak sonuçlanmış ise milestone (M) sürümü oylama ile release candidate (RC) sürümüne dönüşür.

6. TEST VE DEVREYE ALMA

Test ortamına yüklenen release candidate (RC) sürümü üzerinde detaylı olarak işlevsellik ve performans testleri yapılır. Hem yeni yapılan değişikliğin çalışırlığı kontrol edilir hem de mevcut diğer özelliklere olumsuz bir etkisinin olmadığı tespit edilir. Test sonucu, birim testleri ve değişiklik değerlendirmesi aşamalarında tespit edilememiş, daha karmaşık durumların bir araya gelmesi ile oluşan hatalar tespit edilirse test raporuna bu sonuçlar yazılır ve release candidate (RC) etiketi bir artırılarak eksikliğin veya hatanın girildiği “Değişiklik Talebi” adımına dönülmektedir. Bu test olumlu olarak sonuçlanır ise release candidate (RC) sürümü oylama ile GA sürümüne dönüştürülerek gerçek sisteme yüklenmeye hazır hale getirilmektedir.

Yapılacak zaman planı ve müşterinin onayı ile kararlı sürümün gerçek sisteme yükleneceği tarih belirlmekte ve bu tarihte tüm ekip hazır bulunarak yükleme (deployment) işlemi müşterinin gözetiminde gerçekleştirmektedirler.