“Size özel panel geliştirilecek” cümlesi, çalışanların hangi işi daha kolay yapacağını söylemez. Aynı teklif başlığı altında yalnızca veri gösteren bir ekran da, onay ve bildirimleri yöneten bir uygulama da bulunabilir. Fiyat ve takvimi karşılaştırmadan önce ilk sürümde tamamlanacak görevleri ve bunların nasıl kabul edileceğini yazılı hâle getirin.
İlk sürüme hangi kullanıcı görevleri girecek?
Önce rol adları yerine gerçek işleri tarif edin: satış ekibi talep açacak, yönetici onaylayacak, operasyon sorumlusu durumu değiştirecek. Her görev için başlangıç bilgisi, yapılan işlem ve beklenen sonuç bir satırda görülsün. “Raporlama modülü” gibi geniş bir madde yerine hangi sorunun hangi veriyle cevaplanacağını belirtin.
İlk sürümün amacı bütün fikirleri eklemek değil, seçilen iş akışını baştan sona kullanılabilir kılmaktır. Teklifte kapsam içindeki ekran ve işlemlerle sonraki aşamaya bırakılan istekler ayrı listelensin. Böylece yeni bir talep geldiğinde mevcut teslimin parçası mı, ek iş mi olduğu konuşulabilir.
- Her kullanıcı hangi görevi hangi cihazda tamamlayacak?
- İşlem sonunda hangi kayıt, bildirim veya onay oluşacak?
- İlk sürümde bilinçli olarak dışarıda bırakılan işler neler?
Yetkiler ekranlara göre değil, işlemlere göre yazılsın
Bir kullanıcının listeyi görmesi, tüm kayıtları düzenleyebilmesi anlamına gelmez. Teklifte rol ve işlem matrisi isteyin: kim kendi kaydını, kim ekibinin kaydını, kim bütün kayıtları okuyabilir; kim silebilir veya onaylayabilir? Başka bir kullanıcıya ait kayıt bağlantısını açma ve yetkisiz işlem gönderme gibi olumsuz senaryolar da kabul testinde bulunsun.
OWASP, yetkinin gereken en düşük düzeyde verilmesini, varsayılan olarak erişimin reddedilmesini ve her istekte kontrol edilmesini önerir. Bu nedenle yalnızca menü öğesini gizleyen bir arayüzü güvenlik teslimi saymayın; sunucu tarafındaki kontrolün nasıl sınandığını da sorun.
Veri ve entegrasyon sınırını hangi örnek kayıt gösterecek?
Uygulama mevcut bir CRM, e-ticaret sistemi veya tabloyla çalışacaksa verinin nereden geldiğini ve hangi sistemin asıl kayıt kaynağı olduğunu belirleyin. Alan eşlemesi, güncelleme yönü, tekrar kayıt kuralı ve hatalı aktarımın kim tarafından görüleceği teklifte yer alsın. “API bağlantısı yapılır” ifadesi, bu kararların hiçbirini tek başına açıklamaz.
Gerçeğe yakın fakat kişisel verileri gereksiz yere açığa çıkarmayan örnek kayıtlarla bir başarılı ve bir başarısız akış deneyin. Kişisel veri işlenecekse hangi alanın neden gerekli olduğu ve saklama kararları işletmenin ilgili sorumlularıyla netleşmeli. Hata kayıtlarında sorun giderme için yeterli bilgi bulunsun; gizli bilgi ve gereksiz kişisel veri tutulmasın. OWASP, aşırı ayrıntılı kayıtların hassas bilgiyi açığa çıkarabileceğini de hatırlatır.
Kabul testini ekran görüntüsü yerine görevle yapın
Her önemli görev için “verilen durum, kullanıcı eylemi, beklenen sonuç” biçiminde kısa bir test yazın. Boş zorunlu alan, yinelenen kayıt, yetkisiz işlem ve bağlantı kesintisi gibi durumlarda kullanıcının ne göreceği de tanımlansın. W3C WAI, formlarda açık etiket, anlaşılır yönerge ve hata bildirimi önerir; testleri yalnızca fareyle değil klavyeyle de uygulayın.
Görsel onay ile işlevsel kabul ayrı yapılabilir. Bir ekran tasarıma uygun görünürken yanlış kaydı güncelliyor olabilir. Kabul tutanağında her senaryonun sonucu, bulunan hata, sorumlu kişi ve yeniden test tarihi bulunsun. OWASP ASVS, web uygulamalarının güvenlik gereksinimlerini geliştirme ve doğrulama için bir çerçeve sunar; projeye uygun kontroller teklif aşamasında seçilebilir.
Yayın ve devir paketinde hangi haklar bulunmalı?
Alan adı, barındırma, kod deposu, üçüncü taraf hesapları ve veri tabanına ilişkin sahiplik ile erişim düzenini baştan yazın. Yedekleme ve geri yükleme sorumlusu, üretim ortamına kimlerin değişiklik çıkaracağı, hata bildiriminin nasıl yapılacağı ve yayın sonrası destek süresi de net olsun. Bunlar fiyatı etkileyebilen ayrı işlerdir; teklifte varsayım olarak kalmamalı.
Son teslimde çalışan uygulamaya ek olarak rol matrisi, veri alanları ve entegrasyon şeması, test sonuçları, açık iş listesi ve kısa kullanım devri isteyin. OWASP’ın güvenli yazılım sözleşmesi eki de geliştirici ile müşteri arasındaki güvenlik beklentilerinin açıkça konuşulması için bir çerçeve sunar; sözleşme metni yerine hazır bir hukuki cevap olarak kullanılmamalıdır.
Konuyla ilgili kısa cevaplar
Özel web uygulaması teklifinde ekran sayısı yeterli mi?
Hayır. Her ekranın hangi kullanıcı görevini tamamladığı, veri kaynağı, yetki sınırı ve kabul testi de belirtilmelidir.
İlk sürümden çıkarılan işler nasıl kaydedilmeli?
Sonraki aşama listesine gerekçesiyle yazılmalı; kapsam değişirse teslim ve takvim etkisi ayrıca değerlendirilmelidir.
Uygulamayı ne zaman teslim alınmış saymalıyız?
Kararlaştırılan görev ve olumsuz senaryolar test edilip açık sorunlar kaydedildiğinde, hesaplar ve işletim bilgisi ekibinize devredildiğinde kabul kararı verilebilir.