I. Zrelost procesa razvoja programske opreme
Temelj kakovosti programske opreme je standardizacija razvojnih procesov. Ravni zmogljivosti avtomobilskega SPICE so trenutno industrijsko merilo za zrelost procesov programske opreme, vendar je doseganje CL2 ali CL3 le izhodišče. Tisto, kar resnično določa kakovost dobave programske opreme, je nadzor odstopanj med izvajanjem procesa. Če za primer vzamemo upravljanje zahtev, je običajno odstopanje, da se po spremembi zahteve povezani preskusni primeri ne posodobijo sinhrono. V enem projektu je bilo po SOP ugotovljeno, da ima funkcija nadgradnje OTA težavo, ko je bilo vozilo v stanju nizke napolnjenosti, je bila naloga prenosa OTA začasno prekinjena za nedoločen čas brez poročanja o napaki. Osnovni vzrok je bil v tem, da je dokument z zahtevami dodal logiko zaščite pred nizkim stanjem napolnjenosti, vendar so ustrezni testni primeri še vedno zajemali samo preverjanje funkcije prenosa brez vključitve scenarijev prekinitve in obnovitve. Od uvoda do odkritja je ta napaka obsegala štiri ponavljajoče se različice, stroški popravka pa so bili skoraj štiridesetkrat višji, kot če bi jo odkrili zgodaj. Matriko sledljivosti zahtev je treba vdelati v neprekinjen cevovod integracije. Ko se stanje zahteve spremeni v spremenjeno, se morajo samodejno sprožiti opravila pregleda za povezane testne primere, preskusni primeri, ki niso prestali pregleda, pa morajo biti označeni kot blokirni elementi. Tudi pregled kode je treba kvantificirati. Raziskave kažejo, da imajo moduli z manj kot dvema komentarjema pregleda na tisoč vrstic kode več kot trikrat večjo gostoto napak po-objavi kot moduli z več kot petimi komentarji na tisoč vrstic. Vendar pa števila komentarjev pregledov ni mogoče uporabiti kot absolutni pokazatelj, ker obstajajo tudi komentarji nizke{14}}kakovosti. Učinkovit pristop je razvrstitev preglednih komentarjev v pet kategorij: logične napake, manjkajoči robni pogoji, berljivost kode, tveganja delovanja in varnostna tveganja, s posebnim poudarkom na stopnji odkrivanja dveh usodnih kategorij: logičnih napak in varnostnih tveganj.
II. Nenehna integracija in nenehno testiranje
Pospeševanje iteracije programske opreme zahteva premik testiranja v levo, kar pomeni, da je preverjanje kakovosti uvedeno na stopnji potrditve kode. Testiranje enot je skrajna leva obrambna črta, vendar v dejanskih projektih pokritost kode testa enote pogosto trpi zaradi prenapihnjenih vrednosti. V enem projektu krmilnika je poročilo o preskusu enote pokazalo 92-odstotno pokritost linije, vendar je bilo med testiranjem integracije še vedno odkritih veliko število osnovnih napak. Retrospektivna analiza je pokazala, da čeprav so bile vrstice kode, ki vsebujejo te napake, izvedene, preskusne trditve niso preverile ustreznih rezultatov. Pokritost vrstice pomeni le, da je bila koda izvedena, ne pa tudi, da so bili izhodi preverjeni. Ena od metod izboljšave je uvedba testiranja mutacij, ki samodejno ustvari mutante kode za oceno učinkovitosti testnih primerov. Če mutant ni ubit, to kaže na vrzel v testnih trditvah. Druga težava pri neprekinjenih integracijskih cevovodih je predolg čas izvajanja testa. V enem od skladišč programske opreme proizvajalca originalne opreme je celoten nabor regresijskih testov zahteval več kot 20 ur za delovanje, kar pomeni, da so morali razvijalci pogosto čakati do naslednjega dne, da prejmejo povratne informacije po predložitvi kode. Rešitve vključujejo vzporedno testiranje, prednostno določanje testnih primerov in inkrementalno testiranje. Vzporedno testiranje razdeli nabor testov na več izvajalnih vozlišč, kar skrajša čas izvajanja na približno-desetino prvotnega. Prednostno razvrščanje testnih primerov temelji na zgodovinski porazdelitvi napak, pri čemer se daje prednost 20 % testnih primerov, ki najverjetneje odkrijejo nove napake. Ta podnabor lahko zajame približno 70 % novih napak. Inkrementalno testiranje izvaja samo testne primere, povezane s trenutno spremembo kode, z uporabo statične analize za prepoznavanje obsega vpliva spremembe za dinamično filtriranje obsega testa.
III. Merjenje napak programske opreme in analiza temeljnih vzrokov
Merilne metrike za napake programske opreme je treba obravnavati drugače kot napake strojne opreme. Napake strojne opreme se običajno osredotočajo na gostoto napak, kot je število napak na milijon delov. Vendar porazdelitev napak programske opreme sledi Paretovemu načelu, pri čemer je približno 80 % hudih napak skoncentriranih v 20 % modulov. Zato je učinkovitejša metrika trend konvergence napak-na ravni modula, kar pomeni neto spremembo odprtih napak za vsak modul med iteracijami. Če modul pokaže neto povečanje odprtih napak v treh zaporednih iteracijah, to kaže na temeljno arhitekturno težavo, ki zahteva refaktorski pregled. Globina analize vzroka napake določa učinkovitost preventivnih ukrepov. Pogosto uporabljen klasifikacijski okvir kategorizira temeljne vzroke napak programske opreme v pet tipov: odstopanje pri razumevanju zahtev, napake načrtovalske logike, napake pri izvajanju kodiranja, napake pri upravljanju konfiguracije in razlike v odvisnosti od okolja. Napake pri upravljanju konfiguracije so edinstvena kategorija za projekte programske opreme. Pogosti primeri vključujejo uporabo napačne različice knjižnice vmesne programske opreme, nedosledne nastavitve možnosti prevajalnika in manjkajoče kritične popravke med združevanjem vej. Pri enem projektu je bila med zadnjim krogom testiranja pred dostavo odkrita logična napaka pri krmiljenju zavorne luči. Napaka je bila izsledena nazaj do združitve veje tri mesece prej, kjer se je razvijalec napačno odločil zavreči vse spremembe modula za nadzor zavorne luči pri združevanju kode funkcije iz glavne veje. Ta primer nakazuje, da bi morala primerjava razlik po združitvi podružnic postati obvezna vrata z imenovanim osebjem, odgovornim za pregledovanje zahtev za združitev.
IV. Odpoklic programske opreme in upravljanje OTA
S širokim sprejetjem tehnologije OTA se način odpravljanja napak programske opreme temeljito spreminja. Običajni odpoklici programske opreme zahtevajo, da vozila obiščejo servisne centre za bliskavico, kar je drago, dolgotrajno-in trpi zaradi nizke skladnosti uporabnikov. Odpoklice OTA je mogoče dokončati neposredno z daljinskim pritiskom, vendar so to zakonske zahteve