Yazılım
- Anasayfa
- Yazılım
İş akışınıza göre şekillenen yazılım geliştirme
Pek çok işletmede günlük iş, bir hesap tablosu, birkaç mesajlaşma grubu ve masadaki defterler arasında yürür. İşler büyüdükçe bu parçaları bir arada tutmak zorlaşır. Aksaray’da yürüttüğümüz yazılım projelerine bu yüzden kod yazarak değil, bilginin nerede koptuğunu bulmaya çalışarak başlıyoruz. Doğru soruyu bulmak, çoğu zaman cevabın yarısıdır. Bir nakliye firmasını düşünelim. Seferler beyaz tahtada planlanır, sürücüler teslim belgelerinin fotoğrafını mesajla gönderir, muhasebe de aynı bilgileri faturaya yeniden yazar. Bir müşteri yükünün nerede olduğunu sorduğunda cevap için üç kişiyi aramak gerekir. Ay sonunda eksik belgeleri bulmak ise ayrı bir iş yüküne dönüşür. Böyle bir tabloda ilk işimiz, tekrar tekrar yazılan bilgileri ve en çok sorulan soruları listelemektir. Uygulamanın hangi soruya anında cevap vermesi gerektiği bu listeden çıkar. Ekran sayısı ya da özellik listesi bu cevaplardan sonra konuşulur. Böylece geliştirme, gerçek bir sorunu çözmeye odaklanır. Listeyi çıkardıktan sonra, her ihtiyacın sıfırdan geliştirme gerektirmediğini de açıkça konuşuyoruz.
Muhasebe programınızın bir modülü, yaygın bir filo takip hizmeti ya da iyi kurgulanmış bir paylaşımlı tablo sorunu çözüyorsa bunu öneriyoruz. Bu karşılaştırmayı teklif hazırlamadan önce yapıyoruz. Gereksiz bir geliştirme, hem bütçenizi hem de ekibinizin zamanını boşa harcar. İşe özel yazılım geliştirme, kurallarınız hazır ürünlere sığmadığında anlam kazanır. Verilerin birden fazla program arasında elle taşındığı durumlar da buna işaret eder. İşinizi rakiplerinizden ayıran bir yöntemi korumak istediğinizde de özel bir çözüm düşünülebilir. Bu durumda hazır bir programı zorlamak, ekibi her gün geçici çözümlerle idare etmeye iter. Çoğu zaman makul yol ikisinin arasındadır. Kullandığınız programlar yerinde kalır; aralarındaki boşluğu dolduran küçük bir uygulama ya da bir bağlantı geliştirilir. Böylece ekibiniz alıştığı araçlardan vazgeçmek zorunda kalmaz. Bu ara çözüm, ileride daha kapsamlı bir sisteme geçilecekse de sağlam bir ilk adım olur. Hangi yolun seçileceği, sahada yapılacak görüşmelerden sonra netleşir. Bir sistemi kullanacak kişilerin her biri işi farklı bir açıdan görür.
Sevkiyat sorumlusu, sürücü, muhasebeci ve yönetici ile ayrı ayrı konuşuyor, her birinin gününü nasıl geçirdiğini dinliyoruz. Toplantı odasında anlatılan süreç ile sahadaki gerçek çoğu zaman aynı değildir. Mümkünse bir iş gününü yerinde izlemek, gözden kaçan adımları ortaya çıkarır. Görüşmelere gerçek belgeleri de getirmenizi istiyoruz: irsaliyeler, sefer föyleri, teklif dosyaları ve hata yapılan örnekler. Bir alanın neden boş bırakıldığı ya da bir belgenin neden iki kez düzenlendiği, gereksinimleri kâğıttaki listeden daha iyi anlatır. Bu belgeler, uygulamanın hangi bilgileri tutacağının da ilk taslağıdır. Görüşmelerin sonunda, uygulamanın hangi işleri üstleneceğini sade bir dille anlatan bir kapsam belgesi ortaya çıkar. Belgeye neyin değişmesini beklediğinizi de yazıyoruz; örneğin faturaların hazırlanma süresi ya da “araç nerede” diye gelen telefonların sayısı. Bu ölçütlerin bugünkü değerini de birlikte kaydediyoruz. Onaylanan belge, geliştirme boyunca ortak başvuru kaynağımız olur.
Uygulama tasarımında ekranlar ve veri yapısı
Kapsam netleşince, kod yazılmadan önce ana ekranların tıklanabilir taslaklarını hazırlıyoruz. Sürücünün teslimatı kapatacağı ekran ya da muhasebenin fatura listesini göreceği sayfa, bu taslaklarda gerçek verilere benzer örneklerle canlandırılır. Böylece herkes ne elde edeceğini soyut anlatımlar yerine ekran üzerinde görür. Taslaklar, kapsam belgesindeki her maddenin hangi ekranda karşılık bulduğunu da gösterir. Taslakları asıl kullanacak kişilere kullandırarak deniyoruz. Kamyonun kabininde telefon tutan bir sürücü, ofiste geniş ekranda çalışan birinden farklı ihtiyaçlar dile getirir. Hangi bilginin ilk ekranda görüneceği ve kaç dokunuşta işin biteceği gibi kararlar bu denemelerden çıkar. Büyük düğmeler, az yazı gerektiren seçim listeleri ve sade renkler sahada çalışan kullanıcının işini hızlandırır. Bu aşamada yapılan bir değişiklik, birkaç çizgiyi yeniden çizmek kadar kolaydır. Aynı değişiklik geliştirme bittikten sonra istendiğinde ise hem zaman hem de bütçe gerektirir. Bu yüzden itirazların ve fikirlerin taslak aşamasında gelmesini özellikle teşvik ediyoruz. Taslak onaylandığında, ekranların hangi cihazlarda kullanılacağı da netleşmiş olur.
Cihaz seçimi, uygulamanın hangi platformda çalışacağını belirler. Ofiste ve sahada farklı cihazlardan erişilecek sistemler için tarayıcıdan çalışan bir uygulama çoğu zaman yeterlidir. Kurulum gerektirmez, güncellemeler herkese aynı anda ulaşır ve telefonda da ekran boyutuna uyum sağlar. Seçimi, kullanıcıların nerede ve hangi cihazla çalıştığına bakarak yapıyoruz. Sahadaki ekip kamerayı, konum bilgisini ya da barkod okumayı sık kullanıyorsa telefona kurulan bir uygulama daha rahat olabilir. Sürücünün teslim belgesini fotoğraflayıp ilgili sefere eklemesi bu tür bir işlevdir. Masaüstü programlar ise özel donanımla çalışan işlerde öne çıkar. Örneğin kantardan gelen tartı bilgisinin doğrudan kayda aktarılması, ofisteki bir bilgisayara kurulan programla daha kolay kurgulanır. Tasarım, ilk taslakla bitmez; geliştirme sırasında da olgunlaşır. Bütün sistemi kapalı kapılar ardında hazırlamak yerine işi küçük parçalara bölüyoruz. Her parçanın sonunda çalışan bir yazılım sürümünü sizinle birlikte deniyoruz. Ekranlardaki aksaklıklar böylece büyümeden fark edilir. Bu sırada gelen yeni fikirleri ortak bir istek listesine yazıyor, önceliklerini birlikte belirliyoruz.
Ekranların arkasında, bilgilerin birbirine nasıl bağlandığını gösteren bir veri yapısı bulunur. Sağlam bir uygulamanın temeli bu yapıdır. Nakliye örneğinde müşteri, araç, sürücü, sefer ve belge ayrı kayıtlardır; bir sefer bunların hepsini birbirine bağlar. Yapı baştan doğru kurulduğunda, yeni bir ihtiyaç eklemek de kolaylaşır. Girilen verinin kalitesi de bu aşamada düşünülür. Zorunlu alanlar, seçim listeleri ve basit denetimler, aynı müşterinin üç farklı yazımla kaydedilmesini ya da plakanın eksik girilmesini önler. Hatalı veriyle beslenen bir rapor, ne kadar şık görünürse görünsün yanıltır. Bu yüzden veri girişini olabildiğince az yazı gerektirecek biçimde kurguluyoruz. Yöneticinin göreceği özet ekranlar da bu yapıdan türetilir. Günlük sefer sayısı, bekleyen teslim belgeleri ya da faturalanmamış işler gibi göstergeler, ayrı bir tabloda elle toplanmadan kendiliğinden oluşur. Hangi göstergenin ekranda yer alacağına, onu kullanacak kişiyle birlikte karar veriyoruz. Kapsam belgesindeki ölçütler de bu ekranlarda izlenebilir hâle gelir.
Veri yapısında yetkiler, işlem geçmişi ve güvenlik
Veri yapısı kurulurken, kimin hangi bilgiye erişeceği de belirlenir. Her kullanıcı yalnızca işi için gereken ekranları görür. Sürücü kendi seferlerini ve belgelerini, muhasebe fatura ve tahsilat bilgilerini, yönetim ise genel tabloyu izler. Rolleri kişilere değil görevlere göre tanımlamak, ekip değiştiğinde ayarların kolayca güncellenmesini sağlar. Önemli kayıtlarda yapılan her değişiklik, kimin hangi tarihte neyi değiştirdiğiyle birlikte saklanır. Bir tutar düzeltildiğinde eski değer kaybolmaz. Bu işlem geçmişi, anlaşmazlıklarda başvurulacak kaynak olduğu kadar hataların nereden doğduğunu anlamaya da yarar. Silme işlemleri de iz bırakır; yanlışlıkla silinen bir kayıt gerektiğinde geri getirilebilir. Uygulama kişisel veri işliyorsa, yalnızca gerçekten gereken bilgileri topluyor ve bunların ne kadar süre tutulacağını baştan belirliyoruz. Yasal yükümlülüklerin ayrıntısını bir hukukçuyla netleştirmenizi öneriyoruz; teknik tarafta bu kararlara uygun bir yapı kuruyoruz. Saklama süresi dolan kayıtların nasıl ayıklanacağı da bu yapının parçasıdır.
Erişim güvenliği kişiye özel hesaplarla başlar. Ortak kullanılan tek bir parola, bir işlemi kimin yaptığını belirsiz bırakır. Her kullanıcıya ayrı hesap açıyor, yönetici hesapları için iki adımlı giriş öneriyoruz. Ayrılan bir çalışanın hesabı tek adımda kapatılır. Uygulamayla cihazlar arasındaki bağlantılar şifreli kurulur; sahadan gönderilen bilgiler bu sayede aktarım sırasında korunur. Veriler düzenli olarak yedeklenir ve yedekler asıl sistemden ayrı bir yerde tutulur. Yedeğin varlığı tek başına yeterli değildir; ondan geri dönüşün gerçekten çalıştığını belirli aralıklarla deniyoruz. Bir arıza anında hangi adımların izleneceğini ve kime haber verileceğini de kısa bir notta topluyoruz. Sunucunun nerede barındırılacağını ve yönetici erişiminin kimde olacağını proje başında birlikte kararlaştırıyoruz. Sunucu ve yedek hesaplarının işletmeniz adına açılmasını öneriyoruz. Böylece verilerinizin kontrolü her zaman sizde kalır. Yönetici parolaları da bir parola yöneticisinde, yalnızca yetkili kişilerin erişebileceği biçimde saklanır.
Geliştirme ve deneme sırasında gerçek müşteri bilgileri yerine, onlara benzeyen deneme verileri kullanıyoruz. Böylece ekranlar gerçekçi biçimde sınanırken kişisel bilgiler gereksiz yere dolaşıma girmez. Deneme ortamı ile canlı sistem birbirinden ayrı tutulur. Bir denemede yapılan hata, günlük işinizi yürüten kayıtlara dokunmaz. Kodun okunabilir yazılması, sürüm kontrolüyle saklanması ve önemli işlevlerin otomatik testlerle denetlenmesi ilk bakışta görünmeyen ama yazılım kalitesini uzun vadede belirleyen işlerdir. Örneğin fatura tutarını hesaplayan bir kural değiştiğinde, testler eski hesapların bozulmadığını her seferinde yeniden kontrol eder. Bu alışkanlıklar, sistemi yıllar sonra geliştirecek ekibin işini de kolaylaştırır. Güvenlik yalnızca uygulamanın kendisiyle sınırlı değildir. Muhasebe programı ya da banka gibi dış sistemlerle kurulan her bağlantı, verinin dışarıya açıldığı bir kapıdır. Bu kapıların her birine yalnızca gereken yetkiyi tanımlıyor, erişim anahtarlarını kodun içinde değil güvenli bir yerde saklıyoruz.
Veri aktarımı, canlıya geçiş ve düzenli bakım
Yeni sistemin, işletmede zaten kullanılan programlarla nasıl konuşacağı baştan planlanır. Muhasebe programı, e-belge hizmet sağlayıcısı, banka ekstreleri ve mesaj servisleri en sık karşılaştığımız bağlantı noktalarıdır. Hangi bağlantının gerçekten gerekli olduğunu iş akışına bakarak seçiyoruz. Gereksiz her bağlantı, bakım yükünü ve olası hata noktalarını artırır. Örneğin bankadan alınan hesap hareketleri sisteme aktarıldığında, gelen ödemeler açık faturalarla eşleştirilebilir. Muhasebecinin her sabah ekstreyi satır satır kontrol etmesi yerine, yalnızca eşleşmeyen kayıtlar incelenir. Aktarılan her kaydın kaynağı ve aktarım zamanı da saklanır; bir tutarsızlık çıktığında izini sürmek kolaylaşır. Her bağlantı, karşı taraftaki programın güncellenmesiyle etkilenebilir. Bu yüzden bağlantıları düzenli aralıklarla kontrol eden basit izleme adımları kuruyor, bir aktarım durduğunda ilgili kişinin haberdar olmasını sağlıyoruz. Aktarım yeniden başladığında arada kalan kayıtların da tamamlanması için bir kontrol adımı bulunur. Canlı kullanıma geçerken eski kayıtların hangilerinin yeni sisteme taşınacağına birlikte karar veriyoruz.
Açık siparişler, süren sözleşmeler ve güncel müşteri listesi genellikle aktarılır. Kapanmış eski işler ise çoğu zaman arşivde kalabilir. Belirli bir tarihten sonra bütün yeni kayıtların yalnızca yeni sisteme girilmesi, iki düzen arasındaki karışıklığı önler. Yeni sistemi bütün ekibe aynı gün açmak yerine önce küçük bir grupla başlamayı öneriyoruz. Bu, yalnızca bir sevkiyat ekibinin ya da tek bir şubenin yeni düzene geçmesi olabilir. Pilot dönemde çıkan sorunlar, bütün ekibi etkilemeden çözülebilir. Pilot gruptaki kullanıcıların deneyimi, diğer ekiplerin eğitimine de yön verir. Eğitimleri, her rolün yalnızca kendi kullanacağı ekranları gösteren kısa oturumlarla yapıyoruz. Ekipten bir kişiyi daha ayrıntılı eğiterek iç destek noktası hâline getirmek de yeni gelenlerin uyumunu kolaylaştırır. Geçiş tarihini işinizin takvimine göre seçiyoruz. Aksaray’da hasat ve sezon dönemlerine bağlı çalışan işletmeler için bu, yoğunluğun azaldığı bir dönemi beklemek anlamına gelebilir. Teslim edilen bir yazılım, sağlıklı çalışmayı ancak düzenli bakımla sürdürebilir.
İşletim sistemleri, tarayıcılar ve kullanılan yazılım kütüphaneleri güncellendikçe uygulamanın da bunlara uyarlanması gerekir. Güvenlik yamalarının takibi ve yedeklerin denetimi de bu işin temel parçalarıdır. Bakımın kapsamını ve sıklığını teslimden önce yazılı olarak netleştiriyoruz. Sistemin çalışıp çalışmadığını düzenli olarak izleyen kontroller kuruyoruz. Sunucu yavaşladığında ya da bir yedek alınamadığında bu durum ilgili kişiye bildirilir. Sorunları kullanıcıdan gelen şikâyetle değil, bu bildirimlerle öğrenmek müdahaleyi kolaylaştırır. Ekibinizin bir sorunu bildirebileceği tek ve açık bir kanal da belirlenir. Canlı kullanımdan bir süre sonra, kapsam belgesine yazdığımız ölçütleri yeniden ölçüyoruz. Beklenen değişiklik görülmüyorsa sebebini birlikte arıyoruz; bazen eksik olan bir özellik değil, alışkanlıkların henüz değişmemiş olmasıdır. Büyüyen bir işletmenin ihtiyaçları da zamanla değişir. Yeni bir şube ya da ürün grubu için yapılacak genişlemeleri, kullanım verilerine ve ekibinizin geri bildirimlerine bakarak planlıyoruz.
Yazılım projeleri hakkında sık sorulan sorular
Bir yazılım projesinin maliyeti nasıl belirlenir?
Maliyeti; kullanıcı rollerinin ve ekranların sayısı, kurulacak bağlantılar, hedeflenen platformlar ve verilerin taşınması gibi işler belirler. Kapsam belgesi netleştikten sonra bölüm bölüm açıklanan bir teklif sunuyoruz. Bütçeyi aşamalara bölmek de mümkündür; ilk aşamada temel işleyiş kurulur, diğer bölümler sonraya bırakılabilir.
Geliştirme sürecinde ekibimizden ne kadar katkı beklenir?
Başlangıçtaki görüşmelerde ve taslakların değerlendirilmesinde ekibinizin zaman ayırması gerekir. Geliştirme sürerken ise düzenli deneme oturumlarına katılacak ve soruları yanıtlayacak bir sorumlu kişinin belirlenmesi yeterli olur. Bu kişinin işi yakından tanıması süreci hızlandırır.
Projeyi ileride başka bir ekibe devredebilir miyiz?
Evet, bunu baştan hesaba katıyoruz. Yaygın ve iyi belgelenmiş teknolojiler kullanıyor, kurulum adımlarını ve sistemin yapısını anlatan teknik notlar tutuyoruz. Kaynak kodun kime ait olacağı ve nasıl teslim edileceği sözleşmenin konusudur; bunu işin başında birlikte netleştiriyoruz.
Uygulamayı telefondan da kullanabilir miyiz?
Evet. Tarayıcıdan çalışan uygulamalar telefon ve tablet ekranına uyum sağlar; ayrıca bir kurulum gerekmez. Sahada sık kullanılan ekranları, telefonda tek elle kullanılabilecek sadelikte tasarlıyoruz. Kamera ya da konum gibi işlevler yoğun kullanılacaksa ayrı bir mobil uygulama da değerlendirilebilir.
Hesap tablolarında tuttuğumuz eski kayıtlar ne olacak?
Kullanılmaya devam edecek kayıtlar, temizlendikten sonra yeni sisteme taşınır. Önce tablolarınızdaki yazım farklılıklarını, tekrar eden satırları ve eksik alanları birlikte ayıklıyoruz. Aktarım, canlı sisteme geçilmeden deneme ortamında sınanır; eski dosyalarınız da başvuru için korunur.
Verilerimizin güvenliği nasıl sağlanıyor?
Güvenlik, birbirini tamamlayan önlemlerle sağlanır. Sunucu tarafında bileşenler güncel tutulur ve olağan dışı erişim denemeleri izlenir. Uygulama içinde her kullanıcı yalnızca yetkili olduğu bilgiyi görür. Parolaların paylaşılmaması ve cihazların kilitli tutulması gibi alışkanlıkları da eğitim sırasında ekibinizle konuşuyoruz.
