I. Ωριμότητα Διαδικασίας Ανάπτυξης Λογισμικού
Το θεμέλιο της ποιότητας λογισμικού βρίσκεται στην τυποποίηση των διαδικασιών ανάπτυξης. Τα επίπεδα ικανότητας του Automotive SPICE είναι επί του παρόντος το σημείο αναφοράς του κλάδου για την ωριμότητα της διαδικασίας λογισμικού, αλλά η επίτευξη CL2 ή CL3 είναι μόνο η βασική γραμμή. Αυτό που πραγματικά καθορίζει την ποιότητα παράδοσης λογισμικού είναι ο έλεγχος των αποκλίσεων κατά την εκτέλεση της διαδικασίας. Λαμβάνοντας ως παράδειγμα τη διαχείριση απαιτήσεων, μια κοινή απόκλιση είναι ότι μετά από αλλαγές μιας απαίτησης, οι σχετικές περιπτώσεις δοκιμής δεν ενημερώνονται συγχρονισμένα. Σε ένα έργο, μια συνάρτηση αναβάθμισης OTA βρέθηκε μετά το SOP ότι είχε πρόβλημα όπου όταν το όχημα ήταν σε χαμηλή κατάσταση φόρτισης, η εργασία λήψης OTA θα ανασταλεί επ' αόριστον χωρίς να αναφερθεί σφάλμα. Η βασική αιτία ήταν ότι το έγγραφο απαίτησης είχε προσθέσει λογική προστασίας χαμηλής κατάστασης φόρτισης, αλλά οι αντίστοιχες δοκιμαστικές περιπτώσεις εξακολουθούσαν να καλύπτουν μόνο την επαλήθευση της λειτουργίας λήψης χωρίς να περιλαμβάνουν σενάρια διακοπής και ανάκτησης. Από την εισαγωγή μέχρι την ανακάλυψη, αυτό το ελάττωμα κάλυπτε τέσσερις επαναληπτικές εκδόσεις και το κόστος διόρθωσης ήταν σχεδόν σαράντα φορές υψηλότερο από ό,τι αν είχε εντοπιστεί νωρίς. Ο πίνακας ιχνηλασιμότητας απαιτήσεων πρέπει να ενσωματωθεί στον αγωγό συνεχούς ολοκλήρωσης. Όταν μια κατάσταση απαίτησης αλλάζει σε αλλαγή, οι εργασίες αναθεώρησης για συσχετισμένες δοκιμαστικές περιπτώσεις θα πρέπει να ενεργοποιούνται αυτόματα και οι δοκιμαστικές υποθέσεις που δεν έχουν περάσει τον έλεγχο θα πρέπει να επισημαίνονται ως στοιχεία αποκλεισμού. Η αναθεώρηση του κώδικα πρέπει επίσης να ποσοτικοποιηθεί. Η έρευνα δείχνει ότι οι λειτουργικές μονάδες με λιγότερα από δύο σχόλια κριτικής ανά χίλιες γραμμές κώδικα έχουν πυκνότητα ελαττώματος ανάρτησης{12}}τρεις φορές μεγαλύτερη από τις λειτουργικές μονάδες με περισσότερα από πέντε σχόλια ανά χίλιες γραμμές. Ωστόσο, ο αριθμός των σχολίων κριτικής δεν μπορεί να χρησιμοποιηθεί ως απόλυτος δείκτης, επειδή υπάρχουν και σχόλια χαμηλής-ποιότητας. Μια αποτελεσματική προσέγγιση είναι η ταξινόμηση των σχολίων ανασκόπησης σε πέντε κατηγορίες: λογικά σφάλματα, ελλείπουσες οριακές συνθήκες, αναγνωσιμότητα κώδικα, κίνδυνοι απόδοσης και κίνδυνοι ασφάλειας, με ιδιαίτερη έμφαση στο ποσοστό ανίχνευσης των δύο θανατηφόρων κατηγοριών: λογικά σφάλματα και κίνδυνοι ασφάλειας.
II. Συνεχής ολοκλήρωση και συνεχής δοκιμή
Η επιτάχυνση της επανάληψης λογισμικού απαιτεί μετατόπιση δοκιμών προς τα αριστερά, που σημαίνει ότι η επαλήθευση ποιότητας εισάγεται στο στάδιο της δέσμευσης κώδικα. Η δοκιμή μονάδας είναι η πιο αριστερή γραμμή άμυνας, αλλά στα πραγματικά έργα, η κάλυψη κωδικού δοκιμής μονάδας συχνά υποφέρει από διογκωμένες τιμές. Σε ένα έργο ελεγκτή, η αναφορά δοκιμής μονάδας έδειξε κάλυψη γραμμής 92%, αλλά ένας μεγάλος αριθμός βασικών σφαλμάτων βρέθηκε ακόμα κατά τη διάρκεια της δοκιμής ενοποίησης. Η αναδρομική ανάλυση αποκάλυψε ότι αν και οι γραμμές κώδικα που περιείχαν αυτά τα σφάλματα εκτελέστηκαν, οι ισχυρισμοί δοκιμής δεν έλεγξαν τα σχετικά αποτελέσματα. Η κάλυψη γραμμής υποδεικνύει μόνο ότι ο κώδικας έχει εκτελεστεί και όχι ότι οι έξοδοι έχουν επαληθευτεί. Μια μέθοδος βελτίωσης είναι η εισαγωγή της δοκιμής μετάλλαξης, η οποία δημιουργεί αυτόματα μεταλλάξεις κώδικα για την αξιολόγηση της αποτελεσματικότητας των περιπτώσεων δοκιμής. Εάν ένας μεταλλαγμένος δεν σκοτωθεί, υποδηλώνει ένα κενό στους ισχυρισμούς δοκιμής. Ένα άλλο σημείο πόνου στους αγωγούς συνεχούς ολοκλήρωσης είναι ο υπερβολικός χρόνος εκτέλεσης της δοκιμής. Σε ένα αποθετήριο λογισμικού ενός OEM, η πλήρης σουίτα δοκιμής παλινδρόμησης απαιτούσε περισσότερες από 20 ώρες για να εκτελεστεί, πράγμα που σημαίνει ότι οι προγραμματιστές έπρεπε συχνά να περιμένουν μέχρι την επόμενη μέρα για να λάβουν σχόλια μετά την υποβολή του κώδικα. Οι λύσεις περιλαμβάνουν παράλληλες δοκιμές, ιεράρχηση προτεραιοτήτων δοκιμαστικών περιπτώσεων και αυξητικές δοκιμές. Η παράλληλη δοκιμή χωρίζει τη δοκιμαστική σουίτα σε πολλούς κόμβους εκτέλεσης, μειώνοντας τον χρόνο εκτέλεσης περίπου στο ένα-δέκατο του αρχικού. Η ιεράρχηση των δοκιμαστικών περιπτώσεων βασίζεται στην ιστορική κατανομή ελαττωμάτων, δίνοντας προτεραιότητα στο 20% των περιπτώσεων δοκιμής που είναι πιο πιθανό να εντοπίσουν νέα ελαττώματα. Αυτό το υποσύνολο μπορεί να καταγράψει περίπου το 70% των νέων ελαττωμάτων. Η επαυξητική δοκιμή εκτελεί μόνο περιπτώσεις δοκιμών που σχετίζονται με την τρέχουσα αλλαγή κώδικα, χρησιμοποιώντας στατική ανάλυση για τον προσδιορισμό του εύρους επιπτώσεων από την αλλαγή για το δυναμικό φιλτράρισμα του εύρους δοκιμής.
III. Μέτρηση ελαττωμάτων λογισμικού και ανάλυση βασικών αιτιών
Οι μετρήσεις μέτρησης για ελαττώματα λογισμικού πρέπει να αντιμετωπίζονται διαφορετικά από τα ελαττώματα υλικού. Τα ελαττώματα υλικού εστιάζονται συνήθως στην πυκνότητα του ελαττώματος, όπως ο αριθμός των ελαττωμάτων ανά εκατομμύριο εξαρτήματα. Ωστόσο, η κατανομή ελαττωμάτων λογισμικού ακολουθεί την αρχή Pareto, με περίπου το 80% των σοβαρών ελαττωμάτων να συγκεντρώνονται στο 20% των μονάδων. Επομένως, μια πιο αποτελεσματική μέτρηση είναι η τάση σύγκλισης ελαττωμάτων σε επίπεδο ενότητας-, που σημαίνει την καθαρή αλλαγή στα ανοιχτά ελαττώματα για κάθε λειτουργική μονάδα σε επαναλήψεις. Εάν μια ενότητα εμφανίζει καθαρή αύξηση στα ανοιχτά ελαττώματα για τρεις διαδοχικές επαναλήψεις, υποδηλώνει ένα θεμελιώδες αρχιτεκτονικό πρόβλημα που απαιτεί αναθεώρηση ανακατασκευής. Η ανάλυση του βάθους της βασικής αιτίας του ελαττώματος καθορίζει την αποτελεσματικότητα των προληπτικών ενεργειών. Ένα ευρέως χρησιμοποιούμενο πλαίσιο ταξινόμησης κατηγοριοποιεί τις βασικές αιτίες ελαττωμάτων λογισμικού σε πέντε τύπους: απόκλιση κατανόησης απαιτήσεων, ελαττώματα λογικής σχεδίασης, σφάλματα εφαρμογής κωδικοποίησης, λάθη διαχείρισης διαμόρφωσης και διαφορές περιβαλλοντικής εξάρτησης. Τα λάθη διαχείρισης παραμέτρων είναι μια μοναδική κατηγορία για έργα λογισμικού. Συνήθη παραδείγματα περιλαμβάνουν τη χρήση λανθασμένης έκδοσης μιας βιβλιοθήκης ενδιάμεσου λογισμικού, τις ασυνεπείς ρυθμίσεις επιλογών μεταγλωττιστή και την έλλειψη κρίσιμων επιδιορθώσεων κατά τη συγχώνευση διακλαδώσεων. Σε ένα έργο, ανακαλύφθηκε ένα λογικό σφάλμα ελέγχου των φώτων φρένων κατά τον τελευταίο γύρο δοκιμών πριν από την παράδοση. Το σφάλμα εντοπίστηκε σε μια συγχώνευση κλάδου τρεις μήνες νωρίτερα, όπου ο προγραμματιστής είχε επιλέξει λανθασμένα να απορρίψει όλες τις αλλαγές στη μονάδα ελέγχου των φώτων φρένων κατά τη συγχώνευση του κωδικού χαρακτηριστικών από τον κύριο κλάδο. Αυτή η περίπτωση υποδηλώνει ότι η σύγκριση διαφορών μετά τη συγχώνευση υποκαταστημάτων θα πρέπει να γίνει υποχρεωτική πύλη, με καθορισμένο προσωπικό υπεύθυνο για την εξέταση των αιτημάτων συγχώνευσης.
IV. Ανάκληση Λογισμικού και Διαχείριση ΟΤΑ
Με την ευρεία υιοθέτηση της τεχνολογίας OTA, η μέθοδος επιδιόρθωσης ελαττωμάτων λογισμικού υφίσταται μια θεμελιώδη αλλαγή. Οι παραδοσιακές ανακλήσεις λογισμικού απαιτούν από τα οχήματα να επισκέπτονται τα κέντρα εξυπηρέτησης για να αναβοσβήνουν, κάτι που είναι δαπανηρό,-και χρονοβόρο και υποφέρει από χαμηλή συμμόρφωση χρήστη. Οι ανακλήσεις OTA μπορούν να ολοκληρωθούν απευθείας μέσω απομακρυσμένης ώθησης, αλλά ρυθμιστικές απαιτήσεις