Özel yazılım projesine başlamadan önce: ihtiyaç analizi ve kapsam

Özel yazılım projelerinde sorunların büyük kısmı kod yazılırken değil, kod yazılmaya başlamadan önce ortaya çıkar. Ne yapılacağı yeterince net değilse, geliştirme sürecinde her hafta yeni bir istek eklenir, teslim tarihi kayar ve bütçe öngörülemez hâle gelir. İhtiyaç analizi ve yazılı bir kapsam, bu belirsizliği proje başında azaltmanın en etkili yoludur.

Bu yazıda bir özel yazılım projesine başlamadan önce netleştirmeniz gereken konuları sırayla ele alıyoruz: hazır yazılım seçeneği, iş süreçleri, kullanıcı rolleri, ilk sürümün kapsamı, entegrasyonlar, veri güvenliği, sahiplik ve bakım.

Önce şunu sorun: hazır bir yazılım işi görür mü?

Ön muhasebe, CRM, randevu ya da stok takibi gibi yaygın ihtiyaçlar için çok sayıda hazır yazılım vardır. Bunlar hızlı başlar, bakımı sağlayıcıya aittir ve aylık ya da yıllık lisansla kullanılır. Özel yazılım ise şu durumlarda daha anlamlı hâle gelir:

• İş süreciniz sektörünüze ya da işletmenize özgü ve hazır ürünler bu süreci karşılamıyor.
• Birden fazla hazır aracı birbirine bağlamak için çalışanlar aynı veriyi tekrar tekrar elle giriyor.
• Kullanıcı sayısı arttıkça lisans maliyeti sizin için sürdürülemez hâle geliyor.
• Yazılımın kendisi, müşterilerinize sunduğunuz hizmetin ya da ürünün bir parçası olacak.

Bu soruya dürüst bir cevap vermek, gereksiz bir geliştirme bütçesini önleyebilir. Bazen doğru çözüm, hazır bir ürünü kullanıp yalnızca eksik kalan kısmı özel olarak geliştirmektir.

1. Sorunu süreç üzerinden tanımlayın

“Bize bir panel lazım” bir ihtiyaç tanımı değildir. Bunun yerine bugün işin nasıl yürüdüğünü adım adım yazın: talep nereden geliyor, kim kaydediyor, kim onaylıyor, bilgi kime iletiliyor, iş nasıl kapanıyor? Bugün bu adımlar Excel tabloları, WhatsApp grupları ya da kâğıt formlarla yürüyorsa, bunları da olduğu gibi not edin.

Ardından her adımda yaşanan sorunu yazın: bilginin kaybolması, aynı verinin iki kez girilmesi, onayın gecikmesi, raporun elle hazırlanması. Yazılımın neyi çözeceği bu listeden çıkar ve proje sonunda başarıyı ölçmek için de bu liste kullanılır.

2. Kullanıcıları ve rolleri listeleyin

Yazılımı kimlerin kullanacağını ve her birinin neyi görüp neyi değiştirebileceğini baştan belirlemek, hem arayüz tasarımını hem de yetkilendirme yapısını şekillendirir. Basit bir tablo yeterlidir:

• Yönetici: Tüm kayıtları görür, kullanıcı ekler, raporları alır.
• Operasyon çalışanı: Kendisine atanan işleri görür ve günceller.
• Muhasebe: Faturalama ve tahsilat ekranlarına erişir, operasyon kayıtlarını yalnızca okur.
• Müşteri ya da bayi: Yalnızca kendi kayıtlarını ve taleplerini görür.

Rol sayısı arttıkça yazılımın karmaşıklığı da artar. İlk sürümde gerçekten gerekli olan rollerle başlamak, geliştirme süresini kısaltır.

3. İlk sürümün kapsamını daraltın

Her şeyi ilk sürüme sığdırmaya çalışmak, projenin en sık rastlanan gecikme nedenlerinden biridir. İstek listesini üç gruba ayırın: ilk sürümde mutlaka olması gerekenler, ilk sürümden sonra eklenebilecekler ve şimdilik yalnızca fikir olarak kalanlar. İlk sürüm, en kritik iş akışını uçtan uca çalıştıracak kadar küçük olmalıdır. Gerçek kullanıcıların geri bildirimi geldikçe sonraki sürümlerin önceliği de netleşir.

Kullanıcı hikâyesi ve kabul kriteri

Her özelliği kısa bir kullanıcı hikâyesiyle ve ölçülebilir bir kabul kriteriyle yazmak, “bitti” tanımı konusundaki tartışmaları azaltır. Örnek:

• Hikâye: Operasyon çalışanı olarak, bana atanan servis taleplerini tarihe göre sıralı görmek istiyorum; böylece günümü planlayabilirim.
• Kabul kriteri 1: Liste yalnızca giriş yapan kullanıcıya atanan talepleri gösterir.
• Kabul kriteri 2: Talepler randevu tarihine göre sıralanır ve duruma göre filtrelenebilir.
• Kabul kriteri 3: Talep durumu değiştirildiğinde yöneticiye bildirim gider.

Ekranları kodlamadan önce görün

Kapsam yazıyla netleştikten sonra temel ekranların tel kafes çizimleri ya da tıklanabilir bir prototipi hazırlanabilir. Prototip üzerinde yapılan bir değişiklik, kodlanmış bir ekranı değiştirmekten çok daha az emek ister. Prototipi yazılımı her gün kullanacak çalışanlara da gösterin; bir alanın eksik olduğunu ya da bir adımın gereksiz olduğunu çoğu zaman onlar fark eder.

4. Entegrasyonları baştan belirleyin

Özel yazılım nadiren tek başına çalışır. Hangi sistemlerle veri alışverişi yapacağını proje başında bilmek, hem süre hem maliyet tahminini doğrudan etkiler. Türkiye’deki projelerde sık karşılaşılan entegrasyonlar şunlardır:

• E-fatura ve e-arşiv fatura: Faturaların Gelir İdaresi Başkanlığı’nın sistemine iletilmesi için genellikle bir özel entegratörün servisleri kullanılır.
• Ön muhasebe ve ERP yazılımları: Cari hesap, stok ve tahsilat verilerinin aktarımı.
• Ödeme kuruluşları ve sanal POS: Online tahsilat ve iade işlemleri.
• Kargo firmaları ve pazaryerleri: Gönderi oluşturma, takip numarası alma, sipariş ve stok senkronizasyonu.
• SMS, e-posta ve bildirim servisleri: Doğrulama kodları ve bilgilendirme mesajları.

Her entegrasyon için karşı tarafın bir API dokümantasyonu ve test ortamı sunup sunmadığını, kullanım ücreti olup olmadığını ve sözleşme gerektirip gerektirmediğini önceden öğrenin. Test ortamı olmayan bir entegrasyon, geliştirme süresini belirgin biçimde uzatabilir.

5. Veri, güvenlik ve KVKK

Yazılım müşteri, çalışan ya da tedarikçi bilgisi işleyecekse 6698 sayılı Kişisel Verilerin Korunması Kanunu kapsamındaki yükümlülükler de tasarımın bir parçasıdır. Bu yükümlülükler çoğunlukla yazılımı kullanan işletmeye, yani veri sorumlusuna aittir; ama yazılım bunları yerine getirmeyi kolaylaştırmalıdır:

• Yalnızca amaç için gerekli verinin toplanması ve formlarda gereksiz alan bulunmaması.
• Rol bazlı erişim: her kullanıcının yalnızca işi için gereken veriyi görmesi.
• Kritik işlemlerin kim tarafından ne zaman yapıldığını gösteren işlem kayıtları.
• Düzenli yedekleme ve yedekten geri dönüşün test edilmesi.
• Saklama süresi dolan verilerin silinebilmesi ya da anonim hâle getirilebilmesi.

Sunucunun ya da kullanılan bulut hizmetinin hangi ülkede olduğu da önemlidir. Kişisel verilerin yurt dışına aktarımı KVKK’nın 9. maddesinde düzenlenir ve bu madde 2024’te kapsamlı biçimde değiştirildi. Barındırma kararını verirken bu konuyu hukuk danışmanınızla birlikte değerlendirin. Uygulama güvenliği tarafında ise OWASP Top 10 listesi, web uygulamalarında en sık görülen güvenlik risklerini anlamak için yaygın kabul gören bir başlangıç noktasıdır.

6. Kaynak kodu ve hesaplar kimin olacak?

5846 sayılı Fikir ve Sanat Eserleri Kanunu, bilgisayar programlarını eser olarak korur. Kanunun 52. maddesine göre mali haklara ilişkin sözleşmelerin yazılı yapılması ve devredilen hakların tek tek gösterilmesi gerekir. Bu nedenle sözleşmede şu konuların açıkça yazılı olması önemlidir:

• Kaynak kodunun ve mali hakların devredilip devredilmediği ya da yalnızca kullanım lisansı verilip verilmediği.
• Kodun hangi depoda tutulacağı ve işletmenin bu depoya erişimi olup olmayacağı.
• Alan adı, sunucu, bulut, uygulama mağazası ve üçüncü taraf servis hesaplarının işletme adına açılması.
• Projede kullanılan açık kaynak kütüphanelerin lisans koşulları.

Sözleşme hazırlığında bir avukattan destek almanızı öneririz; bu yazı genel bilgilendirme amaçlıdır.

7. Yayından sonrasını da planlayın

Yazılım teslim edildiğinde iş bitmez. İşletim sistemleri, tarayıcılar, kütüphaneler ve entegre olunan servisler güncellendikçe yazılımın da güncellenmesi gerekir. Teklif aşamasında şu soruların cevabını alın: Hata bildirimleri nasıl iletilecek? Kritik bir hata ne kadar sürede ele alınacak? Küçük geliştirme talepleri nasıl ücretlendirilecek? Bakım hizmeti hangi kapsamda ve hangi süreyle verilecek?

Kapsam dokümanında olması gerekenler

1. Projenin amacı ve çözülecek sorunlar
2. Mevcut süreç ve hedeflenen süreç akışı
3. Kullanıcı rolleri ve yetkileri
4. İlk sürüme giren özellikler, kullanıcı hikâyeleri ve kabul kriterleri
5. İlk sürüm dışında bırakılan özellikler
6. Entegrasyonlar ve her biri için sorumlu taraf
7. Veri güvenliği, yedekleme ve barındırma tercihi
8. Teslim aşamaları, test ve kabul süreci
9. Kaynak kodu, hesaplar ve fikri haklar
10. Bakım ve destek koşulları

Sık yapılan hatalar

• Yazılımı kullanacak çalışanları analiz sürecine dâhil etmemek.
• Ekran tasarımlarını görmeden geliştirmeye başlamak.
• Kapsam dışı istekleri yazılı bir değişiklik süreci olmadan projeye eklemek.
• Test ve kabul için zaman ayırmamak; testi yayın gününe bırakmak.
• Hesapları ve kodu yalnızca yazılım firmasının erişebileceği yerlerde tutmak.

Guru Dijital, özel yazılım projelerine ihtiyaç analizi ve kapsam dokümanıyla başlıyor. Aklınızdaki projeyi bu başlıklar üzerinden birlikte netleştirmek isterseniz bir ön görüşme planlayabiliriz.

Kaynaklar

• 6698 sayılı Kişisel Verilerin Korunması Kanunu (Mevzuat Bilgi Sistemi)
• 5846 sayılı Fikir ve Sanat Eserleri Kanunu (Mevzuat Bilgi Sistemi)
• Kişisel Verileri Koruma Kurumu
• OWASP Top 10 (OWASP Foundation)
• OWASP Application Security Verification Standard (OWASP Foundation)