Yazılım bakımı: gelen talep hata mı, yeni geliştirme mi?

Yazılım teslim edildikten sonraki en sık tartışma, gelen talebin hata mı yeni geliştirme mi olduğudur. Ölçüt nettir: hata, kabul edilmiş kapsamın yazıldığı gibi çalışmamasıdır; yeni istek ise kapsamın dışına çıkan bir davranış değişikliğidir ve ayrı planlanır. Bu sınır baştan yazılı olmadığında her talep pazarlık konusu olur, iş kuyruğu tıkanır ve gerçek hatalar yeni isteklerin arkasında bekler.

Hata ile yeni isteğin sınırı

Sınırı belirleyen tek belge kabul kriterleridir. Bir davranış kabul belgesinde yazılıysa ve öyle çalışmıyorsa hatadır. Yazılı değilse, ne kadar makul görünse de yeni istektir. Bu ayrım kimseyi suçlamak için değil, işi öngörülebilir kılmak için yapılır. Kabul tarafı için kabul testi ve teslim kriterleri yazısı çerçeveyi anlatır.

Dış kaynaklı değişiklikler üçüncü bir sınıftır ve karıştırılmamalıdır. Karşı tarafın arayüzü ya da kuralı değiştiyse yazılımda bozulan bir şey yoktur; uyarlama işi vardır.

Destek kaydında ne yazılırsa çözüm hızlanır

Çözüm süresinin en büyük belirleyicisi ilk kaydın kalitesidir. Çalışmıyor cümlesiyle açılan kayıt, geliştiriciyi sorunu yeniden üretmeye uğraştırır. Aşağıdaki altı bilgi varsa inceleme doğrudan başlar.

1. Hangi ekran ve hangi kayıt: adres satırı veya kayıt numarası.
2. Ne zaman: tarih ve mümkünse saat.
3. Hangi kullanıcı ve hangi rol.
4. Beklenen davranış ve gözlenen davranış.
5. Adım adım yeniden üretme yolu.
6. Ekran görüntüsü veya hata metninin tamamı.

Tek bir destek kanalı seçilmesi de aynı ölçüde önemlidir. Talepler sözlü ve dağınık kanallardan geldiğinde kayıt tutulmaz, öncelik sıralaması yapılamaz ve aynı iş iki kez konuşulur. Kayıt düzeni oturduğunda ikinci bir fayda kendiliğinden gelir: hangi ekranın sürekli talep ürettiği görünür hale gelir ve tekrar eden talepler tek bir düzeltmeyle kapatılabilir.

Yeniden üretilemeyen talepler için de bir yol tanımlanmalıdır. Sorun nadir görülüyorsa inceleme kapatılmaz; ilgili ekrana ek kayıt bırakılır ve sorun bir daha yaşandığında elde veri olur. Bu yaklaşım, aylarca açık kalan ve kimsenin ilerletemediği taleplerin önüne geçer.

Öncelik sınıfları nasıl tanımlanır

Öncelik, talebi açanın aciliyet hissine göre değil, işe etkisine göre belirlenir. Üç sınıf çoğu işletme için yeterlidir ve her sınıfın ne demek olduğu örnekle yazılır.

• İş durdurucu: satış, tahsilat, sevk veya resmî belge üretimi duruyor; alternatif yol yok.
• Kısıtlı çalışma: iş sürüyor ama bir bölüm elle telafi ediliyor, hata riski artmış.
• Düşük etki: görsel kusur, metin düzeltmesi, nadir kullanılan ekranda aksaklık.

Sınıflar yazılı olduğunda tartışma süreden önce sınıfa taşınır ve çok daha hızlı sonuçlanır. Sınıflara bağlı yanıt ve çözüm taahhütleri varsa bunlar ayrıca sözleşmede yazılı olur; sözlü taahhüt bakımın en kırılgan parçasıdır.

Bakımın doğal kapsamı

Bakım yalnızca hata gidermek değildir. Çalışır durumda kalmak için yapılması gereken, kimsenin talep açmadığı işler de bakımın parçasıdır ve plansız bırakıldığında bir gün arıza olarak geri döner.

• Kütüphane ve çalışma ortamı güncellemelerinin izlenmesi.
• Güvenlik yamalarının uygulanması.
• Yedeklerin varlığının değil, geri yüklenebilirliğinin sınanması.
• Süresi dolacak sertifika ve entegrasyon anahtarlarının yenilenmesi.
• Hata ve iş kuyruğu kayıtlarının düzenli gözden geçirilmesi.
• Disk, veritabanı boyutu ve arka plan işlerinin izlenmesi.

Yedek tarafındaki ayrıntı için yedekleme ve felaket kurtarma planı, anahtar yenileme için entegrasyon anahtarları yazısı bu listeyi tamamlar.

Destek tek kişiye bağlı kalmasın

Bakımın en kırılgan noktası, sistemi yalnızca bir kişinin biliyor olmasıdır. O kişi izinde olduğunda basit bir talep bile beklemeye geçer. Bunun çaresi daha fazla belge yazmak değil, doğru belgeyi yazmaktır: sistemin hangi sunucularda çalıştığı, hangi dış servislerle konuştuğu, arka plan işlerinin ne yaptığı ve bir arıza anında ilk bakılacak yerler kısa bir sayfada durmalıdır.

• Çalışma ortamlarının ve erişim yollarının listesi.
• Dış entegrasyonların listesi ve her birinin sahibi.
• Zamanlanmış işlerin ne yaptığı ve ne zaman çalıştığı.
• Sık görülen arızalar ve ilk kontrol adımları.
• Yedek ve geri yükleme yordamının nerede yazılı olduğu.

Bu sayfa birkaç saatlik bir iştir ama devir ve acil durum anında en çok işe yarayan belgedir. Kaynak kodun ve ortam erişimlerinin kimde olduğu konusu ayrı bir başlıktır; kaynak kod sahipliği yazısı bu tarafı ele alır.

Sürüm ve değişiklik kaydı

Her yayına bir sürüm numarası ve kısa bir değişiklik notu eşlik etmelidir: neler düzeltildi, neler eklendi, kullanıcı tarafında dikkat edilmesi gereken bir şey var mı. Bu not hem destek ekibinin hem kullanıcının işini kolaylaştırır; bir davranış değiştiğinde hangi yayınla geldiği aranmaz, okunur. Yayının geri alınabilir olması da aynı disiplinin parçasıdır.

Kısa kontrol listesi

• Hata ve yeni istek ayrımı kabul belgesine dayanıyor.
• Tek destek kanalı var ve her talep kayda giriyor.
• Destek kaydında ekran, zaman, kullanıcı ve yeniden üretme adımları isteniyor.
• Öncelik sınıfları örnekle yazılı.
• Güncelleme, yama, yedek sınaması ve anahtar yenileme planlı işler arasında.
• Her yayında sürüm numarası ve değişiklik notu var.

Özet: bakım, teslimden sonra başlayan ayrı bir iş disiplinidir ve sınırları yazılı olduğunda ucuzdur. KAV Yazılım geliştirdiği sistemlerin bakımını bu çerçevede yürütür; kapsam detayı hizmetlerimiz sayfasında ele alınır.