I. Volwassenheid van het softwareontwikkelingsproces
De basis van softwarekwaliteit ligt in de standaardisatie van ontwikkelprocessen. Automotive SPICE-capaciteitsniveaus zijn momenteel de benchmark voor de volwassenheid van softwareprocessen, maar het bereiken van CL2 of CL3 is slechts de basislijn. Wat de kwaliteit van de softwarelevering echt bepaalt, is het beheersen van afwijkingen tijdens de procesuitvoering. Als we het eisenbeheer als voorbeeld nemen, is een veel voorkomende afwijking dat nadat een vereiste is gewijzigd, de bijbehorende testgevallen niet synchroon worden bijgewerkt. In één project werd na SOP ontdekt dat een OTA-upgradefunctie een probleem vertoonde waarbij, wanneer het voertuig bijna leeg was, de OTA-downloadtaak voor onbepaalde tijd werd opgeschort zonder een fout te rapporteren. De hoofdoorzaak was dat het vereistedocument logica voor lage laadstatus had toegevoegd, maar dat de overeenkomstige testgevallen nog steeds alleen betrekking hadden op de verificatie van de downloadfunctie, zonder onderbrekings- en herstelscenario's. Vanaf de introductie tot de ontdekking omvatte dit defect vier iteratieve versies, en de correctiekosten waren bijna veertig keer hoger dan wanneer het vroegtijdig was ontdekt. De traceerbaarheidsmatrix van eisen moet worden ingebed in de continue integratiepijplijn. Wanneer de status van een vereiste verandert in gewijzigd, moeten de beoordelingstaken voor bijbehorende testgevallen automatisch worden geactiveerd en moeten testgevallen die de beoordeling niet hebben doorstaan, worden gemarkeerd als blokkerende items. Codebeoordeling moet ook worden gekwantificeerd. Uit onderzoek blijkt dat modules met minder dan twee recensies per duizend regels code een post-defectdichtheid hebben die meer dan drie keer hoger is dan bij modules met meer dan vijf reacties per duizend regels. Het aantal recensiereacties kan echter niet als absolute indicator worden gebruikt, omdat er ook reacties van lage-kwaliteit bestaan. Een effectieve aanpak is om reviewopmerkingen in vijf categorieën in te delen: logische fouten, ontbrekende randvoorwaarden, leesbaarheid van de code, prestatierisico's en veiligheidsrisico's, met bijzondere aandacht voor het detectiepercentage van de twee fatale categorieën: logische fouten en veiligheidsrisico's.
II. Continue integratie en continu testen
De versnelling van software-iteratie vereist dat het testen naar links wordt verschoven, wat betekent dat kwaliteitsverificatie wordt geïntroduceerd in de fase van het vastleggen van de code. Unit-testen vormen de meest linkse verdedigingslinie, maar in daadwerkelijke projecten heeft de dekking van unit-testcodes vaak te lijden onder te hoge waarden. Bij één controllerproject liet het unittestrapport een lijndekking van 92% zien, maar tijdens de integratietests werd nog steeds een groot aantal basisfouten gevonden. Uit retrospectieve analyse bleek dat, hoewel de coderegels die deze fouten bevatten, werden uitgevoerd, de testbeweringen de relevante output niet controleerden. Lijndekking geeft alleen aan dat de code is uitgevoerd, niet dat de uitvoer is geverifieerd. Eén verbeteringsmethode is het introduceren van mutatietesten, waarbij automatisch codemutanten worden gegenereerd om de effectiviteit van testgevallen te evalueren. Als een mutant niet wordt gedood, duidt dit op een leemte in de testbeweringen. Een ander pijnpunt bij continue integratiepijplijnen is de buitensporige testuitvoeringstijd. In de softwarerepository van één OEM had de volledige regressietestsuite meer dan 20 uur nodig om te draaien, wat betekende dat ontwikkelaars vaak tot de volgende dag moesten wachten voordat ze feedback kregen nadat ze de code hadden ingediend. Oplossingen omvatten parallel testen, prioritering van testcases en incrementeel testen. Parallel testen verdeelt de testsuite over meerdere uitvoeringsknooppunten, waardoor de uitvoeringstijd wordt teruggebracht tot ongeveer een-tiende van de oorspronkelijke tijd. De prioriteitstelling van testgevallen is gebaseerd op de historische verdeling van defecten, waarbij prioriteit wordt gegeven aan de 20% van de testgevallen die het meest waarschijnlijk nieuwe defecten zullen detecteren. Deze subset kan ongeveer 70% van de nieuwe defecten opvangen. Bij incrementeel testen worden alleen testgevallen uitgevoerd die verband houden met de huidige codewijziging, waarbij statische analyse wordt gebruikt om de omvang van de impact van de wijziging te identificeren en de testomvang dynamisch te filteren.
III. Meting van softwarefouten en analyse van de hoofdoorzaken
Meetstatistieken voor softwaredefecten moeten anders worden behandeld dan hardwaredefecten. Hardwaredefecten zijn doorgaans gericht op de defectdichtheid, zoals het aantal defecten per miljoen onderdelen. De distributie van softwaredefecten volgt echter het Pareto-principe, waarbij ongeveer 80% van de ernstige defecten geconcentreerd is in 20% van de modules. Daarom is een effectievere meetwaarde de trend van defectconvergentie op module-niveau, dat wil zeggen de netto verandering in open defecten voor elke module over iteraties heen. Als een module gedurende drie opeenvolgende iteraties een netto toename van open defecten vertoont, duidt dit op een fundamenteel architectonisch probleem dat refactoring-evaluatie vereist. De diepgaande analyse van de oorzaak van defecten bepaalt de effectiviteit van preventieve acties. Een veelgebruikt classificatieraamwerk categoriseert de hoofdoorzaken van softwaredefecten in vijf typen: afwijkingen in het begrijpen van vereisten, defecten in de ontwerplogica, fouten in de coderingsimplementatie, fouten in configuratiebeheer en verschillen in afhankelijkheid van de omgeving. Fouten in configuratiebeheer vormen een unieke categorie voor softwareprojecten. Veelvoorkomende voorbeelden zijn onder meer het gebruik van de verkeerde versie van een middlewarebibliotheek, inconsistente instellingen van compileropties en ontbrekende kritieke oplossingen tijdens het samenvoegen van vertakkingen. Bij één project werd tijdens de laatste testronde vóór de levering een logische fout in de remlichtbesturing ontdekt. De fout was terug te voeren op een fusie van een filiaal drie maanden eerder, waarbij de ontwikkelaar er ten onrechte voor had gekozen om alle wijzigingen aan de remlichtregelmodule te negeren bij het samenvoegen van de featurecode van de hoofdtak. Deze casus suggereert dat het vergelijken van verschillen na het samenvoegen van vestigingen een verplichte poort zou moeten worden, waarbij aangewezen personeel verantwoordelijk is voor het beoordelen van fusieverzoeken.
IV. Software terugroepen en OTA-beheer
Met de wijdverbreide adoptie van OTA-technologie ondergaat de methode voor het repareren van softwarefouten een fundamentele verandering. Bij traditionele terugroepacties van software moeten voertuigen naar servicecentra gaan om te flashen, wat kostbaar en tijdrovend is- en te kampen heeft met een lage naleving door de gebruiker. OTA-terugroepacties kunnen rechtstreeks worden voltooid via push op afstand, maar er zijn wettelijke vereisten