Yazılım
Özel Yazılım Nedir ve Hazır Sistemlerden Hangi Yönleriyle Ayrılır
Beşiktaş web yazılım hizmeti, bir kuruluşun kendine özgü iş akışlarını temel alan ve tarayıcıda çalışan özel bir uygulamanın sıfırdan geliştirilmesidir. Kullanıcı cihazına program kurulmaz; personel ve yetkili müşteriler e-posta adresi ile parola girerek oturum açar. Tüm kayıtlar merkezi sunucudaki veritabanında durduğu için masaüstü, tablet ya da telefondan bağlanan herkes aynı anlık bilgiyi görür. Bayi sipariş portalı, teklif hazırlama paneli, servis formu takibi, randevu modülü, depo sayım ekranı ve personel izin çizelgesi bu kapsamda sık geliştirilen işlerdir. Teslim edilen ürün; kullanıcı ekranlarından, iş kurallarını işleten sunucu kodundan, ilişkisel veri katmanından ve dış servislerle haberleşen bağlantı noktalarından oluşur. Erişim izinleri kişi bazında ayrı ayrı tanımlanır.
Hazır içerik yönetim sistemleri (CMS), örneğin WordPress ya da Joomla, sayfa metni, görsel galerisi, menü ve blog yazısı yayınlamak için geliştirilmiş genel amaçlı ürünlerdir. Veri yapıları yazı, sayfa ve kategori gibi sabit tiplere dayanır. Bayiye göre değişen iskonto, çok kademeli onay zinciri veya cari bakiye hesabı gibi işlevler bu yapıya eklentiyle sonradan iliştirilir. Eklenti adedi arttıkça farklı kaynaklardan gelen kodlar çakışabilir, gereksiz tablolar birikir ve her güncellemede uyumluluk kontrolü gerekir. Özel olarak kodlanan bir yazılımda veri yapısı doğrudan işletmenin nesnelerine göre kurulur; sipariş, cari ve stok kendi tablolarında tutulur. İlk yatırım ve teslim süresi daha yüksektir, buna karşılık kişi başı abonelik ve eklenti lisansı ödenmez.
Özel geliştirme ihtiyacı çoğunlukla somut belirtilerle ortaya çıkar. Aynı bilginin hem hesap tablosuna hem muhasebe programına elle girilmesi, onayların e-posta yazışmalarında kaybolması, aylık raporların birkaç dosyadan elle birleştirilmesi ve hazır paketin kullanıcı sayısıyla artan bedeli bu belirtilerin başında gelir. Süreç standartsa ve dış servis bağlantısı gerekmiyorsa bulut tabanlı bir paket aboneliği daha ekonomik kalır. Beşiktaş’taki işletmeler için yapılan ilk görüşmede bu belirtiler tek tek listelenir, her birinin hazır bir üründe karşılanıp karşılanmadığı işaretlenir. Karşılanmayan maddeler kapsam çalışmasının girdisi olur ve ileride hazırlanacak gereksinim dokümanının iskeletini oluşturur. Liste kısa kalırsa mevcut aracın ayarlarını değiştirmek ya da tek bir eklenti kurmak da seçenek olarak raporlanır.
Geliştirme Süreci Hangi Adımlardan Oluşur ve Nasıl İlerler
Çalışma, gereksinim dokümanının hazırlanmasıyla başlar. Bu aşamada uygulamayı kullanacak her birimle ayrı görüşme yapılır; kullanılan formlar, hesap tabloları, onay adımları ve çıktı alınan raporlar toplanır. Doküman; kullanıcı rollerini, ekran listesini, iş kurallarını, hesaplama formüllerini, bildirim koşullarını ve yanıt süresi gibi işlevsel olmayan beklentileri içerir. Kapsam dışında kalan konular ayrı bir başlıkta yazılır. Her gereksinime ölçülebilir bir kabul ölçütü eklenir; on bin kayıtlık bir raporun üç saniyenin altında açılması bu tür bir ölçüttür. Belgedeki her madde benzersiz bir kodla numaralanır; test vakaları ve sprint işleri bu kodlara bağlanarak izlenebilirlik sağlanır. Süre ve fiyat bu belgeden türetilir. Fiyatı en çok etkileyen kalemler ekran sayısı, bağlanacak servislerin adedi ve taşınacak kayıt hacmidir.
Doküman onaylanınca veri modeli çıkarılır. Sistemin saklayacağı varlıklar, örneğin müşteri, ürün, sipariş, fatura ve ödeme, alanları ve veri tipleriyle listelenir; aralarındaki bağlantılar ve bu bağlantıların türü varlık-ilişki diyagramında (ERD) gösterilir. Bir müşterinin çok sayıda siparişi olabilmesi bu tür bir bağlantıdır. Tekrarlı veri, normal formlara uygun tablo bölümlemesiyle önlenir; filtre ve sıralamada kullanılacak alanlar indekslenir. Şema kararlarında kayıt sayısının birkaç yıl içinde ulaşacağı hacim de hesaba katılır. Ardından tel kafes çizimleri ve tıklanabilir prototip hazırlanır. Prototipin amacı, ekranlar arası geçişleri ve form düzenini kod yazılmadan kullanıcıya göstermektir; arkasında gerçek bir veritabanı bulunmaz. Figma gibi araçlarla hazırlanan bu taslak üzerinde kullanıcı temsilcileri not düşer. Notlar işlendikten sonra arayüz onaylanır ve kodlama planı bu onaylı ekranlar üzerinden hazırlanır.
Kodlama, iki haftalık sprintlere bölünmüş çevik bir planla ilerler. Sprint açılışında o döneme sığacak işler seçilir ve tahmini efor puanı verilir; kapanışta tamamlanan ekranlar hazırlık (staging) ortamında canlı olarak sunulur. Gösterimde gelen düzeltme istekleri iş listesine yazılır ve önceliğe göre sıraya girer. Sprint hızı, yani dönem başına bitirilen puan, kalan takvimi tahmin etmekte kullanılır. Değişiklikler birleştirme isteği (pull request) ile açılır, ikinci bir geliştiricinin onayı olmadan ana koda katılmaz. Son sprintten sonra test turu yürütülür, kabul onayı alınmadan yayına çıkılmaz. Canlıya geçiş bir kontrol listesiyle yapılır: göç betikleri, ortam ayarları, alan adı kaydı, sertifika ve izleme araçları sırayla doğrulanır. Orta ölçekli bir panelin tamamlanması çoğunlukla üç ile beş ay alır.
Teknik Mimari, Veri Katmanı ve Entegrasyonlar Nasıl Kurulur
Beşiktaş yazılım projelerinde mimari, bir isteğin izlediği yola göre katmanlara ayrılır. Tarayıcıdaki arayüz isteği gönderir; sunucu kodu oturumu, yetkiyi ve girdiyi denetler, iş kuralını çalıştırır, veritabanına yazar ya da okur ve yanıtı JSON biçiminde geri döndürür. Sunucu tarafı için Laravel, Django, NestJS veya ASP.NET Core gibi bir çatı (framework) seçilir; uzun süreli destek (LTS) takvimi ve paket ekosistemi bu seçimde belirleyicidir. Kalıcı veri PostgreSQL ya da MySQL üzerinde tutulur. Yabancı anahtar kısıtları ve transaction blokları, yarım kalan bir işlemin tabloları tutarsız bırakmasını engeller. Geçici veriler için Redis, yüklenen belgeler için nesne depolama alanı kullanılır. Sunucu kodu ile arayüz kodu ayrı depolarda ya da aynı deponun ayrı klasörlerinde tutulur, böylece ikisi bağımsız sürümlenebilir.
Ekranlar veriyi doğrudan veritabanından değil, API (programlar arası veri alışverişi için tanımlanmış uç noktalar) üzerinden alır. Uç noktalar REST kurallarına göre adlandırılır, sürüm numarası taşır ve OpenAPI belgesiyle tanımlanır; böylece ileride yazılacak bir mobil istemci ek geliştirme olmadan aynı kaynakları kullanır. Kimlik doğrulama, kısa ömürlü erişim belirteci ile yenileme belirteci çiftiyle yapılır; oturum süresi dolduğunda belirteç geçersiz olur ve kullanıcı yeniden giriş yapar. Yetkiler RBAC yöntemiyle, yani rollere bağlı erişim denetimiyle düzenlenir. Roller, modül ve işlem bazında izin listeleri taşır; bir kullanıcıya birden fazla rol atanabilir. Şube veya bölge gibi kayıt düzeyindeki kısıtlar sorgu katmanında uygulanır, bu sayede kişi yetkisi olmayan satırı listede de göremez.
Dış servis bağlantıları her sağlayıcının resmî entegrasyon belgesine göre yapılır. Ödeme tarafında banka veya lisanslı ödeme kuruluşunun sanal POS servisi bağlanır. Kart bilgisi uygulamanın veritabanına hiç yazılmaz; doğrulama bankanın 3D Secure sayfasında gerçekleşir ve sisteme yalnızca işlem sonucu döner. Tek kullanımlık giriş kodu ve sipariş durum mesajı, operatör onaylı bir toplu SMS sağlayıcısının servisiyle gönderilir. E-fatura ve e-arşiv kayıtları, GİB onaylı bir özel entegratörün API’sine iletilerek oluşturulur. Muhasebe programına satış ve tahsilat hareketleri, mükerrer kayıt oluşmaması için benzersiz anahtarla aktarılır. Kargo entegrasyonunda gönderi numarası alınır, etiket PDF olarak basılır, teslim bilgisi webhook (sağlayıcının gönderdiği otomatik bildirim) ile siparişe işlenir. Bağlantıların çalışma durumu yönetim panelinde ayrı bir ekranda izlenir.
Güvenlik Katmanları, KVKK Gereklilikleri ve Ölçeklenme Nasıl Planlanır
Güvenlik denetimi OWASP Top 10 (web uygulamalarında en sık görülen on risk sınıfı) üzerinden yapılır ve her riskin karşı önlemi kodda karşılık bulur. Bozuk erişim denetimine karşı her uç noktada sunucu tarafı yetki kontrolü yazılır. Enjeksiyona karşı sorgular parametre bağlamayla kurulur. XSS (sayfaya zararlı betik yerleştirme) riskine karşı çıktılar kaçışlanır ve CSP başlığı tanımlanır. CSRF saldırısı form belirteciyle engellenir. Şifreleme iki noktada uygulanır: aktarımda TLS 1.3, depolamada ise kimlik numarası ve banka bilgisi gibi alanlar için AES-256. Parola özetinde bcrypt kullanılır. Şifreleme anahtarları depoya eklenmez; HashiCorp Vault ya da bulut sağlayıcının anahtar yönetim servisi gibi bir kasada durur. Bağımlılıklar her derlemede bilinen açıklar için taranır.
Loglama, bir sorunun nedenini ve kimin hangi işlemi yaptığını sonradan tespit etmeye yarar. Uygulama günlükleri yapılandırılmış biçimde (JSON) merkezi bir toplama aracına gönderilir ve belirli bir süre saklanır. Yetkili kullanıcıların kayıt değiştirme, rapor indirme ve izin düzenleme işlemleri ayrı bir denetim tablosunda eski ve yeni değerleriyle tutulur. Erişim günlükleri, yetkisiz giriş denemelerinin fark edilmesi için uyarı kurallarına bağlanır. Yedekleme planında RPO (göze alınabilecek azami veri kaybı süresi) ve RTO (hizmetin yeniden açılması için hedeflenen süre) değerleri yazılır; anlık görüntüler ve işlem günlüğü yedekleri bu hedeflere göre zamanlanır, bir kopya başka bir coğrafi bölgede saklanır. KVKK açısından veri envanteri, aydınlatma metni, açık rıza kaydı ve saklama-imha politikası panel içinde uygulanır.
Performans, sayısal hedeflerle yönetilir. Gereksinim belgesinde p95 yanıt süresi (isteklerin yüzde 95’inin tamamlandığı süre) ve eş zamanlı oturum kapasitesi yazılır; yük testleri bu değerlere göre değerlendirilir. Veritabanı tarafında sorgu planları incelenir, bileşik indeksler eklenir, bağlantı havuzu (connection pool) ile açılıp kapanan bağlantı maliyeti düşürülür. Tekrar hesaplanması pahalı sonuçlar için önbellek katmanı kurulur. Kullanıcıyı bekleten uzun görevler, örneğin dışa aktarma ve toplu bildirim, arka plan işçilerine verilir. Ölçeklenme için uygulama durumsuz (stateless) tasarlanır; bu sayede yük arttığında aynı kodun yeni kopyaları yük dengeleyici arkasına eklenebilir. Büyüyen tablolar tarih bazında bölümlenir, eski hareketler arşiv tablolarına taşınır. Hedeflerin tutup tutmadığı canlı ortamda panolarla sürekli izlenir.
Test Çeşitleri, Proje Teslimi ve Sürekli Bakım Hangi İşleri İçerir
Test planı, test piramidi adı verilen yapıya göre kurulur: tabanda çok sayıda hızlı birim testi, ortada daha az sayıda entegrasyon testi, tepede sınırlı sayıda uçtan uca test bulunur. Birim testi tek bir fonksiyonu, örneğin indirim hesabını, sabit girdilerle sınar. Entegrasyon testi API, veritabanı ve dış servis taklitleri (mock) ile katmanların uyumunu ölçer. Uçtan uca test, Playwright veya Cypress ile tarayıcıda gerçek kullanıcı adımlarını tekrarlar. Bunlara ek olarak yük testi, güvenlik taraması ve her sürümde regresyon testi yapılır. Kullanıcı kabul testinde (UAT) işletme temsilcileri gereksinim maddelerini tek tek dener. Otomatik testler sürekli entegrasyon (CI) hattında her değişiklikte çalışır. Bulunan her hata, tekrarını yakalayacak yeni bir testle birlikte kapatılır.
Teslim kapsamı sözleşmede madde madde yazılır. Kaynak kodun tamamı, sürüm geçmişi korunarak işletmeye ait bir Git deposuna aktarılır; derleme ve dağıtım betikleri de bu depoda yer alır. Dokümantasyon tarafında README dosyası, mimari şema, veritabanı diyagramı, API referansı, operasyon el kitabı (runbook) ve rollere göre ayrılmış kullanım kılavuzu verilir. Belgeler kodla aynı depoda tutulur ve kodla birlikte güncellenir. Sahiplik konusunda 5846 sayılı Fikir ve Sanat Eserleri Kanunu kapsamındaki mali hakların devri sözleşmeye eklenir, kullanılan açık kaynak kütüphanelerin lisansları listelenir. Sunucu, alan adı ve servis sağlayıcı hesapları işletme adına açılır; teslim günü erişim anahtarları yenilenir. Bu düzen, başka bir ekibin işi devralmasını kolaylaştırır.
Yayındaki yazılımın sürdürülmesi için bakım ve destek sözleşmesi imzalanır. Sözleşme ekinde SLA (hizmet düzeyi taahhüdü) tablosu yer alır; bu tabloda arızaların etki derecesine göre dört seviyeye ayrıldığı ve her seviyenin azami ilk dönüş süresi yazılıdır. Rutin bakım kalemleri şunlardır: işletim sistemi ve çatı güncellemeleri, bağımlılık taraması, güvenlik yaması, yedek doğrulaması, disk ve bellek kullanımının izlenmesi. Destek talepleri bilet sistemi üzerinden açılır ve her kaydın geçmişi saklanır. Yeni ekran, ek rapor ya da ilave entegrasyon bakım bedeline dâhil edilmez; bunlar ayrı iş kalemi olarak fiyatlandırılır. Aylık raporda çalışma süresi, hata sayısı ve ortalama çözüm süresi paylaşılır. Sözleşme süresi çoğunlukla bir yıldır ve yenilenebilir.