Kısa cevap
Bir yazılım bakım ve destek sözleşmesi en az şunları kapsamalıdır: hata düzeltme, güvenlik ve bağımlılık güncellemeleri, öncelik seviyelerine göre yanıt ve çözüm süreleri (SLA), yedekleme ve izleme, küçük geliştirmeler için ayrılan saat ya da kapsam, destek kanalları ve çalışma saatleri, erişim ve veri güvenliği kuralları, sözleşme bittiğinde kaynak kod ve belgelerin teslimi. Kapsam dışında kalan işlerin de açıkça yazılması, sonradan çıkan anlaşmazlıkların çoğunu önler.
Bir yazılım yayına alındığında iş bitmiş gibi görünür, ama aslında yeni bir dönem başlar. İşletim sistemleri ve tarayıcılar güncellenir, kullanılan kütüphanelerde güvenlik açıkları bulunur, mobil mağazalar yeni şartlar getirir, kullanıcılar daha önce kimsenin denemediği yollardan hatalar bulur. Bakımı yapılmayan bir yazılım, hiç değiştirilmese bile zamanla eskir.
Bu yazıda bakım ve destek sözleşmesinde bulunması gereken maddeleri, SLA kavramını ve sözleşme yaparken sorulması gereken soruları anlatıyoruz.
Yazılım bakımı nedir?
Yazılım bakımı, yayındaki bir yazılımın çalışmaya devam etmesi, güvenli kalması ve değişen koşullara uyum sağlaması için yapılan düzenli teknik çalışmaların tamamı demektir. Bakım genellikle dört türe ayrılır:
- Düzeltici bakım: Kullanıcıların ya da izleme sistemlerinin bulduğu hataların giderilmesi
- Uyarlayıcı bakım: İşletim sistemi, tarayıcı, mağaza kuralı ya da entegre edilen servislerdeki değişikliklere uyum
- Önleyici bakım: Güvenlik güncellemeleri, bağımlılık yükseltmeleri, performans iyileştirmeleri
- Geliştirici bakım: Kullanıcı geri bildirimiyle küçük özellik eklemeleri ve iyileştirmeler
Sözleşmede hangi türlerin dahil olduğunun açıkça yazılması gerekir. "Bakım" kelimesi taraflarca çok farklı anlaşılabilir.
Bakım ve destek sözleşmesinde hangi maddeler olmalı?
Aşağıdaki tablo, bir bakım sözleşmesinde yer alması gereken başlıca maddeleri ve her birinde netleştirilmesi gereken soruları özetliyor.
| Madde | Netleştirilmesi gereken |
|---|---|
| Kapsam | Hangi uygulamalar, sunucular, entegrasyonlar dahil? Hangileri hariç? |
| Hata düzeltme | Hata nasıl bildirilir, nasıl önceliklendirilir, hangi sürede ele alınır? |
| Güvenlik güncellemeleri | İşletim sistemi, çatı ve kütüphane güncellemeleri hangi sıklıkla yapılır? |
| SLA | Öncelik seviyelerine göre ilk yanıt ve çözüm hedefleri |
| Erişilebilirlik | Sistemin çalışır durumda olma hedefi, planlı bakım pencereleri |
| Yedekleme | Sıklık, saklama süresi, geri yükleme testi |
| İzleme | Hangi metrikler izlenir, uyarılar kime gider? |
| Küçük geliştirmeler | Aylık saat havuzu mu, iş bazında teklif mi? |
| Destek kanalları | E-posta, talep sistemi, telefon; çalışma saatleri ve tatil günleri |
| Raporlama | Yapılan işlerin aylık ya da dönemsel raporu |
| Erişim ve gizlilik | Sistemlere kim, nasıl erişir; kişisel verilerin korunması |
| Sözleşme sonu | Kaynak kod, belgeler, erişim bilgileri ve verinin teslimi |
SLA nedir, nasıl tanımlanır?
SLA (Service Level Agreement, hizmet seviyesi anlaşması), hizmet sağlayıcının belirli olaylara ne kadar sürede yanıt vereceğini ve hizmetin hangi seviyede sunulacağını ölçülebilir şekilde tanımlayan taahhüt demektir. SLA'nın işe yaraması için hem öncelik seviyelerinin hem de sürelerin nasıl ölçüleceğinin net olması gerekir.
Yaygın bir öncelik yapısı şöyledir:
| Öncelik | Tanım | Örnek |
|---|---|---|
| Kritik | Sistem tamamen kullanılamıyor ya da veri kaybı riski var | Site açılmıyor, ödeme alınamıyor |
| Yüksek | Ana bir iş akışı çalışmıyor, geçici çözüm yok | Sipariş ekranı hata veriyor |
| Orta | Bir özellik hatalı ama geçici çözüm var | Rapor yanlış filtreleniyor, elle düzeltilebiliyor |
| Düşük | Görsel ya da küçük sorunlar, iyileştirme talepleri | Yazım hatası, hizalama sorunu |
Her öncelik için iki ayrı süre tanımlanmalıdır: ilk yanıt süresi (talebin alındığının ve incelendiğinin bildirilmesi) ve çözüm ya da geçici çözüm hedefi. Sürelerin mesai saatleri içinde mi, yedi gün yirmi dört saat mi işlediği de yazılmalıdır. Sürelerin kendisi, işin kritikliğine ve ödenen bedele göre taraflarca belirlenir. Restoran POS'u gibi akşam ve hafta sonu yoğun çalışan bir sistemle, yalnızca mesai saatlerinde kullanılan bir iç panelin ihtiyacı aynı değildir.
Güvenlik ve bağımlılık güncellemeleri neden ayrı bir madde olmalı?
Modern yazılımlar çok sayıda açık kaynak kütüphane üzerine kurulur. Bu kütüphanelerde zaman zaman güvenlik açıkları bulunur ve CVE gibi kamuya açık kayıtlarla duyurulur. Açık duyurulduktan sonra güncellenmeyen bir sistem, bilinen bir zafiyetle çalışmaya devam ediyor demektir.
Sözleşmede şunların yazılması önerilir:
- Kritik güvenlik açıkları için güncellemenin hangi sürede uygulanacağı
- Rutin bağımlılık güncellemelerinin sıklığı (ör. aylık ya da üç aylık)
- Kullanılan çalışma ortamı ve veritabanı sürümlerinin destek süresi takibi; örneğin Node.js ve PostgreSQL gibi projeler her sürümün ne zamana kadar güncelleme alacağını yayımlar
- Ana sürüm yükseltmelerinin (büyük değişiklik içeren güncellemeler) bakım kapsamında mı, ayrı iş olarak mı yapılacağı
Mobil uygulamalarda bu konu daha da belirgindir. Google Play, uygulamaların belirli bir hedef API seviyesini karşılamasını şart koşar ve bu seviye zaman içinde yükselir. Hedef API seviyesi uzun süre güncellenmeyen uygulamalar, yeni Android sürümlerini kullanan yeni kullanıcılara sunulamaz hale gelebilir. Mobil uygulama bakımının bu yüzden düzenli bir takvime bağlanması gerekir.
Küçük geliştirmeler bakıma dahil mi?
Bakım ile yeni geliştirme arasındaki sınır, sözleşmelerde en çok tartışma çıkaran konudur. Bir hata düzeltmesi bakımdır; yeni bir rapor ekranı ise geliştirmedir. Arada kalan işler (bir alana yeni bir seçenek eklemek, bir e-posta şablonunu değiştirmek) için önceden bir kural belirlemek gerekir.
İki yaygın model vardır:
- Saat havuzu: Her ay belirli sayıda geliştirme saati sözleşmeye dahildir; kullanılmayan saatlerin devredip devretmeyeceği yazılır.
- İş bazında teklif: Bakım yalnızca hata ve güncellemeleri kapsar, her geliştirme talebi ayrıca tekliflendirilir.
Hangisi seçilirse seçilsin, talebin kim tarafından onaylanacağı ve tahmini sürenin iş başlamadan paylaşılacağı yazılı olmalıdır.
Sözleşme bittiğinde ne olur?
Bakım sözleşmesi imzalanırken bitişini düşünmek tuhaf gelebilir, ama işletmenin bağımsızlığını koruyan maddeler burada yer alır. Sözleşme sona erdiğinde şunların teslim edileceği yazılmalıdır:
- Güncel kaynak kodun tamamı ve sürüm geçmişi
- Kurulum, dağıtım ve yapılandırma belgeleri
- Sunucu, alan adı, mağaza hesapları ve üçüncü taraf servislerin erişim bilgileri (bu hesapların baştan işletme adına açılması en sağlıklı yoldur)
- Veritabanının güncel bir yedeği
Kişisel veri işleyen sistemlerde bakım ekibi çoğunlukla veri işleyen konumundadır. KVKK'nın 12. maddesi, veri sorumlusunun veri işleyenle birlikte güvenlik tedbirlerinden müştereken sorumlu olduğunu belirtir. Bu yüzden bakım sözleşmesinde erişim yetkileri, gizlilik yükümlülüğü ve veri ihlali durumunda bildirim adımları da yer almalıdır.
Sözleşmeye başlamadan önce yazılım firmasına sorulacak sorular için yazılım firması seçerken sorulması gereken sorular yazımıza bakabilirsiniz. Altyapı tarafındaki yedekleme ve izleme ayrıntılarını ise sunucu ve veritabanı seçimi rehberimizde anlattık. Bakım ve destek yaklaşımımız bakım ve destek hizmet sayfamızda yer alıyor.
Sık sorulan sorular
Web sitesi için de bakım sözleşmesi gerekir mi?
İçerik yönetim sistemi, eklentiler ya da form gibi dinamik parçalar içeren her web sitesi düzenli güncelleme ister. Güncellenmeyen eklenti ve çatılar, duyurulmuş açıkların istismarına açık kalır. Tamamen statik ve nadiren değişen sitelerde ihtiyaç daha azdır, ama alan adı, sertifika ve yedek takibi yine de yapılmalıdır.
SLA'da yanıt süresi ile çözüm süresi arasındaki fark nedir?
Yanıt süresi, talebin alındığının ve bir uzmanın incelemeye başladığının bildirildiği süredir. Çözüm süresi ise sorunun giderildiği ya da işin devam etmesini sağlayan geçici bir çözümün uygulandığı süredir. Karmaşık hatalarda kalıcı çözüm daha uzun sürebileceği için geçici çözüm hedefinin ayrıca tanımlanması faydalıdır.
Yazılımı geliştiren firmadan farklı bir firmayla bakım sözleşmesi yapılabilir mi?
Yapılabilir, ancak yeni firmanın sistemi tanıması için kaynak koda, belgelere ve tüm erişim bilgilerine ihtiyacı olur. Belgeleri eksik bir sistemi devralmak, ilk dönemde inceleme ve öğrenme emeği gerektirir. Bu yüzden geliştirme sözleşmesinde kaynak kod ve belge teslimi baştan güvence altına alınmalıdır.
Bakım sözleşmesi olmadan yazılım kullanılabilir mi?
Kısa vadede kullanılabilir, ama zamanla güvenlik açıkları, uyumsuzluklar ve fark edilmeyen hatalar birikir. Bir sorun çıktığında acil müdahale için uygun ekip bulmak ve sistemi sıfırdan tanımak, düzenli bakımdan çoğu zaman daha zahmetli olur. En azından güvenlik güncellemeleri ve yedekleme için bir düzen kurulmalıdır.
Bakım sözleşmesinin süresi ne kadar olmalı?
Sık kullanılan yapılardan biri, karşılıklı fesih koşullarıyla otomatik yenilenen bir yıllık sözleşmedir. İlk dönemde daha kısa bir deneme süresi de tercih edilebilir. Süreden bağımsız olarak, kapsamın ve SLA'nın belirli aralıklarla birlikte gözden geçirileceği bir madde eklemek, sözleşmeyi ihtiyaçlarla güncel tutar.
Kaynaklar
AssistoTech Ekibi
İstanbul'da web, mobil, masaüstü, oyun, SaaS ve kurumsal yazılım geliştiren ekibiz. Bu yazı, kendi ürünlerimizde ve müşteri projelerinde edindiğimiz deneyime dayanır. Projeniz için bize yazın.
