Bir yazılım teslim uyuşmazlığını teknik olarak incelerken ilk açtığımız belge şartnamedir ve sorun çoğu zaman kodda değil orada başlar: "sistem hızlı olmalı" yazan ama hızın neyle ölçüleceğini söylemeyen bir madde, hiç yazılmamış bir kabul prosedürü, e-postada kalmış bir değişiklik talebi. Bu sayfa, proje başlamadan önce ve sürerken iş sahibinin yanında yaptığımız işi anlatır. Teslimden sonra çıkmış bir anlaşmazlık için yazılım ve kaynak kod incelemesi sayfasına, bu anlaşmazlıkların tipik kökleri için yazılım teslim uyuşmazlıkları yazısına bakabilirsiniz.
Hangi aşamada ne tür destek veriyoruz?
| Aşama | İş sahibinin sorusu | Çıktı |
|---|---|---|
| İhtiyaç | Ne yaptırmam gerekiyor, hazır bir ürün yeter mi? | İhtiyaç analizi, hazır ürün karşılaştırması |
| Şartname | Tedarikçilere ne vereceğim? | Numaralı teknik şartname, kabul senaryoları |
| Teklif | Hangi teklif gerçekçi? | Teklif karşılaştırma matrisi, tedarikçilere soru listesi |
| Geliştirme | İş gerçekten ilerliyor mu? | Aşama incelemeleri, değişiklik talebi kaydı, risk listesi |
| Kabul | Teslimi kabul edeyim mi? | Kabul testi sonuçları, açık hata listesi, tutanak taslağı |
Aşamaların hepsini ya da yalnızca birini alabilirsiniz. En çok fark yarattığı yer şartname ve kabul kriterleridir; geri kalanı onların uygulanmasıdır.
Yazılım analizi: şartnameden önce ne yapılır?
Yazılım analizi, işin bugün nasıl yürüdüğünü, kimin hangi yetkiyle neyi yaptığını ve hangi verinin nereden gelip nereye gittiğini, yazılımdan bağımsız olarak ortaya çıkarma işidir. Kullanıcılarla tek tek konuşuruz, çünkü yöneticinin anlattığı süreçle sahadaki süreç nadiren aynıdır. Çıktılar:
- Bugünkü ve hedeflenen süreç haritası, istisnalarıyla ("onaylayan izindeyse ne olur?").
- Rol ve yetki matrisi.
- Veri envanteri: hangi veri, hangi sistemden geliyor, kişisel veri mi, ne kadar süre tutulacak.
- Entegrasyon listesi: karşı sistemin API'si var mı, test ortamı ve anahtarı kimden alınacak.
- Kapsam dışı listesi. En az kapsamın kendisi kadar önemlidir; teslimde çıkan "bu da dahildi" tartışmasının cevabı buradadır.
İyi bir teknik şartnamede neler bulunur?
Teknik şartname, yazılımın ne yapacağını ve teslimde nasıl sınanacağını, her maddesi tek başına test edilebilecek biçimde yazan belgedir. Gereksinim mühendisliği standardı ISO/IEC/IEEE 29148:2018, tek bir gereksinimin taşıması gereken nitelikler arasında tek anlamlı, tekil (yalnızca bir konuyu anlatan), gerçekleştirilebilir ve doğrulanabilir olmayı sayar. Hazırladığımız şartnamelerin iskeleti:
- Amaç, kapsam ve kapsam dışı işler
- Terimler
- Kullanıcı rolleri ve yetki matrisi
- İşlevsel gereksinimler: numaralı, her biri tek bir davranış
- İşlevsel olmayan gereksinimler: performans eşikleri, desteklenen cihaz ve tarayıcılar, erişilebilirlik (WCAG 2.2 AA), güvenlik (OWASP ASVS 5.0'da seçilen doğrulama seviyesi)
- Denetim kaydı ve zaman damgası: hangi işlemlerin, hangi alanlarla, hangi saat referansıyla kaydedileceği
- Veri taşıma: kaynaklar, dönüşüm kuralları, prova tarihi
- Entegrasyonlar ve dış hizmetler
- Teslim paketi: geçmişiyle kaynak kod, belgeler, etiketlenmiş sürüm ve hash değeri, bağımlılık ve lisans listesi
- Kabul prosedürü: test ortamı, test verisi, süre, hata önem dereceleri
- Bakım dönemi: hata sınıfları ve her sınıf için müdahale süresi
Altıncı madde çoğu şartnamede hiç yoktur. Denetim kaydının neden ve nasıl kurulduğunu özel yazılım geliştirme sayfamızda alan alan anlattık.
Belirsiz bir madde nasıl ölçülebilir hâle getirilir?
Ölçülebilir madde; ölçülecek şeyi, eşiği ve koşulu birlikte söyler. Sık gördüğümüz ifadeler ve yeniden yazılmış hâlleri (sayılar örnektir, projeye göre belirlenir):
| Şartnamedeki ifade | Sorun | Ölçülebilir hâli |
|---|---|---|
| "Sistem hızlı olmalı" | Hangi işlem, hangi yük altında? | 50.000 ürünlük katalogda, 100 eş zamanlı kullanıcıyla arama isteklerinin %95'i 2 saniyenin altında yanıtlanmalı |
| "Kullanıcı dostu arayüz" | Kişiden kişiye değişir | WCAG 2.2 AA; sipariş girme görevi, eğitim almamış beş kullanıcıdan en az dördü tarafından yardımsız tamamlanmalı |
| "Raporlar Excel'e aktarılabilmeli" | Hangi rapor, kaç satır, hangi sütunlar? | Sipariş raporu, seçilen tarih aralığında 100.000 satıra kadar, Ek-3'teki sütunlarla .xlsx olarak 60 saniye içinde indirilmeli |
| "Güvenli olmalı" | Ölçüt yok | OWASP ASVS 5.0 Seviye 2; teslim öncesi bağımsız güvenlik testinde kritik ve yüksek önemde açık bulgu kalmamalı |
| "Mevcut veriler aktarılacak" | Hangi veri, ne kadar temiz? | Ek-5'teki müşteri ve sipariş tabloları aktarılacak, aktarılamayan satırlar gerekçesiyle raporlanacak; prova kabulden en az iki hafta önce yapılacak |
| "Yönetici her şeyi görebilmeli" | Yetki sınırı da iz de yok | Yetki matrisindeki "yönetici" rolü; bu rolün her görüntüleme ve dışa aktarma işlemi denetim kaydına geçmeli |
Kabul kriterleri uyuşmazlığı nasıl önler?
Kabul kriteri, bir gereksinimin karşılanmış sayılması için teslim edilen sürümde gözlenmesi gereken sonucu, önceden ve tarafların üzerinde anlaştığı biçimde tarif eder. Teslimde tartışma "yazılım çalışıyor mu" sorusundan "şu senaryo geçti mi" sorusuna iner. Davranış gereksinimlerini "Diyelim ki / Eğer / O zaman" kalıbında yazarız; bunlar Gherkin dilinin Türkçe anahtar kelimeleridir ve senaryolar istenirse otomatik teste de çevrilebilir:
Özellik: Sipariş iptali
Senaryo: Kargoya verilmiş sipariş müşteri tarafından iptal edilemez
Diyelim ki 1001 numaralı siparişin durumu "kargoda"
Eğer müşteri siparişi iptal etmek isterse
O zaman "Kargoya verilmiş sipariş iptal edilemez" uyarısı gösterilir
Ve siparişin durumu değişmez
Ve reddedilen deneme denetim kaydına yazılırİstenmeyen durumlar ve her zaman geçerli kurallar için EARS kalıplarını kullanırız: "Ödeme kuruluşundan 30 saniye içinde yanıt gelmezse sistem siparişi 'ödeme bekliyor' durumunda tutmalı ve müşteriye yeniden deneme seçeneği sunmalıdır." Kabul prosedürü de şartnamede yazılır: testin hangi ortamda ve hangi veriyle yapılacağı, iş sahibinin kaç iş günü içinde sonuç bildireceği, hangi önem derecesindeki hatanın kabulü engelleyeceği.
Yazılım sözleşmesi eser sözleşmesi olarak nitelendirilirse TBK m.474, iş sahibinin teslimden sonra eseri imkân bulur bulmaz gözden geçirmesini ve ayıpları uygun süre içinde bildirmesini öngörür; m.477'ye göre gözden geçirme ve bildirim ihmal edilirse eser kabul edilmiş sayılır. Sözleşmenizin nasıl nitelendirileceğini ve sürelerin nasıl işleyeceğini avukatınız değerlendirir. Teknik tarafta yapılacak olan, kabul testinin hangi tarihte, hangi sürümde (etiket ve paketin SHA-256 değeri; değeri hash hesaplama aracıyla siz de alabilirsiniz) ve hangi sonuçla yapıldığını tutanağa bağlamak, bulunan hataları tarihli olarak kaydetmektir. Git'teki commit tarihleri geliştiricinin bilgisayarında ayarlanabildiği için teslim anını tek başına göstermez.
Teklifler nasıl karşılaştırılır?
Teklifleri fiyattan önce şartnameye göre okuruz. Aynı soru listesini bütün tedarikçilere gönderir, cevapları yazılı alırız; standart ürün tanıtımı yerine şartnameden seçtiğimiz iki üç senaryoyu canlı göstermelerini isteriz. Karşılaştırma matrisinde baktıklarımız:
| Kriter | Neye bakarız | Uyarı işareti |
|---|---|---|
| Kapsam eşlemesi | Teklif her şartname maddesine ayrı cevap veriyor mu? | Tek cümle: "Şartnameye uygun geliştirilecektir" |
| Varsayımlar | Hangi işi iş sahibine bırakıyor? | Varsayım bölümü yok; içerik girişi ve veri temizliği sessizce size kalmış |
| Efor dağılımı | Analize, teste ve veri taşımaya ayrılan pay | Test ve veri taşımaya hiç süre ayrılmamış |
| Teknoloji | Seçimin gerekçesi, lisans bedelleri, başka bir ekibin devralabilmesi | Tedarikçiye özgü kapalı bir altyapı, belirsiz lisans maliyeti |
| Kod ve hesaplar | Depo, sunucu ve mağaza hesapları kimin adına? | Kaynak kod teslimi yok, sunucu tedarikçinin hesabında |
| Bakım | Hata önem dereceleri ve müdahale süreleri | "Makul sürede destek verilir" |
| Ekip | Projede kimlerin, hangi oranda çalışacağı | Bütün bilgi tek bir kişide |
Bizce en düşük teklif çoğu zaman en çok varsayım içeren tekliftir. Arada kaldığınız iki tedarikçi varsa, şartnameden seçilmiş küçük ve ücretli bir deneme işi çoğu toplantıdan fazlasını gösterir.
Teknik proje yönetimi: geliştirme sürerken ne izleriz?
Bu aşamada iş sahibinin teknik temsilcisi olarak çalışırız. Tedarikçinin proje yöneticisinin yerine geçmeyiz; iş sahibinin göremediği yeri görünür kılarız.
- Aşama incelemeleri. Her aşamanın sonunda test ortamındaki sürümde ilgili kabul senaryolarını koşar, geçenleri ve kalanları yazarız.
- Depo ve derleme kayıtları. Okuma yetkisiyle kod deposunu ve CI kayıtlarını izleriz. Commit sayısı ilerleme ölçüsü değildir; hangi gereksinimin kodunun girdiğine bakarız.
- Değişiklik talebi kaydı. Her talep numaralanır, süreye ve bedele etkisi yazılır. E-postada ya da toplantıda kalan talep, teslimde en çok tartışılan konudur.
- Risk ve hata listesi. Açık hatalar önem derecesiyle, entegrasyon ve veri taşıma riskleri sorumlusuyla.
- Bağımlılık ve lisanslar. Projeye giren üçüncü taraf bileşenlerin lisansları teslimden önce değil, projeye girdikleri anda kontrol edilir.
Bu hizmetin sınırları
- Sözleşmeyi hazırlamayız. Şartnameyi ve kabul prosedürünü, avukatınızın sözleşmeye ek olarak bağlayabileceği teknik belgeler olarak hazırlarız; sözleşme hükümleri ve hukuki değerlendirme avukata aittir.
- Değerlendirdiğimiz ihalede teklif vermeyiz. Şartnamesini yazdığımız ya da tekliflerini değerlendirdiğimiz bir projede kendimiz tedarikçi olmayız.
- Kendi projemizde bağımsız uzman olamayız. Danışmanlık yaptığımız bir projede uyuşmazlık çıkarsa, o proje hakkında hazırlayacağımız görüş bağımsız sayılmaz. Tuttuğumuz kayıtları, yani aşama incelemelerini, değişiklik talebi kaydını ve kabul testi sonuçlarını düzenli biçimde teslim ederiz; teknik değerlendirmeyi projeyle bağı olmayan bir uzmanın ya da mahkemenin görevlendireceği bilirkişinin yapması gerekir (uzman görüşü ile bilirkişi farkı).
- İyi bir şartname projenin başarılı olacağı anlamına gelmez. Ama bir şey ters gittiğinde neyin, ne zaman ters gittiğinin anlaşılmasını sağlar.
Başlamak için ne gerekir?
Elinizde ne varsa: bir sayfalık iş tanımı, eski ya da yarım bir şartname, alınmış teklifler, sözleşme taslağı, bugün kullanılan sistemin ekran görüntüleri ve örnek belgeler. Kişisel veri içeren gerçek kayıtları ilk aşamada göndermeyin; yapıyı görmek için anonimleştirilmiş bir örnek yeter. Kararı kimin vereceğini, takvimi ve bütçe aralığını da yazın. Bütçesi belli olmayan bir şartname ya gereğinden büyük ya gereğinden küçük yazılır.