Yazılım

Yazılım geliştirme sürecini iş akışınız üzerine kurmak

Özel yazılım, işinizi hazır bir programın kalıbına sokmak yerine programı sizin çalışma biçiminize göre kurmaktır. Ağrı’da stok, sipariş ya da randevu takibini defterle yürüten işletmeler için ilk adım, bugünkü düzeni ayrıntısıyla anlamaktır. Bu düzeni anlamadan hazırlanan her ekran, ekibinize yeni bir alışkanlık dayatma riski taşır. Bu yüzden ilk görüşmelerde ekranlardan söz etmeden önce işin nasıl yürüdüğünü dinliyoruz. Bir siparişin nereden geldiğini, kimin onayladığını, hangi aşamada beklediğini ve nasıl kapandığını adım adım çıkarıyoruz. Sorunların çoğu bu adımlar arasındaki boşluklarda saklıdır. Aynı bilginin birkaç kez yazıldığı ya da bir onay için saatlerce beklendiği noktalar bu dinlemede ortaya çıkar. Mümkünse işin yapıldığı yere gidip süreci yerinde izliyoruz. Depoda, tezgâhta ya da sahada çalışan kişinin gündelik alışkanlıkları, masa başında anlatılanlardan farklı olabilir. Gözlemlerimizi herkesin anlayacağı sade bir akış şemasına dönüştürüp sizinle doğruluyoruz. Bu şema, projenin sonraki bütün adımlarında ortak bir başvuru belgesi olarak kullanılır.

İş akışı netleştikten sonra, ihtiyacın hangi yolla karşılanacağına birlikte karar veriyoruz. Her ihtiyaç sıfırdan yazılım geliştirme gerektirmez. Piyasada işinizi büyük ölçüde karşılayan bir program varsa bunu açıkça söylüyoruz. Bazen hazır bir aracı birkaç ek modülle desteklemek, baştan bir sistem kurmaktan daha mantıklı bir yoldur. Özel geliştirme bazı durumlarda öne çıkar. İşiniz sektörün alışılmış kalıplarına uymuyorsa ya da birkaç programı elle birbirine bağlamak zorunda kalıyorsanız bu seçenek anlam kazanır. Hazır paketlerin kullanıcı sınırları büyümenizi zorluyorsa da durum aynıdır. Aynı bilgiyi her gün iki ayrı programa elle giren bir ekip, bu ihtiyacı genellikle ilk fark edendir. Karşılaştırmayı yalnızca bugünkü maliyete göre yapmıyoruz. Lisans yenilemeleri, uyarlama ihtiyacı, verinin kime ait olacağı ve ileride yapılacak eklemeler birlikte değerlendirildiğinde daha sağlıklı bir karar çıkar. Bu değerlendirmeyi sizinle birlikte yazılı hâle getiriyoruz. Böylece verilen kararın hangi gerekçelere dayandığı, uzun zaman sonra da okunabilir.

Özel bir çözümde karar kılındığında kapsamı ve öncelikleri belirlemeye geçiyoruz. İstek listesi çoğu zaman ilk görüşmeden sonra hızla uzar. Her maddeyi işinize kattığı değer ve gerektirdiği emek açısından tartıyoruz. Ardından listeyi “mutlaka olmalı”, “olsa iyi olur” ve “sonraya kalabilir” diye üç gruba ayırıyoruz. Kapsamı yazılı bir belgeye döküyoruz. Bu belgede ekranlar, kullanıcıların yapacağı işlemler ve alınacak raporlar sade bir dille yer alır. Sonradan ortaya çıkan yeni istekler de bu belgeye eklenerek konuşulur. Belge, teknik bilgisi olmayan bir yöneticinin de okuyup onaylayabileceği açıklıkta hazırlanır. Takvimi de bu aşamada netleştiriyoruz. Onay verecek kişiyi ve işinizin yoğunlaştığı dönemleri baştan konuşuyoruz. Yoğun sezonun ortasına denk gelen bir geçiş, özenli bir planı bile zorlayabilir. Ekibin eğitime ayırabileceği zamanı da takvime işliyoruz. Kapsam ve zamanlama birlikte netleştiğinde geliştirme sağlam bir zemine oturur.

İlk sürümü kullanıcılarla birlikte geliştirmek

Kapsam belgesindeki her madde aynı anda geliştirilmez; yazılım projesi ilk sürümle başlar. İlk sürüm, işin en sık tekrarlanan ve en çok zaman alan adımlarına odaklanmalıdır. Örneğin Ağrı’nın köylerinden süt toplayan bir işletmeyi düşünelim. Üreticiden alınan miktarın kaydı, ödeme hesabı ve günlük özet, ilk sürüm için yeterli bir başlangıç olabilir. Az sayıda işlevle yayına çıkmak, sistemin gerçek kullanımda nasıl davrandığını erkenden görmenizi sağlar. Çalışanların hangi ekranı sık açtığı, nerede zorlandığı ve neyi hiç kullanmadığı ancak bu aşamada netleşir. Bu bilgiler masa başında tahmin edilemez. Sahadan gelen her gözlem, bir sonraki adımın daha isabetli planlanmasına katkı verir. Sonraki eklemeleri bu gözlemlere dayanarak sıralıyoruz. Böylece emek, varsayılan ihtiyaçlara değil gerçekten kullanılan işlevlere harcanır. İlk sürümün sade kalması, ekibinizin yeni düzene alışmasını da kolaylaştırır. Az sayıda ekranla başlayan çalışanlarda sisteme karşı oluşabilecek çekinceler de azalır. Yeni işlevler ise ekip bir öncekine alıştıkça adım adım devreye alınır.

Kullanıcılarla birlikte çalışmak, kod yazılmadan önce başlar. İlk iş olarak ekranların tıklanabilir taslaklarını hazırlıyoruz. Bunlar, programı her gün kullanacak kişilerin düğmeleri, alanları ve geçişleri önceden denemesine imkân verir. Bu aşamada yapılan bir değişiklik, kodlanmış bir ekranı değiştirmekten çok daha zahmetsizdir. Her deneme, ekranların gerçek iş sırasına uyup uymadığını da gösterir. Taslakları yalnızca yöneticilerle değil, programı kullanacak çalışanlarla da sınıyoruz. Depodaki görevli, muhasebedeki çalışan ya da sahadaki personel kendi işini en yakından tanıyan kişidir. Onların “bu alan burada olmasın” gibi yorumları, sonradan yaşanacak pek çok sorunu baştan önler. Deneme sırasında takıldıkları yerleri not ediyor, taslağı buna göre düzeltiyoruz. Taslak aşamasında yazı büyüklüğü, renklerin anlamı ve hata mesajlarının dili de netleşir. Bilgisayar kullanımına alışkın olmayan çalışanlar için az sayıda ve açık etiketli alan içeren ekranlar tercih ediyoruz. Sık yapılan işlemler için kısayollar gibi küçük kolaylıklar da bu aşamada konuşulur.

Telefon ya da tablet üzerinden kullanılacak ekranları ayrıca deniyoruz. Taslaklar onaylandıktan sonra geliştirmeye geçiyoruz. Geliştirmeyi kısa dönemlere bölüyor, her dönemin sonunda çalışan bir bölümü size gösteriyoruz. Siz de ekranları kendi işinize benzer örneklerle deneyip geri bildirim veriyorsunuz. Böylece ilerleme rapor satırlarında değil, gerçek ekranlarda görünür. Erken fark edilen bir yanlış anlama, küçük bir düzeltmeyle giderilir. Kodu düzenli, açıklamalı ve sürüm takip sistemiyle geliştiriyoruz. Bu düzen, ileride başka bir geliştiricinin de projeyi anlayıp sürdürebilmesini sağlar. Her değişikliğin ne zaman ve neden yapıldığı kayıtlı kalır. Kodun önemli bölümlerini ekip içinde ikinci bir gözle gözden geçirmek, hataların erken yakalanmasına yardım eder. Yazılım testlerini geliştirmenin sonuna bırakmıyoruz. Her yeni bölüm, önceki bölümleri bozmadığından emin olmak için otomatik ve elle yapılan kontrollerden geçer. Hesaplama içeren ekranlarda sonuçları gerçek örneklerle tek tek karşılaştırıyoruz. Test ortamı, gerçek verilerinizi etkilemeden denemeler yapabilmeniz için canlı sistemden ayrı tutulur.

Geliştirilen sistemde veri akışı ve güvenlik

Geliştirme ilerledikçe verinin sisteme nereden girip nereye aktarıldığı önem kazanır. Yeni sistem, işletmenizde zaten kullanılan araçlarla konuşabilmelidir. Muhasebe programı, e-fatura altyapısı, kargo firması ya da kısa mesaj servisiyle veri alışverişi, aynı bilginin iki kez girilmesini önler. Hangi bağlantının gerçekten gerekli olduğunu iş akışınıza bakarak belirliyoruz. Bağlantıları kurarken karşı tarafın sunduğu resmî arayüzleri kullanıyoruz. Bir servis geçici olarak yanıt vermediğinde ne olacağını baştan tanımlıyoruz; işlem sıraya alınır ve sorun giderildiğinde tamamlanır. Aktarımların kaydını tutarak hangi verinin ne zaman gönderildiğini izlenebilir kılıyoruz. Bir aktarım başarısız olduğunda ilgili kişiye bildirim gitmesini de sağlıyoruz. Bazı durumlarda Excel tabloları hâlâ pratik bir çözümdür. Sistemden tablo olarak rapor almak ya da hazır tabloları içeri aktarmak, ekibinizin alışkanlıklarını bir anda değiştirmeden geçiş yapmasına yardımcı olur. Geçişi bu yüzden kademeli planlıyoruz. İçeri aktarılan dosyaları, hatalı ya da eksik satırlar sisteme girmeden önce ayrıca denetliyoruz.

Veri akışı kadar, bu veriye kimin ulaşabileceği de baştan düşünülmelidir. Her kullanıcı yalnızca kendi işi için gereken bilgiyi görmelidir. Kasiyerin maaş bilgilerini, depo görevlisinin müşteri telefonlarını görmesine gerek yoktur. Rolleri ve yetkileri baştan tanımlamak hem hataları hem de istenmeyen bilgi paylaşımını azaltır. Parolaların güvenli biçimde saklanması, bağlantıların şifrelenmesi ve önemli işlemlerde ikinci bir doğrulama istenmesi temel önlemlerdir. Kimin hangi kaydı ne zaman değiştirdiğini gösteren işlem geçmişi de sistemin içinde tutulur. Bir anlaşmazlıkta bu geçmiş, neyin olduğunu açıkça gösterir. İşten ayrılan bir çalışanın erişimini tek adımda kapatabilmek de bu önlemlerin parçasıdır. Sistemin çalıştığı sunucu ve kullanılan bileşenler de düzenli güncellenmelidir. Güvenlik açığı bildirilen bir kütüphane zamanında yenilenmezse özenle yazılmış kod bile risk altında kalır. Bu güncellemeleri yazılım bakımının kalıcı bir parçası olarak planlıyoruz. Her değişikliği önce test ortamında deneyip ardından canlı sisteme aktarıyoruz.

Güvenliğin bir diğer boyutu yasal yükümlülüklerdir. Müşteri, hasta ya da çalışan bilgisi tutan her sistem, Kişisel Verilerin Korunması Kanunu’na uygun kurulmalıdır. Hangi bilginin neden toplandığını, ne kadar süre saklanacağını ve kimlerin erişebileceğini planlama aşamasında belirliyoruz. Bu kararları sistemin ayarlarına ve ekranlarına yansıtıyoruz. Gerekmeyen bilgiyi hiç toplamamak, korunması gereken veri miktarını da azaltır. Örneğin bir randevu sistemi için kimlik numarası gerçekten gerekli değilse bu alanı formdan çıkarıyoruz. Hassas alanları ise veritabanında şifreli saklıyoruz. Saklama süresi dolan kayıtların nasıl ayıklanacağını da sistemin içinde tanımlıyoruz. Veri sahiplerine sunulacak aydınlatma metni, açık rıza gereken durumlar ve verilerin silinmesi gibi konularda hukuk danışmanınızla birlikte ilerlemenizi öneriyoruz. Biz de sistemin bu kararları teknik olarak uygulayabilmesini sağlıyoruz. Silme talebi geldiğinde kişiye ait kayıtların kolayca bulunabilmesi bunun bir örneğidir. Mevzuattaki değişiklikler de bakım sırasında göz önünde tutulur.

Güvenliği yedekleme ve düzenli bakımla sürdürmek

Güvenlik önlemleri, düzenli yedekleme olmadan eksik kalır. Yedek yalnızca veritabanını değil; yüklenen belgeleri, fotoğrafları ve sistem ayarlarını da kapsamalıdır. Hangi verinin hangi aralıkla kopyalanacağını işin temposuna göre belirliyor, bunu bakım belgesine yazıyoruz. Yedeklerin başarıyla alınıp alınmadığı da düzenli olarak kontrol edilir. Bir kesinti yaşandığında kimin neyi yapacağını gösteren kısa bir acil durum planı hazırlıyoruz. Plan; sorunun kime bildirileceğini, sistemin hangi sırayla yeniden çalıştırılacağını ve bu sürede işin nasıl yürüyeceğini anlatır. Yedekten geri dönüş adımlarını da bu planla birlikte en az bir kez deniyoruz. Elektrik ya da internet kesintisi gibi durumlar iş akışını tamamen durdurmamalıdır. Bunun için çevrimdışı kayıt imkânı veya basılı yedek formlar gibi geçici çözümler planlıyoruz. Bağlantı geri geldiğinde bu kayıtlar sisteme aktarılır. Kış aylarında sık yaşanabilecek bu tür aksaklıkları planlama sırasında ayrıca konuşuyoruz. Sistemin güvenle işlemesi, onu kullanacak ekibin hazırlığına da bağlıdır.

Yayına almadan önce gerçek verilerle son bir deneme yapıyoruz. Eski kayıtlarınızı temizleyip yeni yapıya aktarıyor, aktarım sonrasında sayıların eski kayıtlarla tuttuğunu birlikte kontrol ediyoruz. Geçiş gününü mümkün olduğunca işinizin sakin bir dönemine denk getiriyoruz. Eğitimi herkese aynı anda uzun bir sunumla değil, her rolün kendi ekranları üzerinden veriyoruz. Adım adım kullanım notları, ekibe sonradan katılanların da sistemi kendi başına öğrenmesine yardım eder. Parola seçimi ve oturumu kapatmak gibi güvenlik alışkanlıkları da eğitimin bir parçasıdır. Sık sorulan sorular zamanla bu notlara eklenir. Yayından sonraki ilk dönemde kullanıcılardan gelen soruları ve hata bildirimlerini yakından izliyoruz. Bakım kapsamını ve bize nasıl ulaşacağınızı sözleşmede açıkça tanımlıyoruz; böylece destek talepleri belirsiz kalmaz. Bildirimleri tek bir kanaldan toplamak, hiçbir talebin gözden kaçmamasına yardım eder. Bu dönemde biriken talepler, bir sonraki bakım planına da yön verir.

Düzenli bakım, sistemin işletmenizle birlikte büyümesine de zemin hazırlar. İşletmeniz büyüdükçe yeni şubeler, yeni ürün grupları ya da farklı raporlama ihtiyaçları ortaya çıkar. Sistemi baştan modüler kurduğumuz için yeni bir bölüm eklemek mevcut yapıyı bozmadan yapılabilir. Kullanıcı sayısı arttığında altyapının nasıl genişleyeceğini de önceden düşünüyoruz. Yeni istekleri bir liste hâlinde topluyor, dönemsel görüşmelerde önceliklerini sizinle birlikte belirliyoruz. Acil bir düzeltme ile beklemesi mümkün bir iyileştirmeyi ayırmak, bütçenizi ve ekibinizin zamanını doğru yere harcamanızı sağlar. Her yeni ekleme, mevcut yedekleme ve yetki düzenine uyumu açısından ayrıca değerlendirilir. Uzun ömürlü bir yazılım yalnızca kodla değil, düzenli bakım ve açık iletişimle ayakta kalır. Teknoloji değiştikçe hangi bileşenin yenileneceğini önceden planlamak, sistemin yıllar içinde eskimeden çalışmasını destekler. Bu planı dönemsel görüşmelerde sizinle birlikte güncelliyor, alınan kararları kayıt altına alıyoruz.

Yazılım Projelerinde Sıkça Sorulan Sorular

Evet, kapsam doğru belirlendiğinde küçük işletmeler için de uygun olabilir. Tek bir sorunu çözen sade bir uygulama, örneğin randevu ya da stok takibi, büyük bir sistemle başlamaktan daha mantıklıdır. Önemli olan, çözülecek işin gerçekten her gün tekrarlanan bir ihtiyaç olmasıdır.

Maliyet; ekran ve işlev sayısına, bağlanacak dış sistemlere, kullanıcı rollerinin çeşitliliğine ve mobil kullanım ihtiyacına göre değişir. Bu yüzden kapsam netleşmeden sağlıklı bir teklif vermek mümkün değildir. Kapsam belgesi hazırlandıktan sonra kalemleri tek tek açıklayan bir teklif sunuyoruz.

Sistemde tuttuğunuz veriler size aittir ve dışa aktarılabilir biçimde tasarlanır. Kaynak kodun kullanım ve mülkiyet haklarının kimde olacağı ise sözleşmede açıkça yazılır. Bu konuyu işe başlamadan önce netleştirmenizi öneririz.

En yoğun katkı başlangıçtaki görüşmelerde ve taslakların sınandığı aşamada gerekir. Geliştirme sırasında düzenli aralıklarla ekranları deneyip geri bildirim vermeniz yeterlidir. Sizin tarafınızda karar verebilecek bir kişinin belirlenmesi, sürecin aksamadan ilerlemesine yardım eder.

Teknoloji seçimini projenin ihtiyacına göre yapıyoruz. Yaygın kullanılan, iyi belgelenmiş ve uzun süredir desteklenen araçları tercih etmek, ileride destek bulmayı kolaylaştırır. Seçilen yazılım altyapısını ve gerekçelerini teklifte açıkça belirtiyoruz.

Evet. Yeni istekler önce mevcut yapıya etkisi açısından değerlendirilir, ardından ayrı bir iş olarak planlanır. Takvim, eklemenin büyüklüğüne göre ayrıca belirlenir. Çalışan bölümlerin etkilenmemesi için değişiklikleri önce ayrı bir test ortamında deniyoruz.