Yazılım
Yazılım Hizmeti Nedir ve Hazır Sistemlerden Nasıl Ayrılır
Özel web tabanlı uygulama, bir işletmenin kendi iş akışına göre sıfırdan kodlanan ve tarayıcı üzerinden çalışan sistemdir. Kullanıcı bilgisayarına kurulum gerekmez; erişim için internet bağlantısı ve güncel bir tarayıcı yeterlidir. Bu kapsamdaki Şişli web yazılım çalışmaları sipariş takibi, randevu planlama, stok yönetimi, bayi portalı veya müşteri paneli gibi ihtiyaçlara yönelik hazırlanır. Uygulama; veri tabanı, sunucu tarafı kodu ve kullanıcı arayüzü olmak üzere üç ana katmandan oluşur. Her katman ayrı sorumluluk taşır ve birbirinden bağımsız güncellenebilir. Kapsam, işletmenin hangi süreçleri dijital ortama taşımak istediğine göre belirlenir. Bir modül tek bir departmanı ilgilendirebileceği gibi birden fazla birimi ortak veri üzerinden bağlayan geniş bir platform da kurulabilir.
Hazır içerik yönetim sistemleri (CMS; WordPress, Joomla gibi) sayfa, blog yazısı ve menü yönetimi için tasarlanmıştır. Bu sistemlerde ek özellikler eklentilerle sağlanır. Eklenti sayısı arttıkça güncelleme uyumsuzlukları, güvenlik açıkları ve sayfa yavaşlaması görülebilir. Özel bir yazılımın veri yapısı ise baştan işletmenin kayıt türlerine göre kurulur; gereksiz tablo ve kod bulunmaz. Yetki tanımları, raporlar ve iş kuralları doğrudan koda işlenir. Buna karşılık ilk kurulum maliyeti ve geliştirme süresi hazır sisteme göre daha yüksektir. Lisans bedeli olmaması ve eklenti bağımlılığının ortadan kalkması uzun dönemde bu farkı kısmen dengeler. Seçim, beklenen işlev listesinin hazır araçlarla ne ölçüde karşılanabildiğine bakılarak yapılır. İhtiyaç yalnızca içerik yayınlamaksa hazır sistemde kalmak daha ekonomik bir yoldur.
Özel geliştirme şu durumlarda tercih edilir: iş süreci hazır ürünlerin varsayılan akışına uymuyorsa, birden fazla dış sistemle veri alışverişi gerekiyorsa, kullanıcı sayısı arttıkça lisans maliyeti yükseliyorsa veya veriler üçüncü taraf bir platformda tutulamıyorsa. Restoran, klinik, lojistik firması, üretim atölyesi ve eğitim kurumu gibi işletmeler bu ihtiyaçlarla sık karşılaşır. Şişli yazılım projelerinde ilk görüşmede mevcut araçlar, Excel tabloları ve manuel adımlar listelenir. Bu liste, hangi işin otomatikleştirileceğini ve hangisinin hazır bir hizmetle çözülebileceğini ayırmak için kullanılır. Her ihtiyaç için sıfırdan kodlama önerilmez; e-posta, takvim veya dosya paylaşımı gibi standart işler genellikle mevcut servislerle bağlanır. Karar, maliyet ve süre tahminiyle birlikte kısa bir rapor olarak sunulur.
Özel Uygulama Geliştirme Süreci Hangi Adımlardan Oluşur
Bir yazılım projesinin ilk aşaması ihtiyaç analizidir. Bu aşamada sistemi kullanacak birimlerle görüşülür, mevcut iş akışı adım adım çıkarılır ve hangi verinin kim tarafından girildiği, onaylandığı ya da raporlandığı belirlenir. Toplanan bilgiler gereksinim dokümanına aktarılır. Doküman; işlevsel gereksinimleri (sistemin ne yapacağı), işlevsel olmayan gereksinimleri (hız, erişilebilirlik, güvenlik düzeyi), kullanıcı rollerini ve kapsam dışı kalan maddeleri içerir. Her madde için kabul ölçütü yazılır; böylece teslimde neyin tamamlanmış sayılacağı baştan bellidir. Süre ve bütçe bu dokümana göre hesaplanır. Ekran sayısı, entegrasyon adedi, raporlama derinliği ve veri taşıma ihtiyacı maliyeti en çok etkileyen kalemlerdir. Onaylanan doküman, sonraki tüm aşamaların referansı olarak saklanır.
Gereksinimler netleşince veri modeli hazırlanır. Veri modeli; sistemdeki varlıkları (müşteri, sipariş, ürün, fatura gibi), bu varlıkların alanlarını ve aralarındaki ilişkileri gösteren şemadır. ER diyagramı (varlık-ilişki şeması) ile çizilir ve tablo yapısı, birincil anahtarlar, zorunlu alanlar bu aşamada kararlaştırılır. Model sonradan değiştirildiğinde birçok ekranı etkilediği için erken onay alınır. Ardından prototip üretilir. Prototip, ekranların tıklanabilir ama veri işlemeyen bir taslağıdır; Figma veya benzeri bir araçla hazırlanır. Kullanıcılar menü yapısını, form alanlarını ve liste görünümlerini bu taslak üzerinde dener. Geri bildirimler kodlama başlamadan işlenir, bu da ileride yapılacak düzeltme miktarını azaltır. Prototip onayı, ekran adedinin ve iş yükünün kesinleşmesini de sağlar.
Kodlama sprint adı verilen iki haftalık döngülerle yürütülür. Her sprintin başında o döngüde bitirilecek işler seçilir, sonunda çalışan sürüm müşteriye gösterilir. Bu yöntem çevik (agile) geliştirme olarak bilinir ve öncelik değişikliklerinin erken fark edilmesini sağlar. Her sprint çıktısı test ortamına kurulur; hata kayıtları bir iş takip aracında (Jira, Trello gibi) izlenir. Tüm modüller tamamlanınca genel test turu yapılır ve kabul testleri çalıştırılır. Yayın aşamasında kod canlı sunucuya aktarılır, alan adı ve SSL sertifikası bağlanır, varsa eski sistemdeki veriler yeni tablolara taşınır. İlk haftalarda hata ve yük takibi yoğun biçimde sürdürülür, kullanıcılara kısa bir kullanım eğitimi verilir. Sprint sayısı, projenin büyüklüğüne göre genellikle altı ile on iki arasında değişir.
Teknik Mimari, Kullanıcı Yetkileri ve Dış Sistem Bağlantıları
Sunucu tarafı, iş kurallarının çalıştığı ve verinin işlendiği katmandır. Bu katmanda PHP (Laravel), Node.js, Python (Django) veya .NET gibi teknolojiler kullanılır. Seçim; ekibin uzmanlığına, barındırma ortamına ve beklenen trafik hacmine göre yapılır. Veritabanı olarak ilişkisel yapılar için MySQL, PostgreSQL ya da MS SQL tercih edilir; yapısı sık değişen belgeler veya kayıt günlükleri için MongoDB gibi belge tabanlı çözümler eklenebilir. Arayüz tarafında React, Vue veya sunucuda üretilen şablonlar kullanılabilir. Uygulama genellikle bulut sunucuda (VPS ya da AWS, Azure, Google Cloud gibi servislerde) çalıştırılır. Geliştirme, test ve canlı ortam birbirinden ayrı tutulur; böylece yapılan değişiklik önce kontrollü bir kopyada denenir. Sürüm kontrolü için Git kullanılır.
API (uygulama programlama arayüzü), sistemin başka uygulamalarla veri alışverişi yaptığı kontrollü kapıdır. Çoğunlukla REST mimarisiyle ve JSON biçiminde çalışır; mobil uygulama, iş ortağı paneli veya raporlama aracı aynı API üzerinden beslenebilir. Erişim, token tabanlı kimlik doğrulama (JWT, OAuth 2.0) ile sınırlandırılır. Kullanıcı rolleri ve yetkiler ise RBAC (rol tabanlı erişim denetimi) modeliyle tanımlanır. Yönetici, operasyon personeli, muhasebe ve müşteri gibi roller oluşturulur; her rolün hangi ekranı göreceği, hangi kaydı düzenleyebileceği ve hangi raporu dışa aktarabileceği ayrı ayrı belirlenir. Kritik işlemler için çift onay ya da iki aşamalı doğrulama eklenebilir. Yetki matrisi gereksinim dokümanında tablo olarak tutulur.
Entegrasyonlar, dış servislerin sunduğu API’ler üzerinden kurulur. Ödeme tarafında iyzico, PayTR, Param gibi sanal POS sağlayıcıları ve 3D Secure doğrulaması kullanılır; kart bilgisi uygulama sunucusunda saklanmaz. SMS bildirimi ve tek kullanımlık doğrulama kodu için Netgsm, İleti Merkezi gibi toplu mesaj servisleri bağlanır. E-fatura ve e-arşiv kesimi, Gelir İdaresi Başkanlığı onaylı özel entegratörler aracılığıyla yapılır. Muhasebe tarafında Logo, Mikro, Paraşüt gibi programlara cari hesap ve fatura aktarımı sağlanır. Kargo için Yurtiçi, Aras, MNG gibi firmaların servisleriyle gönderi kaydı açılır ve takip numarası otomatik çekilir. Her bağlantıda hata durumları kayıt altına alınır ve başarısız istekler yeniden denenir.
Güvenlik, KVKK Uyumu ve Performans İçin Alınan Teknik Önlemler
Güvenlik çalışmalarında OWASP Top 10 listesi temel alınır. OWASP, web uygulamalarındaki en yaygın riskleri yayımlayan açık bir topluluktur. Listede SQL enjeksiyonu (veritabanına zararlı sorgu gönderilmesi), XSS (sayfaya zararlı betik eklenmesi), hatalı erişim denetimi, zayıf kimlik doğrulama ve güncel olmayan bileşen kullanımı gibi maddeler yer alır. Bunlara karşı parametreli sorgular, girdi doğrulama, çıktı kodlama ve CSRF jetonları uygulanır. Şifreleme iki noktada yapılır: iletim sırasında TLS (HTTPS) ile, depolamada ise hassas alanların AES gibi algoritmalarla şifrelenmesiyle. Parolalar geri çözülemeyen bcrypt veya Argon2 özetleriyle tutulur. Bağımlılıkların güvenlik bildirimleri düzenli taranır ve açık bulunan paketler güncellenir. Yayından önce OWASP ZAP gibi otomatik tarayıcılarla zafiyet taraması yapılır.
Loglama, sistemde kimin ne zaman hangi işlemi yaptığının kayıt altına alınmasıdır. Giriş denemeleri, kayıt silme, yetki değişikliği ve dışa aktarma işlemleri ayrı bir denetim tablosunda tutulur. Yedekleme günlük otomatik olarak alınır ve kopyalar farklı bir sunucu ya da bölgede saklanır. Felaket kurtarma planı; sunucu arızası, veri bozulması veya saldırı sonrası sistemin hangi sürede ayağa kalkacağını (RTO) ve en fazla ne kadar veri kaybının kabul edileceğini (RPO) tanımlar. KVKK (Kişisel Verilerin Korunması Kanunu) kapsamında aydınlatma metni, açık rıza kaydı, veri saklama süreleri ve silme ya da anonimleştirme işlemleri koda eklenir. Kişisel verilere erişim yalnızca yetkili rollere açılır. Log dosyaları belirlenen süre boyunca saklanır ve yetkisiz değişikliğe karşı korunur.
Performans için önce veritabanı sorguları ele alınır. Sık kullanılan alanlara indeks eklenir, gereksiz tekrar eden sorgular birleştirilir ve büyük listeler sayfalama ile parça parça getirilir. Sık okunan veriler Redis gibi bellek içi önbellekte tutulur. Dosya ve görseller CDN (içerik dağıtım ağı) üzerinden sunulur. Rapor üretimi, toplu e-posta veya fatura kesimi gibi uzun süren işler kuyruk sistemine aktarılır ve arka planda çalıştırılır. Ölçeklenme iki yolla sağlanır: dikey ölçeklenmede mevcut sunucunun işlemci ve belleği artırılır, yatay ölçeklenmede yük dengeleyici arkasına yeni sunucular eklenir. Yük testleriyle eş zamanlı kullanıcı sınırı ölçülür ve yanıt süreleri izleme panelinden takip edilir. Kabul edilebilir gecikme sınırı gereksinim dokümanında tanımlanır.
Test Türleri, Teslim Edilenler ve Bakım Kapsamı Nelerdir
Kalite kontrol üç test türüyle yürütülür. Birim testi, tek bir fonksiyonun ya da sınıfın beklenen çıktıyı verip vermediğini ölçer; PHPUnit, Jest veya PyTest gibi araçlarla otomatik çalıştırılır. Entegrasyon testi, modüllerin birbirleriyle ve dış servislerle doğru haberleştiğini doğrular; örneğin ödeme onayının sipariş durumunu güncellemesi bu testte kontrol edilir. Kabul testi ise işletme temsilcileri tarafından, gereksinim dokümanındaki kabul ölçütlerine göre yapılır. Bu testlerin otomatik olanları her kod değişikliğinde CI/CD hattında (sürekli entegrasyon ve dağıtım) çalışır; başarısız test varsa sürüm canlıya alınmaz. Gerekli görülürse bağımsız bir sızma testi de yaptırılır. Test sonuçları raporlanarak teslim dosyasına eklenir. Kritik akışlar için tarayıcı üzerinde çalışan uçtan uca testler de hazırlanabilir.
Teslimde kaynak kodun tamamı, işletme adına açılmış bir Git deposunda (GitHub, GitLab veya Bitbucket) verilir. Kurulum kılavuzu, API dokümantasyonu, veritabanı şeması ve kullanıcı el kitabı bu pakete dahildir. Sunucu, alan adı, e-posta servisi, ödeme sağlayıcısı ve SMS hesabı gibi tüm hizmetler işletmenin kendi adına açılır; ajans bu hesaplara yalnızca yetkili kullanıcı olarak eklenir. Böylece hizmet sağlayıcı değişse bile erişim ve veri sahipliği işletmede kalır. Yönetici parolaları teslim tutanağıyla iletilir ve ilk girişte değiştirilmesi istenir. Kodda kullanılan açık kaynak kütüphanelerin lisans listesi de belgelenir. Fikri mülkiyet hakları sözleşmede ayrı bir madde olarak tanımlanır. Teslimden sonraki kod değişiklikleri aynı depoda sürüm etiketleriyle izlenir.
Kullanıma alınan yazılımı güncel ve güvenli tutmak için bakım ve destek kapsamı sözleşmeyle belirlenir. Standart pakette sunucu ve çatı (framework) güncellemeleri, güvenlik yamaları, yedeklerin kontrolü ve çalışma süresi izlemesi yer alır. Hata düzeltmeleri, öncelik seviyesine göre tanımlı yanıt süreleriyle (SLA, hizmet seviyesi anlaşması) ele alınır; sistemi durduran bir arıza ile görsel bir kusur aynı sürede değerlendirilmez. Yeni modül, rapor ya da ekran talepleri bakım kapsamı dışında tutulur ve ayrı iş kalemi olarak fiyatlanır. Aylık destek saat havuzu, sık küçük değişiklik isteyen işletmeler için uygun bir seçenektir. Yılda en az bir kez bağımlılık taraması ve performans ölçümü yapılarak sonuçlar raporlanır.