Teknik rehber
Özel kod envanteri dönüşüm ve bakım kararları için nasıl anlamlı hâle getirilir?
Envanter, her özel kod birimi için aynı soruları aynı kanıt standardıyla cevapladığında anlamlı hâle gelir: kullanılıyor mu, kime ait, neye bağlı, ne sıklıkla değişiyor, hangi kritik süreci taşıyor ve teknik riski ne? Bu cevaplar bir karar sınıfına bağlanır; sınıflandırılamayan birimler de ayrı bir listede görünür kalır.
- Hazırlayan Castintech
- Son doğrulama 23 Eylül 2026
- 9 dk okuma
- Kaynakça
Bu rehberde
Bölümler
Kapsam. Bu rehber, SAP® yazılımı üzerinde ABAP® programlama diliyle geliştirilmiş özel kod için genel bir envanter yöntemidir. Kullanılabilecek analiz araçları ve kontroller ürün ve sürüme göre değişir; rehberde anılan SAP araçlarının kendi ortamınızda bulunduğu ve hangi kapsamda çalıştığı ayrıca doğrulanmalıdır. Envanterin neden yalnız bir nesne listesi olmaması gerektiğinin kısa açıklaması Özel kod envanteri ve teknik borç yaklaşımı sayfasındadır.
Envanterin birimi neden nesne değil, işlev olmalıdır?
Tek tek nesneler üzerinden karar vermek zordur; çünkü bir iş işlevi çoğu zaman bir program, ona bağlı sınıflar, tablolar ve arayüzlerden oluşan bir gruptur. Bu grubun bir parçasını emekliye ayırıp diğerini korumak genellikle anlamsızdır. Envanterde karar, bu işlevsel grup, yani karar birimi üzerinden verilir; nesneler ise birimin altında listelenir.
Karar birimi yaklaşımı, iş sahibiyle konuşmayı da kolaylaştırır. Süreç sahibi bir nesne adını tanımaz; ancak “sipariş onayında kullanılan ek kontrol” gibi bir işlev tanımını tanır ve ona ihtiyaç olup olmadığını söyleyebilir.
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.
Adım 1: Karar birimleri nasıl belirlenir?
İlk adımda nesneler, birlikte bir iş işlevini yerine getiren gruplara ayrılır. Gruplama için nesnelerin bulunduğu geliştirme yapısı, adlandırma kuralları, çağrı ilişkileri ve ortak kullanılan tablolar birlikte değerlendirilir. Hiçbir gruba yerleşmeyen nesneler ayrı bir “birimsiz nesneler” listesinde tutulur; bu liste çoğu zaman eski denemelerin ve kalıntıların bulunduğu yerdir.
Her birim için kısa bir işlev tanımı yazılır. Tanım, teknik olmayan bir okuyucunun anlayabileceği dilde olur ve hangi süreçte kullanıldığını belirtir.
Adım 2: Kullanım kanıtı nasıl toplanır?
Kullanım kanıtı, çalışma zamanında kaydedilen kullanım verisinden gelir ve her zaman bir ölçüm dönemiyle birlikte yazılır. Dönem; ay sonu, çeyrek sonu ve yıl sonu kapanışı gibi dönemsel süreçleri kapsamıyorsa, bu süreçlere bağlı birimler için kullanım yokluğu kanıt sayılmaz. Kapsanmayan dönem envanterde açıkça belirtilir.
Kullanım verisi yorumlanırken dikkat edilecekler:
- zamanlanmış işler, kullanıcı olmadan da düzenli çalışır; çalışmaları iş ihtiyacını kanıtlamaz
- başka sistemlerden çağrılan arayüzler, kullanıcı ekranlarında görünmez
- bir birimin bir parçası çalışırken diğer parçası hiç çalışmıyor olabilir
- test ve geliştirme sistemlerindeki kullanım, canlı kullanımla karıştırılmaz
Adım 3: İş sahipliği nasıl doğrulanır?
Her karar birimi için bir süreç sahibi bulunur ve birimin hâlâ gerekli olup olmadığı ona sorulur. Teknik ekip kodun ne yaptığını açıklayabilir; ancak işin buna ihtiyacı olup olmadığına süreç sahibi karar verir. Sahibi bulunamayan birimler ayrı bir karar konusu olarak yönetime taşınır.
Süreç sahibine sorulacak sorular:
- Bu işlev bugün hangi iş sonucunu destekliyor?
- Bu işlev olmasaydı süreç nasıl yürürdü?
- Standart bir yetenek bu ihtiyacı artık karşılıyor olabilir mi?
- Bu işlevin sahipliğini kim üstlenecek?
Adım 4: Bağımlılıklar nasıl çıkarılır?
Bağımlılıklar statik analizle, yani kod çalıştırılmadan kaynak üzerinden çıkarılır. Her birim için üç yön kaydedilir: birimin kullandığı standart nesneler, birimin kullandığı veya onu kullanan diğer özel nesneler ve birimin dış sistemlerle arayüzleri. Yönü belirtilmeyen bir bağımlılık listesi, bir değişikliğin neyi etkileyeceğini söyleyemez.
Standart nesnelere bağımlılık, yükseltme ve dönüşüm riskinin ana kaynağıdır. Diğer özel nesnelere bağımlılık ise emekliye ayırma kararlarını etkiler: kullanılmıyor görünen bir birim, başka bir birimin çağırdığı bir yardımcı işlevi içeriyor olabilir.
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 Bağımlılıklar çıkarılırken kullanılan her standart nesnenin bu listede yer alıp almadığı ayrı bir alan olarak kaydedilir; yayımlanmamış nesneye bağımlılık, teknik risk değerlendirmesinin girdisidir.
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
Adım 5: Değişiklik sıklığı ve kritik süreç ilişkisi neden eklenir?
Değişiklik geçmişi iki şey söyler: birimin canlı bir ihtiyaca hizmet edip etmediği ve her değişiklikte ne kadar risk taşıdığı. Sık değişen bir birim hem gerekli olma olasılığı yüksek hem de her yükseltmede dikkat isteyen bir birimdir. Uzun süredir değişmeyen bir birim ise kararlı olabilir veya unutulmuş olabilir; ayrım yine kullanım ve sahiplik kanıtıyla yapılır.
Kritik süreç ilişkisi, birim çalışmazsa ne olacağını yazar: sipariş, sevkiyat, faturalama veya yasal bildirim gibi bir süreç durur mu, gecikir mi, yoksa yalnız bir rapor mu eksik kalır? Bu bilgi, teknik riskle birlikte önceliği belirleyen ana eksendir.
Adım 6: Teknik risk nasıl değerlendirilir?
Teknik risk birden fazla kaynaktan birleştirilir. SAP, ABAP Test Cockpit (ATC) aracını ABAP kodunun statik ve dinamik kalite kontrolü için bir araç olarak tanımlar [1]; ATC performans, güvenlik, sözdizimi ve adlandırma kuralları gibi konuları denetler [2]. 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 bulgulara şu bilgiler eklenir:
- clean core seviyesi (SAP Cloud ERP Private bağlamında tanımlanan A–D modeli kullanılabiliyorsa) [4][5]
- otomatik test kapsamı
- belgelerin varlığı ve güncelliği
- birimi tanıyan kişi sayısının az olması gibi bilgi yoğunlaşması riskleri
SAP belgelerine göre eski sürümlerde bazı kontroller bulunmayabilir ve bu durumda kod daha güncel bir merkezi kontrol sisteminden uzaktan analiz edilebilir [3]. Hangi kontrol varyantının kullanıldığı her bulgu kaydında yazılır; aksi hâlde farklı zamanlarda alınan sonuçlar karşılaştırılamaz.
Sınıflandırma ve önceliklendirme nasıl yapılır?
Her karar birimi, toplanan kanıtlara göre bir karar sınıfına yerleştirilir. Sınıflar, yapılacak işi tarif eder; teknik bulgu sayısını değil. Beş sınıf kullanılır: koru, uyarla, standarda dön, emekliye ayır ve incele. Kanıtı eksik veya çelişkili olan birimler zorla bir sınıfa sokulmaz; “incele” sınıfında kalır.
| Karar sınıfı | Tipik koşul | Sonraki adım |
|---|---|---|
| Koru | Kullanılıyor, sahibi var, teknik riski kabul edilebilir | Belgeyi güncelle, izlemeye devam et |
| Uyarla | Kullanılıyor ve gerekli; yükseltme veya dönüşümü etkileyen bulgusu var | Uyarlama kapsamını ve testini planla |
| Standarda dön | İhtiyaç sürüyor; standart yetenek artık karşılıyor olabilir | Standart çözümü doğrula, geçişi planla |
| Emekliye ayır | Kullanım kanıtı yok ve süreç sahibi gerekmediğini doğruladı | Geri alınabilir bir kaldırma adımı planla |
| İncele | Kanıt eksik veya çelişkili; sahibi bulunamadı | Eksik kanıtı ve karar sahibini belirle |
Önceliklendirmede iki eksen birlikte kullanılır: kritik süreç ilişkisi ve teknik risk. Her ikisi de yüksek olan birimler ilk sıraya alınır. Kritik süreç ilişkisi yüksek ama teknik riski düşük olanlar korunur ve izlenir. Teknik riski yüksek ama kritik süreçle ilişkisi düşük olanlarda önce emekliye ayırma veya standarda dönme seçenekleri değerlendirilir.
Envanter çıktısı neyi söyleyemez?
Envanter güçlü bir karar aracıdır, ancak sınırları vardır ve bu sınırlar çıktıda açıkça yazılmalıdır:
- Kullanım kaydının olmaması, kullanılmadığının kesin kanıtı değildir; yalnız ölçülen dönemde görülmediğini gösterir.
- Bulgu sayısı iş yükünü tek başına göstermez; aynı bulgu türü farklı birimlerde çok farklı emek gerektirebilir.
- Statik analiz iş kuralının doğru olup olmadığını söylemez.
- Envanter bir anın fotoğrafıdır; yeni geliştirmeler ve yükseltmeler onu eskitir.
- Araç çıktısı, kullanılan kontrol varyantı ve sürümle sınırlıdır.
Envanter kaydında hangi alanlar bulunmalı?
| Alan | Açıklama |
|---|---|
| Karar birimi | İşlevsel grup adı ve kısa işlev tanımı |
| Nesneler | Birime ait nesnelerin listesi |
| Süreç ve iş sahibi | Birimin hizmet ettiği süreç ve sahibi |
| Teknik sahip | Birimi tanıyan ve değişikliğinden sorumlu kişi veya ekip |
| Kullanım kanıtı | Kullanım durumu ve ölçüm dönemi |
| Bağımlılıklar | Standart nesneler, diğer özel nesneler, arayüzler (yönüyle) |
| Değişiklik geçmişi | Son değişiklik ve değişiklik sıklığı |
| Kritik süreç ilişkisi | Birim çalışmazsa ne olur |
| Teknik bulgular | Bulgu özeti, kullanılan kontrol varyantı ve tarih |
| Karar sınıfı | Koru, uyarla, standarda dön, emekliye ayır, incele |
| Kanıt türü ve varsayımlar | Kararın dayandığı kanıt ve doğrulanmamış varsayımlar |
| Karar tarihi ve onaylayan | Kararın ne zaman ve kim tarafından verildiği |
Sık yapılan yanlış varsayımlar
- “Nesne sayısı iş yükünü gösterir.” Göstermez. İş yükü, karar sınıflarına ve her sınıftaki birimlerin karmaşıklığına bağlıdır.
- “Kullanılmayan kod risk taşımaz.” Taşıyabilir: güvenlik açığı içerebilir, yükseltme kontrollerinde bulgu üretir ve envanteri kalabalıklaştırır.
- “Geçiş kontrolleri envanterin yerine geçer.” Geçiş kontrolleri belirli uyumsuzlukları bulur; kullanım, sahiplik ve gereklilik sorularını cevaplamaz.
- “Teknik ekip envanteri tek başına tamamlayabilir.” Gereklilik ve sahiplik kararları süreç sahiplerinden gelir.
- “Bir kez sınıflandırılan birim aynı sınıfta kalır.” Süreç, sürüm ve standart yetenek değiştikçe sınıf da değişebilir.
Kontrol listesi
- Nesneler karar birimlerine gruplandı; birimsiz nesneler ayrı listede
- Her birim için teknik olmayan bir işlev tanımı yazıldı
- Kullanım kanıtı ölçüm dönemiyle birlikte kaydedildi; kapsanmayan dönemler belirtildi
- Her birim için süreç sahibi bulundu veya bulunamadığı kayda geçti
- Bağımlılıklar yönüyle birlikte çıkarıldı
- Değişiklik geçmişi ve kritik süreç ilişkisi eklendi
- Teknik bulgular kontrol varyantı ve tarihle birlikte kaydedildi
- Her birim bir karar sınıfına yerleştirildi
- Önceliklendirme iki eksenle yapıldı
- Varsayımlar ve envanterin sınırları çıktıda yazıldı
Sınır notları
Bu rehber genel teknik açıklamadır. SAP araçları ve kontrolleri hakkındaki bilgiler kaynakçadaki belgelere dayanır ve sürüme bağlıdır. Karar birimi yaklaşımı, karar sınıfları ve önceliklendirme eksenleri Castintech’in değerlendirme çerçevesidir; SAP’nin görüşü olarak okunmamalıdır. Bu rehber belirli bir envanterin süresini veya sonucunu tahmin etmez.
Sık sorulan sorular
Nesne bazında çalışmak yanlış mı?
Yanlış değildir; teknik analiz zaten nesne düzeyinde yapılır. Ancak karar, iş işlevini oluşturan nesne grubunun tamamı için verilmelidir. Aksi hâlde bir işlevin bir parçası emekliye ayrılırken diğer parçası korunabilir.
Sahibi bulunamayan kod için ne yapılmalı?
Sahipsizlik kendi başına bir karar konusudur ve yönetime taşınır. Karar verilene kadar birim “incele” sınıfında kalır. Kullanım kanıtı da yoksa, geri alınabilir bir devre dışı bırakma denemesi bir seçenek olarak değerlendirilebilir.
Envanter ne kadar ayrıntılı olmalı?
Verilecek kararla orantılı olmalıdır. Bir dönüşüm kapsamını belirlemek için karar birimi düzeyi çoğu zaman yeterlidir; uyarlama işini planlamak için ise uyarla sınıfındaki birimlerin nesne düzeyinde incelenmesi gerekir.
SAP S/4HANA geçiş kontrolleri envanterin yerine geçer mi?
Hayır. Bu kontroller, sadeleştirilmiş SAP nesnelerinin kritik kullanımlarını bulmaya yardımcı olur [2]. Bir birimin kullanılıp kullanılmadığını, kime ait olduğunu veya hâlâ gerekli olup olmadığını söylemez; bu sorular envanterin diğer boyutlarıyla cevaplanır.
Envanterden iş yükü tahmini çıkarılabilir mi?
Yön gösterici bir tahmin çıkarılabilir; kesin bir tahmin çıkarılamaz. Tahmin, karar sınıflarının dağılımına ve açıkça yazılmış varsayımlara dayanmalı; varsayımlar doğrulandıkça güncellenmelidir.
İlgili sayfalar ve rehberler
- Özel kod envanteri ve teknik borç yaklaşımı: envanterin neden bir karar aracı olduğu
- Clean Core yaklaşımında genişletme kararı: seviye modeli ve yeni genişletmelerin değerlendirilmesi
- Dönüşüm öncesi teknik belirsizlikler: envanterin dönüşüm planındaki yeri
- Tüm teknik rehberler
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.