Mobil Uygulama Yayın ve Devir Teslim Hizmeti Sorumluluğu Nasıl Belirlenir?

Mobil Uygulama Yayın Teslimi Nasıl Ölçülebilir Olur?

Mobil uygulama yayın ve devir teslim hizmeti, tek bir “uygulamayı yayınlama” görevi yerine birbirinden ayrılmış teslimler ve kabul koşullarıyla tanımlanmalıdır. Ölçülebilir teslim, tamamlandığı iki taraf tarafından nesnel biçimde doğrulanabilen sürüm, dosya, erişim, test sonucu veya dokümandır. Bu yaklaşım, geliştirme ekibinin yaptığı iş ile müşteri onayına, mağaza incelemesine veya üçüncü taraf sürecine bağlı işleri birbirinden ayırır.

Teslim kapsamını hangi aşamalar oluşturmalı?

Teklifte geliştirme, test, mağaza başvurusu, canlıya geçiş ve teknik devir tek bir satırda birleştirilmemelidir. Her aşamanın sorumlu tarafı, gerekli müşteri girdisi, kabul yöntemi ve dış bağımlılıkları ayrı yazılmalıdır. Örneğin uygulamanın teknik olarak mağazaya gönderilmeye hazır olması ile mağaza tarafından onaylanmış ve son kullanıcıya açılmış olması aynı teslim noktası değildir. Sözleşme bu farkı görünür kıldığında takvim ve sorumluluk tartışmaları önemli ölçüde azalır.

• Test için paylaşılacak aday sürüm ve sürüm numarası
• Kabul senaryoları ve hata sınıflandırma yöntemi
• Mağaza başvurusu için gerekli içerik ve görsel varlıklar
• Canlı yayın öncesindeki müşteri onay noktası
• Kaynak kodu, tasarım dosyaları ve teknik dokümantasyon paketi
• Garanti ve yayın sonrası destek başlangıç koşulu

Program testleri hataların varlığını gösterebilir, ama yokluklarını asla gösteremez.- Edsger W. Dijkstra

Yayın Hesapları ve Uygulama Sahipliği Kimde Olmalı?

Uygulama mağazası hesapları, mümkün olduğunca uygulamayı uzun vadede işletmesi beklenen şirketin kontrolünde olmalıdır; geliştirme firması ise gerekli yetkilerle operasyonu yürütebilir. Hesap sahipliği ile günlük yönetim yetkisinin ayrılması, sağlayıcı değiştiğinde uygulamanın güncelleme, yayınlama veya ticari yönetim kabiliyetinin kaybolmasını önler. Hesapların çalışanların kişisel e-posta adresleri yerine kurumsal kimliklerle açılması da erişim sürekliliğini güçlendirir.

Hesap ve erişim planında hangi bilgiler bulunmalı?

Apple, Google ve kullanılan diğer platformlarda ana hesap sahibi, yönetici rolleri, çok faktörlü doğrulama yöntemi, hesap kurtarma süreci ve kurumsal iletişim adresleri belirlenmelidir. Android projelerinde özellikle imzalama varlıklarının sahipliği kritik bir konudur. Bu nedenle yayın hesabı ve imzalama anahtarının kimde olması gerektiğini teklif aşamasında netleştirmek, ileride sağlayıcı bağımlılığı oluşmasını engelleyen temel kontrollerden biridir.

• Geliştirici hesabının yasal ve kurumsal sahibi
• Yönetici, geliştirici ve yayınlama rollerinin dağılımı
• İki aşamalı doğrulama ve hesap kurtarma sorumluluğu
• İmzalama anahtarları, sertifikalar ve ilgili kimlik bilgileri
• Abonelik ve uygulama içi satın alma yapılarına erişim
• Sağlayıcı değişiminde erişimlerin kapatılma ve aktarılma süreci

Uygulama Kabul Testleri Hangi Ölçütlerle Tamamlanır?

Uygulamanın kabul edildiği yalnızca ekranların açılmasıyla değil, önceden belirlenmiş kabul senaryolarının beklenen sonuçları üretmesiyle doğrulanmalıdır. Kabul testi, kritik kullanıcı akışlarının, entegrasyonların, izinlerin, hata durumlarının ve temel iş kurallarının sözleşmede belirtilen beklentileri karşılayıp karşılamadığını gösteren teslim aşamasıdır. Bu nedenle kabul kriterlerinin geliştirme bittikten sonra oluşturulması yerine analiz ve teklif sürecinde tanımlanması gerekir.

Kabul senaryoları nasıl yapılandırılmalı?

Her senaryo kullanıcı rolü, başlangıç koşulu, yapılacak işlem, beklenen sonuç ve kabulü engelleyecek hata seviyesiyle yazılabilir. Ödeme, giriş veya sipariş gibi kritik işlevlerle düşük öncelikli görsel farklılıklar aynı ağırlıkta değerlendirilmemelidir. Aday firmaları karşılaştırırken kod kalitesi, test süreci ve mağaza yayın deneyimini birlikte değerlendirmek, firmanın yalnızca uygulama geliştirme değil kontrollü teslim konusunda da yeterli olup olmadığını anlamayı kolaylaştırır.

• Kayıt, giriş ve yetkilendirme akışlarının doğrulanması
• Ödeme, sipariş veya temel iş süreçlerinin test edilmesi
• API ve üçüncü taraf entegrasyonlarının kontrol edilmesi
• Desteklenen cihaz ve işletim sistemi kapsamının tanımlanması
• Kritik, yüksek, orta ve düşük hata seviyelerinin ayrılması
• Kabulü engelleyen hata eşiğinin önceden belirlenmesi

Kaynak Kod ve Tasarım Dosyaları Nasıl Teslim Edilmeli?

Mobil uygulama kaynak kodu teslimi, yalnızca sıkıştırılmış bir proje klasörünün müşteriye gönderilmesi olarak görülmemelidir. Teknik devir paketi; kaynak kodu deposunu, sürüm geçmişini, düzenlenebilir tasarım dosyalarını, ortam yapılandırmalarını, API belgelerini, kurulum talimatlarını ve kullanılan harici servislerin envanterini kapsamalıdır. Temel ölçüt, yeni bir teknik ekibin projeyi teslim aldıktan sonra makul bir hazırlıkla geliştirme ve yayın faaliyetlerine devam edebilmesidir.

Devir paketinde hangi teknik varlıklar bulunmalı?

Kod deposunun müşterinin kurumsal hesabına aktarılması veya proje başından itibaren müşteri hesabında tutulması değerlendirilebilir. Tasarım tarafında yalnızca PDF veya ekran görüntüsü değil, düzenlenebilir ana kaynaklar ve bileşen kütüphanesi teslim edilmelidir. iOS projelerinde kaynak kodunun yanında yayın yetkileri de kritik olduğu için kaynak kod devri ve yayın yetkilerinin nasıl güvenceye alınacağını sözleşme öncesinde değerlendirmek bütüncül bir devir planı oluşturulmasını sağlar.

• Git deposu ve gerekli sürüm geçmişi
• Düzenlenebilir tasarım dosyaları ve bileşen sistemi
• API uçları, veri sözleşmeleri ve entegrasyon belgeleri
• Derleme ve dağıtım için gerekli kurulum yönergeleri
• Üçüncü taraf servis ve lisans envanteri
• Gizli anahtarların güvenli aktarım ve yenileme planı

Mağaza İnceleme Taleplerini Hangi Taraf Karşılamalı?

Mağaza incelemesinden gelen değişiklik taleplerinin sorumluluğu, talebin nedenine göre ayrılmalıdır. Teknik hata veya geliştirme kapsamındaki uyumsuzluk sağlayıcının sorumluluğunda olabilirken; şirket doğrulaması, yasal metin, iş modeli, içerik veya müşteri kararına bağlı konular müşterinin girdisini gerektirebilir. Mağaza inceleme geri dönüşü otomatik olarak geliştiricinin hatası veya müşterinin gecikmesi olarak değerlendirilmemeli, talep önce kategorize edilmelidir.

Mobil uygulama yayın desteğinin sınırı nerede çizilmeli?

Teklif, ilk mağaza gönderimini kimin yapacağını, inceleme geri dönüşlerine kimin cevap vereceğini ve hangi tür değişikliklerin mevcut kapsamda değerlendirileceğini açıklamalıdır. Yeni özellik gerektiren bir mağaza talebi ile mevcut işlevin teknik uyumluluk düzeltmesi aynı kapsama alınmamalıdır. App Store yayını, bakım ve sürüm güncellemelerinin tekliflerde nasıl karşılaştırıldığını incelemek, yayın hizmetinin geliştirme ve bakım kalemlerinden hangi noktalarda ayrıldığını değerlendirmeye yardımcı olur.

• İlk mağaza başvurusunun hazırlanması ve gönderilmesi
• Teknik reddin analiz edilmesi ve gerekli düzeltmenin yapılması
• Müşterinin sağlaması gereken yasal ve ticari içerikler
• Hesap veya şirket doğrulama belgelerinin temini
• Yeni özellik gerektiren taleplerin kapsam değişikliği sayılması
• İnceleme sonrasındaki yeniden gönderim sorumluluğunun belirlenmesi

Fikrî Haklar ve Lisanslar Sözleşmede Nasıl Ayrılmalı?

Fikrî haklar, kaynak kodu teslimi ve üçüncü taraf lisanslar mobil uygulama sözleşmesinde ayrı maddeler olarak ele alınmalıdır. Kaynak kodunun müşteriye teslim edilmesi, bütün fikrî hakların kendiliğinden devredildiği anlamına gelmeyebilir. Benzer şekilde projede kullanılan bazı yazılım kütüphaneleri, SDK'lar veya ticari servisler sağlayıcının devredemeyeceği lisans koşullarına tabi olabilir. Hak devri kapsamı, projeye özel oluşturulan varlıklarla önceden var olan bileşenleri açık biçimde ayırmalıdır.

Sözleşme hangi sahiplik konularını açıklamalı?

Hangi kodun projeye özel üretildiği, hangi bileşenlerin sağlayıcının daha önce geliştirdiği yapılar olduğu, açık kaynak lisanslarının yükümlülükleri ve tasarım varlıklarının kullanım hakları yazılı olmalıdır. Bu konuda kaynak kod, fikrî haklar ve devir teslim hükümlerinin sözleşmede nasıl güvenceye alınabileceğini incelemek, mobil uygulama projesindeki benzer riskleri değerlendirmek için yararlı bir çerçeve sunar. Hukuki sonuçlar sözleşmeye ve uygulanacak hukuka göre değişebileceğinden gerektiğinde uzman hukuk görüşü alınmalıdır.

• Projeye özel geliştirilen kaynak kodunun devir kapsamı
• Sağlayıcının önceden sahip olduğu yeniden kullanılabilir bileşenler
• Açık kaynak lisansları ve bunların yükümlülükleri
• Ticari SDK ve servis hesaplarının sahipliği
• Font, ikon, görsel ve tasarım varlıklarının lisans durumu
• Sözleşme sona erdiğinde devam eden kullanım hakları

Garanti ve Ücretli Bakım Sınırı Nasıl Tanımlanmalı?

Garanti ile ücretli bakım aynı hizmet olarak yazılmamalıdır. Garanti, kabul edilmiş proje kapsamındaki bir işlevin tanımlandığı şekilde çalışmaması durumunda yapılacak hata düzeltmelerini; bakım ise yeni ihtiyaçlar, platform değişiklikleri, sürekli iyileştirmeler ve kapsam genişletmelerini kapsayabilir. Garanti kapsamı yeni özellik geliştirme taahhüdü değildir. Başlangıç koşulu, kapsanan hata türleri ve kapsam dışı durumlar sözleşmede açıkça belirtilmelidir.

Yayın sonrası destek teklifi nasıl ayrıştırılmalı?

Yayın sonrası destek aylık bakım paketi, talep bazlı teknik çalışma veya ayrı geliştirme sprintleri şeklinde sunulabilir. Önemli olan, hangi talebin garanti kapsamında ücretsiz hata düzeltmesi, hangisinin yeni geliştirme sayılacağının önceden anlaşılmasıdır. İşletim sistemi güncellemeleri, mağaza politikası değişiklikleri veya üçüncü taraf servislerde yapılan değişiklikler de ayrı sorumluluk kategorileri olarak tanımlanabilir. Böylece destek hizmetinin kapsamı hem müşteri hem sağlayıcı açısından öngörülebilir hale gelir.

• Kabul sonrasında garanti dönemini başlatan olay
• Garanti kapsamındaki hata tanımı ve önem seviyeleri
• Yeni özellik ve kapsam genişletmelerinin hariç tutulması
• İşletim sistemi değişikliklerinin nasıl ele alınacağı
• Üçüncü taraf servis değişikliklerinin sorumluluğu
• Bakım taleplerinin planlama ve ücretlendirme yöntemi

Yayın Gecikmelerinde Sorumluluk Nasıl Paylaştırılmalı?

Yayın gecikmelerindeki sorumluluk, gecikmeyi doğuran görevin sahibine ve kontrol edilebilirliğine göre belirlenmelidir. Mağazanın inceleme süresi, müşterinin geciktirdiği şirket belgesi, geliştiricinin düzeltmesi gereken teknik hata veya harici servis sağlayıcısının onayı aynı tür gecikme değildir. Sorumluluk matrisi, her bağımlılık için görev sahibini, gerekli girdiyi ve gecikmenin proje takvimine etkisini görünür hale getirir.

Yayın takvimindeki bağımlılıklar nasıl yazılmalı?

Teklifte yalnızca tek bir “yayın tarihi” belirtilmesi yerine hesap açılışı, test sürümü, müşteri kabulü, mağaza gönderimi, inceleme yanıtı ve canlıya geçiş gibi kilometre taşları tanımlanmalıdır. Müşterinin sağlayacağı içerik veya belgeler gecikirse takvimin nasıl güncelleneceği; teknik hata tespit edilirse düzeltme sorumluluğunun kimde olduğu önceden yazılabilir. Mağazaların veya diğer üçüncü tarafların kontrolündeki incelemeler için kesin sonuç tarihi vaat etmek yerine yapılacak eylemler ve yanıt sorumlulukları tanımlanmalıdır.

• Hesap doğrulama ve şirket belgelerinin teslim tarihleri
• Kabul testlerinin kapanış ve onay kilometre taşı
• Mağaza başvurusunun gönderileceği proje aşaması
• Teknik red durumunda düzeltme ve yeniden gönderim akışı
• Müşteri kaynaklı beklemelerde takvim güncelleme yöntemi
• Üçüncü taraf süreçlerinde eylem sorumluluğunun belirlenmesi

Teklifte Devir Teslim Kontrol Listesi Nasıl İstenmeli?

Mobil uygulama teklifinde yalnızca geliştirme süresi ve toplam bedel değil, kabul ve devir teslim kontrol listesi de istenmelidir. Böyle bir liste, farklı sağlayıcıların yayın, hesap sahipliği, test, kod teslimi, dokümantasyon, fikrî haklar, garanti ve bakım yaklaşımını aynı kriterler üzerinden karşılaştırmayı mümkün kılar. Karşılaştırılabilir teklif, genel hizmet ifadeleri yerine teslim edilecek varlıkları, görev sahiplerini ve kabul koşullarını açıkça gösteren tekliftir.

Firma teklifinde hangi teslim maddeleri bulunmalı?

Her teslim için sorumlu taraf, teslim formatı, kabul yöntemi ve proje içindeki zamanı belirtilmelidir. “Yayın desteği dahildir” gibi genel bir ifade yerine mağaza hesabını kimin açacağı, başvuruyu kimin yöneteceği, kodun nasıl devredileceği ve garanti sonrasında desteğin nasıl sürdürüleceği açıklanmalıdır. Farklı firmalardan teklif toplarken mobil uygulama tekliflerini kapsam, sözleşme ve sahiplik açısından karşılaştırmak, geliştirme ücretinin ötesindeki operasyonel farkları görünür hale getirir.

• Yayın hesaplarının sahibi ve erişim modeli
• Kabul testleri, hata seviyeleri ve onay yöntemi
• Kaynak kodu, tasarım ve API dokümantasyonu teslimi
• Mağaza başvurusu ve inceleme geri dönüşü sorumlulukları
• Fikrî haklar ve üçüncü taraf lisansların kapsamı
• Garanti, ücretli bakım ve yayın sonrası destek sınırları