Kurumsal Yazılım Tedarikçisi Değerlendirme Sürecinde Kod ve Dokümantasyon Teslim Yetkinliği Nasıl Sınanır?

Yazılım Tedarikçisinin Teslim Yetkinliği Nasıl Sınanır?

Bir yazılım tedarikçisinin teslim yetkinliği, proje sonunda dosya gönderip gönderemeyeceğinden çok daha geniş bir konudur. Aday firma; kaynak kod, mimari açıklamalar, API belgeleri, test kayıtları, sürüm notları, kurulum adımları ve açık teknik borçlar için nasıl bir teslim standardı kullandığını gösterebilmelidir. Teslim yetkinliği, başka bir teknik ekibin sistemi anlayıp çalıştırabilmesini sağlayacak bilgi ve erişimlerin düzenli, güncel ve doğrulanabilir biçimde bırakılmasıdır. Bu nedenle değerlendirme, satış sunumundan çok gerçek veya anonimleştirilmiş teslim örnekleri üzerinden yapılmalıdır.

Demo ile teknik teslim disiplinini birbirinden ayırın

İyi görünen bir demo ürün kalitesi hakkında fikir verebilir; ancak sistemin bakım, yayın, hata ayıklama veya ekip değişimi sırasında ne kadar yönetilebilir olduğunu göstermez. Adaydan önceki bir projeye ait anonim mimari şema, README yapısı, API açıklaması veya sürüm kaydı örneği istenebilir. Daha genel firma değerlendirmesinde kurumsal yazılım için doğru yazılım firmasını seçmeye yönelik rehber, teknik yeterlilik ile operasyonel süreçleri birlikte karşılaştırmak için destekleyici bir çerçeve sunar. Örneklerin tutarlı olması, tedarikçinin dokümantasyonu proje sonuna bırakmadığını gösterir.

• Kaynak kod ve depo yapısı örneği
• Mimari ve entegrasyon dokümanı örneği
• Test ve kabul kaydı örneği
• Sürüm notu ve yayın geçmişi
• Kurulum ve ortam hazırlama prosedürü
• Bilgi aktarımı ve devir planı

Herhangi biri bilgisayarın anlayabileceği kod yazabilir. İyi programcılar insanların anlayabileceği kod yazar. - Martin Fowler

Kurumsal Yazılımda Hangi Teknik Belgeler Teslim Edilmeli?

Kurumsal yazılım tesliminde belgeler, yalnız kullanıcı kılavuzundan oluşmamalıdır. Sistem mimarisi, bileşen sorumlulukları, veri modeli, API sözleşmeleri, entegrasyon bağımlılıkları, ortam değişkenleri, kurulum ve yayın adımları ile temel operasyon prosedürleri proje kapsamına göre belgelenmelidir. Teknik dokümantasyon şartları, sistemi geliştiren ekip dışındaki yetkin bir teknik kişinin yapıyı anlayabilmesini ve güvenli biçimde müdahale edebilmesini hedeflemelidir. Belge listesi sözleşmeye eklenirse teslim anında “dokümantasyon” kelimesinin farklı yorumlanması önlenir.

Belgenin varlığından çok kullanılabilirliğini kontrol edin

Bir PDF veya wiki sayfasının teslim edilmiş olması tek başına yeterli değildir. Belgelerin sürümle uyumlu olması, kullanılan servis ve bağımlılıkları göstermesi, kurulum adımlarını tekrar edilebilir biçimde açıklaması ve kritik kararların gerekçelerini içermesi gerekir. Mimari karar kaydı, API örnekleri, veri sözlüğü ve hata giderme notları özellikle karmaşık sistemlerde devralma süresini kısaltabilir. Aday firmadan belge şablonlarını önceden istemek, teslim standardının ne kadar sistematik olduğunu anlamaya yardımcı olur. Belgelerin hangi aralıklarla ve kim tarafından güncelleneceği de proje yönetim planında açıklanmalıdır.

• Sistem ve çözüm mimarisi açıklaması
• Veri modeli ve veri sözlüğü
• API ve entegrasyon dokümantasyonu
• Kurulum, yapılandırma ve yayın prosedürü
• Ortam değişkenleri ve bağımlılık listesi
• Operasyon ve hata giderme notları

Kaynak Kod Erişimi ve Depo Sahipliği Nasıl Düzenlenmeli?

Kaynak kod erişimi, proje sonunda tek seferlik dosya teslimi olarak ele alınmamalıdır. Kurumun ihtiyaç duyduğu erişim seviyesi, kodun hangi Git deposunda tutulacağı, yönetici yetkisinin kimde olacağı, erişimlerin ne zaman açılacağı ve iş ilişkisi sona erdiğinde nasıl devam edeceği sözleşmede açıklanmalıdır. Kaynak kod teslimi sözleşmesi, kodun kendisi kadar commit geçmişi, branch yapısı, sürüm etiketleri ve ilgili yapılandırma dosyalarının erişilebilirliğini de kapsamalıdır. Kurumsal kontrol, yalnız son sürümün ZIP dosyasını almakla sağlanmaz.

Kod devrini proje sonuna bırakmayın

Kurumsal projelerde kurumun en azından depo görünürlüğüne proje sırasında sahip olması, teslim riskini azaltabilir. Adayın branch stratejisi, code review süreci, release etiketleme yöntemi ve üretim yayın akışı incelenmelidir. kod devri ve yayın sürecinin nasıl doğrulanacağını açıklayan içerik, yalnız kod dosyalarının değil geliştirme geçmişinin ve yayın mekanizmasının da değerlendirilmesi gerektiğini gösterir. Üçüncü taraf özel paketler veya tedarikçiye ait ortak bileşenler varsa bunların erişim ve kullanım koşulları ayrıca belirtilmelidir.

• Git deposunun sahibi ve yöneticileri
• Kurumun proje boyunca erişim seviyesi
• Commit, branch ve sürüm geçmişinin korunması
• Build ve deployment dosyalarının kapsamı
• Gizli anahtarların ve sırların devir yöntemi
• Üçüncü taraf veya ortak kod bileşenleri

Mimari ve API Dokümantasyonu Hangi Detayları İçermeli?

Mimari ve API dokümantasyonu, sistemin hangi bileşenlerden oluştuğunu ve bu bileşenlerin birbirleriyle nasıl iletişim kurduğunu açıklamalıdır. Servis sınırları, veri akışları, dış sistem bağımlılıkları, kimlik doğrulama yöntemi, hata yanıtları ve kritik iş kuralları görünür olmalıdır. Mimari dokümanın amacı, yalnız mevcut çözümü tarif etmek değil, bakım veya değişiklik sırasında hangi parçanın neden etkileneceğini anlaşılır hale getirmektir. API dokümanı da endpoint listesinden daha fazlasını; istek ve yanıt örneklerini, yetkilendirmeyi, hata senaryolarını ve sürümleme yaklaşımını içermelidir.

Dokümanın canlı sistemle eşleşmesini sınayın

Adaydan yalnız şablon istemek yerine, örnek bir dokümanın gerçek bir sürümle nasıl ilişkilendirildiğini sorun. Otomatik üretilen API belgeleri yararlı olabilir; ancak iş kurallarını, bağımlılıkları ve mimari karar gerekçelerini her zaman açıklamaz. Bu nedenle otomatik dokümantasyon ile insan tarafından hazırlanan açıklamalar birbirini tamamlamalıdır. Entegrasyon noktalarında veri formatı, hata davranışı, rate limit veya yeniden deneme mantığı gibi operasyonel ayrıntılar da kayıt altına alınmalıdır. Kurumun kendi ekiplerinin dokümanı inceleyip anlaşılmayan noktaları teslim öncesi geri bildirebilmesi önemli bir kabul adımıdır.

• Bileşenler ve servis sorumlulukları
• Veri akışları ve entegrasyon noktaları
• Kimlik doğrulama ve yetkilendirme yaklaşımı
• API istek ve yanıt örnekleri
• Hata kodları ve istisna senaryoları
• Sürümleme ve geriye uyumluluk yaklaşımı

Yazılım Test Sonuçları ve Kabul Kanıtları Nasıl Paylaşılmalı?

Test sonuçları, “test edildi” ifadesinden daha ayrıntılı ve izlenebilir biçimde paylaşılmalıdır. Kritik gereksinimlerin hangi test senaryolarıyla doğrulandığı, hangi ortamda çalıştırıldığı, beklenen ve gerçekleşen sonuçlar, açık hatalar ve yeniden test durumu görülebilmelidir. Yazılım kalite güvence süreci, fonksiyonel testlerin yanında proje ihtiyacına göre entegrasyon, güvenlik, performans, uyumluluk veya regresyon kontrollerini de kapsayabilir. Hangi test türlerinin sözleşme kapsamında olduğu ve kabul için hangi kanıtların yeterli sayılacağı proje başlamadan tanımlanmalıdır.

Kabul kriterlerini gereksinimlerle ilişkilendirin

Test kayıtları, ilgili kullanıcı hikâyesi, gereksinim veya teknik kriterle eşleştirilebildiğinde satın alma ekibi teslimin kapsamını daha objektif değerlendirebilir. Açık hataların önem derecesi ve hangi kusurların canlıya çıkışı engelleyeceği de önceden belirlenmelidir. test ve kabul kriterlerinin sözleşmeye dahil edilmesini ele alan rehber, kalite güvence işinin yalnız geliştirme ekibinin iç süreci olarak bırakılmaması gerektiğini destekler. Kullanıcı kabul testi (UAT), teknik test ve üretim sonrası doğrulamanın sorumluları ayrı ayrı belirtilmelidir.

• Test senaryosu ve ilgili gereksinim
• Test ortamı ve kullanılan sürüm
• Beklenen ve gerçekleşen sonuç
• Hata önceliği ve çözüm durumu
• Regresyon ve yeniden test kayıtları
• Kabul onayı ve sorumlu taraf

Sürüm Kaydı ve Kurulum Prosedürü Teslimde Nasıl Olmalı?

Sürüm kaydı ve kurulum prosedürü, başka bir ekibin yazılımı doğru sürümle yeniden kurabilmesini ve yayınlayabilmesini sağlayacak kadar açık olmalıdır. Hangi bileşenin hangi sürümde olduğu, veritabanı değişiklikleri, yapılandırma gereksinimleri, bağımlılıklar, migration adımları ve geri dönüş yöntemi kayıt altına alınmalıdır. Tekrarlanabilir kurulum, yalnız geliştiricinin kişisel bilgisinde kalan komutlara değil, doğrulanmış prosedürlere ve mümkünse otomasyonlara dayanmalıdır. Bu alanın zayıf olması, kod teslim edilmiş olsa bile sistemi devralmayı ciddi biçimde zorlaştırabilir.

Yayın sürecini belge üzerinden gerçekten yeniden çalıştırın

Teslim öncesi iyi bir kontrol, kurulum veya yayın adımlarının tedarikçi dışındaki yetkin bir kişi tarafından dokümana bakılarak uygulanabilmesidir. Eksik ortam değişkenleri, bilinmeyen manuel adımlar veya kişisel hesaplara bağlı servisler bu denemede ortaya çıkar. Sürüm notlarında yalnız yeni özellikler değil, kırılma riski taşıyan değişiklikler, veritabanı migrationları ve geri alma koşulları da görünmelidir. CI/CD akışı kullanılıyorsa pipeline tanımı, gerekli erişimler ve üretim ortamına geçiş yetkileri de devir kapsamının parçası olarak ele alınmalıdır.

• Sürüm numarası ve değişiklik geçmişi
• Ortam hazırlama ve bağımlılık adımları
• Veritabanı migration prosedürü
• Build ve deployment süreci
• Rollback veya geri dönüş adımları
• CI/CD erişim ve yetki bilgileri

Lisans ve Yazılım Kullanım Hakları Nasıl Açıklanmalı?

Lisans ve kullanım hakları, kaynak kod erişiminden ayrı bir sözleşme konusu olarak açıkça tanımlanmalıdır. Kuruma özel geliştirilen kodun kullanım, değiştirme ve devretme hakları; tedarikçinin önceden var olan bileşenleri; açık kaynak paketler; ticari kütüphaneler ve üçüncü taraf servisleri birbirinden ayrılmalıdır. Hak sahipliği açıklığı, kaynak kodun teslim edilmesinin otomatik olarak sınırsız kullanım veya fikri mülkiyet devri anlamına geldiği varsayımını önler. Hukuki kapsam ülke ve sözleşme yapısına göre değişebileceği için maddeler gerektiğinde yetkin hukuk uzmanıyla ayrıca değerlendirilmelidir.

Üçüncü taraf bağımlılıklarını ayrı envanterde görün

Aday firmadan kullanılan harici paketlerin, lisans türlerinin, ücretli servislerin ve yenileme gerektiren aboneliklerin listesini istemek önemlidir. Bir bileşenin bugün ücretsiz olması gelecekteki kullanım şartlarının hiç değişmeyeceği anlamına gelmez; bu nedenle mevcut lisans ve bağımlılık durumu teslim tarihinde kayıt altına alınmalıdır. lisans ve içerik hakları için sağlayıcıya sorulabilecek soruları ele alan içerik, hak ve lisans konularını teklif aşamasında netleştirmek için benzer bir karar çerçevesi sunar.

• Kuruma özel geliştirilen kodun kullanım hakları
• Tedarikçiye ait önceden geliştirilmiş bileşenler
• Açık kaynak paketler ve lisansları
• Ticari kütüphane ve servis abonelikleri
• Değiştirme, çoğaltma ve devretme koşulları
• Sözleşme sonu lisans devamlılığı

Bakım ve Destek Koşulları Teknik Teslimden Nasıl Ayrılır?

Bakım ve destek hizmetleri, teknik teslimin yerine geçmemelidir. Kurum yazılımı kullanmaya devam edebilmek için zorunlu olarak aynı tedarikçiye bağlı kalıyorsa, teslim ve bilgi sahipliği açısından önemli bir risk oluşabilir. Teknik teslim bağımsızlığı, bakım anlaşması sona erse bile kurumun kod, belge, ortam bilgileri ve gerekli erişimler üzerinden sistemi başka bir ekibe devredebilmesini ifade eder. Buna karşılık bakım; hata müdahalesi, güncelleme, izleme, destek saatleri ve geliştirme kapasitesi gibi ayrı operasyonel hizmetleri kapsayabilir.

Sözleşmede teslim ile sürekli hizmet kalemlerini ayırın

Aday tekliflerde hangi materyallerin proje teslim bedeline dahil olduğu, hangilerinin yalnız aktif bakım sözleşmesi sırasında sağlandığı açıkça görülmelidir. Kaynak kod, temel dokümantasyon ve kurulum bilgisi gibi kritik devir unsurlarının yalnız destek paketi devam ettiği sürece erişilebilir olması istenmeyen bağımlılık yaratabilir. Kritik sistemlerde bakım modelinin nasıl kurulabileceğini anlamak için bakım ve müdahale modelini ele alan rehber, teslim sonrası operasyon sorumluluklarını ayrı değerlendirmek için yararlı bir referans noktasıdır.

• Proje teslimine dahil kalıcı materyaller
• Bakım sözleşmesine bağlı hizmetler
• Hata müdahale ve destek kapsamı
• Sürüm yükseltme ve güncelleme sorumluluğu
• İzleme ve operasyon hizmetleri
• Tedarikçi değişiminde devamlılık koşulları

Başka Bir Ekip Yazılımı Hangi Materyallerle Devralabilir?

Başka bir ekibin yazılımı devralabilmesi için yalnız kod deposuna erişmesi yeterli değildir. Mimari belgeler, kurulum prosedürleri, ortam bilgileri, veri modeli, entegrasyon açıklamaları, açık hata listesi, sürüm geçmişi ve operasyon notları birlikte sunulmalıdır. Ayrıca kritik bileşenler için bilgi aktarım oturumları ve soru-cevap süreci planlanabilir. Başarılı ekip devri, yeni ekibin tedarikçiye sürekli bağımlı olmadan sistemi kurabilmesi, temel sorunları teşhis edebilmesi ve kontrollü değişiklik yapabilmesiyle ölçülmelidir.

Devir provasını gerçek bir kabul adımı olarak kullanın

Proje kapanmadan önce kurumun kendi teknik ekibi veya bağımsız bir ekip, dokümantasyonu kullanarak geliştirme ortamını ayağa kaldırmayı ve basit bir değişikliği yayın akışına hazırlamayı deneyebilir. Bu prova, eksik belgeleri ve kişiye bağlı bilgileri görünür hale getirir. kaynak kod ve proje devrini güvenceye almaya yönelik rehber, devir teslim konusunu sağlayıcı seçiminden itibaren planlamanın önemini destekler. Devir oturumlarının kaydı ve açık soruların kapanış listesi de teslim kanıtının bir parçası olabilir.

• Kaynak kod ve tam sürüm geçmişi
• Mimari, veri ve entegrasyon belgeleri
• Kurulum ve yayın prosedürleri
• Açık hata ve teknik borç listesi
• Erişim, ortam ve operasyon bilgileri
• Bilgi aktarımı oturumları ve soru listesi

Yazılım Tedarikçisi Görüşmesinde Hangi Kanıtlar İstenmeli?

Kurumsal yazılım tedarikçisi değerlendirme görüşmesinde, adaylardan yalnız yetkinlik beyanı değil karşılaştırılabilir teknik kanıtlar istenmelidir. Anonimleştirilmiş mimari doküman, API örneği, test raporu, sürüm kaydı, kurulum prosedürü ve teslim kontrol listesi; firmanın süreci gerçekten uygulayıp uygulamadığını anlamaya yardımcı olur. Aynı örnek setini her adaydan istemek satın alma ekibinin değerlendirmesini daha tutarlı hale getirir. Karşılaştırılabilir teslim kanıtı, tekliflerin “iyi dokümantasyon sağlarız” gibi genel ifadeler yerine somut çıktı standartları üzerinden incelenmesini sağlar.

Teknik görüşmeyi kısa bir teslim senaryosuyla tamamlayın

Adaya, “Proje yarın başka bir ekibe devredilecek olsa bugün hangi dosya, erişim ve kayıtları teslim edersiniz?” sorusu yöneltilebilir. Cevap; kod deposundan lisans envanterine, test kanıtlarından kurulum adımlarına ve bilgi aktarımına kadar tüm yaşam döngüsünü kapsamalıdır. Tekliflerde bu çıktılar açıkça yer almıyorsa, sözleşmeye teslim listesi ve kabul kriterleri olarak eklenmeleri istenebilir. Son karar yalnız proje fiyatı ve teslim tarihine değil, kurumun yazılım üzerinde uzun vadeli teknik kontrolünü koruyacak devir disiplinine de dayanmalıdır.

• Örnek teknik dokümantasyon paketi
• Kaynak kod ve depo erişim modeli
• Test raporu ve kabul kanıtı
• Lisans ve üçüncü taraf bileşen listesi
• Kurulum, yayın ve rollback prosedürü
• Bilgi aktarımı ve ekip devri planı