Uygulama Modernizasyonu Hizmeti

Uygulama modernizasyonu ne zaman gerekir?

Uygulama modernizasyonu, çalışan iş kurallarını korurken kullanımını veya bakımını zorlaştıran parçayı yenilemektir. Sipariş, raporlama, ortak erişim ya da veri paylaşımındaki bir sorunla başlayıp korunacak davranışı ve ilk değişikliği birlikte belirleriz.

Hangi parçalar yenilenebilir?

Hedefi mevcut kod, veri, lisanslar ve çalışma ortamına göre seçer; ilk akışın uygulanabilirliğini pilotla sınarız.

• Masaüstü uygulaması → ortak erişim, çevrimdışı çalışma ve cihaz bağlantısı ihtiyacına göre yenilenmiş masaüstü, web veya karma uygulama.
• Eski PHP uygulaması → bağımlılıkları incelenmiş bir sürüm geçişi veya aşamalarla ayrılmış bileşenler.
• .NET ya da Java uygulaması → işlev sınırları, testleri ve yayınlama düzeni daha açık bir yapı.
• Veritabanına veya ön yüze sıkı bağlı bir iş akışı → davranışı test edilebilen uygulama sınırları.

Mevcut yazılımı düzeltmek mi, yenilemek mi, hazır ürüne geçmek mi?

Siparişin alınması, stoktan düşülmesi veya raporun hazırlanması gibi bir işi seçelim. Aşağıdaki seçenekleri o işin maliyeti, bekleme süresi ve erişim güvenliği üzerinden karşılaştırırız.

Seçenek	Hangi durumda uygun olabilir?	Pilot sırasında neye bakarız?
Mevcut parçayı düzeltmek	Sorun tek sorgu, rapor veya bağlantıyla sınırlıysa	Aynı sonucun daha az bekleme ve müdahaleyle alınması
Sürüm ve bağımlılıkları yükseltmek	İş akışı uygun; güncelleme, destek veya kapasite engeli varsa	İş kurallarının korunması, güncelleme yolu ve aynı yükte kaynak kullanımı
Bir iş akışını yeni uygulamaya taşımak	Ortak erişim veya bağımsız geliştirme gereken bölüm ayrılabiliyorsa	Yetkiler, iki sistem arasında veri tutarlılığı ve geri dönüş
Hazır ürüne geçmek	Standart ihtiyaçları karşılayan bir ürün varsa	Veri aktarımı, toplam abonelik/lisans gideri, entegrasyon ve veriyi dışarı alma imkânı

Teklifin karşılaştırması yalnız geliştirme bedelinden oluşmaz: geçişte iki sistemi çalıştırma, eğitim, lisanslar ve sonraki bakım da toplam maliyete girer. Sonuç tarayıcıda, masaüstünde veya bir cihaz üzerinde çalışabilir; hedefi işin gereksinimi belirler.

İncelemeden canlı geçişe nasıl ilerleriz?

1. Mevcut davranışı kaydetme: kritik işlemler, iş kuralları, veri ilişkileri, bağımlılıklar ve başlangıç ölçümleri.
2. İlk parçayı seçme: iş değeri, bağımlılık ve geri alınabilirlik üzerinden sınırları belirleme; kabul testlerini yazma.
3. Uygulama ve karşılaştırma: üzerinde anlaşılan işlevi hazırlama, temsili veriyle eski ve yeni sonuçları karşılaştırma.
4. Geçiş provası: veri aktarımı, mutabakat, yetkiler, işletim kontrolleri ve geri dönüş adımlarını deneme.
5. Devir: kabul edilen sürümü, belgeleri ve açık kalan işleri sorumlularıyla teslim etme.

Kodla birlikte neler teslim edilir?

• Kapsam içindeki kod değişiklikleri ve çalıştırma talimatları.
• Korunacak iş kurallarını ve değişen davranışları açıklayan belgeler.
• Veri geçişi ve mutabakat planı; kapsamda varsa aktarım betikleri.
• Kabul testi sonuçları, ölçüm ortamı ve açık kalan bulgular.
• Yayınlama, izleme ve geri dönüş adımlarını içeren devir notu.

Değişikliğin gerekçesi maliyet, performans ve süreklilik hedefleriyle kurulabilir. Kapsam henüz belirsizse Legacy Sağlık Raporu bu kararın ön çalışmasıdır.

Ne zaman mevcut uygulamayı korumak daha uygun?

Sorun tek bir rapor, sorgu veya bağlantıyla sınırlıysa bütün uygulamayı değiştirmek yerine o parçayı düzeltmek yeterli olabilir. Bakımı yapılabilen ve iş ihtiyacını karşılayan bölümleri geçiş kapsamına sırf eski oldukları için eklemeyiz.

Modernizasyon teklifini ne belirler?

Bağımlılıklar, testlerin durumu, veri aktarımı, entegrasyonlar ve izin verilen kesinti aralığı işin kapsamını belirler. Teklifte inceleme, pilot, geçiş ve devir ayrı gösterilir; üçüncü taraf lisans ve işletim giderleri ayrıca ele alınır.

Sık sorulan sorular

Kullandığımız yazılımın adını veya sürümünü bilmiyorsam nereden başlamalıyım?

Hangi işi yaptığınızı, nerede beklediğinizi ve işi kaç kişinin kullandığını anlatmanız yeterli. İlk değerlendirmede teknik envanteri birlikte çıkarırız. Görüşme için parola, müşteri verisi veya kaynak kodu göndermeniz gerekmez.

Bütün uygulamayı yeniden yazmak gerekir mi?

Keşif bunu göstermedikçe kapsamı bütün uygulama olarak belirlemeyiz. Tek bir rapor, ekran veya işlevin ayrılması yeterli olabilir. Mevcut sistemi koruma, kısmi yenileme ve daha geniş geçiş seçenekleri gerekçeleriyle karşılaştırılır.

Geçiş sırasında işimiz durur mu?

Kesinti ihtiyacı veri yapısına ve geçiş yöntemine bağlıdır. Bakım penceresi, paralel çalışma ve geri dönüş koşulları planlanır; kesintisiz geçiş varsayılmaz. Prova sonucu takvim ve kapsam yeniden değerlendirilebilir.

Eski kayıtların doğru taşındığını nasıl kontrol ederiz?

Kayıt sayıları tek başına yeterli değildir. Kritik alanlar, toplamlar, ilişkiler ve örnek iş işlemleri için mutabakat kuralları belirlenir. Hatalı veya eksik kayıtların nasıl ele alınacağı geçiş öncesinde yazılır.

Hangi yeni teknoloji kullanılacak?

İş gereksinimleri, mevcut ekibin bakım imkânı, bağımlılıklar ve pilot sonucu birlikte değerlendirilir. Sitede bir teknolojinin yer alması, o teknoloji için teslim edilmiş bir proje veya hazır çözüm bulunduğu anlamına gelmez.

Teslimden sonra bakım kimde kalır?

Sorumlu ekip, erişimler, işletim belgeleri ve destek kapsamı sözleşmede belirlenir. Devir, yalnızca kod dosyalarının paylaşılmasıyla tamamlanmış sayılmaz; üzerinde anlaşılan çalıştırma ve bakım adımları da teslim edilir.