I. Maduresa del procés de desenvolupament de programari
La base de la qualitat del programari es troba en l'estandardització dels processos de desenvolupament. Els nivells de capacitat d'SPICE d'automoció són actualment la referència de la indústria per a la maduresa del procés de programari, però assolir CL2 o CL3 és només la línia de base. El que realment determina la qualitat del lliurament del programari és el control de les desviacions durant l'execució del procés. Prenent com a exemple la gestió de requisits, una desviació habitual és que després d'un canvi de requisit, els casos de prova associats no s'actualitzen de manera sincrònica. En un projecte, es va trobar que una funció d'actualització OTA després de SOP tenia un problema en què quan el vehicle estava en un estat de càrrega baix, la tasca de descàrrega de l'OTA es suspenia indefinidament sense informar d'error. La causa principal era que el document de requisits havia afegit una lògica de protecció d'estat de càrrega baix, però els casos de prova corresponents encara només cobrien la verificació de la funció de descàrrega sense incloure escenaris d'interrupció i recuperació. Des de la introducció fins al descobriment, aquest defecte va abastar quatre versions iteratives i el cost de la correcció va ser gairebé quaranta vegades més gran que si s'hagués trobat abans. La matriu de traçabilitat de requisits s'ha d'incrustar en el pipeline d'integració contínua. Quan l'estat d'un requisit canvia a canviat, les tasques de revisió dels casos de prova associats s'han d'activar automàticament i els casos de prova que no han superat la revisió s'han de marcar com a elements de bloqueig. També cal quantificar la revisió del codi. Les investigacions mostren que els mòduls amb menys de dos comentaris de revisió per mil línies de codi tenen una densitat de defectes post-alliberament més de tres vegades més gran que els mòduls amb més de cinc comentaris per mil línies. Tanmateix, el nombre de comentaris de ressenya no es pot utilitzar com a indicador absolut perquè també existeixen comentaris de baixa-qualitat. Un enfocament eficaç és classificar els comentaris de revisió en cinc categories: errors lògics, condicions de límit que falten, llegibilitat del codi, riscos de rendiment i riscos de seguretat, amb especial atenció a la taxa de detecció de les dues categories fatals: errors lògics i riscos de seguretat.
II. Integració contínua i proves contínues
L'acceleració de la iteració del programari requereix desplaçar les proves cap a l'esquerra, el que significa que la verificació de qualitat s'introdueix en l'etapa de confirmació del codi. Les proves unitàries són la línia de defensa més a l'esquerra, però en els projectes reals, la cobertura del codi de proves unitàries sovint pateix valors inflats. En un projecte de controlador, l'informe de prova de la unitat mostrava una cobertura de línia del 92%, però encara es van trobar un gran nombre d'errors bàsics durant les proves d'integració. L'anàlisi retrospectiva va revelar que, tot i que les línies de codi que contenien aquests errors es van executar, les afirmacions de prova no van comprovar les sortides rellevants. La cobertura de línia només indica que el codi s'ha executat, no que les sortides s'han verificat. Un mètode de millora és introduir proves de mutació, que genera automàticament mutants de codi per avaluar l'eficàcia dels casos de prova. Si no mata un mutant, indica un buit en les afirmacions de la prova. Un altre punt dolent en les canonades d'integració contínua és el temps excessiu d'execució de proves. Al dipòsit de programari d'un OEM, la suite de proves de regressió completa va requerir més de 20 hores per executar-se, el que significa que els desenvolupadors sovint havien d'esperar fins l'endemà per rebre comentaris després d'enviar el codi. Les solucions inclouen proves paral·leles, priorització de casos de prova i proves incrementals. Les proves paral·leles divideixen el conjunt de proves en diversos nodes d'execució, reduint el temps d'execució a aproximadament una-desena part de l'original. La priorització dels casos de prova es basa en la distribució històrica de defectes, prioritzant el 20% dels casos de prova amb més probabilitats de detectar nous defectes. Aquest subconjunt pot capturar aproximadament el 70% dels nous defectes. Les proves incrementals només executen casos de prova relacionats amb el canvi de codi actual, utilitzant anàlisi estàtica per identificar l'abast de l'impacte del canvi per filtrar dinàmicament l'abast de la prova.
III. Mesurament de defectes del programari i anàlisi de la causa arrel
Les mètriques de mesura dels defectes del programari s'han de tractar de manera diferent als defectes del maquinari. Els defectes de maquinari normalment se centren en la densitat de defectes, com ara el nombre de defectes per milió de peces. Tanmateix, la distribució de defectes del programari segueix el principi de Pareto, amb aproximadament el 80% dels defectes greus concentrats en el 20% dels mòduls. Per tant, una mètrica més eficaç és la tendència de convergència de defectes a nivell de mòdul-, és a dir, el canvi net dels defectes oberts per a cada mòdul entre iteracions. Si un mòdul mostra un augment net dels defectes oberts durant tres iteracions consecutives, suggereix un problema arquitectònic fonamental que requereix una revisió de refactorització. La profunditat de l'anàlisi de la causa arrel del defecte determina l'eficàcia de les accions preventives. Un marc de classificació d'ús habitual classifica les causes arrel dels defectes del programari en cinc tipus: desviació de comprensió de requisits, defectes de lògica de disseny, errors d'implementació de codificació, errors de gestió de configuració i diferències de dependència ambiental. Els errors de gestió de configuració són una categoria única per als projectes de programari. Els exemples habituals inclouen l'ús de la versió incorrecta d'una biblioteca de programari intermedi, la configuració d'opcions del compilador inconsistents i la falta de solucions crítiques durant la fusió de branques. En un projecte, es va descobrir un error lògic de control de la llum de fre durant la ronda final de proves abans del lliurament. L'error es va remuntar a una fusió de sucursals tres mesos abans, on el desenvolupador havia escollit incorrectament descartar tots els canvis al mòdul de control de la llum de fre quan fusionava el codi de funció de la branca principal. Aquest cas suggereix que la comparació de diferències després de la fusió de sucursals hauria de convertir-se en una porta obligatòria, amb personal designat responsable de revisar les sol·licituds de fusió.
IV. Recuperació de programari i gestió OTA
Amb l'adopció generalitzada de la tecnologia OTA, el mètode per solucionar els defectes del programari està experimentant un canvi fonamental. Les retirades de programari tradicionals requereixen que els vehicles visitin els centres de servei per flashejar, cosa que és costosa, consumeix-temps i pateix un baix compliment dels usuaris. Les retirades de l'OTA es poden completar directament mitjançant l'empenta remota, però els requisits reglamentaris