Yazılım geliştirme: web, mobil ve dijital dönüşüm
md9'un yazılım bölümü özel iş yazılımı, iOS ve Android uygulaması, API ve entegrasyon, kurumsal web sitesi, teknik SEO ve yapay zekâ aramalarında görünürlük işlerini kapsar. Bu yazılımları, yazılım uyuşmazlıklarını teknik olarak inceleyen bir ekip olarak yazıyoruz: her projede kimin neyi ne zaman değiştirdiğini gösteren denetim kaydı, saat dilimi belli zaman damgaları ve teslimden önce yazılmış kabul kriterleri varsayılan olarak yer alır.
Dijital dönüşüm çoğu işletmede büyük bir projeyle değil, bir tablonun artık taşınamaz hâle gelmesiyle başlar: siparişler Excel'de, onaylar e-postada, fiyatı en son kimin değiştirdiğini kimse hatırlamıyor. Bu işi yazılıma taşırken yalnızca ekranları değil, o ekranlarda yapılan her işlemin kaydını da tasarlıyoruz.
Hangi işleri yapıyoruz?
Her sayfada o işte neyi nasıl yaptığımızı, sizden ne istediğimizi ve teslimde ne verdiğimizi yazdık. İhtiyacınızın hangisine girdiğinden emin değilseniz proje danışmanlığı ve teknik şartname sayfasından başlayın: yazılımı kimin yapacağından bağımsız olarak, önce neyin yapılacağını yazılı hâle getiriyoruz.
Yazılım uyuşmazlıklarını incelemek yazdığımız koda ne katıyor?
Teslim ve ayıp uyuşmazlıklarında yazılımı teknik olarak incelerken en çok aradığımız kayıtlar, çoğu projede hiç tutulmamış olanlardır. Kendi projelerimizde bunları baştan kuruyoruz:
| Uyuşmazlıkta sorulan | Çoğu projede durum | Bizim varsayılanımız |
|---|---|---|
| Kaydı kim, ne zaman değiştirdi? | Yalnızca son hâl var; updated_at alanı kimin değiştirdiğini söylemiyor | Eski ve yeni değeri, kullanıcıyı, IP adresini ve kaynak portu tutan, uygulama içinden silinemeyen denetim kaydı (audit log) |
| Olay hangi saatte oldu? | Sunucu, veri tabanı ve uygulama farklı saat dilimleriyle yazıyor; dilim hiçbir yerde belirtilmiyor | Zamanlar UTC ve RFC 3339 biçiminde saklanır, ekranda Türkiye saatine çevrilir; sunucular NTP ile senkron |
| İş şartnameye uygun teslim edildi mi? | Şartnamede "hızlı", "kullanıcı dostu" gibi ölçülemeyen maddeler | Her madde için önceden yazılmış, teslimde aynen koşulan kabul senaryosu |
| Hangi sürüm teslim edildi? | "Son hâlini gönderdik" e-postası | Etiketlenmiş sürüm, paketin SHA-256 değeri ve kabul tutanağı |
| Kod ve hesaplar kimde? | Depo, sunucu ve mağaza hesabı geliştiricinin adına | Depo, bulut ve uygulama mağazası hesapları baştan iş sahibinin adına açılır |
Bir ayrıntı daha: Git'teki commit tarihleri ve yazar adları geliştiricinin bilgisayarında serbestçe yazılabilir, bu yüzden tek başına kanıt değildir. Teslimleri, depo platformunun ve derleme sisteminin (CI) sunucu tarafında tuttuğu zamanlarla da belgeliyoruz.
Gerçek bir örnek: UDF Mobil (md9)
UDF Mobil (md9), UYAP'ın kullandığı .udf belgelerini iPhone'da açan, düzenleyen, PDF ve Word'e çeviren, React Native ve TypeScript ile yazdığımız uygulamadır. Belgeler yalnızca cihazda işlenir; dönüştürme, metin tanıma (OCR) ve KVKK maskeleme internet bağlantısı olmadan çalışır. Cihazdan çıkan veriler (kullanım istatistikleri, çökme raporları, reklam verileri gibi) gizlilik politikasında tek tek tabloyla yazılıdır ve bir kısmı uygulama ayarlarından kapatılabilir.
Sınırlarını da aynı açıklıkla yazıyoruz: imza özelliği belgeye görsel bir imza ekler, e-imza değildir; imzalı bir UDF'nin imzasını korumaz ve doğrulamaz; uygulama yalnızca iPhone'da çalışır. Ürünün ayrıntıları ürünler bölümünde, mobil tarafta nasıl çalıştığımız mobil uygulama geliştirme sayfasında.
Çalışma modeli: analiz, şartname, geliştirme, teslim
- Analiz. Bugünkü süreci, kullanıcı rollerini, mevcut veriyi ve bağlanılacak sistemleri çıkarırız. Hazır bir ürün işinizi görüyorsa bunu burada söyleriz.
- Şartname ve kabul kriterleri. Her gereksinim numaralanır ve test edilebilir yazılır: "hızlı olmalı" yerine ölçü, eşik ve test koşulu. Kabul senaryoları bu aşamada, kod yazılmadan önce hazırlanır.
- Geliştirme. Kısa aralıklarla test ortamında çalışan sürüm gösterilir. Değişiklik talepleri numaralı ve yazılı kaydedilir; süreye ve bedele etkisi onaylanmadan işe alınmaz.
- Teslim. Kabul senaryoları teslim edilen sürümde koşulur, sonuç tutanağa geçer. Kaynak kod geçmişiyle, kurulum ve işletim belgesiyle, bağımlılık ve lisans listesiyle birlikte devredilir; bakım ayrıca kararlaştırılır.
Sık sorulan sorular
Yazılım geliştirme süreci nasıl işler?
Dört aşamada: analiz, şartname ve kabul kriterleri, geliştirme, teslim. Analiz bugünkü süreci, rolleri ve veriyi çıkarır; şartname her gereksinimi ölçülebilir yazar; geliştirme kısa aralıklarla test ortamında gösterilen sürümlerle ilerler; teslim, önceden yazılmış kabul senaryolarının teslim edilen sürümde koşulmasıyla tamamlanır. Fiyatı ve takvimi analizden sonra yazılı veririz, çünkü kapsamı yazılmamış bir işin süresi de tahminden ibarettir.
Yazılım şirketi seçerken nelere dikkat edilmeli?
Teklifin şartname maddelerini tek tek karşılayıp karşılamadığına, varsayımların ve kapsam dışı işlerin yazılı olup olmadığına, test ve veri taşımaya süre ayrılıp ayrılmadığına, kaynak kodun ve hesapların kimin adına olacağına bakın. En düşük teklif çoğu zaman en çok varsayım içeren tekliftir. Karşılaştırma matrisini ve tedarikçilere sorulacak soruları proje danışmanlığı sayfasında anlattık.
Adli bilişim yapan bir ekip neden yazılım geliştiriyor?
İki iş birbirini besliyor. Yazılım uyuşmazlıklarını incelerken hangi kaydın yokluğunun tartışmayı çözümsüz bıraktığını görüyoruz; kendi yazılımımızda o kayıtları baştan tutuyoruz. Yazılım geliştirirken de bir sistemin kaydı nerede, hangi saatle ve kimin yetkisiyle ürettiğini içeriden bildiğimiz için incelemede neye bakacağımızı biliyoruz. Kimin neyi ne zaman yaptığını gösteremeyen bir yazılım, anlaşmazlık çıktığında iki tarafı da elinde kanıtsız bırakır.
Geliştirdiğiniz bir yazılımla ilgili uyuşmazlıkta uzman görüşü verir misiniz?
Hayır. Kendi yazdığımız ya da şartnamesini hazırladığımız bir yazılım hakkında hazırlayacağımız görüş bağımsız sayılmaz. Böyle bir durumda elimizdeki teknik kayıtları, yani depo geçmişini, kabul tutanaklarını ve değişiklik talebi kaydını düzenli biçimde teslim ederiz. Teknik değerlendirmeyi o projeyle bağı olmayan bir uzmanın ya da mahkemenin görevlendireceği bilirkişinin yapması gerekir.
Hangi teknolojilerle çalışıyorsunuz?
Teknolojiyi projenin gereksinimine ve bakımını sonra kimin yapacağına göre seçer, gerekçesini şartnameye yazarız. UDF Mobil'i React Native ve TypeScript ile yazdık; bu site ise Python ile yazılmış bir derleme betiğinin ürettiği statik HTML sayfalardan oluşuyor. Yalnızca bizim bildiğimiz bir altyapıya bağlı kalmanızı istemeyiz: kod, belgeleriyle birlikte başka bir ekibin devralabileceği biçimde teslim edilir.