Konu sayfası
SAP® yazılımında özel kod envanteri ve teknik borç: listeden karara
Yıllar içinde SAP® yazılımı üzerinde ABAP® programlama diliyle geliştirilen özel kod, çoğu kurumda iş süreçlerinin görünmeyen bir parçasına dönüşür. Dönüşüm, yükseltme veya bakım kararı yaklaştığında ilk istenen şey genellikle bir listedir. Bu sayfa, o listenin nasıl bir karar aracına dönüştüğünü ve hangi kanıtların birbirinden ayrı tutulması gerektiğini açıklar.
- Hazırlayan Castintech
- Son doğrulama 23 Eylül 2026
- 7 dk okuma
- Kaynakça
Bu sayfada
Bölümler
Envanter ile ham nesne listesi arasındaki fark nedir?
Ham nesne listesi, sistemde hangi özel nesnelerin bulunduğunu söyler. Envanter ise her nesne için bir karar verilebilmesini sağlar: kullanılıyor mu, kime ait, neye bağlı, değişirse ne etkilenir ve bu nesneyle ne yapılmalı? Listedeki satır sayısı iş yükü hakkında fikir verir; kararı ise ancak bu sorulara verilen cevaplar belirler.
Bu fark yönetim açısından önemlidir. Yalnız nesne sayısına dayanan bir plan, hiç kullanılmayan kodu uyarlamak için emek harcayabilir; kritik bir süreci taşıyan küçük bir nesneyi ise gözden kaçırabilir.
Bir envanter hangi boyutlarla karar verilebilir hâle gelir?
Dört boyut birlikte değerlendirildiğinde envanter karar üretir: kullanım kanıtı, iş sahipliği, teknik bağımlılık ve değişiklik riski. Bu boyutlardan biri eksik kaldığında karar o boyutun varsayımına dayanır. Varsayım da kayda geçirilmediği sürece daha sonra kanıt gibi okunabilir ve yanlış bir karara dayanak olabilir.
| Boyut | Cevaplanan soru | Tipik kanıt |
|---|---|---|
| Kullanım | Bu kod gerçekten çalışıyor mu, ne sıklıkla? | Çalışma zamanı kullanım kayıtları |
| Sahiplik | Hangi süreç ve hangi ekip bu koda ihtiyaç duyuyor? | Süreç sahibiyle yapılan doğrulama |
| Bağımlılık | Kod hangi standart nesnelere, arayüzlere ve diğer özel nesnelere bağlı? | Statik analiz ve kullanım yeri listeleri |
| Değişiklik riski | Kod veya bağlı olduğu nesneler değişirse ne bozulur? | Kod kontrol bulguları, test kapsamı, değişiklik geçmişi |
Çalışıyor olması, gerekli olduğu anlamına gelir mi?
Hayır. Bir programın düzenli çalışması, iş sürecinin ona hâlâ ihtiyaç duyduğunu kanıtlamaz. Zamanlanmış bir iş, kimsenin okumadığı bir rapor üretiyor olabilir; bir arayüz, artık kullanılmayan bir sisteme veri taşıyor olabilir. Kullanım kanıtı ancak iş sahibinin doğrulamasıyla birlikte gereklilik kanıtına dönüşür.
Tersi de geçerlidir: seyrek çalışan kod gereksiz değildir. Yıl sonu kapanışında veya yasal bir bildirimde bir kez çalışan bir nesne, kısa bir ölçüm penceresinde hiç görünmeyebilir. Bu nedenle kullanım verisinin kapsadığı dönem envanterde açıkça yazılır.
Statik kanıt ile çalışma zamanı kanıtı neden ayrı tutulur?
Statik kanıt, kodun ne yapabileceğini ve neye bağlı olduğunu gösterir; kod çalıştırılmadan kaynak üzerinden elde edilir. Çalışma zamanı kanıtı ise kodun gerçekte ne kadar ve hangi koşullarda çalıştığını gösterir. İkisi farklı soruları cevaplar ve birbirinin yerine geçmez; karar için ikisine birlikte bakılır.
Statik analiz, kullanılmayan bir nesnede de bulgu üretir; çalışma zamanı verisi ise ölçülen dönemin dışında kalan kullanımı göstermez. Karar tablosunda her iki kanıt türü ayrı sütunlarda tutulur ve hangisinin eksik olduğu görünür kalır.
Kod kontrol aracı çıktısı neden kararın tamamı değildir?
SAP, ABAP Test Cockpit (ATC) aracını ABAP kodunun ve ilgili depo nesnelerinin statik ve dinamik kalite kontrolü için bir araç olarak tanımlar [1]. SAP S/4HANA® yazılımına geçiş bağlamında sadeleştirilmiş SAP nesnelerinin kritik kullanımlarını bulmaya yardımcı kontroller de sunulur [2]. Bu çıktılar değerlidir; ancak bir bulgunun iş açısından önemini, kodun kullanılıp kullanılmadığını veya kime ait olduğunu söylemez.
Ayrıca aracın kapsamı sürüme bağlıdır. SAP belgelerine göre eski sürümlerde bazı kontroller bulunmayabilir; bu durumda kodun daha güncel bir merkezi kontrol sisteminden uzaktan analiz edilmesi mümkündür [3]. ATC iş akışı, bulgular için muafiyet talep etme ve onaylama adımlarını da içerir [3]. Muafiyetlerin gerekçesi envanterde kaydedilmezse, aynı karar sonraki değerlendirmede yeniden tartışılır.
Clean Core bağlamında envanter neyi gösterir?
SAP’nin clean core genişletme modeli, genişletmeleri SAP Cloud ERP Private bağlamında dört seviyede sınıflandırır [5]. Level A yalnız yayımlanmış arayüzleri ve genişletme noktalarını kullanır; Level D ise önerilmeyen nesneleri veya teknikleri kullanır [4][5]. SAP belgesine göre ATC bulgu önceliği bu seviyelerle eşleşir: Level A’da bulgu yoktur, Level D’de öncelik 1 bulgu oluşur [4][5].
Bu sınıflandırma envantere yükseltme riski açısından bir eksen ekler; ancak kullanım ve sahiplik boyutlarının yerini tutmaz. Level D’de sınıflanan bir nesne hiç kullanılmıyorsa ilk karar onu uyarlamak değil, emekliye ayırmayı değerlendirmek olabilir. Modelin ayrıntısı ve ürün kapsamı Clean Core yaklaşımında genişletme kararı rehberindedir.
Gerçek ürün ekranı
Ekranı okumak için yatay kaydırın ya da görseli seçip tam boyutta açın.
Ekranda görülen Geliştirme ortamının proje gezgininde “Released Objects” (yayımlanmış nesneler) ağacı: nesneler türlerine göre gruplanmış ve sayılarıyla listelenmiş.
Açıkladığı karar Envanterdeki bir nesnenin yalnız yayımlanmış nesnelere dayanıp dayanmadığı bu listeyle karşılaştırılarak görülür; Clean Core değerlendirmesi bu ayrımı temel alır.
Veri durumu Görselde iş verisi yok; yalnız nesne kategorileri ve sayıları görünür. Proje adı kaynak görselde SAP tarafından gizlenmiştir.
Ürün: ABAP Development Tools Kaynak: SAP-samples/abap-cheat-sheets © 2022 SAP SE or an SAP affiliate company and abap-cheat-sheets contributors Lisans: Apache License 2.0, değiştirilmeden kullanılmıştır
Teknik borç ve dönüşüm önceliği nasıl ilişkilendirilir?
Teknik borç, bugünkü çözümün gelecekte değişikliği pahalılaştıran kısmıdır. Envanterde her teknik borç kalemi, hangi kararı zorlaştırdığıyla birlikte kaydedilir: yükseltmeyi mi, bir süreci değiştirmeyi mi, yoksa bir sistemi devreden çıkarmayı mı? Bağlandığı karar belirtilmeyen teknik borç, önceliklendirme listesinde yalnızca bir sayı olarak kalır.
Dönüşüm önceliği bu nedenle yalnız bulgu yoğunluğuna göre değil, kritik süreçle ilişkiye ve değişiklik riskine göre belirlenir. Bakım takvimi de bir planlama girdisidir. Hangi ürün kapsamında hangi tarihlerin geçerli olduğu, kaynaklarıyla birlikte Dönüşüm öncesi teknik belirsizlikler rehberinde verilmiştir.
Yönetim kararı için hangi çıktılar anlamlıdır?
Yönetim için anlamlı olan, nesne sayısından çok karar sınıflarının dağılımı ve hâlâ karar bekleyen konulardır. Bu çıktılar, yönetimden beklenen kararları henüz kanıt bekleyen konulardan ayırır; böylece yönetim, teknik ayrıntıya girmeden önceliği kendisi belirleyebilir. Bir envanterin sonunda en az şu çıktılar beklenir:
- karar sınıfına göre dağılım: koru, uyarla, standarda dön, emekliye ayır, incele
- sahibi belirlenemeyen nesneler ve bunların bağlı olduğu süreçler
- kullanım kanıtı olmayan ancak kritik bir süreçle ilişkili görünen nesneler
- yükseltme veya dönüşümü doğrudan etkileyen bulgular
- varsayıma dayanan kararların listesi ve bunları doğrulayacak adımlar
Envanteri oluşturma yöntemi ve sınıflandırma ölçütleri Özel kod envanterinin değerlendirilmesi rehberinde ayrıntılı olarak ele alınmıştır.
Diyagramın metin açıklaması
Başlangıç: ham nesne listesi; ad taşımayan program, sınıf, tablo ve arayüz işaretleri. Satır sayısı iş yükü hakkında fikir verir, kararı belirlemez. Birlikte bir iş işlevini yerine getiren nesneler üç kesikli karar birimi içinde gruplanır; hiçbir birime yerleşmeyen nesneler ayrı bir listede kalır ve omurgaya bağlanmaz. Her karar birimi aynı kanıt standardından geçer: kullanım kanıtı (ölçüm dönemiyle; kullanım kaydının olmaması yalnız ölçülen dönemde görülmediğini gösterir), iş sahipliği, yönüyle bağımlılıklar, değişiklik sıklığı, kritik süreç ilişkisi ve teknik risk (kod kontrol bulguları kontrol varyantı ve tarihiyle). Omurga karar noktası 1'e iner: kanıt tam ve tutarlı mı? Tamsa birim dört sonuç sınıfından birine gider: koru, uyarla, standarda dön veya emekliye ayır; her sınıfın sonraki adımı yazılıdır. Kanıt eksik veya çelişkiliyse birim zorla bir sınıfa sokulmaz; kesikli yol 'incele' düğümüne gider ve eksik kanıt ile karar sahibi belirlenir. Öncelik, kritik süreç ilişkisi ve teknik risk birlikte değerlendirilerek belirlenir. Döngü yoktur. Nesneler temsilîdir ve ad taşımaz; diyagram bir tablo veya envanter ekranı değildir. Mobilde diyagram üç sıralı panelde okunur: 1/3 ham nesnelerden karar birimlerine, 2/3 aynı kanıt standardı, 3/3 karar sınıfı. Künye: Castintech, D2, Eylül 2026; teknik anlatım diyagramı, SAP® ürün arayüzü değildir.
Bu sayfa neyi iddia etmiyor?
Bu sayfa genel teknik açıklamadır. Belirli bir envanterin sonucunu, kod miktarını veya dönüşüm süresini tahmin etmez. Hiçbir aracın tek başına bir envanter kararı ürettiğini iddia etmiyoruz. Ürüne ve sürüme bağlı bilgiler kaynak ve son doğrulama tarihiyle verilmiştir; kendi ortamınızda ayrıca doğrulanmalıdır.
Sık sorulan sorular
Envanter için en az ne kadarlık kullanım verisi gerekir?
Tek bir süre her kurum için doğru değildir. Ölçüm penceresi, dönemsel süreçleri (ay sonu, çeyrek sonu, yıl sonu kapanışı gibi) kapsayacak biçimde seçilir. Kapsanmayan dönemler envanterde açıkça yazılır ve o dönemlere bağlı nesneler için karar iş sahibiyle doğrulanır.
Kullanılmayan kod hemen silinebilir mi?
Kullanım kaydının olmaması tek başına yeterli değildir. Ölçüm penceresinin dışında kalan bir kullanım, başka bir koddan dolaylı çağrı veya yasal saklama gereksinimi olabilir. Önce iş sahibiyle doğrulama yapılır; ardından geri alınabilir bir emekliye ayırma adımı planlanır.
ATC bulgusu olmayan kod sorunsuz mudur?
Hayır. Bulgu olmaması, kullanılan kontrol varyantının aradığı sorunların bulunmadığını gösterir. Kontrol kapsamı dışındaki mantık hataları, performans davranışı veya iş kuralı uyumu ayrıca değerlendirilir.
Envanteri kim sahiplenmeli?
Envanterin teknik kısmını geliştirme ekibi çıkarabilir; ancak sahiplik ve gereklilik kararları süreç sahiplerinden gelir. Bu iki rolün ayrı ayrı adlandırıldığı bir envanter, karar sürecinde daha az geri dönüş üretir.
Envanter bir kez yapılınca yeterli olur mu?
Hayır. Yeni geliştirmeler, yükseltmeler ve süreç değişiklikleri envanteri eskitir. Envanterin hangi tarihte ve hangi kanıtla güncellendiği kaydedilir; karar anında bu tarih kontrol edilir.
İlgili rehberler ve sayfalar
- Özel kod envanterinin değerlendirilmesi: sınıflandırma ve önceliklendirme yöntemi
- Clean Core yaklaşımında genişletme kararı: seviye modelinin kapsamı ve yükseltme etkisi
- Dönüşüm öncesi teknik belirsizlikler: bakım takvimi bilgilerinin doğru kapsamla kullanımı
- Entegrasyon yaklaşımı
- Çalışma yaklaşımımız
Kaynakça
Metindeki köşeli parantez içindeki numaralar aşağıdaki kaynaklara işaret eder.
- 1
Quality Checking with the ABAP Test Cockpit (ATC) — help.sap.com, ABAP platform belgeleri.
Kaynak tarihi: belge sürümü 2025 FPS01 (Şubat 2026) Son doğrulama: 23.09.2026
- 2
Static Code Checks in the Context of an SAP S/4HANA Migration — help.sap.com, ABAP platform belgeleri.
Kaynak tarihi: belge sürümü 2025 FPS01 (Şubat 2026) Son doğrulama: 23.09.2026
- 3
Usage Scenario and Technical Requirements — help.sap.com, ABAP platform belgeleri.
Kaynak tarihi: belge sürümü 2025 FPS01 (Şubat 2026) Son doğrulama: 23.09.2026
- 4
Extensibility — help.sap.com, SAP Cloud ALM uygulama yardımı.
https://help.sap.com/docs/cloud-alm/applicationhelp/extensibility
Kaynak tarihi: sayfada belirtilmemiş Son doğrulama: 23.09.2026
- 5
Clean core extensibility: Creating scalable, upgrade-ready extensions for the Autonomous Enterprise — SAP beyaz kitabı, bölüm 3.3 (s. 19–22).
https://www.sap.com/docs/download/2024/09/20aece06-d87e-0010-bca6-c68f7e60039b.pdf
Kaynak tarihi: belgede açık yayın tarihi yok; s. 52’de “(08/26)” ve “© 2026” ibaresi var Son doğrulama: 23.09.2026
Son doğrulama: 23 Eylül 2026
SAP, ABAP, and SAP S/4HANA are the trademarks or registered trademarks of SAP SE or its affiliates in Germany and in other countries.
Bu içerik Castintech tarafından bağımsız olarak hazırlanmıştır.
Bağımsızlık notu
- Castintech, SAP SE ile ortaklık, yetkilendirme, onay veya sponsorluk ilişkisi iddia etmez.
- SAP ve bu sayfada geçen SAP ürün adları, SAP SE’nin veya iştiraklerinin ticari markalarıdır.
- Castintech’in sunduğu çalışma, bağımsız teknik danışmanlık ve destek kapsamındadır.