Yazdırdığınız yazılımın kodu kimin olmalı?

Çalışan ekran ile teslim edilen ürün aynı değildir

Firmanız için bir teklif uygulaması geliştirildiğini düşünün. Çalışanlar giriş yapıyor, ürün seçiyor ve PDF alıyor. Günlük kullanım açısından iş tamamlanmış görünebilir. Ancak fiyat tablosunu değiştirecek geliştirici ayrıldığında başka bir ekibin uygulamayı çalıştırıp çalıştıramayacağı henüz bilinmez. Kaynak kod konusu tam da bu noktada önem kazanır. Ekranı kullanma, yazılımı değiştirme ve farklı bir yerde çalıştırma olanaklarını proje başında ayrı ayrı konuşun. Bunları aynı anlama gelen teslimler gibi değerlendirmeyin; her biri için hangi dosyanın ve hangi belgenin verileceği açık olsun.

Bu yazı bir sözleşmenin hukuki sonucunu belirlemez. Hakların kapsamı anlaşmaya, kullanılan bileşenlere ve uygulanacak hukuka göre değerlendirilir. Sözleşme maddelerini gerektiğinde hukuk uzmanıyla inceleyin. Teknik açıdan yapılabilecek iş, beklenen teslimi anlaşılır bir listeye çevirmektir. Hangi bölüm size özel geliştiriliyor, hangi bölüm hazır hizmet olarak kullanılıyor ve hangi bölüm üçüncü taraf kütüphaneye dayanıyor? Bu ayrım olmadan bütün kodun aynı koşulla teslim edileceğini varsaymak yanıltıcı olabilir.

İhtiyacınız teslim modelini belirler

Hazır bir abonelik hizmetinde sağlayıcının kaynak kodunu teslim etmesi beklenmeyebilir. Bunun yerine veri dışa aktarımı, hizmet sona erdiğinde erişim ve entegrasyon olanakları değerlendirilir. Size özel bir uygulamada ise kaynak deposunun, kurulum tarifinin ve değişiklik yapma koşullarının teslim kapsamına alınması istenebilir. İki model de farklı gereksinimlere cevap verir. Kararı yalnız ilk fiyat üzerinden vermeyin. Uygulama firmanın temel işini yürütüyorsa başka bir tedarikçiyle devam edebilme ihtiyacı daha belirgin olabilir.

İstenen teslim, proje kapsamıyla uyumlu olsun. Örneğin uygulamanın sizin için yazılan ekranlarını alırken kullanılan bulut hizmetinin iç yazılımını alamazsınız. Ancak o hizmete hangi verilerin gönderildiğini ve bağlantının nasıl kurulduğunu belgelemesini isteyebilirsiniz. Teklifte yer almayan bir teslimin sonradan kendiliğinden oluşacağını düşünmek yerine soruyu yazılı olarak netleştirin.

Kodun yanında hangi bilgiler bulunmalı?

Bir klasörde kaynak dosyalarının bulunması iyi bir başlangıçtır; sürdürülebilir teslim için tek başına yeterli değildir. Kodun hangi sürümü yayında, hangi geliştirme aracı kullanılıyor ve bağımlılık sürümleri nasıl sabitleniyor? Yapılandırma değişkenlerinin adları, örnek değerleri ve güvenli biçimde temin yöntemi belgelenmelidir. Gerçek parola veya anahtarlar kod deposuna konmamalıdır. Yeni ekip, sırları ayrı ve yetkili bir süreçte edinerek uygulamayı kurabilmelidir. Üretim ortamına ait gizli bilgileri teslim belgesine açıkça yazmak teslimi kolaylaştırmaz; yeni bir risk oluşturur.

Veritabanı yapısı, kurulum adımları, örnek test verisi ve yedekten geri dönüş tarifi de pakette yer alsın. Zamanlanmış görevleri, dış servis bağlantılarını ve dosya saklama yerlerini kaydedin. Bir rapor yalnız belli bir sunucudaki yazı tipiyle oluşuyorsa bu gereksinim bilinmelidir. Ayrıca kullanıcı rollerini ve yöneticinin yapabildiği işlemleri açıklayın. Bu belgeler uygulamanın her ayrıntısını uzun bir kitap halinde anlatmak zorunda değildir; yeni ekibin sistemi güvenli biçimde çalıştıracağı bilgiyi eksiksiz vermelidir.

Bağımlılıkları ve kullanım koşullarını ayırın

Uygulama açık kaynak kütüphane, ücretli bileşen veya sağlayıcıya ait ortak modül kullanabilir. Bunların kullanım koşulları aynı değildir. Bileşen adı, sürüm, lisans kaynağı ve yenileme gereksinimini bir envanterde tutun. Ücretli bir bileşen geliştiricinin hesabında kayıtlıysa yeni ekipte nasıl kullanılacağını önceden sorun. Satın alınmış olması, sınırsız aktarım veya her ortamda kullanım anlamına gelmeyebilir. İlgili koşulu gerçek lisans belgesinden kontrol edin; genel bir varsayıma dayanarak karar vermeyin.

Kod deposunun işletmeye ait bir hesapta tutulması erişimi kolaylaştırabilir; hesabın sahibi olmak tek başına bütün kullanım haklarını açıklamaz. Geliştiricinin hangi katkıları teslim ettiği ve hangi sınırların bulunduğu sözleşmede görülmelidir. Aynı şekilde veri sahipliği ve veri taşıma olanağı koddan ayrı ele alınmalıdır. Yeni bir ekibe geçerken müşteri kayıtlarını dışa aktaramıyorsanız kod teslim edilmiş olsa bile geçişte sorun yaşayabilirsiniz. Sistemler arasında veri aktarımını bu nedenle teslim planına dahil edin.

Teslimi küçük bir kabul testiyle doğrulayın

Projenin sonunda yalnız dosya saymak yerine temiz bir test ortamı kurun. Teslim belgesini kullanarak uygulamayı çalıştırın, örnek kullanıcıyla giriş yapın ve bir temel işlemi tamamlayın. Ardından yedeği geri yükleyin ve örnek veriyi dışa aktarın. İşlem sırasında belgede bulunmayan bir adım gerekiyorsa bunu ekleyin. Testi üretim verisini yaymadan ve canlı sistemi değiştirmeden yapın. Böylece dosyanın teslim edildiği ile teslimin kullanılabilir olduğu arasındaki fark somut biçimde görünür.

Son kontrol listesinde depo adresi, teslim sürümü, kurulum tarifi, bağımlılık envanteri, veri dışa aktarımı, bakım sorumlusu ve ayrılma adımlarını birlikte tutun. Değişiklik yapılınca bu liste de güncellensin. Amaç bütün projelerde aynı sözleşmeyi kullanmak değil, sizin işinizi sürdürecek teslimi tanımlamaktır. Başlangıçta konuşulan model, teklif ve kabul kaydı birbiriyle eşleştiğinde tedarikçi değişimi daha anlaşılır bir teknik işe dönüşür.

Sık sorulan sorular

Kaynak kodu almak tek başına yeterli mi?

Hayır. Kurulum belgesi, bağımlılıklar, uygun kullanım koşulları ve temiz ortamda çalıştırma doğrulaması da gerekir.

Her yazılımda kod teslimi beklenir mi?

Hazır abonelik hizmeti ile size özel geliştirilen yazılımın teslim modeli farklı olabilir. Modeli ve kapsamı sözleşmede açıkça belirleyin.

Tedarikçi değişimi nasıl sınanır?

Yetkili yeni bir ekibin teslim paketiyle test ortamını kurmasını ve örnek veriyi dışa aktarmasını kabul testine ekleyin.