Özel Yazılım Projesi Nasıl Teslim Alınır? 5 Aşamalı Kabul ve Denetim Rehberi

Birçok şirket yöneticisi, yazılım ajansının yaptığı 45 dakikalık bir demo sunumunu izleyip “Harika görünüyor, ellerinize sağlık” diyerek teslim tutanağını imzalar ve son hakediş ödemesini yapar. Ancak canlı operasyona geçildiğinde gerçekler acı biçimde ortaya çıkar:

• Sistem 10 kullanıcı aynı anda sipariş girdiğinde veritabanı seviyesinde kilitlenir.
• Yazılımcı işten ayrıldığında kimse kodun nasıl derlendiğini ve sunucuya nasıl yüklendiğini bilmez.
• Veritabanı otomatik yedeklenmemiştir ve ilk sunucu arızasında haftalık sipariş verileri yok olur.
• Yeni bir geliştirici çağrıldığında “Bu kod spagetti, dokümantasyon yok, baştan yazmamız lazım” der.

Bu kabusu yaşamamak ve yazılım sermayenizi garanti altına almak için 5 Aşamalı Profesyonel Yazılım Kabul Protokolü uygulanmalıdır.

---

1. Kaynak Kod ve Mimari Bağımsızlık Denetimi

Yazılım geliştiricisine veya ajansına son ödemeyi yapmadan önce projenin teknik mülkiyetinin tam olarak devralındığı kanıtlanmalıdır.

---

2. Kullanıcı Kabul Testleri (UAT) ve Hata Seviyelendirmesi

Geliştirilen sistem yönetim kuruluna veya patrona değil; günde 8 saat o ekranda çalışacak fabrika operatörüne, depo sorumlusuna ve muhasebeciye test ettirilmelidir.

UAT sürecinde hatalar rastgele değil, katı bir hata matrisine göre sınıflandırılmalıdır:

Hata Seviyesi	Tanım	Kabul Edilebilir Sayı
P1 (Kritik Blocker)	Sistemin çökmesi, veri kaybı, fatura veya stok hesaplamasının yanlış yapılması, güvenlik açığı	0 (Sıfır tolerans)
P2 (Önemli Major)	Temel bir iş sürecinin aksaması ancak geçici bir alternatif yolla çözülebilmesi	0 (Canlıya geçmeden önce sıfırlanmalıdır)
P3 (Minör / Kozmetik)	Buton hizalaması, renk uyumsuzluğu, yazım hatası, ikincil filtreleme sırası	En fazla 3 (Teslim sonrası 15 günde çözülmek üzere)

UAT’de Mutlaka Sınanması Gereken 3 Senaryo Grubu:

1. Pozitif Senaryolar: Standart bir siparişin girilmesi, üretime iş emri açılması ve faturanın kesilmesi.
2. Negatif ve İstisna Senaryolar: Stokta olmayan malı satmaya çalışma, yetkisiz personelin iskonto oranını aşması, hatalı TC kimlik/vergi numarası girilmesi.
3. Stres ve Eşzamanlılık Testi: 20 kullanıcının aynı anda tek bir stoğu rezerve etmeye çalıştığı durumda yarış durumlarının (Race Condition) başarıyla engellendiğinin doğrulanması.

---

3. Veritabanı ve Performans Denetimi

Bir yazılımın ilk gün 100 kayıt varken hızlı çalışması hiçbir şey ifade etmez. 1 yıl sonra 100.000 sipariş kaydı biriktiğinde sistemin donmaması için veritabanı mimarisi denetlenmelidir.

---

4. Yedekleme ve Felaket Kurtarma Canlı Tatbikatı

Teslimat sırasında ajansa veya yazılımcıya şu talep iletilmelidir:
“Canlı veritabanını test sunucusunda sıfırlayın ve dünkü yedekten geri yükleyin.”

Eğer geliştirici bu testi 20 dakikada sorunsuz tamamlayamıyorsa, şirketin felaket kurtarma stratejisi sadece kâğıt üzerinde kalmış demektir.

• RPO (Recovery Point Objective - Kurtarma Noktası): En fazla kaç dakikalık veri kaybına tahammül var? (Hedef: < 15 dakika).
• RTO (Recovery Time Objective - Kurtarma Süresi): Sunucu çöktüğünde yeni sunucuya geçiş kaç dakika sürer? (Hedef: < 1 saat).
• 3-2-1 Kuralı: Verinin 3 kopyası, 2 farklı ortamda (örneğin sunucu diski + S3 uyumlu R2 depolama) ve 1 kopyası tamamen farklı bir coğrafi veri merkezinde şifreli tutulmalıdır.

---

5. Hukuki Teslim Tutanağı ve 14 Günlük Gölge Çalışma

Nihai teslim tutanağı asla tek bir günde imzalanmamalıdır. Sistem canlıya alındıktan sonra en az 14 gün boyunca eski sistem (Excel veya eski paket) ile yeni yazılım paralel (gölge çalışma) yürütülmelidir.

Teslim tutanağında mutlaka yer alması gereken 4 hukuki madde:

1. 90 Günlük Ayıp ve Gizli Kusur Garantisi: Canlı operasyonda ortaya çıkacak her türlü kodlama, hesaplama ve güvenlik hatası hiçbir ek ücret talep edilmeksizin öncelikli olarak düzeltilir.
2. Fikri ve Sınai Mülkiyet Devri: Geliştirilen yazılımın kaynak kodlarının, veri tabanı şemasının ve görsel tasarımlarının tüm mülkiyetinin kayıtsız şartsız müşteriye devredildiği yazılı olarak belirtilir.
3. Gizlilik ve KVKK Taahhüdü: Geliştirici ekibin şirket verilerini, müşteri listelerini veya ticari sırları hiçbir üçüncü tarafla paylaşamayacağı cezai şarta bağlanır.
4. Devir ve Dokümantasyon Teslimi: API dokümantasyonu, veritabanı ilişkisel diyagramı (ERD) ve kullanıcı video kılavuzlarının teslim edildiği kayda geçirilir.

KodDelta’da Adım Bazlı Güvenli Teslimat Modeli

KodDelta’da projeler hiçbir zaman belirsiz 6 aylık kör süreçlerle ilerlemez. Adım Adım Bütçeleme Modeli sayesinde her 2 haftalık sprint sonunda çalışan bir ekranı test eder, onaylar ve yalnızca kabul kriterlerini geçen aşamaların ödemesini yaparsınız.

Projelerimizin geliştirme metodolojisi ve fiyatlandırma bantları hakkında bilgi almak için Fiyat Sayfamızı inceleyebilir veya 30 dakikalık mimari keşif randevusu alabilirsiniz.

Sıkça sorulan sorular

Yazılım tesliminde kaynak kod nasıl kontrol edilmelidir?

Kodun derlenmemiş, okunabilir (TypeScript, Python, SQL) formatta, tam Git commit geçmişiyle birlikte temiz bir depoda (GitHub/GitLab) teslim edildiği ve yerel bir ortamda 5 dakikada ayağa kaldırılabildiği doğrulanmalıdır.

UAT (Kullanıcı Kabul Testi) neden zorunludur?

Yazılımcıların geliştirdiği test ortamı ile gerçek şirket operasyonu farklıdır. UAT aşamasında gerçek fabrika/saha personeli uçtan uca senaryoları dener ve tüm istisnaları (hatalı girdi, iptal akışları) onaylar.

Yazılım firmasıyla teslim tutanağı imzalamadan önce ne yapılmalıdır?

Eksik ve hatalar listesi (bug tracker) çıkarılmalı, kritik P1/P2 hatalar sıfırlanmadan ve en az 2 haftalık canlı paralel çalışma dönemi tamamlanmadan nihai kabul tutanağı imzalanmamalıdır.

Kabul kriterini kim yazmalı, ne zaman?

Sistemi kullanacak kişi, sözleşmeden önce. Depo modülünün kriterini depo sorumlusu yazarsa kriter gerçek bir işlemi tarif eder ve ölçülebilir olur; satıcının yazdığı kriter satıcının kolay geçtiği kriterdir.

Yedekten geri dönüş testi nasıl yapılır?

Test ortamındaki veritabanı sıfırlanır, dünkü yedekten geri yüklenir ve süre tutulur. Kabul edilebilir veri kaybı ve geri dönüş süresi hedefleri sözleşmede yazılı olmalı; test bu hedeflerle karşılaştırılır. Yedek almak bakım değildir, geri yükleyip açıldığını görmek bakımdır.

Teslimden sonra garanti süresi ne olmalı, neyi kapsar?

Yazıdaki örnek 90 gündür. Kapsam, kodlama hatalarının ücretsiz ve öncelikli düzeltilmesidir; yeni ekran veya yeni kural talebi garanti değil, bakım ya da ek modül kapsamına girer. İkisinin sınırı teslim tutanağında yazılmalıdır.

İlgili rehberler

• Mobil uygulama seçimi: PWA mı, native mi? Kurumsal saha ve maliyet rehberi
• En iyi yazılım şirketleri 2026: Türkiye'deki kurumsal yazılım firmaları sıralaması
• ERP şartnamesi ve ihtiyaç analizi şablonu 2026: Başarısızlığı önleyen 16 maddelik RFP rehberi

Hizmet sayfası: Kurumsal yazılım hizmeti