Özel Yazılım Geliştirme Maliyeti Nasıl Belirlenir?

Neden her projede farklı bir rakam çıkar?

Özel yazılımda satın aldığınız şey bir paket değil, sizin sürecinizin yazılıma dönüştürülmesidir. İki işletme aynı işi yapıyor olsa bile onay adımları, belge tipleri, istisnalar ve kullandıkları diğer sistemler farklıdır. Bu farklar doğrudan geliştirme kapsamına yansır.

Bu nedenle "bir mobil uygulama ne kadar?" sorusunun tek bir cevabı yoktur. Aynı soruyu "kaç ekran, hangi kullanıcı rolleri, hangi sistemle entegre, çevrimdışı çalışacak mı?" biçiminde sorduğunuzda cevap netleşmeye başlar.

Aşağıdaki başlıklar, bir teklifin arkasındaki iş kalemleridir. Teklif alırken bunların her birinin ayrı ayrı yazılmış olması, farklı firmaların tekliflerini karşılaştırılabilir kılar.

Kapsam: kaç süreç, kaç ekran, kaç istisna?

Maliyeti en çok belirleyen kalem kapsamdır. Bir satın alma talep sistemi, yalnız talep açma ve tek kademe onaydan ibaret olabilir; ya da bütçe kontrolü, çok kademeli onay, tedarikçi karşılaştırması ve ERP'ye sipariş aktarımı içerebilir. İkisi aynı isimle anılır, ancak iş yükleri birbirinden çok uzaktır.

İstisnalar da kapsamın parçasıdır ve çoğu zaman geç fark edilir. "Tutar belirli bir eşiği aşarsa genel müdür de onaylar", "acil taleplerde onay sonradan alınır", "bir kalem stoktan karşılanırsa satın almaya düşmez" gibi kurallar, ekran sayısını değil mantık karmaşıklığını artırır.

• İlk sürümde hangi süreçler yer alacak, hangileri sonraya kalacak?
• Kaç farklı belge veya kayıt tipi oluşturulacak?
• Süreçte kaç karar noktası ve kaç istisna kuralı var?
• Hangi ekranlar yalnız görüntüleme, hangileri veri girişi yapacak?

Kullanıcı ve rol yapısı

Kullanıcı sayısından çok rol sayısı önemlidir. Beş yüz kişinin aynı ekranı kullandığı bir uygulama, on kişinin altı farklı rolle çalıştığı bir uygulamadan daha basit olabilir. Her rol; kendi ekranı, kendi yetki kuralları ve kendi test senaryosu demektir.

Şirket dışından kullanıcı olacaksa (bayi, müşteri, tedarikçi) kapsam bir kademe daha büyür: dışarıya açılan bir uygulamada kimlik doğrulama, veri ayrıştırma ve güvenlik gereksinimleri şirket içi bir uygulamadan farklıdır.

Web mi, mobil mi, ikisi birden mi?

Bir süreç yalnız tarayıcıda çalışacaksa geliştirme tek platform üzerinde ilerler. Aynı süreç sahada telefonla da yürütülecekse, mobil taraf ayrı bir tasarım, ayrı bir test ve ayrı bir dağıtım süreci getirir.

Bazı projelerde mobil ihtiyacı, mobil uyumlu bir web uygulamasıyla karşılanabilir. Kamera, barkod okuma, konum veya çevrimdışı çalışma gerekiyorsa mobil uygulama devreye girer. Bu ayrım, kapsamın ve dolayısıyla bütçenin belirleyici sorularından biridir.

Entegrasyon: kaç sistem, hangi yönde?

Her entegrasyon ayrı bir iş kalemidir. Maliyeti belirleyen şey entegrasyon sayısından çok, verinin hangi yöne aktığı ve karşı sistemin ne sunduğudur. Tek yönlü bir veri okuma ile iki yönlü, hata durumunda geri alınabilen bir belge akışı aynı iş değildir.

Karşı sistemin resmî bir arayüzü varsa iş öngörülebilir ilerler. Arayüz yoksa veya sınırlıysa, veriye ulaşmanın yolu ayrıca tasarlanır ve bu ek efor doğurur. SAP Business One tarafında ürünle gelen resmî servis arayüzleri üzerinden çalışırız; bu, entegrasyonun kapsamını baştan tanımlanabilir kılar.

• Hangi sistemlerle konuşulacak: ERP, CRM, e-ticaret, banka, kargo, üretim makineleri?
• Veri tek yönlü mü akacak, iki yönlü mü?
• Aktarım anlık mı olacak, belirli aralıklarla mı?
• Karşı sistemin resmî bir API'si var mı?
• Hata durumunda kayıt nerede birikecek ve kim müdahale edecek?

Veri taşıma ve mevcut kayıtlar

Yeni uygulama boş bir ekranla açılmaz. Cari kartlar, ürünler, kullanıcılar ve çoğu zaman geçmiş işlemler taşınır. Bu kalemin süresi veri hacminden çok verinin kalitesine bağlıdır: aynı müşterinin üç farklı yazımla kayıtlı olduğu bir listede asıl iş, aktarım değil temizliktir.

Hangi geçmişin taşınacağı da bir karardır. Bazı projelerde yalnız açık kayıtlar taşınır, geçmiş arşivde bırakılır. Bu karar erken verildiğinde kapsam küçülür.

Çevrimdışı çalışma ve cihaz yetenekleri

Saha uygulamalarında en çok gözden kaçan kalem çevrimdışı çalışmadır. İnternetin olmadığı yerde veri girilebilecekse, uygulamanın veriyi cihazda tutması, bağlantı gelince göndermesi ve aynı kaydın iki kez oluşmasını engellemesi gerekir. Bu, ekran sayısını değiştirmez ama arkadaki mantığı belirgin biçimde büyütür.

Barkod veya QR okuma, kamera, imza alanı, konum ve yazıcı kullanımı da ayrı ayrı değerlendirilir. Her biri hem geliştirme hem de gerçek cihazlarla test gerektirir.

Raporlama ve yönetim ekranları

Uygulamanın ürettiği veriyi kimin, hangi kırılımda göreceği baştan konuşulmalıdır. Birkaç listeleme ekranı ile rol bazlı filtrelenen, dışa aktarılabilen ve grafikli bir yönetim paneli farklı büyüklükte işlerdir.

Pratik bir yaklaşım, ilk sürümde operasyonun çalışması için gereken listeleri vermek; yönetim panelini gerçek veri biriktikten sonra, kullanıcıların gerçekten baktığı göstergeler üzerinden kurmaktır.

Güvenlik, test ve devreye alma

Kimlik doğrulama, yetki ayrımı, girdi doğrulama ve işlem geçmişi sonradan eklenen özellikler değildir; tasarımın parçasıdır ve iş kaleminde karşılığı vardır. Dışarıya açılan uygulamalarda bu başlık daha da ağırlaşır.

Test tarafında, geliştirme sırasında yapılan kontrollerin yanına kullanıcıların kendi işlerini sistemde denediği bir kabul testi eklenir. Devreye alma ise eğitim, gerçek veriyle ilk kullanım ve ilk günlerdeki yakın destek demektir. Takvimde bu adımlara yer ayrılmadığında, sorunlar canlı kullanımda ve daha pahalıya çözülür.

Bakım ve yeni geliştirmeler

Yazılım canlıya alındığında proje bitmez. İşletim sistemi ve tarayıcı güncellemeleri, entegre olunan sistemlerin sürüm değişiklikleri, mevzuat değişiklikleri ve kullanıcıların yeni talepleri zaman içinde iş üretir.

Bu nedenle bütçeyi yalnız ilk teslim üzerinden değil, uygulamanın kullanımda kalacağı süreyi de düşünerek planlamak gerekir. Bakımın nasıl tanımlandığı (kimin, hangi sürede, hangi kapsamda müdahale edeceği) teklifte yazılı olmalıdır.

Teklif alırken kapsamı nasıl hazırlarsınız?

Aşağıdaki başlıkları yazılı hale getirdiğinizde farklı firmalardan aldığınız teklifler karşılaştırılabilir olur. Aynı liste, projenin ilerleyen aşamalarında kapsam tartışmalarını da azaltır.

• Hangi süreç, hangi adımlarla yazılıma taşınacak?
• Kaç kullanıcı, kaç rol ve hangi yetkilerle çalışacak?
• Hangi ekranlar web, hangileri mobil olacak?
• Hangi sistemlerle entegrasyon zorunlu, hangisi sonraya kalabilir?
• Hangi mevcut veri taşınacak, hangisi arşivde kalacak?
• İlk sürümde hangi raporlar zorunlu?
• Çevrimdışı çalışma, barkod, kamera veya imza gerekiyor mu?
• Canlıya geçiş sonrası destek ve bakım nasıl tanımlanacak?
• Kaynak kod, dokümantasyon ve yayın ortamı kimde olacak?

Sonuç

Özel yazılımın maliyeti; kapsam, rol yapısı, entegrasyon sayısı, veri durumu ve devreye alma disiplininin toplamıdır. Bu kalemler netleşmeden verilen rakam tahmindir; netleştikten sonra verilen rakam ise tarafların üzerinde anlaşabileceği bir plandır.

Kapsamınızı birlikte çıkarmak ve hangi ihtiyacın standart bir uyarlamayla, hangisinin özel geliştirmeyle çözüleceğini konuşmak isterseniz bize ulaşabilirsiniz.

Sık sorulan sorular