Üretim sisteminde yapılan her değişiklik, değiştirilen bileşenin ötesine uzanan sonuçlar doğurur. Paylaşılan bir fonksiyonda yapılan bir değişiklik, önceki davranışına bağlı olan çağırıcıları bozar. Bir veritabanı şema değişikliği, değiştirilen sütuna referans veren her sorguyu sessizce geçersiz kılar. Bir COBOL copybook güncellemesi, onu içeren her programın yeniden derlenmesini gerektirir; bu da düzinelerce iş akışında yüzlerce programı kapsayabilir ve bunların tümünün üretime geçmeden önce test edilmesi gerekir. Etki analizinin yanıtladığı soru, bir değişikliğin sonuçları olup olmadığı değil, tam olarak hangi bileşenlerin etkilendiği, bunların değiştirilen öğeyle nasıl bağlantılı olduğu ve değişikliğin güvenli bir şekilde dağıtılabilmesi için tam doğrulama kapsamının ne olması gerektiğidir.
Kullanıcılar fark etmeden önce senkronizasyon hatalarını tespit edin.
SMART TS XL Veriler arasındaki tüm ilişkileri haritalandırarak ekibinizin arama sonuçlarına ulaşmadan önce kalite hatalarını tespit etmesini sağlar.
Daha fazla bilgi edinEtki analizi yapılmadan, bu soru tahmin yoluyla, değişikliği yapan geliştiriciye sorarak, tüm test paketini çalıştırıp hataların doğru şeylerde kümelenmesini umarak veya kullanıcılar hataları bildirdiğinde etkilenen bileşenleri keşfederek yanıtlanır. Etki analizi araçları, tahmin yerine yapısal kanıtlar sunar: kaynak kodunu ayrıştırır, bağımlılıkları eşler ve önerilen değişikliğin etkileyeceği her bileşenin numaralandırılmış bir listesini oluşturur. Bu kılavuzda ele alınan araçlar, statik analiz platformlarından test seçim motorlarına ve kurumsal bağımlılık eşleyicilerine kadar uzanır ve her biri etki analizi probleminin farklı bir boyutunu kapsar.
Yazılım Mühendisliğinde Etki Analizi Nedir?
Yazılım mühendisliğinde etki analizi, önerilen bir değişiklikten doğrudan veya dolaylı olarak etkilenen sistemin tüm bileşenlerini belirleme sürecidir. Şu soruyu yanıtlar: Bunu değiştirirsem, başka neler değişir? Uygulama öncesinde, planlama, tasarım ve değişiklik onayı sırasında çalışır; test veya olay müdahalesi sırasında değil.
Bu terim, analiz ettikleri konular ve zamanlama açısından farklılık gösteren, ancak birbiriyle ilişkili çeşitli faaliyetleri kapsamaktadır:
Etki analizini değiştir Önerilen kod değişikliğinin kapsamını, değişiklik yapılmadan önce belirler. Önerilen değişiklik sonucunda hangi modüllerin, fonksiyonların, veritabanı tablolarının ve bağımlı sistemlerin değiştirilmesi veya yeniden test edilmesi gerekeceğini tanımlar.
Test etki analizi (TIA) TIA, belirli bir kod değişikliğine hangi mevcut testlerin uygun olduğunu belirleyen, değişiklik etki analizinin özel bir uygulamasıdır. Tüm test paketini çalıştırmak yerine, TIA, değiştirilen kodu ve ona bağlı bileşenleri kapsayan minimum test alt kümesini seçerek, etkilenen kapsamı korurken test yürütme süresini azaltır.
Gereksinimlerin etki analizi Bir gereksinim değiştiğinde hangi gereksinimlerin, tasarım unsurlarının ve sonraki aşama teslimatlarının etkilendiğini belirler. Düzenlemeye tabi sektörlerde bu, değişen bir gereksinime bağlı olan her sonraki aşama ürününün güncellenmesini ve yeniden doğrulanmasını sağlar.
Üçünün de ortak bir temeli var: bileşenlerin birbirleriyle nasıl ilişkili olduğunu gösteren bir bağımlılık modeli ve bu modeli bir başlangıç noktasından (değiştirilen bileşen) dolaşarak ona bağlı olarak ulaşılabilen her şeyi listeleyen bir mekanizma.
Etki Analizinin Üç Türü
Etki analizi teknikleri, bağımlılık bilgilerini nasıl topladıklarına göre sınıflandırılır:
| Menşei | Yöntem | Neler Buluyor? | Ne zaman kullanılır? |
|---|---|---|---|
| Statik etki analizi | Kaynak kodu çalıştırmadan ayrıştırır. | Tüm sözdizimsel referanslar: fonksiyon çağrıları, içe aktarmalar, alan erişimleri, şema referansları | Uygulama öncesinde, değişiklik planlaması sırasında; her türlü kod tabanında çalışır. |
| Dinamik etki analizi | Kodun gerçek yürütme yollarını gözlemlemek için kullanılan araçlar. | Sadece test çalışması sırasında gerçekten çalıştırılan bileşenler | Çalışma zamanına özgü bağımlılıklar; statik analizin gözden kaçırabileceği yolları belirler. |
| Gereksinimlere dayalı (anlamsal) | Gereksinimler, tasarımlar ve kod arasındaki izlenebilirlik bağlantılarını takip eder. | Gereksinim değişikliğinden etkilenen yukarı ve aşağı yönlü unsurlar | Düzenlemeye tabi sektörler; sistem mühendisliği; güvenlik açısından kritik yazılımlar |
Statik etki analizi, çalışan bir sistem veya test altyapısı gerektirmeden yalnızca kaynak kod üzerinde çalıştığı için en yaygın kullanılan yöntemdir. Bu kılavuzdaki araçlar ve diğer kaynaklar tarafından kullanılan teknik de budur. SMART TS XL Kurumsal kod tabanı analizi için. Dinamik analiz, statik analizi tamamlayarak, statik analizin yalnızca kaynak koddan çözemediği dinamik olarak oluşturulmuş sorgular veya geç bağlantılı fonksiyon çağrıları gibi çalışma zamanı davranışlarını yakalar. Uygulamada, çoğu üretim etki analizi programı ikisini birleştirir: statik analiz temel bağımlılık haritasını sağlar ve dinamik profil oluşturma, gözlemlenen çalışma zamanı davranışına karşı bunu doğrular.
Statik ve Dinamik Darbe Analizi: Temel Farklar
Statik etki analizi muhafazakardır: kodda var olan ancak pratikte asla çalıştırılmayan bağımlılıkları dahil ederek etkilenen kapsamı abartabilir. Dinamik etki analizi gözlemlediği şeyler açısından hassastır ancak eksiktir; yalnızca izlenen oturum sırasında gerçekten çalıştırılanları yakalar, farklı girdiler veya yapılandırmalar altında çalıştırılan yolları kaçırır. Tamlığın hassasiyetten daha önemli olduğu üretim sistemleri için statik analiz daha güvenli bir varsayılan yöntemdir.
Etki Analizi Süreci: Adım Adım
Yapılandırılmış bir etki analizi süreci, kullanılan araçtan bağımsız olarak tutarlı bir sıra izler:
Adım 1: Değişikliği tanımlayın. Tam olarak neyin değiştiğini belirleyin: belirli işlev, alan, sınıf, modül, copybook veya veritabanı sütunu. Bu adımda gösterilen hassasiyet, bundan sonraki her şeyin doğruluğunu belirler. Belirsiz değişiklik tanımları ("ödeme modülünü değiştiriyoruz") belirsiz etki sonuçları doğurur.
Adım 2: Bağımlılık modelini oluşturun veya sorgulayın. Bağımlılık modeli, sistemdeki tüm bileşenler arasındaki ilişkileri temsil eder. Otomatik araçlar için bu model, kaynak kodun ayrıştırılmasıyla oluşturulur. Küçük sistemlerde manuel analiz için ise dokümantasyon olarak saklanabilir. Model güncel olmalıdır: eski bağımlılık dokümantasyonu, yanlış etki değerlendirmelerine yol açar.
3. Adım: Değişim noktasından başlayarak bağımlılık grafiğini dolaşın. Değiştirilen bileşenden başlayarak, gelen tüm bağımlılık kenarlarını (değiştirilen bileşene bağlı bileşenler) ve giden kenarları (değiştirilen bileşenin bağlı olduğu ve değişiklikten sonra farklı davranabilecek bileşenler) takip edin. Ulaşılabilir tüm bağımlı bileşenler numaralandırılana kadar geçişli olarak devam edin.
4. Adım: Etkilenen bileşenleri risk düzeyine göre sınıflandırın. Etkilenen tüm bileşenler eşit risk taşımaz. Değiştirilen bir işlevi doğrudan çağıran bir bileşen, beş bağımlılık seviyesi uzakta olan bir bileşenden daha yüksek risk taşır. Bulguları yakınlık, kritiklik ve test kapsamına göre sınıflandırarak iyileştirme çabalarını odaklayın.
Adım 5: Test kapsamını tanımlayın. Etki kümesi, etkilenen bileşenlerin tam listesi olup minimum test kapsamını tanımlar. Etki kümesindeki otomatik test kapsamı bulunmayan herhangi bir bileşen, test eklenerek veya manuel doğrulama yapılarak ele alınması gereken bir riski temsil eder.
Adım 6: Belgeleme ve inceleme. Etki değerlendirmesini, değişiklik onayının temeli olarak değişiklik danışma kuruluna (CAB) veya ilgili paydaşlara sunun. Risk sınıflandırmasıyla birlikte belirtilen etki kapsamı, geliştirici tahminlerinin yerini yapısal kanıtlarla alır.
Test Etki Analizi: CI/CD'de Nasıl Çalışır?
Test etki analizi (TIA), etki analizini özellikle test problemine uygular: bir kod değişikliği verildiğinde, hangi testlerin çalıştırılması gerekir? TIA olmadan, CI işlem hatları her commit'te tüm test paketini çalıştırır. 50,000 test içeren ve çalışması 45 dakika süren bir test paketine sahip bir kod tabanında, bu, her çekme isteğinin 45 dakika boyunca bloke olması anlamına gelir; bu nedenle geliştiriciler bunu atlatmaya çalışır, sonuçları beklemeden birden fazla commit gönderir ve testin sağlaması gereken geri bildirim döngüsünü kaybederler.
TIA, kod ve testler arasındaki eşleştirmeyi izleyerek bu sorunu çözüyor: hangi kod satırlarının hangi testler tarafından kapsandığını takip ediyor. Bir commit belirli satırları değiştirdiğinde, TIA yalnızca bu satırları ve bunlara bağlı öğeleri kapsayan testleri seçiyor. 50,000 dosyadan üçünü etkileyen bir değişiklik, 50,000 test yerine 200 test gerektirebilir. İşlem hattı dakikalar yerine saniyeler içinde tamamlanıyor.
Bu eşleme, test yürütmesini kapsama verilerini kaydetmek üzere izleyerek ve ardından bu kapsama verilerini kapsadığı koda göre indeksleyerek depolayarak oluşturulur. Her yeni commit'te TIA:
- Git diff çıktısından hangi dosyaların ve fonksiyonların değiştiğini belirler.
- Bu dosyaları ve işlevleri hangi testlerin kapsadığını kontrol eder.
- Değiştirilen kodun statik bağımlılık grafiğindeki herhangi bir bileşeni kapsayan testler ekler.
- Seçilen alt kümeyi çalıştırır; kalan tüm testler etkilenmemiş varsayılarak geçer.
TIA'yı uygulayan araçlar arasında Microsoft'un Visual Studio'daki Test Etki Analizi, Parasoft'un TIA motoru, Gradle'ın test seçimi ve Jest, pytest ve diğer test çalıştırıcıları için çeşitli CI entegre eklentileri yer almaktadır. TIA'nın doğruluğu, bağımlılık modelinin doğruluğuna bağlıdır; yalnızca bağımlılık geçişi olmadan doğrudan kod kapsamını izleyen bir araç, değişiklikten üç seviye uzaktaki bileşenleri kapsayan testleri gözden kaçıracaktır.
TIA Uygulamada: Öncesi ve Sonrası
Tipik bir kurumsal arka uç hizmetinde, TIA'yı etkinleştirmek, ortalama çekme isteğinde test yürütme süresini %60-80 oranında azaltır. Dezavantajı ise, paylaşılan yardımcı programları, temel sınıfları veya yaygın olarak kullanılan yapılandırmaları etkileyen çok büyük değişikliklerin yine de büyük test alt kümelerini tetikleyebilmesidir. TIA, değişikliklerin yerelleştirildiği özellik geliştirme ve hata düzeltmeleri için en büyük değeri sağlar. Çerçeve yükseltmeleri veya paylaşılan şema değişiklikleri gibi çapraz kesen değişiklikler için, tam bir test çalıştırması daha güvenli bir seçenektir.
Gereksinim ve Değişim Yönetiminde Etki Analizi
Sistem mühendisliği ve düzenlemeye tabi yazılım geliştirmede, etki analizi kodun ötesine geçerek tüm yapıt zincirini kapsar: gereksinimler, tasarım özellikleri, test senaryoları, risk değerlendirmeleri ve doğrulama kanıtları. Değişen bir gereksinim yalnızca kodu etkilemekle kalmaz, aynı zamanda bu gereksinimi uygulayan her tasarım öğesini, onu doğrulayan her test senaryosunu, onu varsayan her risk değerlendirmesini ve ona atıfta bulunan her uyumluluk belgesini de etkiler.
Gereksinim tabanlı etki analizi, bu alt kapsamı belirlemek için izlenebilirlik bağlantılarını kullanır. Her gereksinimi, onu uygulayan tasarım unsurlarına, test senaryolarına ve doğrulama kanıtlarına bağlayan bir izlenebilirlik matrisi, herhangi bir gereksinim değişikliğinin gerektirdiği yeniden doğrulamanın tüm kapsamını belirlemeyi mümkün kılar. Düzenlemeye tabi sektörlerde, FDA 21 CFR Bölüm 11 kapsamındaki tıbbi cihazlar, DO-178C kapsamındaki havacılık yazılımları, ISO 26262 kapsamındaki otomotiv yazılımları gibi sektörlerde, bu yeniden doğrulama kapsamı isteğe bağlı bir kalite uygulaması değil, yasal bir gerekliliktir.
Gereksinim etki analizi ile kod etki analizi arasındaki bağlantı izlenebilirliktir: Bir gereksinim belirli bir yazılım bileşenine kadar izlenebilir olduğunda ve bu bileşen kod düzeyinde bir etki analizinde tanımlandığında, etki analizi sonuçları, yeniden doğrulama çabasını bu bileşeni doğrulayan belirli test senaryolarına odaklamak için kullanılabilir. Jama Connect ve IBM DOORS dahil olmak üzere modern gereksinim yönetimi platformları bu izlenebilirliği destekler ve gereksinim düzeyinde yerleşik etki analizi yetenekleri sağlar.
Büyük ve Eski Kod Tabanları için Etki Analizi
Büyük kod tabanları, özellikle de on yıllar boyunca büyümüş kurumsal sistemler için etki analizi, 10,000 satırlık bir servis için yapılan etki analizinden niteliksel olarak farklıdır. Ölçek farklılıkları sadece niceliksel değildir. Büyük eski kod tabanları, yaşayan hiçbir ekip üyesinin tam olarak anlayamayacağı bağımlılık yapılarına sahiptir: paylaşılan veri kümeleri aracılığıyla örtük bağlantıya sahip binlerce program, yüzlerce program tarafından aynı anda dahil edilen copybook'lar, yalnızca çalışma zamanına özgü bağımlılıklar yaratan karmaşık koşullu yürütme mantığına sahip JCL iş akışları.
Büyük kod tabanlarının çeşitli özellikleri, manuel etki analizini güvenilmez hale getirir:
Örtük bağımlılıklar. COBOL sistemlerinde, 300 program tarafından dahil edilen bir copybook, onu aramayı bilmeyen herhangi bir geliştirici için görünmez bir bağımlılık yaratır. Bir alan yeniden adlandırması gibi görünen bir copybook üyesindeki değişiklik, 300 programın tamamının yeniden derlenmesini ve yeniden test edilmesini gerektirebilir. Otomatik analiz olmadan, bu kapsam aşamalı olarak keşfedilir ve her yeni hata, gözden kaçan başka bir bağımlılığı ortaya çıkarır.
Diller arası bağımlılıklar. Bir COBOL programı bir DB2 tablosuna yazıyor. Bir Java servisi aynı tablodan veri okuyor. Bir Python işlem hattı, Java servisinin çıktısını işliyor. DB2 şemasındaki bir değişiklik, üç katmanı da etkiliyor. Tek dilli hiçbir statik analiz aracı bu diller arası zinciri izleyemez; üç dili de birleşik bir bağımlılık modelinde anlayan ve birbirine bağlayan bir araca ihtiyaç duyar.
Veriler aracılığıyla dolaylı bağımlılıklar. Birbirini asla çağırmayan iki program, paylaşılan bir dosya aracılığıyla yine de birbirine bağlı olabilir. Program A, Veri Kümesi X'e yazıyor; Program B, Veri Kümesi X'ten okuyor. Veri Kümesi X'in yapısındaki bir değişiklik her ikisini de etkiliyor, ancak bağımlılık bir fonksiyon çağrısı değil, JCL DD ifadeleri ve COBOL FD tanımları aracılığıyla ifade edilen bir veri sözleşmesidir. Yalnızca fonksiyon çağrılarını izleyen yapısal analiz, bu tür bağımlılıkları tamamen gözden kaçırır.
Ölü kod ve erişilebilirlik. Büyük kod tabanları, tanımlanmış ancak asla çağrılmamış kodları, kaldırılan özelliklerden kalan fonksiyonları, yerini almış ancak silinmemiş prosedürleri biriktirir. Ölü kodu etkilenen kapsama dahil eden etki analizi, değişiklik kapsamını abartır ve test çabalarını üretimde asla ulaşılmayacak bileşenlere yönlendirir.
MKS miras modernizasyonu Bu ortamlar için analiz çözümü, tüm bu durumları ele almalıdır: kullanılan dilleri (COBOL, JCL, PL/I, RPG, Assembler ve DB2 dahil) ayrıştırmalı, paylaşılan veri yapıları aracılığıyla örtük bağımlılıkları çözmeli, diller arası zincirleri izlemeli ve erişilebilir kodu erişilemez koddan ayırt etmelidir.
Etki Analizi Araçları: Karşılaştırmaları
Aşağıdaki araçlar, yazılım geliştirmede etki analizinin ana kategorilerini kapsamaktadır. Her biri, neyi analiz ettiği, hangi dilleri desteklediği ve hangi etki analizi problem sınıfını en iyi şekilde ele aldığı açısından değerlendirilmiştir.
| araç | Birincil Yaklaşım | Diller | En |
|---|---|---|---|
| SMART TS XL | Statik + diller arası bağımlılık eşlemesi | COBOL, JCL, Java, Python, .NET, RPG, SQL | Kurumsal ve ana bilgisayar sistemlerinin çok dilli etki analizi |
| SciTools tarafından anlaşıldı | Statik analiz, çağrı grafikleri, bağımlılık görselleştirmesi | 70+ dil | Çok dilli kod anlama ve etki kümeleri |
| Yapı101 | Mimari analiz, bağımlılık grafikleri | Java, C#, JVM/.NET | Java/C# kurumsal uygulamalarında yapısal etki |
| CAST AIP | Uygulama zekası, teknik borç, etki | Java, .NET, COBOL, SQL | Portföy düzeyinde iş ve teknik etki analizi |
| Axivion Suite | C/C++ için anlamsal bağımlılık grafikleri | C, C ++ | Güvenlik açısından kritik sistemler, MISRA uyumluluğu, gömülü sistemler |
| parasoft | Test etki analizi, CI/CD entegrasyonu | Java, C/C++, .NET | TIA, düzenlemeye tabi sektörlerde, güvenlik açısından kritik testler. |
| Jama Bağlantısı | Gereksinimlerin izlenebilirliği, yapıt etkisi | Dil bağımsız (gereksinim düzeyi) | Sistem mühendisliği, düzenlemeye tabi sektörler, DO-178C/ISO 26262 |
| SonarQube | Kod kalitesi, bir dil içindeki bağımlılık analizi | 30+ dil | Kod kalitesi kontrol noktaları; sınırlı sistemler arası etki analizi |
| IntelliJ IDEA / Eclipse | IDE çağrı hiyerarşisi, referans analizi | Java, Kotlin, Python | Proje kapsamında geliştirici düzeyinde yerel etki analizi |
SciTools tarafından anlaşıldı Modern dillerde çalışan yazılım ekipleri için en kapsamlı özel etki analizi aracıdır. Etki Kümeleri özelliği, belirli bir değişiklikten etkilenen tüm kod varlıklarının, başlangıç noktasından bağımlılık grafiği üzerinden erişilebilen her fonksiyonun, sınıfın ve değişkenin geçişli kapanışını hesaplar. 70'ten fazla dili destekler ve ayrıntılı çağrı grafikleri, veri akış diyagramları ve varlık ilişkisi haritaları üretir.
Yapı101 Java ve C# mimari düzeyinde etki analizi için en güçlü araçtır. Paket ve sınıf bağımlılık yapısını etkileşimli haritalar olarak görselleştirir ve önerilen değişikliklerin mimari sınırları ihlal ettiği veya bağımlılık grafiğinde yeni döngüler oluşturduğu yerleri belirler.
CAST AIP Portföy düzeyinde faaliyet gösteren bu sistem, COBOL, Java, .NET, SQL ve diğer diller de dahil olmak üzere tüm uygulama ortamını analiz ederek teknik etki analizinin yanı sıra iş etkisi puanları üretir. Genellikle birleşme ve devralma durum tespiti ve portföy rasyonelleştirme programlarında kullanılır.
Axivion Suite Bu, etki analizinin düzenleyici gereklilikleri (ISO 26262, DO-178C, MISRA) karşılaması ve analizin tamamlandığına dair resmi kanıt üretmesi gereken, güvenlik açısından kritik C ve C++ geliştirme alanlarını hedeflemektedir.
parasoft Düzenlemeye tabi sektörler için en güçlü TIA çözümüdür; kod kapsamını ifade düzeyine kadar izleyen ve kesin bağımlılık taramasına dayalı olarak test alt kümelerini seçen, CI/CD entegre bir test seçim motoruna sahiptir.
SonarQube Proje içi bağımlılık analizi ve kod kusuru tespiti sağlar ancak sistemler arası veya diller arası etki analizi için tasarlanmamıştır. Etki analizi yığınındaki değeri, bağımlılık eşleyici olmaktan ziyade, hangi değiştirilmiş bileşenlerin yeni kalite veya güvenlik sorunları ortaya çıkardığını belirleyen bir kalite kontrol noktası olarak işlev görmesidir.
IDE tabanlı araçlar (IntelliJ çağrı hiyerarşisi, Visual Studio referans analizi, Eclipse çağrı grafiği) bir proje içindeki geliştirici odaklı yerel etki analizi sağlar. Bir değişikliğin bir modül içindeki etkilerini anlamada etkilidirler, ancak projeler arası, diller arası veya ana bilgisayar bağımlılıklarını izleyemezler.
Ne kadar SMART TS XL Etki Analizi Gerçekleştirir
SMART TS XL Ortamdaki her kaynak dosyayı, COBOL programlarını, JCL iş akışlarını, copybook'ları, SQL şemalarını, Java sınıflarını, Python modüllerini, RPG programlarını ve diğerlerini ayrıştırarak etki analizi gerçekleştirir ve tüm dillerdeki tüm yapısal ilişkileri temsil eden birleşik bir bağımlılık modeli oluşturur. Bu model temeldir: etki analizi, herhangi bir bileşenden başlayarak bağımlılık grafiğini dolaşarak etkilenen her şeyi listeleyen bir sorgudur.
Bir ekip COBOL copybook üyesinde değişiklik yapmayı önerdiğinde, SMART TS XL'S etki analizi Cevaplar: Bu copybook'u hangi programlar içeriyor? Bu programlardan hangileri hangi JCL iş adımları tarafından çağrılıyor? Bu programlar hangi DB2 tablolarını okuyor veya yazıyor? Bu tabloları hangi Java servisleri kullanıyor? Bu programları hangi test senaryoları kapsıyor? Cevap bir tahmin değil, dosya adları, program adları, iş adları ve satır numaralarıyla birlikte gerçek kod yapısından türetilmiş eksiksiz, numaralandırılmış bir listedir.
MKS uygulama bağımlılık eşlemesi Bu özellik, doğrudan ve dolaylı bağımlılıkları ayırt etmek ve en yüksek riskli bağlantıları vurgulamak için renk kodlaması kullanarak, değiştirilen bileşen merkezli bağımlılık grafiğinin görsel diyagramlarını oluşturur. Bu diyagramlar, CAB incelemesi için kanıt tabanı ve test planlaması için yol haritası görevi görür.
MKS JCL genişlemesi Bu özellik, analizden önce PROC'lardaki sembolik parametre ikamesini çözerek, bağımlılık modelinin çözümlenmemiş şablon referansları yerine gerçek çalışma zamanı yürütmesini yansıtmasını sağlar. Sembolik parametrelere bağlı olarak farklı programları çağıran bir PROC, tüm çağırıcılarında gerçekten çağırdığı tüm programlara çözümlenir; bu, sembolik parametrelerden habersiz araçların gözden kaçırdığı eksiksiz bir kapsama alanıdır.
Teknik durum tespiti yapan, eski sistemlerin modernizasyonunu planlayan veya birden fazla dil ve platformu kapsayan sistemlerdeki değişiklikleri yöneten kurumsal ekipler için, SMART TS XL'S kurumsal arama Bu özellik, bağımlılık modelini sorgulanabilir hale getirir: Belirli bir alanın her kullanımını, belirli bir işlevi çağıran her programı, belirli bir veri kümesi üreten her JCL işini, herhangi bir boyuttaki kod tabanında saniyeler içinde bulabilirsiniz.
Etki Analizi En İyi Uygulamaları
Etki analizine kod yazmadan önce başlayın, sonrasında değil. Etki analizinin amacı, bir değişiklik yapma kararını bilgilendirmek ve ortaya çıkan işin kapsamını belirlemektir; uygulama sonrasında nelerin bozulduğunu açıklamak değildir. Bir değişiklik zaten devam ederken yapılan etki değerlendirmesi, planlama aracı değil, sonradan yapılan bir gerekçelendirmedir.
Etki değerlendirmesinin sınırlarını açıkça tanımlayın. Büyük sistemlerdeki etki grafikleri neredeyse her şeyi kapsayacak şekilde genişleyebilir. Analizi çalıştırmadan önce analiz sınırını, maksimum bağımlılık derinliğini, hariç tutulan ölü kodu ve kapsam dışı sistemleri tanımlayın. Kısıtlamasız geçiş, teknik olarak doğru ancak operasyonel olarak işe yaramayan sonuçlar üretir.
Yeniden test edilmesi gereken durumlar ile izlenmesi gereken durumlar arasındaki farkı açıklayın. Etki kümesindeki her bileşen aynı test yanıtını gerektirmez. Kritik bir yolda değiştirilen işlevi doğrudan çağıran bir bileşen yeniden test edilmelidir. Nadiren çalıştırılan beş seviyeli kod aracılığıyla değiştirilen fonksiyona ulaşan bir bileşen üretim ortamında izlenebilir. Risk sınıflandırması, etki listesini bir test planına dönüştürür.
Bağımlılık modelini güncel tutun. Güncelliğini yitirmiş veya eksik bir bağımlılık modeline karşı yapılan etki analizi, hiç etki analizi yapılmamasından daha kötüdür, çünkü yanlış bir kapsamda yanlış bir güven duygusu yaratır. Bağımlılık modelleri, kod tabanında yapılan her önemli değişiklikte yeniden oluşturulmalı veya değiştirilen dosyaları otomatik olarak yeniden analiz eden bir CI/CD entegrasyonu aracılığıyla artımlı olarak güncellenmelidir.
Etki analizini değişiklik kontrolüyle birleştirin. Etki analizi, çıktısı resmi bir değişiklik kontrol sürecine dahil edildiğinde tam değerini gösterir. Kapsamı, risk sınıflandırmasını ve test gereksinimlerini belgeleyen bir etki raporu, değişiklik danışma kurullarına, geliştirici tahminlerine değil, gerçek sisteme dayalı yetkilendirme kararları alabilmeleri için ihtiyaç duydukları yapısal kanıtı sağlar.
Eski sistemler için, örtük veri bağlantısını dikkate alın. Eski bir sistem için yalnızca fonksiyon çağrılarını izleyen herhangi bir bağımlılık analizi eksiktir. Ana bilgisayar ortamlarında paylaşılan dosyalar, veri kümeleri, veritabanları ve mesaj kuyrukları aracılığıyla birbirine bağlı programlar yaygındır ve yalnızca fonksiyon çağrılarına dayalı analizde görünmezdir. Bağımlılık modeli, eksiksiz bir etki kapsamı oluşturmak için veri düzeyindeki bağlantıyı da hesaba katmalıdır.
Etki analizi altyapısına yapılan yatırım, ister özel bir araç aracılığıyla olsun, örneğin SMART TS XLParasoft gibi bir test etki analizi motoru veya Jama gibi bir gereksinim izlenebilirlik platformu, beklenmedik sorunlara yol açmayan değişikliklerin, tam test paketinin çalıştırılmasına gerek kalmayan testlerin ve olaylara neden olmayan dağıtımların maliyetiyle telafi edilir. Bu telafi varsayımsal değildir. Tespit edilmemiş bir bağımlılıktan kaynaklanan her üretim olayı, değişiklik yapılmadan önce gerçekleşmeyen analizin doğrudan maliyetidir.
