19 Mayıs ve Alaçam’da Özel Yazılım Projesi Planlama

Özel yazılım ihtiyacı, her iş için yeni bir uygulama yaptırmak anlamına gelmez. Önce mevcut araçlarla çözülemeyen bir iş akışı belirlenmelidir: aynı siparişin iki kez girilmesi, stok ile teslimat bilgisinin ayrışması veya onay bekleyen tekliflerin takip edilememesi gibi. Bu rehber, 19 Mayıs ve Alaçam’da faaliyet gösteren bir işletmenin yazılım teklifini somut ihtiyaçlar üzerinden hazırlamasına yardımcı olur. Buradaki örnekler varsayımsal iş akışlarıdır; tamamlanmış müşteri projesi ya da ilçelere ilişkin pazar araştırması olarak sunulmaz.

İlk toplantıya ekran listesi değil, bir işlem örneği götürün

“Stok ekranı, müşteri ekranı ve rapor ekranı olsun” demek kapsamı açıklamaz. Bir siparişin işletmeye ulaşmasından teslimine kadar kim tarafından, hangi bilgiyle ve hangi araçta işlendiğini yazın. Normal işlemin yanında eksik ürün, iptal, fiyat değişikliği ve kısmi teslimat gibi istisnaları da ekleyin. Yazılımın başarısı çoğu zaman bu istisnaların kayıpsız yönetilmesine bağlıdır.

1. Bir müşteri talebi alınır; ilgili kişi ve talep tarihi kaydedilir.
2. Teklif hazırlanır; hangi fiyatın kim tarafından onaylandığı tutulur.
3. Onaylanan teklif siparişe çevrilir; tekrar veri girilmez.
4. Stok veya hizmet kapasitesi kontrol edilir; eksik kalem sorumlu kişiye bildirilir.
5. Teslim edilen miktar işlenir; açık kalan kalemler görünür kalır.

Bu örneği kendi sürecinize uyarlayın. Sipariş yerine servis kaydı, üretim emri veya bayi talebi kullanabilirsiniz. Her adım için sorumlu rol, zorunlu alan ve tamamlanma koşulu tanımlandığında geliştirici ile işletme aynı kapsamı konuşmaya başlar.

Hazır araç mı, özel geliştirme mi?

Standart bir muhasebe, basit müşteri takibi veya genel randevu ihtiyacı için mevcut bir ürün yeterli olabilir. Özel geliştirme; birden fazla sistemi bağlamak, işletmeye özgü onay kurallarını uygulamak veya hazır araçların izin vermediği veri akışını yönetmek gerektiğinde değerlendirilmelidir. Kararı sadece ilk teklif tutarıyla vermeyin: lisans, veri taşıma, entegrasyon bakımı ve ekip eğitimi de toplam iş yükünün parçasıdır.

İlk sürümü en çok tekrar edilen ve en fazla hata üreten tek akışla sınırlandırmak faydalıdır. Sonraki ihtiyaçları ayrı bir listeye yazın. Henüz kullanılmayacak özelliklerin geliştirilmesi, ana sorunun çözümünü geciktirebilir. Kapsam dışındaki işler ve değişikliklerin nasıl fiyatlandırılacağı teklif içinde açıkça belirtilmelidir.

Veri ve entegrasyon sorularını baştan cevaplayın

Müşteri, ürün ve sipariş kayıtları için kalıcı bir tanımlayıcı belirleyin. Aynı ürüne farklı Excel dosyalarında farklı adlar verilmesi, aktarım sırasında iki ürün oluşmasına yol açabilir. Taşınacak verinin örnek dosyasını hazırlayın; yinelenen kayıtlar, eksik alanlar ve tarih biçimleri üzerinde anlaşın. Canlı geçişten önce küçük bir örnek aktarım yapılmalı ve kayıt sayıları karşılaştırılmalıdır.

• Kaynak: Fiyat ve stok için hangi sistem esas alınacak?
• Yön: Veri tek yönde mi, iki yönde mi aktarılacak?
• Hata: Bağlantı kesilirse işlem bekleyecek mi, tekrar mı denenecek?
• Tekrar: Aynı bildirim iki kez gelirse ikinci sipariş oluşması nasıl önlenecek?
• Görünürlük: Başarısız aktarımı kim görecek ve düzeltecek?

Kullanıcı yetkilerini görev bazında tasarlayın

Bir kullanıcının sisteme giriş yapması bütün kayıtları görmesine veya değiştirmesine izin verildiği anlamına gelmez. Satış ekibi teklif hazırlayabilir, depo teslimat kaydı oluşturabilir, yönetici belirli fiyat değişikliklerini onaylayabilir. Bu yetkiler yalnızca ekrandaki düğmeleri gizleyerek değil, sunucuda her işlem için kontrol edilmelidir. OWASP’ın yetkilendirme rehberi de en az ayrıcalık ve her istekte yetki kontrolünü temel ilke olarak açıklar.

Kullanıcı kapatıldığında erişimin sona ermesi, toplu dışa aktarmaların sınırlandırılması ve önemli değişikliklerde işlem izinin tutulması kabul testlerine yazılmalıdır. Testlerde gerçek müşteri bilgileri yerine anonimleştirilmiş örnek veriler kullanın. Canlı veri yedeğinin alınması kadar, yedekten geri dönüşün denenmesi de teslimatın önemli bir parçasıdır.

“Bitti” demeden önce denenmesi gereken senaryolar

• İki kişi aynı kaydı değiştirirken birinin güncellemesi sessizce kaybolmamalı.
• Aynı sipariş tekrar gönderildiğinde ikinci kayıt oluşmamalı.
• Yetkisiz kullanıcı bağlantıyı doğrudan açarak kayda erişememeli.
• Entegrasyon kesintisi, yanlışlıkla başarılı işlem olarak gösterilmemeli.
• Telefon ekranında zorunlu işlemler tamamlanabilmeli; hata mesajı ilgili alanı açıklamalı.
• Örnek veri aktarımı ve yedekten geri dönüş sonucu yazılı olarak doğrulanmalı.

Başarıyı yalnızca ekranların açılmasıyla ölçmeyin. Bir siparişin kaç kez elle girildiğini, tamamlanma süresini ve düzeltme gerektiren kayıt sayısını proje öncesinde ölçün; pilot kullanım sonrasında aynı ölçümü tekrarlayın. Yazılımın gerçekten iş yükünü azaltıp azaltmadığı bu karşılaştırmayla görülebilir.

Teklif ve teslimat için kısa kontrol listesi

Teklifte iş akışı, ilk sürümün kapsamı, entegrasyon sorumluları, örnek veri, kabul testleri, eğitim, bakım ve teslim edilen kaynaklara erişim ayrı ayrı yer almalıdır. Sabit bir “her proje şu kadar günde biter” vaadi yerine bağımlılıklar ve işletmenin sağlayacağı bilgiler açıkça yazılmalıdır.

Deca Yazılım’ın Samsun özel yazılım hizmeti üzerinden kapsam görüşmesi yapılabilir. Atakum/Samsun merkezli ekibimizle 19 Mayıs ve Alaçam için çalışma ve toplantı biçimi keşif sırasında netleştirilir. Teknik kapsamı hazırlamak için ayrıca özel yazılım geliştirme sayfasını inceleyebilirsiniz.

Teknik kaynak: OWASP — yetkilendirme kontrolü. Bu yazı genel proje planlama rehberidir; örnekler kendi iş akışınıza göre doğrulanmalıdır.