I. Yazılım Geliştirme Süreci Olgunluğu
Yazılım kalitesinin temeli, geliştirme süreçlerinin standartlaştırılmasında yatmaktadır. Otomotiv SPICE yetenek seviyeleri şu anda yazılım süreci olgunluğu için endüstri standardıdır, ancak CL2 veya CL3'e ulaşmak yalnızca temeldir. Yazılım teslim kalitesini gerçekten belirleyen şey, süreç yürütme sırasındaki sapmaların kontrolüdür. Gereksinim yönetimini örnek olarak alırsak, yaygın bir sapma, bir gereksinim değiştikten sonra ilgili test senaryolarının eşzamanlı olarak güncellenmemesidir. Bir projede, SOP'tan sonra, aracın şarj durumu düşük olduğunda OTA indirme görevinin bir hata bildirilmeden süresiz olarak askıya alınmasına neden olan bir soruna sahip olan bir OTA yükseltme işlevi bulundu. Bunun temel nedeni, gereksinim belgesinin düşük durum şarj koruma mantığını eklemesiydi ancak ilgili test senaryoları, kesinti ve kurtarma senaryolarını içermeksizin yalnızca indirme işlevi doğrulamasını kapsıyordu. Girişten keşfe kadar, bu kusur dört yinelemeli versiyona yayıldı ve düzeltme maliyeti, erken bulunmasına göre neredeyse kırk kat daha yüksekti. Gereksinim izlenebilirlik matrisinin sürekli entegrasyon hattına yerleştirilmesi gerekir. Bir gereksinim durumu değişti olarak değiştiğinde, ilişkili test senaryolarına ilişkin inceleme görevleri otomatik olarak tetiklenmeli ve incelemeyi geçemeyen test senaryoları, engelleyici öğeler olarak işaretlenmelidir. Kod incelemesinin de sayısallaştırılması gerekir. Araştırmalar, her bin kod satırında ikiden az inceleme yorumu bulunan modüllerin, yayın sonrası hata yoğunluğunun, bin satır başına beşten fazla yorum içeren modüllere göre üç kattan daha yüksek olduğunu gösteriyor. Ancak inceleme yorumlarının sayısı mutlak bir gösterge olarak kullanılamaz çünkü düşük kaliteli-yorumlar da mevcuttur. Etkili bir yaklaşım, inceleme yorumlarını beş kategoride sınıflandırmaktır: mantık hataları, eksik sınır koşulları, kodun okunabilirliği, performans riskleri ve güvenlik riskleri ve özellikle iki önemli kategorinin tespit oranına odaklanarak: mantık hataları ve güvenlik riskleri.
II. Sürekli Entegrasyon ve Sürekli Test
Yazılım yinelemesinin hızlandırılması, testin sola kaydırılmasını gerektirir; bu, kalite doğrulamanın kod işleme aşamasında başlatıldığı anlamına gelir. Birim testi, savunmanın en soldaki hattıdır, ancak gerçek projelerde birim test kodu kapsamı genellikle şişirilmiş değerlerden muzdariptir. Bir kontrolör projesinde, ünite test raporu hat kapsamının %92 olduğunu gösterdi ancak entegrasyon testi sırasında hala çok sayıda temel hata bulundu. Geriye dönük analiz, bu hataları içeren kod satırlarının yürütülmesine rağmen test iddialarının ilgili çıktıları kontrol etmediğini ortaya çıkardı. Hat kapsamı yalnızca kodun yürütüldüğünü gösterir, çıktıların doğrulandığını değil. İyileştirme yöntemlerinden biri, test senaryolarının etkinliğini değerlendirmek için otomatik olarak kod mutantları üreten mutasyon testini uygulamaya koymaktır. Bir mutantın öldürülmemesi, test iddialarında bir boşluk olduğunu gösterir. Sürekli entegrasyon işlem hatlarındaki bir başka sorun noktası da aşırı test yürütme süresidir. Bir OEM'in yazılım deposunda, tüm regresyon testi paketinin çalıştırılması 20 saatten fazla sürdü; bu da geliştiricilerin kodu gönderdikten sonra geri bildirim almak için genellikle ertesi güne kadar beklemek zorunda kaldıkları anlamına geliyordu. Çözümler arasında paralel testler, test senaryosunun önceliklendirilmesi ve artımlı testler yer alır. Paralel test, test paketini birden fazla yürütme düğümüne bölerek yürütme süresini orijinalin yaklaşık onda birine indirir. Test senaryosunun önceliklendirilmesi, yeni hataları tespit etme olasılığı en yüksek olan test senaryolarının %20'sine öncelik vererek geçmiş hata dağılımına dayanır. Bu alt küme, yeni kusurların yaklaşık %70'ini yakalayabilir. Artımlı test, test kapsamını dinamik olarak filtrelemek için değişikliğin etki kapsamını belirlemek üzere statik analiz kullanarak yalnızca geçerli kod değişikliğiyle ilgili test senaryolarını yürütür.
III. Yazılım Kusur Ölçümü ve Kök Neden Analizi
Yazılım kusurlarına ilişkin ölçüm metriklerinin donanım kusurlarından farklı şekilde ele alınması gerekir. Donanım kusurları genellikle milyon parça başına kusur sayısı gibi kusur yoğunluğuna odaklanır. Bununla birlikte, yazılım kusurlarının dağıtımı Pareto prensibini takip eder; ciddi kusurların yaklaşık %80'i modüllerin %20'sinde yoğunlaşmıştır. Bu nedenle, daha etkili bir ölçüm, modül-düzeyinde kusur yakınsama eğilimidir; bu, yinelemeler boyunca her modül için açık kusurlardaki net değişiklik anlamına gelir. Bir modül ardışık üç yinelemede açık kusurlarda net bir artış gösteriyorsa, bu, yeniden düzenleme incelemesi gerektiren temel bir mimari soruna işaret eder. Kusurun kök neden analizinin derinliği, önleyici faaliyetlerin etkinliğini belirler. Yaygın olarak kullanılan bir sınıflandırma çerçevesi, yazılım hatasının temel nedenlerini beş türe ayırır: gereksinim anlama sapması, tasarım mantığı hataları, kodlama uygulama hataları, konfigürasyon yönetimi hataları ve çevresel bağımlılık farklılıkları. Konfigürasyon yönetimi hataları, yazılım projeleri için benzersiz bir kategoridir. Yaygın örnekler arasında bir ara katman yazılımı kitaplığının yanlış sürümünün kullanılması, tutarsız derleyici seçeneği ayarları ve dal birleştirme sırasında eksik kritik düzeltmeler yer alır. Bir projede, teslimattan önceki son test turu sırasında fren lambası kontrol mantık hatası keşfedildi. Hatanın izi, geliştiricinin ana daldan özellik kodunu birleştirirken yanlışlıkla fren lambası kontrol modülündeki tüm değişiklikleri atmayı seçtiği üç ay önceki bir dal birleştirmeden kaynaklanıyordu. Bu durum, şube birleşmesinden sonra fark karşılaştırmasının zorunlu bir kapı haline gelmesi gerektiğini ve birleşme taleplerinin gözden geçirilmesinden sorumlu atanmış personelin görevlendirilmesi gerektiğini göstermektedir.
IV. Yazılım Geri Çağırma ve OTA Yönetimi
OTA teknolojisinin yaygın olarak benimsenmesiyle birlikte yazılım hatalarını düzeltme yöntemi de köklü bir değişime uğruyor. Geleneksel yazılım geri çağırma işlemleri, araçların flashlama için servis merkezlerini ziyaret etmesini gerektirir; bu da maliyetli, zaman alıcı ve düşük kullanıcı uyumluluğuna neden olan bir işlemdir. OTA geri çağırmaları doğrudan uzaktan kumandayla tamamlanabilir ancak yasal gereklilikler