Yazılım Devralma Kontrol Listesi

Kritik kullanıcıları, günlük görevleri ve uygulamanın bağlı olduğu sistemleri çıkarın. Sipariş alma, fatura aktarımı veya müşteri dosyasına erişim gibi akışların kesintisinde kimin etkileneceğini iş sahibiyle konuşun. Teknik incelemenin önceliğini bu etkiler belirlesin.

Son dönemde tekrar eden olayları, manuel düzeltmeleri ve destek taleplerini isteyin. Bir işin sorunsuz görünmesi, arka planda çalışanların her gün kayıt düzeltmediği anlamına gelmez. Mevcut işleyişi hem kullanıcıyla hem operasyon ekibiyle doğrulayın.

Kod, test ortamı, dağıtım sistemi, veritabanı şeması ve dış servislerin sorumlularını listeleyin. İnceleme için mümkün olan en dar erişimleri kullanın; örnek veriyi gerçek müşteri bilgisi gerektirmeyecek şekilde hazırlayın. Canlı sistemde deneme yapmadan önce ayrı bir doğrulama ortamı kurun.

Kurulum belgesini uygulamayı daha önce kullanmamış bir ekip üyesine verin. Eksik ortam değişkenlerini, kişisel bilgisayardaki dosyalara bağımlılıkları ve açıklanmayan manuel adımları kaydedin. İnceleme için kullanılan kod sürümü raporda yer alsın.

Bir kritik akış için normal durum, hatalı veri ve yetkisiz kullanıcı örneklerini deneyin. Mevcut otomatik testlerin yalnızca sayısına bakmayın; hangi iş kuralını koruduklarını anlayın. Test bulunmuyorsa değişiklikten önce mevcut davranışı kayıt altına alan sınırlı kontroller planlayın.

Paketlerin ve çalışma zamanının güncelleme durumunu, özel lisanslı bileşenleri ve kullanılan dış API sürümlerini belirleyin. GitHub Dependabot gibi araçlar bilinen bağımlılık açıklarını gösterebilir; uyarı çıkmaması uygulamanın tüm güvenlik sorunlarından arındığı anlamına gelmez.

Her bulguyu uygulamadaki kullanım ve iş etkisiyle birlikte değerlendirin. Sürüm yükseltmenin veri şeması, arayüz veya entegrasyon davranışını değiştirip değiştirmediğini test ortamında inceleyin. Toplu güncelleme ile kapsamı belirsiz bir yeniden geliştirmeyi aynı iş paketi olarak sunmayın.

“Kod kötü” gibi genel yargılar karar vermeyi zorlaştırır. Gözlenen durumu, doğrulama yöntemini, iş etkisini ve sonraki adımı ayrı kaydedin. İncelenmeyen alanı başarılı kabul etmek yerine henüz doğrulanmadı olarak işaretleyin.

Mevcut sistem iş ihtiyacını karşılıyorsa önce kritik boşlukları kapatıp kademeli geliştirme düşünülebilir. Bir modül değişirken geri kalan akışın çalışması mümkün mü, verinin yeni yapıya taşınması nasıl doğrulanacak ve iki sistem bir süre birlikte işletilecek mi sorularını cevaplayın.

İnceleme sonunda kanıtlanan bulgular, açık sorular, öncelikli işler ve tahminin dayandığı varsayımlar teslim edilsin. Destek sorumluluğunun hangi tarihte ve hangi koşulla devralınacağını ayrıca yazın. Yeniden yazım önerisini yalnızca teknoloji yaşına dayandırmayın.

Teknik devir rehberi kabul edilen teslim paketini; kabul testleri ise kritik akışların doğrulanmasını tamamlar. Entegrasyon belirsizliği varsa API kapsam rehberindeki soruları inceleme listesine ekleyin.