Web Uygulaması Projesinde Kaynak Kod, Hosting ve Devir Teslim Şartları Nasıl Belirlenir?

Web Uygulaması Kaynak Kod Sahipliği Nasıl Belirlenmeli?

Web uygulamasının kaynak koduna ilişkin haklar, proje modeli ve kullanılan bileşenler ayrıştırılarak sözleşmede açık biçimde belirlenmelidir. İşletmeye özel geliştirilen kod, sağlayıcının daha önce oluşturduğu genel amaçlı kütüphaneler, açık kaynak paketler ve lisanslı üçüncü taraf bileşenler aynı sahiplik kategorisinde değerlendirilmemelidir. Müşterinin uygulamayı işletme, bakım yaptırma, farklı bir firmayla geliştirmeye devam etme ve gerekli kaynaklara erişme hakları hangi kapsamda veriliyorsa bunlar açıkça yazılmalıdır.

Kaynak kod teslimi ile fikri hakları birbirinden ayırın

Bir Git deposuna erişim verilmesi, tek başına tüm fikri hakların devredildiği veya yazılımın başka bir ekip tarafından sürdürülebileceği anlamına gelmez. Repository sahipliği, branch geçmişi, bağımlılık dosyaları, özel paketler ve lisans sınırlamaları ayrı kontrol edilmelidir. Kaynak kod sahipliği, erişim hakkı, kullanım hakkı ve fikri hak devri sözleşmede birbirinden ayrılmış maddeler olarak tanımlanmalıdır. Bu yaklaşım, uygulamanın gelecekteki geliştirme ve bakım seçeneklerini daha görünür hale getirir.

• Projeye özel geliştirilen kaynak kodun kapsamı ve kullanım hakları
• Sağlayıcıya ait önceden geliştirilmiş ortak bileşenlerin durumu
• Açık kaynak ve ticari paketlerin lisans koşulları
• Git deposunun sahipliği ve müşteri erişim seviyesi
• Firma değişikliğinde kodun kullanılmasına ilişkin sözleşme hükümleri

Programlar insanların okuyabilmesi için, ancak ikincil olarak makinelerin çalıştırabilmesi için yazılmalıdır. - Harold Abelson ve Gerald Jay Sussman

Web Uygulama Teklifinde Teknik Varlıklar Nasıl Yazılmalı?

Web uygulama teklifinde teknik varlıklar, geliştirme hizmetinden bağımsız teslim ve sahiplik kalemleri olarak yazılmalıdır. Kaynak kod, veritabanı, alan adı, SSL sertifikaları, bulut hesabı, e-posta servisleri, CDN, obje depolama, yedekleme alanları ve harici API hesapları için kimin satın alacağı, yöneteceği ve erişim sağlayacağı belirtilmelidir. Böylece teklif bedelinin yalnızca geliştirmeyi mi yoksa altyapı ve üçüncü taraf hizmetlerini de mi kapsadığı anlaşılır.

Teklifi sözleşmeye dönüşebilecek ayrıntıda hazırlayın

Teklifte “hosting dahil” veya “kaynak kod teslim edilir” gibi kısa ifadeler yerine hizmet süresi, hesap sahipliği, yenileme sorumluluğu, erişim seviyesi ve proje sonunda uygulanacak teslim yöntemi yazılmalıdır. Teknik varlık envanteri, teklif ile sözleşme arasında kapsam kaybını önleyen temel referanslardan biridir. Bu nedenle web uygulaması tekliflerini fiyat, kapsam ve sözleşme açısından karşılaştırma yaklaşımı teknik sahiplik maddeleriyle birlikte değerlendirilmelidir.

• Teklif kapsamında oluşturulacak tüm teknik hesapların listesi
• Her hesabın sahibi, yöneticisi ve ödeme sorumlusunun belirtilmesi
• Dahil olan lisanslar ile müşteri tarafından alınacak lisansların ayrılması
• Proje sonundaki erişim ve teslim yönteminin açıklanması
• Süreli hizmetlerin yenileme ve iptal sorumluluklarının tanımlanması

Kod Deposu ve Geliştirme Erişimleri Nasıl Yönetilmeli?

Kod deposu ve geliştirme erişimleri, proje devam ederken de müşterinin teknik sahiplik modeline uygun biçimde yönetilmelidir. Repository yalnızca bir geliştiricinin kişisel hesabında tutulmamalı; kurum, proje veya yetkilendirilmiş organizasyon hesabı altında sürdürülebilir bir yapı kurulmalıdır. Kimlerin yönetici yetkisine sahip olduğu, erişimlerin nasıl kaldırıldığı, deployment anahtarlarının nerede saklandığı ve kritik değişikliklerin nasıl kayıt altına alındığı belirlenmelidir.

Tek kişiye bağlı erişim modelinden kaçının

Bir geliştiricinin ayrılması veya sağlayıcının değişmesi halinde kod geçmişine, issue kayıtlarına ve CI/CD bağlantılarına erişilemiyorsa teknik devir zorlaşır. Müşteri tarafının her geliştirici hesabını yönetmesi gerekmeyebilir ancak kurumsal erişim sürekliliği sağlanmalıdır. Repository, deployment ve yönetici erişimleri kişisel hesaplardan mümkün olduğunca ayrılarak kurumsal kontrol altında tutulmalıdır. Yetki seviyesi ihtiyaca göre sınırlandırılabilir; önemli olan kritik varlıkların tek kişinin hesabına bağımlı kalmamasıdır.

• Repository organizasyonunun ve yönetici hesabının açık biçimde belirlenmesi
• Geliştirici erişimlerinin rol bazlı ve geri alınabilir olması
• Branch, release ve versiyon geçmişinin korunması
• CI/CD anahtarlarının güvenli ve devredilebilir biçimde yönetilmesi
• Proje sona erdiğinde erişim kapatma prosedürünün tanımlanması

Hosting ve Bulut Hesapları Hangi Tarafın Adına Olmalı?

Hosting ve bulut hesaplarının hangi tarafın adına açılacağı, uygulamanın operasyon modeli ve hizmet sorumluluklarına göre belirlenmeli; ancak müşterinin kritik altyapıya erişim ve taşıma hakkı sözleşmede güvence altına alınmalıdır. Uzun süre kullanılacak üretim altyapısında hesapların işletme adına açılması veya işletmenin üst düzey yönetici erişimine sahip olması, sağlayıcı değişikliğinde altyapının kontrolünü korumayı kolaylaştırır.

Hesap sahipliği ile operasyon sorumluluğunu ayırın

Müşteri hesabın sahibi olurken günlük sunucu yönetimini yazılım firması üstlenebilir. Buna karşılık firmanın kendi altyapısında yönetilen hizmet sunuluyorsa veri erişimi, yedekleme, taşıma yöntemi ve sözleşme sona erdiğinde verilecek çıktılar ayrıca tanımlanmalıdır. Hosting sahipliği ile sunucunun teknik yönetimi aynı sorumluluk değildir ve sözleşmede ayrı maddeler halinde ele alınmalıdır. bulut ve sunucu yönetiminin operasyonel kapsamı incelenerek yedekleme, izleme ve erişim sorumlulukları daha net karşılaştırılabilir.

• Bulut veya hosting hesabının hukuki ve operasyonel sahibinin belirlenmesi
• Müşteri için yönetici veya acil durum erişiminin tanımlanması
• Sunucu yönetimi, güncelleme ve izleme sorumluluğunun ayrılması
• Yedeklerin nerede tutulacağı ve kim tarafından erişileceğinin yazılması
• Taşıma gerektiğinde veri ve altyapı çıktılarının nasıl alınacağının belirtilmesi

Üçüncü Taraf Servis ve Lisans Sahipliği Nasıl Kurulmalı?

Üçüncü taraf servis ve lisans sahipliği, web uygulaması sözleşmesinde ayrı bir envanter halinde düzenlenmelidir. Ödeme altyapısı, SMS, e-posta, harita, kimlik doğrulama, analitik, hata izleme, CDN, depolama veya yapay zekâ servisleri gibi dış bağımlılıkların hangi hesap üzerinden çalıştığı bilinmelidir. Bir servisin yazılımcı hesabına bağlı olması, sağlayıcı değişikliğinde veri geçmişinin veya yapılandırmanın kaybedilmesine yol açabilir.

Her dış bağımlılığın taşınabilirliğini önceden kontrol edin

Bazı servisler hesap devrine izin verirken bazıları yeni hesap oluşturulmasını ve yeniden yapılandırmayı gerektirebilir. Bu nedenle API anahtarlarının, webhook ayarlarının, gönderici doğrulamalarının, domain kayıtlarının ve ödeme profillerinin kim tarafından yönetildiği belgelenmelidir. Üçüncü taraf servislerde amaç her hesabı mutlaka müşteri adına açmak değil, kritik bağımlılıkların sahipliğini, erişimini ve taşınabilirliğini baştan görünür hale getirmektir. Lisans yenileme tarihleri ve ücret sorumluluğu da geliştirme kapsamından ayrı tutulmalıdır.

• Harici servislerin ve kullanılan hesapların eksiksiz envanteri
• API anahtarları ve yönetici erişimlerinin saklama yöntemi
• Lisans sahibi ile ödeme sorumlusunun açıkça belirtilmesi
• Hesap devri mümkün değilse yeniden kurulum prosedürünün tanımlanması
• Servis kapanması halinde kullanılabilecek alternatiflerin belgelenmesi

Proje Sonunda Hangi Teknik Dokümanlar Teslim Edilmeli?

Proje sonunda teslim edilmesi gereken teknik dokümanlar, başka bir yetkin ekibin uygulamayı kurabilmesi, çalıştırabilmesi ve bakımını sürdürebilmesi için gereken bilgileri kapsamalıdır. Mimari özet, ortam gereksinimleri, kurulum adımları, veritabanı yapısı, entegrasyon noktaları, zamanlanmış görevler, deployment süreci ve kritik yapılandırmalar minimum devir paketi içinde değerlendirilmelidir. Dokümantasyonun kapsamı projenin karmaşıklığına göre sözleşme öncesinde tanımlanmalıdır.

Dokümantasyonu projenin sonunda hazırlanan dosya yapmayın

Dokümanların geliştirme boyunca güncellenmesi, son aşamada eksik veya eski bilgi teslim edilmesi riskini azaltır. README dosyaları, API şemaları, veri sözlüğü, ortam değişkenleri açıklamaları ve operasyon talimatları sürümle birlikte yönetilebilir. Teknik devir teslim, yalnızca kaynak kod arşivi değil uygulamanın nasıl çalıştığını açıklayan güncel bilgi setidir. özel yazılım geliştirme sürecinin fikirden canlı kullanıma uzanan aşamaları teslim paketinin hangi adımlarda hazırlanması gerektiğini değerlendirmeye yardımcı olur.

• Sistem mimarisi ve temel bileşen ilişkilerini açıklayan teknik özet
• Kurulum, yapılandırma ve deployment talimatları
• Veritabanı, API ve entegrasyon dokümantasyonu
• Zamanlanmış görevler, kuyruklar ve arka plan servislerinin açıklaması
• Operasyon, yedekleme ve hata inceleme prosedürleri

Veri, Yedek ve Sunucu Erişimleri Nasıl Teslim Edilmeli?

Veri, yedek ve sunucu erişimleri devir teslim planında ayrı kalemler olarak yer almalıdır. Veritabanının hangi formatta dışa aktarılacağı, dosya depolarının nasıl teslim edileceği, yedeklerin hangi tarihe kadar saklanacağı, sunucu yönetici erişimlerinin nasıl paylaşılacağı ve gizli anahtarların hangi yöntemle aktarılacağı önceden tanımlanmalıdır. Özellikle kişisel veya ticari hassas veri bulunan uygulamalarda kontrolsüz parola paylaşımı yerine güvenli erişim devri uygulanmalıdır.

Devir sonrası eski erişimlerin kapatılmasını planlayın

Yeni firma veya kurum içi ekip erişimi aldıktan sonra eski kullanıcıların, deploy anahtarlarının, servis hesaplarının ve kişisel tokenların gözden geçirilmesi gerekir. Yedeklerin yalnızca mevcut olması değil, geri yüklenebilir olduğunun doğrulanması da önemlidir. Başarılı bir teknik devir, yeni erişimlerin verilmesi kadar artık gerekmeyen eski erişimlerin kontrollü biçimde kapatılmasını da kapsar. Teslim tutanağında hangi erişimin ne zaman devredildiği ve kimin doğruladığı kayıt altına alınabilir.

• Veritabanı ve dosya depoları için dışa aktarım yöntemi
• Son alınan yedeğin tarihi ve geri yükleme doğrulaması
• Sunucu, panel ve bulut yönetici erişimlerinin devri
• API anahtarları, sertifikalar ve gizli bilgilerin güvenli aktarımı
• Eski kullanıcı, token ve erişimlerin kapatılmasına ilişkin kontrol listesi

Firma Değişikliğinde Yazılım Devir Teslimi Nasıl Yönetilir?

Firma değişikliğinde yazılım devir teslimi, sözleşme sona erdiğinde doğaçlama yürütülen bir işlem olmamalı; proje başında tanımlanmış bir geçiş prosedürüne dayanmalıdır. Mevcut sağlayıcının hangi teknik varlıkları teslim edeceği, yeni ekiple kaç oturum bilgi aktarımı yapacağı, açık hata ve geliştirme taleplerinin nasıl devredileceği, geçiş döneminde kimin üretim sorumluluğunu taşıyacağı önceden belirlenmelidir.

Geçiş desteğini bakım hizmetinden ayrı tanımlayın

Firma değişikliği sırasında hem eski hem yeni ekibin kısa süreli olarak aynı sistem üzerinde çalışması gerekebilir. Bu dönemde erişim sorumlulukları, değişiklik dondurma kuralları, son deployment yetkisi ve kritik sorun iletişim kanalı belirlenmelidir. Devir teslim desteği, normal bakım hizmetinin belirsiz bir uzantısı olarak değil süresi, kapsamı ve teslim kriterleri tanımlı ayrı bir hizmet olarak ele alınmalıdır. yazılım firması tekliflerini karşılaştırırken kullanılan kapsam yaklaşımı, geçiş sorumluluklarını farklı sağlayıcılarda aynı başlıklar altında değerlendirmek için kullanılabilir.

• Devir başlangıç tarihi ve sorumlu kişilerin belirlenmesi
• Açık hata, geliştirme ve operasyon taleplerinin aktarılması
• Yeni ekibe teknik bilgi transferi oturumlarının planlanması
• Geçiş döneminde deployment ve üretim sorumluluğunun tanımlanması
• Devir tamamlandığında yazılı kabul ve erişim kontrolünün yapılması

Bu Şartlar Web Uygulaması Sözleşmesine Nasıl Eklenmeli?

Kaynak kod, hosting ve devir teslim şartları web uygulaması sözleşmesine ölçülebilir teslimler, sorumluluklar ve kabul kriterleri şeklinde eklenmelidir. “Kaynak kod verilecektir” gibi genel ifadeler yerine repository erişimi, dokümantasyon, hesap sahipliği, veri dışa aktarımı, lisanslar, geçiş desteği ve erişim kapatma işlemleri ayrı maddeler halinde tanımlanmalıdır. Teklifte yer alan teknik kapsamın sözleşme ekine dönüştürülmesi, ticari görüşme sırasında mutabık kalınan detayların kaybolmasını azaltır.

İmzadan önce teknik teslim kontrol listesi oluşturun

Sözleşme imzalanmadan önce proje yöneticisi, teknik sorumlu ve satın alma ekibi aynı varlık listesini kontrol etmelidir. Kabul koşulları yalnızca uygulamanın çalışmasına değil, gerekli erişim ve dokümanların teslim edilmesine de bağlanabilir. İyi tanımlanmış bir web uygulaması sözleşmesi, proje sonunda kimin neyi teslim edeceğini ve müşterinin uygulamayı nasıl sürdürebileceğini belirsiz bırakmaz. Ayrıca yazılım projesi başlamadan önce firmaya sorulması gereken teknik sorular, sözleşme öncesi son değerlendirme listesine dahil edilebilir.

• Kaynak kod, hesap ve veri sahipliğinin ayrı sözleşme maddelerinde yazılması
• Teknik teslimlerin kabul kriterleri ve sorumlularının belirlenmesi
• Üçüncü taraf lisans ve yenileme yükümlülüklerinin açıklanması
• Firma değişikliği ve sözleşme sonu geçiş prosedürünün tanımlanması
• Teslim tamamlandıktan sonra erişim kapatma ve doğrulama adımlarının yazılması