I. Programinės įrangos kūrimo proceso branda
Programinės įrangos kokybės pagrindas yra kūrimo procesų standartizavimas. Automobilių SPICE pajėgumų lygiai šiuo metu yra pramonės etalonas programinės įrangos procesų brandai, tačiau pasiekti CL2 arba CL3 yra tik pradinis rodiklis. Kas iš tikrųjų lemia programinės įrangos pristatymo kokybę, yra nukrypimų kontrolė proceso vykdymo metu. Kaip pavyzdį imant reikalavimų valdymą, dažnas nukrypimas yra tas, kad pasikeitus reikalavimams, susiję bandomieji atvejai nėra atnaujinami sinchroniškai. Viename projekte po SOP buvo rasta OTA atnaujinimo funkcija, dėl kurios, kai transporto priemonė buvo mažai įkrauta, OTA atsisiuntimo užduotis buvo sustabdyta neribotam laikui, nepranešant apie klaidą. Pagrindinė priežastis buvo ta, kad reikalavimo dokumente buvo pridėta žemos įkrovos apsaugos būsenos logika, tačiau atitinkami bandomieji atvejai vis tiek apėmė tik atsisiuntimo funkcijos patikrinimą, neįtraukiant pertraukimo ir atkūrimo scenarijų. Nuo įvado iki atradimo šis defektas apėmė keturias kartotines versijas, o taisymo kaina buvo beveik keturiasdešimt kartų didesnė nei tuo atveju, jei jis būtų rastas anksti. Reikalavimų atsekamumo matrica turi būti įtraukta į nuolatinį integravimo vamzdyną. Kai reikalavimo būsena pasikeičia į pakeista, susijusių bandomųjų atvejų peržiūros užduotys turėtų būti automatiškai suaktyvintos, o bandomieji atvejai, kurie nepraėjo peržiūros, turėtų būti pažymėti kaip blokuojantys elementai. Kodo peržiūrą taip pat reikia įvertinti kiekybiškai. Tyrimai rodo, kad modulių, kuriuose tūkstančiui kodo eilučių yra mažiau nei du apžvalgos komentarai, įrašo{12}}leidimo defektų tankis yra daugiau nei tris kartus didesnis nei modulių, kurių tūkstančiui eilučių yra daugiau nei penki komentarai. Tačiau atsiliepimų komentarų skaičius negali būti naudojamas kaip absoliutus rodiklis, nes taip pat yra žemos kokybės komentarų. Veiksmingas būdas yra suskirstyti peržiūros komentarus į penkias kategorijas: loginės klaidos, trūkstamos ribinės sąlygos, kodo skaitomumas, veikimo rizika ir saugos rizika, ypatingą dėmesį skiriant dviejų mirtinų kategorijų – loginių klaidų ir saugos rizikos – aptikimo dažniui.
II. Nuolatinis integravimas ir nuolatinis testavimas
Norint pagreitinti programinės įrangos iteraciją, bandymas turi būti perkeltas į kairę, o tai reiškia, kad kokybės patikrinimas įvedamas kodo įpareigojimo etape. Vienetų testavimas yra kairėje pusėje esanti gynybos linija, tačiau realiuose projektuose vieneto testavimo kodo aprėptis dažnai kenčia nuo išpūstų verčių. Viename valdiklio projekte bloko bandymo ataskaita parodė, kad linijos aprėptis yra 92%, tačiau atliekant integracijos testavimą vis tiek buvo rasta daug pagrindinių klaidų. Retrospektyvinė analizė atskleidė, kad nors kodo eilutės su šiomis klaidomis buvo vykdomos, bandymo teiginiai nepatikrino atitinkamų išėjimų. Linijos aprėptis rodo tik tai, kad kodas buvo įvykdytas, o ne tai, kad išėjimai buvo patikrinti. Vienas iš tobulinimo būdų yra įvesti mutacijų testavimą, kuris automatiškai generuoja kodo mutantus, kad įvertintų testavimo atvejų efektyvumą. Jei mutantas nėra nužudytas, tai rodo bandymo teiginių spragą. Kitas nepertraukiamo integravimo vamzdynų negalavimas yra per ilgas bandymo vykdymo laikas. Vienoje OĮG programinės įrangos saugykloje visam regresijos testų rinkiniui paleisti prireikė daugiau nei 20 valandų, o tai reiškia, kad kūrėjai dažnai turėjo laukti kitos dienos, kad gautų atsiliepimą po kodo pateikimo. Sprendimai apima lygiagretųjį testavimą, testavimo atvejo prioritetų nustatymą ir laipsnišką testavimą. Lygiagretus testavimas padalija bandymų rinkinį į kelis vykdymo mazgus, todėl vykdymo laikas sutrumpėja iki maždaug vienos dešimtosios originalo. Bandomųjų atvejų prioritetų nustatymas grindžiamas istoriniu defektų pasiskirstymu, pirmenybę teikiant 20 % bandymų atvejų, kurie greičiausiai aptiks naujus defektus. Šis pogrupis gali užfiksuoti maždaug 70% naujų defektų. Laipsniškas testavimas atlieka tik bandomuosius atvejus, susijusius su dabartiniu kodo pakeitimu, naudojant statinę analizę, kad nustatytų pakeitimo poveikio apimtį, kad būtų dinamiškai filtruojama bandymo apimtis.
III. Programinės įrangos defektų matavimas ir pagrindinės priežasties analizė
Programinės įrangos defektų matavimo metrika turi būti traktuojama kitaip nei aparatinės įrangos defektai. Aparatūros defektai paprastai yra susiję su defektų tankiu, pvz., defektų skaičiumi milijonui dalių. Tačiau programinės įrangos defektų paskirstymas vyksta pagal Pareto principą, o maždaug 80% rimtų defektų sutelkti 20% modulių. Todėl efektyvesnė metrika yra modulio-lygio defektų konvergencijos tendencija, ty grynasis kiekvieno modulio atvirų defektų pokytis per iteraciją. Jei modulis rodo grynąjį atvirų defektų padidėjimą tris kartus iš eilės, tai rodo esminę architektūrinę problemą, kurią reikia peržiūrėti. Defekto priežasties analizės gylis lemia prevencinių veiksmų efektyvumą. Dažniausiai naudojama klasifikavimo sistema suskirsto programinės įrangos defektų priežastis į penkis tipus: reikalavimų supratimo nuokrypis, projektavimo logikos defektai, kodavimo diegimo klaidos, konfigūracijos valdymo klaidos ir priklausomybės nuo aplinkos skirtumai. Konfigūracijos valdymo klaidos yra unikali programinės įrangos projektų kategorija. Dažni pavyzdžiai yra netinkamos tarpinės programinės įrangos bibliotekos versijos naudojimas, nenuoseklūs kompiliatoriaus parinkčių nustatymai ir trūkstami svarbūs pataisymai sujungiant šakas. Viename projekte stabdžių žibintų valdymo logikos klaida buvo aptikta paskutiniame bandymų etape prieš pristatymą. Klaida buvo siejama su filialų sujungimu prieš tris mėnesius, kai kūrėjas neteisingai pasirinko atmesti visus stabdžių žibintų valdymo modulio pakeitimus, kai sujungia funkcijos kodą iš pagrindinės šakos. Šis atvejis rodo, kad skirtumų palyginimas po filialų sujungimo turėtų tapti privalomu vartu, o paskirti darbuotojai būtų atsakingi už sujungimo prašymų peržiūrą.
IV. Programinės įrangos iškvietimas ir OTA valdymas
Plačiai pritaikius OTA technologiją, programinės įrangos defektų šalinimo metodas iš esmės keičiasi. Tradicinės programinės įrangos atšaukimas reikalauja, kad transporto priemonės apsilankytų aptarnavimo centruose dėl blykstės, o tai brangu,{1}}atima daug laiko, o naudotojai nesilaiko reikalavimų. OTA atšaukimas gali būti baigtas tiesiogiai nuotoliniu būdu, tačiau taikomi reguliavimo reikalavimai