Επαλήθευση Signoff Beyond Coverage

Μια κοινή άποψη σχεδιασμού της σήμανσης επαλήθευσης είναι η έναρξη με ένα ολοκληρωμένο σχέδιο επαλήθευσης, που καλύπτει κάθε απαίτηση που ορίζεται μεταξύ των προδιαγραφών και των περιπτώσεων χρήσης, του αρχιτεκτονικού ορισμού και τυχόν άλλων σχετικών εγγράφων. Στη συνέχεια αναπτύσσονται δοκιμές για να καλύψουν κάθε χαρακτηριστικό του σχεδίου επαλήθευσης. Αυτές οι δοκιμές εκτελούνται και διορθώνονται και τα εντοπισμένα ζητήματα αντιμετωπίζονται στο πλαίσιο του σχεδιασμού. Αυτή η διαδικασία επαναλαμβάνεται μέχρι να επιτευχθεί το συμφωνημένο επίπεδο κάλυψης. Η λειτουργική κάλυψη είναι η μέτρηση με την οποία μετράται αυτή η διαδικασία και λειτουργεί καλά εντός του πεδίου εφαρμογής της. Οι σημαντικότεροι προμηθευτές ηλεκτρονικών αυτοματισμών σχεδιασμού (EDA) διαθέτουν εργαλεία για την εκτέλεση προσομοιώσεων, τη συγκέντρωση στατιστικών στοιχείων κάλυψης και την περαιτέρω προώθηση αυτών των μετρήσεων. Αλλά αυτή δεν είναι όλη η ιστορία στην υπογραφή. Η κάλυψη μετρά τη συμμόρφωση με το σχέδιο επαλήθευσης, το οποίο αφαιρείται αρκετά βήματα από τις απαιτήσεις του πελάτη. Πώς γνωρίζουν οι σχεδιαστές ότι οι κρίσιμες πληροφορίες δεν απορρίφθηκαν ή προστέθηκαν στην πορεία;

Τι άλλο έχει σημασία στο signoff;

Όλα πριν από τις εσωτερικά αναπτυγμένες λειτουργικές προδιαγραφές/απαιτήσεις έχουν σημασία. Δεν είναι δυνατό να κλείσει πλήρως ο βρόχος μεταξύ των απαιτήσεων των πελατών και της υλοποίησης/επαλήθευσης, εκτός εάν περιλαμβάνονται στην ανάλυση. Τώρα οι αλυσίδες αξίας συμπιέζονται και τα συστήματα-σε-τσιπ (SoC) γίνονται πιο ειδικά για εφαρμογές. Οι πελάτες αναμένουν σχέδια προσαρμοσμένα στις ακριβείς ανάγκες τους, επομένως αυτά που όρισαν ως απαιτήσεις πρέπει να ταιριάζουν στην υλοποίηση/επαλήθευση. Δεν θα τύχει καλής υποδοχής εάν ο πελάτης ανακαλύψει ότι αναμένεται να επιδιορθώσει τις αναντιστοιχίες.

Η πρόκληση εδώ είναι ότι ο ορισμός μπορεί να είναι ένας μάλλον μικτός σάκος εισόδων: Word, PDF, έγγραφα που βασίζονται σε DITA, υπολογιστικά φύλλα, Simulink, SysML ή πρωτότυπα εικονικά μοντέλα και φορτία λογισμικού που θα πρέπει να εκτελούνται στο τελικό υλικό (ίσως με περιθώριο αλλαγές). Μπορεί επίσης να υπάρχουν τεκμηριωμένες απαιτήσεις σε DOORS, Jama Connect ή σε παρόμοια μορφή. Πώς υποδηλώνει η ομάδα επαλήθευσης, η ομάδα σχεδιασμού ή ο αρχιτέκτονας ότι η υλοποίηση και η επαλήθευση ταιριάζουν με τις απαιτήσεις; Θα κάνουν ό,τι καλύτερο μπορούν, φυσικά, αλλά πού είναι η λεπτομερής και ελεγχόμενη διαδικασία για να διασφαλιστεί ότι κάθε απαίτηση αντιστοιχεί σε μια υλοποίηση υλοποίησης και ότι η επαλήθευση της υλοποίησης καλύπτεται επαρκώς;

Για να γίνει αυτό πιο συγκεκριμένο, ας υποθέσουμε ότι υπάρχει ένα χαρακτηριστικό που θέλει ένας σημαντικός πελάτης, αλλά κανείς άλλος δεν το απαιτεί. Ίσως λόγω παράβλεψης ή παρεξήγησης, αυτό το χαρακτηριστικό δεν εντάσσεται στις λειτουργικές προδιαγραφές/απαίτηση. Συμβαίνει πάρα πολύ συχνά. Ακόμη και το ιδανικό της κάλυψης 100% δεν θα αντιμετωπίσει αυτό το πρόβλημα, καθώς η κάλυψη είναι τόσο καλή όσο το σχέδιο επαλήθευσης. Υπάρχει μεγάλο πρόβλημα εάν το σχέδιο επαλήθευσης δεν αντικατοπτρίζει με ακρίβεια τις απαιτήσεις.

Ή ας υποθέσουμε ότι κατά τη διάρκεια του σχεδιασμού, μια ομάδα αποφασίζει ότι δεν μπορεί να εφαρμόσει ακριβώς αυτό που ζητάει η προδιαγραφή, αλλά εφαρμόζεται μια εναλλακτική με την πεποίθηση ότι θα είναι εξίσου καλή ή ακόμα καλύτερη. Η ομάδα δεν γνωρίζει ότι αυτή η αλλαγή θα επηρεάσει την απόδοση σε κάποια σπάνια αλλά σημαντική περίπτωση χρήσης. Ίσως αυτό να πιαστεί σε προσομοίωση; Ίσως, αλλά είναι πολύ δύσκολο να είσαι ολοκληρωμένος σε δοκιμές σε επίπεδο συστήματος. Υπάρχει πραγματικός κίνδυνος αυτή η προβληματική αλλαγή να επιβιώσει μέχρι το πυρίτιο.

Η ιχνηλάτηση απαιτήσεων συμπληρώνει την κάλυψη για αποσύνδεση επαλήθευσης

Ο έλεγχος ισοδυναμίας μεταξύ εγγράφων του Word, εικονικών μοντέλων και επιπέδου μεταφοράς μητρώου (RTL) δεν είναι πιθανό να είναι δυνατός στη διάρκεια της ζωής μας, αλλά δεν χρειάζεται να είναι. Οι κατασκευαστές συστημάτων και οι ομάδες λογισμικού χρησιμοποιούν ήδη ενεργά την ιχνηλασιμότητα απαιτήσεων ως μια πολύ ισχυρή μέθοδο για την παρακολούθηση της αντιστοιχίας μεταξύ απαιτήσεων ανώτατου και επιπέδου υλοποίησης, μέχρι την υλοποίηση, την επαλήθευση και τη δοκιμή. Αυτή η ιχνηλασιμότητα υποστηρίζεται με την ανίχνευση απαιτήσεων με χρήση της μορφής ανταλλαγής απαιτήσεων (ReqIF) με πλατφόρμες όπως τα εργαλεία DOORS και Jama Connect.

Αν και αυτά τα εργαλεία έχουν σχεδιαστεί για εύκολη υιοθέτηση στον κόσμο του λογισμικού, δεν κατανοούν τη σημασιολογία υλικού. Υποστηρίζουν συνδέσεις «ξένου αντικειμένου» για σύνδεση με δεδομένα σχεδίασης και επαλήθευσης, αλλά το βάρος για τη σωστή δημιουργία αυτών των συνδέσεων πέφτει στους μηχανικούς σχεδιασμού και επαλήθευσης. Αυτό μπορεί να μην ήταν τόσο κακό αν υπήρχαν μόνο μερικές εκατοντάδες αντικείμενα για παρακολούθηση. Σκεφτείτε όμως τον χάρτη μνήμης, τον χάρτη διακοπής, τον χάρτη IO muxing. Αυτά μπορεί να εκτελούνται σε δεκάδες χιλιάδες αντικείμενα ή περισσότερα. Οι μη αυτόματες ενημερώσεις όλων αυτών των αντικειμένων μέσω αλλαγών σχεδιασμού και επαναδιαμερισμού καθίστανται εξαιρετικά δύσκολες, αν όχι αδύνατες.

Μια καλύτερη προσέγγιση είναι μέσω της διαχείρισης ιχνηλασιμότητας, η οποία μπορεί να συνδεθεί με εργαλεία όπως το ReqIF από την πλευρά του πελάτη και απευθείας με τα τεχνουργήματα που παρακολουθούνται από τις ομάδες σχεδιασμού και επαλήθευσης. Η κατανόηση της σημασιολογίας του σχεδιασμού επιτρέπει τη δυνατότητα να συναχθούν οι συνδέσεις μεταξύ των απαιτήσεων και της υλοποίησης και να διατηρηθούν σωστά αυτές οι παρακολουθήσεις καθώς εξελίσσεται το έργο. Αυτή η μέθοδος εξασφαλίζει ελεγχόμενες συνδέσεις από τις προδιαγραφές των πελατών, μέχρι τις απαιτήσεις σχεδιασμού και τελικά μέχρι την υλοποίηση του SoC.

Αυτή είναι η ιχνηλασιμότητα που μπορεί να ολοκληρώσει τον στόχο επισήμανσης επαλήθευσης με χαμηλό αντίκτυπο στις ομάδες σχεδιασμού SoC. Το είδος της υποστήριξης ιχνηλασιμότητας που θα βρείτε Arteris Harmony Trace.