Bu inceleme çoğunlukla bir yazılım projesi bittiğinde ya da yarıda kaldığında gündeme gelir. İş sahibi yazılımın eksik veya hatalı teslim edildiğini, yüklenici işin şartnameye uygun tamamlandığını ve yeni taleplerin kapsam dışı olduğunu söyler. Teknik inceleme bu tartışmayı ölçülebilir hâle getirir. Uyuşmazlıkların tipik kökleri için yazılım teslim uyuşmazlıkları yazımıza bakabilirsiniz; bu sayfa incelemenin nasıl yapıldığını anlatır.
Hangi uyuşmazlıklarda yazılım incelenir?
| İddia | Teknik soru | Başlıca kayıtlar |
|---|---|---|
| Teslim edilmedi, eksik teslim | Teslim edilen depo veya paket şartnamedeki modüllerin hangilerini içeriyor? | Depo, teslim e-postası veya tutanağı, sunucudaki kurulum, derleme kayıtları |
| Ayıplı, hatalı yazılım | Hata yeniden üretilebiliyor mu; kaynağı kod mu, ortam mı, veri mi? | Hata kayıtları (issue tracker), uygulama logları, test ortamı |
| Şartnameye aykırılık | Her madde karşılanmış mı? | Sözleşme, şartname, değişiklik talepleri, kabul testleri |
| Performans | Şartnamedeki ölçüt ölçülebilir mi, sağlanıyor mu? | Yük testleri, sunucu izleme kayıtları |
| Güvenlik | Bilinen türde açık var mı, teslim tarihinde var mıydı? | Kod, bağımlılık listesi, tarama çıktıları |
| Kod sahipliği, geliştirme geçmişi | Kod hangi hesaplardan, hangi tarihlerde depoya girdi; başka bir kod tabanıyla örtüşüyor mu? | Commit geçmişi, platform kayıtları, benzerlik analizi |
Teknik şartnameye uygunluk nasıl değerlendirilir?
Uygunluk, şartnamenin her maddesinin test edilebilir bir ifadeye çevrilip teslim edilen sürüm üzerinde tek tek denenmesiyle değerlendirilir. Sıramız şöyle:
- Sürümü sabitleriz. Hangi commit, hangi derleme, hangi paket; paketin SHA-256 değeri kayda geçer. Taraflar "teslim edilen yazılım" derken çoğu zaman farklı sürümlerden söz eder.
- Gereksinim listesi çıkarırız. Sözleşme, şartname, teklif ekleri ve yazılı değişiklik taleplerinden. "Kullanıcı dostu arayüz" gibi ölçülemeyen maddeleri ayrıca işaretleriz; raporda ölçülmüş gibi sunulmazlar.
- Kaynak koddan derleyip kurarız. Belgelenmiş, yalıtılmış bir ortamda. Derlenemiyorsa bu da bulgudur: eksik bağımlılık, belgelenmemiş yapılandırma, depoda olmayan dosya.
- Her maddeyi test ederiz ve sonucu kanıtıyla (ekran kaydı, log, test çıktısı) saklarız.
- Kronolojiyi kurarız. Hangi hata ne zaman bildirildi, ne zaman kapatıldı, hangi talep sonradan geldi; issue tracker kayıtları ve yazışmalar tek zaman çizelgesinde.
Sonuç bir uygunluk matrisidir. Örnek (kurgusal):
| Madde | Şartname ifadesi | Sonuç | Kanıt |
|---|---|---|---|
| 4.2 | Siparişler tarih aralığına göre Excel'e aktarılabilmeli | Kısmen | 10.000 satırın üzerinde zaman aşımı; test-4.2.log |
| 5.1 | Yetkiler rol bazlı tanımlanmalı | Karşılandı | Rol tablosu ve uç nokta kontrolleri, commit a1b2c3d |
| 6.3 | Girişte SMS doğrulaması | Test edilemedi | SMS sağlayıcı hesabı teslim edilmemiş |
| 7.4 | "Raporlar hızlı açılmalı" | Ölçülemez | Şartnamede ölçüt yok |
Şartnamede kalite ölçütü yoksa bulguları adlandırmak için ISO/IEC 25010 kalite modelinden yararlanırız; ama bu modeli taraflar üzerinde anlaşmış gibi sunmayız. Proje teslim kriterleri ayrıca okunur: kabul testi senaryoları, kullanıcı kabul (UAT) tutanakları, canlıya geçiş koşulları. Sistemin fiilen hangi tarihten beri kullanıldığı da kayıtlarla gösterilebilir: canlı veri tabanındaki ilk gerçek kayıtlar, kullanıcı trafiği, ödeme ya da e-fatura entegrasyonundaki canlı işlemler. Bu kullanımın hukuken kabul anlamına gelip gelmediğini ise avukat ve mahkeme değerlendirir. Yeni bir projede kabul kriterlerini baştan ölçülebilir yazmak için proje danışmanlığı ve şartname sayfamıza bakın.
Hatalar ve sürüm farkları nasıl tespit edilir?
Bir hata, yeniden üretilebildiği ölçüde bulgu olur. Her hata için yeniden üretim adımlarını, beklenen ve gerçekleşen sonucu, sürümü ve kaynağını yazarız. Kaynak ayrımı çoğu uyuşmazlığın düğüm noktasıdır:
| Kaynak | Tipik belirti | Ayırmak için bakılan |
|---|---|---|
| Kod | Aynı girdiyle her ortamda aynı hata | Temiz kurulumda yeniden üretim, ilgili kod satırı |
| Yapılandırma, ortam | Testte çalışan işlev canlıda çalışmıyor | Ortam değişkenleri, çalışma zamanı sürümleri, zaman aşımı ayarları |
| Veri | Hata yalnızca belirli kayıtlarda çıkıyor | Hatayı tetikleyen kayıtlar, eski sistemden taşınan verinin biçimi |
| Dış hizmet | Hata belirli bir entegrasyonda, belirli saatlerde | Sağlayıcının API yanıt kodları ve sürüm notları |
Önem derecesini sözleşmede bir tanım varsa ona göre, yoksa işlevin kullanılabilirliğine etkisine göre ayrı bir sütunda gösterir, ölçütü raporda açıklarız.
Sürüm farkı için teslim edilen paketin hash değerini, depodaki etiketten (tag) yeniden derlenen paketle karşılaştırırız. Derleme her seferinde bayt bayt aynı çıktıyı vermeyebilir (gömülü derleme zamanı, imza); o zaman karşılaştırma dosya düzeyinde yapılır. İki sürüm arasındaki kod farkı git diff v1.4..v1.5 gibi bir komutla çıkarılır ve her değişiklik bir talep ya da hata kaydıyla eşlenir. Web uygulamasında canlıdaki JavaScript paketinin, mobil uygulamada sürüm ve derleme numarasının hangi commit'e denk geldiğini ayrıca doğrularız.
Git geçmişi ve commit kayıtları neyi gösterir?
Git geçmişi, kodun hangi sırayla ve hangi hesaplar adına depoya girdiğini gösterir. Ancak commit içindeki ad, e-posta ve tarih, commit'i oluşturan bilgisayarın yazdığı bilgilerdir; tek başına kimlik ya da zaman kanıtı değildir.
| Kayıt | Ne söyler | Dikkat |
|---|---|---|
| Author date / committer date | Kodun yazıldığı beyan edilen an ve commit'in oluşturulduğu an | GIT_AUTHOR_DATE, GIT_COMMITTER_DATE veya git commit --date ile ayarlanabilir; git log --pretty=fuller ikisini ayrı gösterir |
| Yazar adı ve e-postası | Commit'i yapanın beyanı | Serbest metindir, herkes her adı yazabilir |
| İmzalı commit | İmzalayan anahtar sahibinin commit nesnesini onayladığı | Tarihin doğru olduğunu göstermez; git log --show-signature ve %G? ile doğrulanır |
| reflog | Yerel depoda dal uçlarının ne zaman değiştiği | Yalnızca geliştiricinin kendi bilgisayarında; varsayılan 90 gün, erişilemeyen girdiler 30 gün |
| Platform kayıtları (GitHub örneği) | Push, merge ve force push olaylarını kimliği doğrulanmış kullanıcıyla ilişkilendirir; doğrulanan imzada verified_at zamanı | Events API yalnızca son 30 gün ve en fazla 300 olay; kurumsal audit log 180 gün, Git olayları 7 gün |
Bu yüzden commit tarihlerini sunucu tarafında bağımsız tutulan zamanlarla karşılaştırırız: push kayıtları, CI/CD çalışma zamanları, imza doğrulama zamanı. Geçmiş force push veya rebase ile yeniden yazılmışsa eski hâl, geliştirici bilgisayarlarının reflog'unda ya da daha önce alınmış depo kopyalarında bulunabilir.
Uyuşmazlık başlıyorsa depoyu geçmişiyle birlikte (ör. git clone --mirror) ve platformun etkinlik kayıtlarını bugün dışa aktarın; ZIP olarak indirilen kod geçmişi taşımaz. Dışa aktarılan dosyaların SHA-256 değerini hash hesaplama aracıyla kaydedebilirsiniz; neden önemli olduğunu hash ve delil bütünlüğü yazımızda anlattık.
Kod sahipliği ve benzerlik hakkında teknik olarak ne söylenebilir?
Teknik inceleme, kodun hangi hesaplar adına, ne zaman ve hangi kaynaktan depoya girdiğine dair izleri ortaya koyar; kodun hukuken kime ait olduğuna mahkeme karar verir. Hangi dosyayı hangi hesapların değiştirdiğine, çalışmanın zamana yayılıp yayılmadığına ve tek commit'te on binlerce satırın eklendiği anlara bakarız. Sonuncusu kodun başka yerden taşındığına işaret edebilir, tek başına bunu göstermez.
İki kod tabanı arasındaki benzerlik için MOSS ve JPlag gibi araçlar kullanılır. Gizli ticari kodda hesaplamayı tamamen yerel yapan JPlag'ı tercih ederiz; MOSS kodu Stanford'daki sunucuya gönderir. Skor kopyalama kanıtı değildir; ortak kütüphaneleri ve açık kaynak bileşenleri ayıkladıktan sonra kalan eşleşmeleri tek tek inceler, raporda yüzde yerine eşleşen blokları gösteririz.
API entegrasyonları, veri tabanı yapısı ve mimari
Pek çok "yazılım çalışmıyor" şikâyetinin kaynağı yazılımın bağlandığı dış hizmettir: ödeme kuruluşu, e-fatura entegratörü, SMS sağlayıcısı, kargo API'si. Entegrasyonun test anahtarlarıyla mı canlı anahtarlarla mı çalıştığına, yanıt kodlarının loglanıp loglanmadığına, hatada yeniden deneme yapılıp yapılmadığına bakarız. Veri tabanı şemasının şartnamedeki veri modelini karşılayıp karşılamadığını ve migration geçmişini ayrıca inceleriz; kayıt düzeyindeki sorular veri tabanı incelemesinin konusudur. Teklifte söz edilen mimari ("yüksek erişilebilirlik", "yatay ölçeklenebilir") ile kurulu sistem arasındaki farkı dağıtım yapılandırmasından gösteririz.
Lisanslama mekanizmaları: iki ayrı soru
- Üçüncü taraf lisansları: Teslim edilen yazılımdaki açık kaynak ve ticari bileşenler hangi lisanslarla gelmiş? Bileşen listesini ScanCode gibi araçlarla çıkarır, lisansları SPDX tanımlayıcılarıyla (ISO/IEC 5962:2021) raporlarız. Sonuç bir yazılım malzeme listesi (SBOM) olarak SPDX veya CycloneDX (ECMA-424) biçiminde de verilebilir.
- Lisans veya aktivasyon kilidi: Yazılımda belirli bir tarihten sonra işlevleri kapatan, uzak bir sunucuya lisans sorgusu yapan ya da anahtar isteyen bir kod var mı? Varsa hangi commit'le eklendiğini ve nasıl tetiklendiğini gösteririz.
Performans ve güvenlik bulguları
Performans ancak ölçütle değerlendirilir: "100 eş zamanlı kullanıcıda sayfa 2 saniyede açılmalı" test edilebilir, "hızlı olmalı" edilemez. Testi şartnamedeki koşullara en yakın ortamda yapar, donanım ve veri hacmi farklarını raporda belirtiriz. Yavaşlığın kaynağı sunucu kaynakları, eksik indeksler ya da kod olabilir; bunu izleme kayıtlarıyla ayırırız.
Güvenlik bulgularını OWASP Top 10:2025 kategorileriyle (ör. A01 Broken Access Control, A05 Injection) sınıflandırırız. Statik analiz ve bağımlılık taraması çıktılarını tek başına bulgu saymaz, her uyarıyı kodda doğrularız. Bir bağımlılıktaki açığın teslim tarihinde bilinip bilinmediği de kontrol edilir: teslimden sonra yayımlanan bir zafiyet, teslim anındaki durum hakkında aynı şeyi söylemez.
Yazılım davasında bilirkişi ve uzman görüşü
Uyuşmazlık mahkemeye taşındığında teknik incelemeyi mahkemenin görevlendirdiği bilirkişi yapar; Bilirkişilik Daire Başkanlığının listesinde "Yazılım" (18.02) ayrı bir alt uzmanlık alanıdır. Sözleşme eser sözleşmesi olarak nitelendirilirse TBK m.474/2 de her iki tarafa, giderini karşılayarak eserin bilirkişi tarafından gözden geçirilmesini ve sonucun raporla belirlenmesini isteme imkânı tanır. Bilirkişiyi yargı mercii görevlendirdiği için (HMK m.266) talebin hangi yolla yapılacağını avukatınız değerlendirir; dava öncesi delil tespiti (HMK m.400) de bir yoldur.
Biz bilirkişi değiliz; taraflardan biri için çalışırız: dava öncesinde durumu kayda geçiren teknik rapor, dava sırasında HMK m.293 kapsamında uzman görüşü ya da dosyadaki bilirkişi raporunun teknik değerlendirmesi. Uzman görüşü mahkemeyi bağlamaz; Yargıtay'a göre tarafın belgeye dayalı beyanı niteliğindedir (9. HD, E.2022/2237, K.2022/3385). Öte yandan esaslı bir uzman görüşü bilirkişi raporuyla ciddi biçimde çelişiyorsa mahkemenin bu çelişkiyi gidermesi gerektiği de Yargıtay kararlarında yer alır (15. HD, E.2015/5127, K.2016/4635).
TBK m.474/1'e göre iş sahibi, teslimden sonra eseri gözden geçirmek ve ayıpları uygun süre içinde bildirmekle yükümlüdür; m.477'ye göre gözden geçirme ve bildirim ihmal edilirse eser kabul edilmiş sayılır; m.478 taşınmaz yapılar dışındaki eserlerde ayıp davaları için teslimden itibaren iki yıllık (yüklenicinin ağır kusurunda yirmi yıllık) zamanaşımı öngörür. Sözleşmenizin bu hükümlere tabi olup olmadığını avukatınız değerlendirir. Teknik açıdan söyleyebileceğimiz şu: teslim edilen sürümü ve hata kayıtlarını erken sabitlemek sonraki her tartışmayı kolaylaştırır.
İnceleme için hangi materyal gerekir?
- Sözleşme, teknik şartname, teklif ve ekleri, kabul kriterleri, yazılı değişiklik talepleri.
- Kaynak kod deposu, geçmişiyle birlikte: okuma yetkisi ya da ayna kopya.
- Teslim edilen paketler, kurulum dosyaları, teslim tutanağı veya e-postası.
- Hata ve iş takip kayıtlarının dışa aktarımı (Jira, GitHub Issues vb.), CI/CD çalışma kayıtları.
- Test ve canlı ortam erişimi; varsa izleme ve uygulama logları.
- Taraflar arasındaki yazışmalar, e-posta orijinalleriyle.
Raporda neler bulunur?
İncelenen sürüm ve hash değerleri, test ortamı ve araç sürümleri, uygunluk matrisi, hata listesi, zaman çizelgesi, commit ve benzerlik analizi, test edilemeyen maddeler ve erişilemeyen kayıtlar. "Ayıplıdır" ya da "yüklenici kusurludur" demeyiz; "4.2 maddesindeki işlev teslim edilen sürümde şu koşulda çalışmıyor" der, kanıtını ekleriz.