Yazılım kusurlarının kök neden analizi nasıl yapılır?

29 Temmuz 2021 Osman Selçok

Kök neden analizi, yazılım ekiplerinin kusurlarını nasıl düzeltebilecekleri konusunda önemli bir rol oynar. Kök neden analizinin nasıl kullanılacağı ve ekiplerin süreçten en iyi şekilde nasıl yararlanabileceği aşağıda açıklanmıştır.

Kurumsal yazılım, talimatlar, veriler, ilgili hizmetler ve bağımlılıkların karmaşık bir etkileşimini içerir. Yazılım kusurları ortaya çıktığında, kaçınılmaz olarak yaptıkları gibi, geliştiriciler bu aksaklıkların altında yatan nedenleri belirlemeli ve anlamalıdır.

Yazılım kusurları için kök neden analizi (RCA), geliştiricilerin bir hatanın neden oluştuğunu daha iyi anlamak ve iyileştirmeleri sağlamak için adımlar atmak için kullandığı bir yaklaşımdır. Süreç, bir tıbbi ekibin semptomları tedavi etmekten ziyade bir hastanın hastalığını nasıl teşhis etmek ve iyileştirmek istediğine benzer.

Geniş anlamda, kök neden analizi, kusurların veya başarısızlık olaylarının altında yatan nedenlerin nedenlerini belirleme sürecidir. Altta yatan neden netleştiğinde, ekip sorunu kaynağında düzeltebilir. Yazılım uzmanları süreci düzgün bir şekilde gerçekleştirdiğinde ekip, ürün tasarımı, test ve genel kaliteyi iyileştirmek için RCA sonuçlarını kullanabilir. Yazılım kusurları için kök neden analizinin bazı kurumsal faydalarına daha yakından bakalım.

Kusurlar nelerdir?

Yazılım geliştirme perspektifinden bakıldığında, bir kusur, yalnızca bir kodlama hatasından kaynaklanan bir hata mesajı veya sistem çökmesi değildir. Kusurlar, örneğin yazılımın kusursuz çalıştığı ancak kullanıcının beklediğini yapmadığı durumlar gibi, gerçek ve beklenen sonuç arasındaki herhangi bir sapmadır.

Bir kusur, bir yazılım gereksinimleri belirtiminde özetlenen beklentilerden bir sapmayı temsil eder. Canlı yazılımda, üretim öncesi testler işlevsel veya performans sorunlarını tespit edemediğinde de kusurlar oluşur. İşte altı örnek:

Orijinal yazılım gereksinimlerindeki hatalar, gözden kaçanlar veya boşluklar . Bu kusurlar, bir gereksinim atlandığında veya unutulduğunda, kötü ifade edildiğinde, paydaşlar tarafından gerektiği gibi anlaşılmadığında veya geliştiriciler tarafından yanlış anlaşıldığında ortaya çıkabilir.
Yazılımın tasarımındaki veya mimarisindeki hatalar. Bu problemler, yazılım tasarımcıları verimsiz bir yazılım algoritması veya süreci oluşturduğunda veya bu algoritma veya süreç, sonuçlarında gerekli kesinliği sağlamadığında ortaya çıkar.
Kodlama veya uygulamadaki hatalar. Bu kusurlar, eksik parantezlerden yanlış hata işlemeye kadar her şeyin neden olduğu geleneksel hataları içerir.
Test planlamasındaki veya test etkinliklerindeki hatalar. Bu kusurlar, yetersiz test edilmiş özelliklerden ve işlevlerden kaynaklanmaktadır.
Dağıtımdaki hatalar veya gözden kaçmalar. Bu kusurlara bir örnek, bir ekibin yetersiz VM kaynakları tedarik etmesi olabilir.
Bir ekibin geliştirme döngüsünü yönetmek için kullandığı süreç veya ilkelerdeki hatalar . Bu kusurlar, örneğin bir ekip, yeterli tasarım, kodlama veya test incelemesi olmadan onay veya onay aldığında ortaya çıkar.

Kök neden analizi sorunu keşfettiğinde, ekip kusuru düzeltmek ve gelecekteki oluşumlarını önlemek için proaktif adımlar atabilir. Kusur, örneğin tasarım hatasından kaynaklanıyorsa, geliştiriciler düzeltme yapmak için tasarım ve gereksinim belgelerini inceleyebilir. Hataya bir test hatası neden olduysa, geliştiriciler test senaryolarını ve ölçümleri güncelleyebilir.

Sorun giderme ile kök neden analizi karşılaştırması

RCA ve sorun giderme farklı süreçlerdir. Sorun giderme ve genel sorun çözme metodolojileri belirli sorunları çözer. Örneğin, bir uygulamanın sistem durumu izlemesi, bir yazılım örneğinin kilitlendiğini ve yanıt vermediğini ortaya çıkarırsa , ekip, yazılım örneğini yeniden başlatarak veya sunucuyu yeniden başlatarak sorunu çözebilir.

Ancak yazılım kusurları için kök neden analizi, yazılımın belirli bir hata durumu nedeniyle yanıt vermediğini ortaya çıkarabilir. Belki uygulama verilere erişemez ve yazılım bu tür hataları zarif bir şekilde ele alacak şekilde tasarlanmamıştır. Ekip, yanıt olarak, hata işlemeyi ele alan ve muhtemelen sorunun tekrarlanmasını önleyecek bir yazılım yaması yayınlayabilir.

Yazılım kusurları için kök neden analizinin faydaları

Kök neden analizi, SDLC’de daha önce sorunları bulmaya ve çözmeye yardımcı olarak bir kuruluşa para kazandırabilir.

Bir işletme, sorunları geliştirme döngüsünün başlarında bulmak ve düzeltmek için RCA’yı kullanırsa, kuruluş daha kaliteli yazılımları daha hızlı ve daha uygun maliyetli bir şekilde oluşturabilir. Canlı yazılımlardaki sorunları önleyen kök neden analizi, müşteri memnuniyetini de artırır ve şirket itibarını korur. Yazılım geliştirmede kök neden analizinin bazı avantajları şunlardır:

daha düşük yazılım kusur oranları;
geliştirilmiş yazılım kalitesi (aynı kusurları ve tekrar eden hataları ortadan kaldırır);
azaltılmış geliştirme maliyetleri;
sorun giderme düzeltmelerini ve iyileştirmeleri azaltarak kısaltılmış geliştirme döngüleri;
geliştirilmiş kullanıcı ve müşteri memnuniyeti;
geliştirilmiş geliştirici üretkenliği (bir ekibin çabalarını düzeltmeler yerine yeni özelliklere ve iyileştirmelere odaklamasına olanak tanır); ve
geliştirme ve üretim ortamlarında başka yerlerdeki sorunların tanımlanması.

Kök neden analizi nasıl yapılır

Bir ekip RCA’yı çok çeşitli şekillerde gerçekleştirebilir, ancak organize, mantıklı ve nesnel bir yaklaşım genellikle en uygun ve etkili olarak kabul edilir. Analiz genellikle günlük verilerini, yardım masasını ve sorun bileti ayrıntılarını ve bir olaydan elde edilen diğer kanıtları inceler. Bir RCA ekibi bu bilgileri incelerken, üyeleri bir kusurun altında yatan nedenleri anlamaya başlayabilir ve bunları ele almak için stratejiler ve öneriler formüle edebilir.

Bu tartışmanın amaçları doğrultusunda, bir RCA ekibini, düzeltici eylemleri araştırmak için temel nedenleri tartışmak veya belirlemek için bir araya gelen herhangi bir grup olarak düşünün.

Toplantı için hazırlanın. RCA toplantıları gerektiğinde – belki beklenmedik, kritik bir hatanın ardından – veya yazılım geliştirme ekibi içinde düzenli olarak planlanmış olaylar olarak yapılabilir. RCA ekip lideri, genellikle günlükler, ekran görüntüleri, raporlama ve diğer kaynaklar dahil olmak üzere her bir hatayla ilgili ayrıntıları ve verileri toplayacaktır.

RCA ekip üyeleri, gereksinimler, tasarım, uygulama, test etme, operasyonlar ve geliştirmede yer alan diğer herkes gibi yazılımın yaşam döngüsünün her aşamasında yer alan temsilcileri içerebilir. Ekip ayrıca ilk problem üzerinde çalışan ve sorunu çözen kişilerden de oluşabilir. Her bir RCA ekip üyesi ayrıntıları gözden geçirir ve konuyu kendi yaşam döngüsü aşamasından tartışmak için hazırlanmış olarak toplantıya gelir.

Kusursuz raporlama ve öneriler

Yazılım kusurları için temel neden analizi, yalnızca bir ekip RCA sonuçlarını nesnel olarak alıp uygularsa değer kazanır. RCA girişimleriyle ilgili en büyük zorluklar, suç algısı ve sorumluluk ataması gibi insan kavramlarını içerir . Başka bir deyişle, hiç kimse bir kusurun kendi hatası olduğunu kayıtlara geçirmek istemez. Ne yazık ki, bir analiz parmakları işaret ettiğinde, ardından gelen kızgınlık ve moral kaybı, genellikle temel neden analizinin faydalarını baltalayabilir ve karşılığında ekip üyelerinin, yöneticilerin ve iş liderlerinin direnişine yol açabilir.

Tüm RCA çabalarının kusursuz tarafsızlık içermesi çok önemlidir. Raporlama ve tavsiyeler her zaman suçu yalnızca bir bireye veya ekibe yüklemeyen eyleme geçirilebilir adımlar olarak çerçevelenmelidir. Raporlama ve tavsiyeler suçsuz olduğunda, bir ekibin değişiklikleri kızgınlık veya direnç göstermeden alması ve uygulaması daha olasıdır.

Problemi tanımla. Ayrıntılar mevcut olduğunda, RCA ekibi kusuru ve yazılım üzerindeki etkisini toplu olarak değerlendirmek için bir araya gelebilir. Tartışmanın bu aşaması, aşağıdakiler de dahil olmak üzere çeşitli yaygın analitik soruları yanıtlayarak neler olduğuna odaklanır:

Sorun nedir?
Hangi olaylar veya tetikleyiciler soruna yol açtı?
Sorun hangi sistemleri veya hizmetleri etkiledi?
Sorun ne kadar sürdü?
Sorunun ne gibi etkileri oldu?
Kim (eğer varsa) dahil oldu?

Altta yatan nedenleri beyin fırtınası yapın. RCA ekip üyeleri kanıtları gözden geçirdikten ve sorunu net bir şekilde tanımladıktan sonra olası temel nedeni veya nedenleri göz önünde bulundurabilirler. Kusurun neden oluştuğuna odaklanın ve temel nedeni belirlemek için araçlarla beyin fırtınası yapın. RCA ekip lideri genellikle toplantının bu bölümünü yönetir ve tüm üyelerin fikirlere katkıda bulunmasını sağlar.

Düzeltici eylemi seçin. RCA ekibi bir kusurun olası temel nedenini belirledikten sonra, en uygun kök neden düzeltici eyleme karar verebilir. Burada ekip, altta yatan nedenlere nasıl değinileceğini belirlemelidir. Düzeltici eylemler, gereksinimleri güncelleme, kodlama stilleri ve standartlarını zorlama, yazılımda belirli değişiklikler veya düzeltmeler yapma, test senaryoları ekleme veya dağıtım ortamında değişiklikler yapma gibi RCA bulgusuna bağlı olarak önemli ölçüde değişebilir.

Ekip, yazılım düzeyinde halihazırda yapılmış olan kod tabanı düzeltmelerine eklenip eklenmeyeceğine ve bu değişikliklerin yeniden test edilmesi gerekip gerekmediğine karar vermelidir. Bir düzeltmenin diğer özellikleri ve işlevleri etkilemediğinden emin olun.

Önleyici eylemi seçin. Kök neden analizinin gerçek değeri, sürekli iyileştirmedir. Kusurlar bulmak ve düzeltmek için paraya mal olur. Bir sorunun altında yatan nedeni anlayarak, bir RCA ekibinin önerileri, aynı veya diğer uygulamalarda benzer sorunların nasıl önlenebileceğini gösterebilir. Bir RCA sürecinin son kısmı, benzer sorunların tekrar etmesinin nasıl önleneceğine dair açık rehberlikle sonuçlanmalıdır. Bu öneriler, kök neden önleyici eylemler (RCPA’lar) olarak bilinir ve daha iyi dokümantasyon, daha fazla ekip eğitimi veya beceri seti geliştirmeleri, süreç değişiklikleri veya BT altyapısı iyileştirmeleri gibi çok çeşitli devam eden önerileri içerebilir.

Yazılım kusurları için kök neden analizine yönelik yaklaşımlar

Yazılım ekipleri, aşağıdakiler dahil olmak üzere, temel neden analizi görevlerine yaklaşmak için çok sayıda araçtan yararlanabilir:

Balık kılçığı diyagramları
Beş Neden
Dağılım grafikleri
Arıza Modu ve Etkileri Analizi (FMEA)
Pareto çizelgeleri

Kılçık diyagramları ve Beş Neden en popüler tekniklerdir.

Balık kılçığı analizi. Ishikawa diyagramı veya neden-sonuç diyagramı olarak da adlandırılan bir kılçık analizi, analistlerin olası nedenleri orijinal sorundan ayrılan kategorilere ayırarak bir kök nedeni görselleştirmelerine yardımcı olmak için tasarlanmıştır. Ortaya çıkan diyagram bir balığın iskeletini andırıyor – dolayısıyla adı. Uygulamada, altta yatan sorun veya konu balığın “başına” yazılır. Görselin “kemikleri” olası nedenlerin kategorileridir. Analistler daha sonra her kategori altındaki birincil nedenleri belirler; gerekirse, diyagram yapıcılar ikincil ve üçüncül nedenleri ekleyebilirler.

Beş Neden analizi. Neden diye sormak, insanların bir problemin ardışık katmanlarına inmelerine izin verir. Her nedenin cevabı, bir sonraki ardışık sorunun temeli olur. Süreç, bir çocuğun art arda neden sorularını sormasına benzer, yetişkin her cevap verdiğinde, çocuk bu cevabı bir sonraki soru için temel olarak kullanır. Teknik beyin fırtınasına dayanır.

Beş Neden analizi, veri veya istatistik kullanmadığından öznel olabilir, bu nedenle yaklaşım karmaşık durumlar için uygun değildir. Analiz ayrıca bir temel nedene ulaşmak için beşten fazla soru gerektirebilir, ancak beş soru genellikle bir başlangıç noktasıdır. Sadece dört “neden” içeren basit bir örnek düşünün:

Sorun: Bir yazılım uygulamasından günlük dosyası eksik.

Günlük dosyası neden eksik?
- Günlük dosyası, beklendiği mantıksal birim numarası veya klasörde mevcut değil.
Günlük dosyası neden mevcut değildi?
- Günlük dosyası yazılım uygulamasında etkinleştirilmedi.
Günlük özelliği neden etkinleştirilmedi?
- Yazılım uygulaması düzgün yapılandırılmamış.
Yazılım neden düzgün yapılandırılmadı?
- Bir ekip, uygulamayı yetersiz şekilde belgelemiş veya yazılımı kurmak ve kullanmak için bir süreci tamamlayamamıştır. Nihai cevap, günlüğü etkinleştirmek ve daha iyi dokümantasyon ve kullanıcı eğitimi sağlamak olabilir.