א. בשלות תהליך פיתוח תוכנה
הבסיס של איכות התוכנה טמון בסטנדרטיזציה של תהליכי פיתוח. רמות יכולת SPICE לרכב הן כיום אמת מידה בתעשייה עבור בשלות תהליכי תוכנה, אך הגעה ל-CL2 או CL3 היא רק קו הבסיס. מה שבאמת קובע את איכות אספקת התוכנה הוא בקרת הסטיות במהלך ביצוע התהליך. אם ניקח לדוגמה את ניהול הדרישות, סטייה נפוצה היא שלאחר שינוי דרישה, מקרי הבדיקה הקשורים אינם מתעדכנים באופן סינכרוני. בפרויקט אחד, פונקציית שדרוג OTA נמצאה לאחר SOP עם בעיה שבה כאשר הרכב היה במצב טעינה נמוך, משימת ההורדה של OTA תושעה ללא הגבלת זמן מבלי לדווח על שגיאה. הסיבה העיקרית הייתה שמסמך הדרישה הוסיף לוגיקה להגנה על מצב טעינה נמוך, אך מקרי הבדיקה התואמים עדיין כיסו רק אימות פונקציית הורדה מבלי לכלול תרחישי הפרעה ושחזור. מההקדמה ועד לגילוי, הפגם הזה השתרע על פני ארבע גרסאות איטרטיביות, ועלות התיקון הייתה גבוהה כמעט פי ארבעים מאשר אילו היה נמצא מוקדם. יש להטמיע את מטריצת העקיבה של הדרישות בצינור האינטגרציה הרציף. כאשר סטטוס דרישה משתנה לשינוי, יש להפעיל אוטומטית את משימות הבדיקה עבור מקרי בדיקה משויכים, ויש לסמן מקרי בדיקה שלא עברו בדיקה כפריטים חוסמים. יש גם לכמת סקירת קוד. מחקרים מראים שלמודולים עם פחות משתי הערות ביקורת לכל אלף שורות קוד יש צפיפות פגמים של פרסום-שגבוהה יותר מפי שלושה ממודולים עם יותר מחמש הערות לאלף שורות. עם זאת, לא ניתן להשתמש במספר הערות הביקורת כאינדיקטור מוחלט מכיוון שקיימות גם הערות באיכות נמוכה-. גישה יעילה היא לסווג הערות ביקורת לחמש קטגוריות: שגיאות לוגיות, תנאי גבול חסרים, קריאות קוד, סיכוני ביצועים וסיכוני בטיחות, תוך התמקדות מיוחדת בשיעור הזיהוי של שתי הקטגוריות הקטלניות: שגיאות לוגיות וסיכוני בטיחות.
II. אינטגרציה מתמשכת ובדיקות מתמשכות
האצת איטרציית התוכנה מחייבת העברה של בדיקות שמאלה, כלומר אימות האיכות מוצג בשלב התחייבות הקוד. בדיקת יחידות היא קו ההגנה השמאלי ביותר, אך בפרויקטים בפועל, כיסוי קוד בדיקות יחידה סובל לעתים קרובות מערכים מנופחים. בפרויקט בקר אחד, דוח בדיקת היחידה הראה כיסוי קו של 92%, אך עדיין נמצאו מספר רב של שגיאות בסיסיות במהלך בדיקות האינטגרציה. ניתוח רטרוספקטיבי העלה כי למרות ששורות הקוד המכילות שגיאות אלו בוצעו, קביעות הבדיקה לא בדקו את הפלטים הרלוונטיים. כיסוי קו מציין רק שהקוד בוצע, לא שהפלטים אומתו. שיטת שיפור אחת היא הצגת בדיקת מוטציות, אשר מייצרת אוטומטית מוטציות קוד כדי להעריך את היעילות של מקרי בדיקה. אם מוטנט לא נהרג, זה מצביע על פער בקביעות הבדיקה. נקודת כאב נוספת בצינורות אינטגרציה מתמשכת היא זמן ביצוע בדיקה מופרז. במאגר התוכנה של OEM אחד, חבילת בדיקות הרגרסיה השלמה דרשה יותר מ-20 שעות כדי לרוץ, כלומר מפתחים נאלצו לעתים קרובות להמתין עד למחרת כדי לקבל משוב לאחר שליחת הקוד. הפתרונות כוללים בדיקות מקבילות, תעדוף מקרי בדיקה ובדיקות מצטברות. בדיקה מקבילה מפצלת את חבילת הבדיקה על פני מספר צמתי ביצוע, ומצמצמת את זמן הביצוע לכ-עשירית מהמקור. תעדוף מקרי בדיקה מבוסס על התפלגות פגמים היסטורית, תוך מתן עדיפות ל-20% ממקרי הבדיקה בעלי הסבירות הגבוהה ביותר לזהות פגמים חדשים. תת-קבוצה זו יכולה ללכוד כ-70% מהפגמים החדשים. בדיקות מצטברות מבצעות רק מקרי בדיקה הקשורים לשינוי הקוד הנוכחי, תוך שימוש בניתוח סטטי כדי לזהות את היקף ההשפעה מהשינוי לסינון דינמי של היקף הבדיקה.
III. מדידת פגמים בתוכנה וניתוח סיבות שורש
יש להתייחס למדדי מדידה של פגמי תוכנה בצורה שונה מפגמי חומרה. פגמי חומרה מתמקדים בדרך כלל בצפיפות הפגמים, כגון מספר הפגמים למיליון חלקים. עם זאת, הפצת פגמים בתוכנה פועלת לפי עקרון פארטו, כאשר כ-80% מהפגמים החמורים מרוכזים ב-20% מהמודולים. לכן, מדד יעיל יותר הוא מגמת התכנסות הפגמים ברמת המודול-, כלומר השינוי נטו בפגמים הפתוחים עבור כל מודול על פני איטרציות. אם מודול מראה עלייה נטו בפגמים פתוחים במשך שלוש איטרציות רצופות, זה מרמז על בעיה ארכיטקטונית בסיסית הדורשת סקירה מחדש. עומק ניתוח שורשי הפגם קובע את האפקטיביות של פעולות מניעה. מסגרת סיווג נפוצה מקטלגת את גורמי השורש של פגמי תוכנה לחמישה סוגים: סטייה בהבנת הדרישות, פגמים בלוגיקה בתכנון, שגיאות יישום קידוד, טעויות בניהול תצורה והבדלי תלות סביבתית. טעויות בניהול תצורה הן קטגוריה ייחודית לפרויקטי תוכנה. דוגמאות נפוצות כוללות שימוש בגרסה שגויה של ספריית תוכנות ביניים, הגדרות אפשרויות מהדר לא עקביות ותיקונים קריטיים חסרים במהלך מיזוג סניפים. בפרויקט אחד, התגלתה שגיאה לוגית בקרת אור בלמים במהלך סבב הבדיקה האחרון לפני המסירה. השגיאה מקורה במיזוג סניפים שלושה חודשים קודם לכן, שבו היזם בחר בטעות לבטל את כל השינויים במודול בקרת אורות הבלמים בעת מיזוג קוד תכונה מהענף הראשי. מקרה זה מצביע על כך שהשוואת הבדלים לאחר מיזוג סניפים צריכה להפוך לשער חובה, עם צוות ייעודי שאחראי לבדיקת בקשות המיזוג.
IV. ריקול תוכנה וניהול OTA
עם האימוץ הנרחב של טכנולוגיית OTA, שיטת תיקון פגמי התוכנה עוברת שינוי מהותי. החזרת תוכנה מסורתית מחייבת רכבים לבקר במרכזי שירות לצורך הבהוב, דבר שהוא יקר, גוזל זמן-וסובל מתאימות נמוכה של משתמשים. ניתן להשלים ריקול של OTA ישירות באמצעות דחיפה מרחוק, אך דרישות רגולטוריות