И. Зрелост процеса развоја софтвера
Основа квалитета софтвера лежи у стандардизацији развојних процеса. Нивои СПИЦЕ способности у аутомобилској индустрији су тренутно мерило у индустрији за зрелост софтверских процеса, али достизање ЦЛ2 или ЦЛ3 је само основа. Оно што заиста одређује квалитет испоруке софтвера је контрола одступања током извршавања процеса. Узимајући управљање захтевима као пример, уобичајено одступање је да се, након промене захтева, повезани тест случајеви не ажурирају синхроно. У једном пројекту, откривено је да функција ОТА надоградње након СОП-а има проблем да када је возило ниско напуњено, задатак преузимања ОТА би био суспендован на неодређено време без пријављивања грешке. Основни узрок је био тај што је документ са захтевима додао логику заштите од ниског стања пуњења, али одговарајући тестни случајеви су и даље покривали само верификацију функције преузимања без укључивања сценарија прекида и опоравка. Од увода до открића, овај недостатак је обухватао четири итеративне верзије, а цена корекције била је скоро четрдесет пута већа него да је рано откривена. Матрица следљивости захтева треба да буде уграђена у цевовод континуиране интеграције. Када се статус захтева промени у промењен, задаци прегледа за повезане тестне случајеве треба аутоматски да се покрену, а тест случајеви који нису прошли преглед треба да буду означени као блокирајуће ставке. Преглед кода такође треба да буде квантификован. Истраживања показују да модули са мање од два коментара за рецензије на хиљаду редова кода имају густину дефекта-објављивања више од три пута већу од модула са више од пет коментара на хиљаду редова. Међутим, број коментара на рецензију се не може користити као апсолутни показатељ јер постоје и коментари ниског{14}}квалитета. Ефикасан приступ је класификовати коментаре прегледа у пет категорија: логичке грешке, недостајући гранични услови, читљивост кода, ризици перформанси и безбедносни ризици, са посебним фокусом на стопу откривања две фаталне категорије: логичке грешке и безбедносни ризици.
ИИ. Континуирана интеграција и континуирано тестирање
Убрзање софтверске итерације захтева померање тестирања улево, што значи да се провера квалитета уводи у фази урезивања кода. Јединично тестирање је крајња лева линија одбране, али у стварним пројектима покривеност кода јединичним тестом често пати од надуваних вредности. У једном пројекту контролера, извештај теста јединице показао је покривеност линије од 92%, али је и даље пронађен велики број основних грешака током интеграцијског тестирања. Ретроспективна анализа је открила да иако су линије кода које садрже ове грешке извршене, тестне тврдње нису проверавале релевантне излазе. Покривеност линије само указује да је код извршен, а не да су излази верификовани. Један од метода побољшања је увођење тестирања мутација, које аутоматски генерише мутанте кода за процену ефикасности тест случајева. Ако мутант није убијен, то указује на недостатак у тест тврдњама. Још једна болна тачка у цевоводима за континуирану интеграцију је прекомерно време извршења теста. У складишту софтвера једног ОЕМ-а, комплетном пакету регресијских тестова било је потребно више од 20 сати да се покрене, што значи да су програмери често морали да чекају до следећег дана да би добили повратне информације након слања кода. Решења укључују паралелно тестирање, приоритизацију тест случајева и инкрементално тестирање. Паралелно тестирање дели тестни пакет на више извршних чворова, смањујући време извршења на приближно једну-десетину оригиналног. Одређивање приоритета тест случајева је засновано на историјској дистрибуцији дефеката, дајући приоритет 20% тест случајева који ће највероватније открити нове дефекте. Овај подскуп може да ухвати приближно 70% нових дефеката. Инкрементално тестирање извршава само тест случајеве који се односе на тренутну промену кода, користећи статичку анализу за идентификацију обима утицаја промене да би се динамички филтрирао опсег теста.
ИИИ. Мерење софтверских грешака и анализа узрока
Метрике мерења за софтверске дефекте треба да се третирају другачије од хардверских дефеката. Дефекти хардвера се обично фокусирају на густину дефеката, као што је број дефеката на милион делова. Међутим, дистрибуција софтверских дефеката следи Парето принцип, са приближно 80% озбиљних дефеката концентрисаних у 20% модула. Стога је ефикаснија метрика тренд конвергенције дефекта на нивоу модула-, што значи нето промену отворених дефеката за сваки модул током итерација. Ако модул покаже нето повећање отворених дефеката за три узастопне итерације, то сугерише фундаментални архитектонски проблем који захтева преглед рефакторисања. Дубина анализе основног узрока дефекта одређује ефикасност превентивних акција. Уобичајени класификациони оквир категоризује основне узроке софтверског квара у пет типова: одступање у разумевању захтева, дефекти логичке конструкције, грешке у имплементацији кодирања, грешке у управљању конфигурацијом и разлике у зависности од средине. Грешке у управљању конфигурацијом су јединствена категорија за софтверске пројекте. Уобичајени примери укључују коришћење погрешне верзије библиотеке средњег софтвера, недоследне поставке опција компајлера и недостајуће критичне исправке током спајања грана. У једном пројекту, откривена је логичка грешка у контроли кочионог светла током последње рунде тестирања пре испоруке. Грешка је праћена до спајања гране три месеца раније, где је програмер погрешно изабрао да одбаци све промене на модулу за контролу кочионог светла приликом спајања кода функције из главне гране. Овај случај сугерише да би поређење разлика након спајања грана требало да постане обавезна капија, са одређеним особљем одговорним за преглед захтева за спајање.
ИВ. Опозив софтвера и ОТА управљање
Са широким усвајањем ОТА технологије, метод поправљања софтверских дефеката пролази кроз фундаменталну промену. Традиционално опозив софтвера захтева да возила посећују сервисне центре ради флешовања, што је скупо, дуготрајно-и пати од ниске усклађености корисника. ОТА опозива се може извршити директно путем даљинског притиска, али регулаторних захтева