HMMY Τεχνολογία Λογισμικού Διδάσκων Κώστας Κοντογιάννης Αναπλ. Καθηγητής, Ε.Μ.Π

Σύνοψη  Αξιοπιστία Λογισμικού –Τι είναι η αξιοπιστία συστημάτων λογισμικού? –Βασικές αρχές –Μοντέλα

Αξιοπιστία Λογισμικού – Ορισμός - Χρήση Η αξιοπιστία ενός συστήματος λογισμικού ορίζεται σαν η πιθανότητα P(t) ότι το σύστημα δεν θα αστοχήσει στο διάστημα κάποιου συγκεκριμένου χρόνου λειτουργίας του t, και δεδομένου ότι το σύστημα λειτουργεί σε κάποιο περιβάλλον e Η αξιοπιστία ενός συστήματος λογισμικού επηρεάζεται κατά το πλείστον από τη διαδικασία προδιαγραφής / σχεδίασης / υλοποίησης / ελέγχου και όχι από τη χρόνο χρήσης του (σε αντίθεση με άλλα «φυσικά» συστήματα π.χ. μια μηχανή) Η έννοια της αξιοπιστίας ενός συστήματος λογισμικού χρησιμοποιείται ως: –Διαχείριση έργων: είμαστε έτοιμοι για τη νέα έκδοση του συστήματος? Χρειαζόμαστε περισσότερο έλεγχο (testing)? –Υπολογισμό εύρους αλλαγής και επέκτασης: οι αλλαγές στον κώδικα μπορεί να μειώσουν την αξιοπιστία του συστήματος –Κριτήριο για την αξιολόγηση κάποιας μεθοδολογίας ή τεχνολογίας κατασκευής λογισμικού / /

Βασικές Αρχές Αστοχία Συστήματος, Σφάλμα, Ελάττωμα –Ελάττωμα (fault): Κάποιο ελάττωμα στον κώδικα που μπορεί να οδηγήσει το σύστημα σε αστοχία. Το ελάττωμα μπορεί να είναι επικεντρωμένο σε ένα σημείο ή να είναι διάσπαρτο (αλληλεπίδραση από διαφορετικούς παράγοντες). Το ελάττωμα μπορεί να οδηγήσει σε σφάλμα ή όχι –Σφάλμα (error): Η διαφοροποίηση της εσωτερικής κατάστασης (state) του συστήματος καθώς αυτό λειτουργεί από την προδιαγεγραμμένη εσωτερική κατάσταση που θα έπρεπε να βρίσκεται το σύστημα κατά τη λειτουργία του. Το σφάλμα μπορεί να οδηγήσει σε αστοχία ή όχι –Αστοχία Συστήματος (failure): Η διαφοροποίηση της παρατηρούμενης συμπεριφοράς του συστήματος από αυτή που έχει προδιαγραφεί Χρόνος –Χρόνος εκτέλεσης (σε χρόνο μηχανής CPU time)  –Ημερολογιακός χρόνος εκτέλεσης - Calendar time (t) Η έννοια της αστοχίας του συστήματος σε σχέση με την έννοια του χρόνου –Η αστοχία είναι στιγμιαία –Χρήσιμη μετρική είναι ο χρόνος ανάμεσα σε δύο αστοχίες - Time between failures) –Άλλη χρήσιμη μετρική είναι ο συνολικός αριθμός αστοχιών μέχρι κάποιο συγκεκριμένο χρόνο λειτουργίας (π.χ. Από το χρόνο αρχικής έκδοση του συστήματος) - Cumulative failures) –Τέλος μια άλλη μετρική είναι ο αριθμός αστοχιών σε κάποιο συγκεκριμένο χρονικό όριο (π.χ. Μεταξύ 500 και 700 CPU hours) - Failures in a time interval

Βασική Ερώτηση : Πως μπορούμε να υπολογίσουμε την αύξηση της αξιοπιστίας ενός συστήματος λογισμικού όσο αφαιρούμε ελαττώματα από τον κώδικα? Σημεία Προβληματισμού : Έλεγχος - ( Πόσο πρέπει να ελέγξουμε ? Πότε μπορούμε να σταματήσουμε το έλεγχο? ) Κατά τη λειτουργία ( Πόσοι χρειάζονται για την υποστήριξη του συστήματος ?) Αυξητικά μοντέλα αξιοπιστίας λογισμικού ( S/W reliability growth models ) : Παρατηρούμε τη συμπεριφορά αστοχίας του συστήματος από ιστορικά δεδομένα και υπολογίζουμε τη μελλοντική του συμπεριφορά (σε σχέση με πάντα με τις αναμενόμενες αστοχίες). Στη βιβλιογραφία έχουν προταθεί περίπου 40 διαφορετικά μοντέλα. Αξιοπιστία Λογισμικού

Ορολογία Ελάττωμα (Fault) Σφάλμα (Error) Αστοχία (Failure) Είναι στον κώδικα... (bug) Εσωτερική κατάσταση του συστήματος Παρατηρούμενη Μπορεί να προκαλέσει

Βασικές Αρχές – Σχηματικά Σύστημα Λογισμικού Τι μετράμε: Μέσο συνολικό αριθμό αστοχιών (Average Total Number of Failures): μ(τ), Ένταση αστοχιών (Failure Intensity) – Αριθμός αστοχιών στη μονάδα του χρόνου : λ(τ) Συνολικός μέσος χρόνος ανάμεσα σε διαδοχικές αστοχίες του συστήματος (Mean Time to Failure): 1/λ(τ) Παρατηρούμενες Αστοχίες Τυχαία επιλογή εκτέλεσης Το σύστημα εκτελείται K φορές με διαφορετικά δεδομένα εισόδου κάθε φορά σε ένα ή περισσότερους (ίδιους) υπολογιστές

Αξιοπιστία και Διαθεσιμότητα Μια απλή μετρική της έννοιας της αξιοπιστίας (reliability) είναι η : MTBF = MTTF + MTTR, όπου MTBF Συνολικός μέσος χρόνος ανάμεσα σε διαδοχικές αστοχίες του συστήματος MTTF μέσος χρόνος ανάμεσα σε διαδοχικές αστοχίες του συστήματος MTTR μέσος χρόνος αποκατάστασης ελαττώματος Η MTBF είναι καλύτερος εκτιμητής της αξιοπιστίας από ότι η μετρική “ελαττώματα/KLOC”

Διαθεσιμότητα ( Availability ) ορίζεται σαν η πιθανότητα το σύστημα να συμπεριφερθεί σύμφωνα με τις προδιαγραφές του όταν ζητηθεί η λειτουργία του σε κάποια συγκεκριμένη χρονική στιγμή. Γενικά, η μετρική της έννοιας της διαθεσιμότητας είναι και καλύτερος εκτιμητής της συντηρισιμότητας ενός συστήματος από τη μετρική MTTR. Αξιοπιστία και Διαθεσιμότητα

Ένταση Αστοχιών σε «φυσικά» Συστήματα και Κατασκευές

Ένταση Αστοχιών σε Συστήματα Λογισμικού

Μεθοδολογίες Υπολογισμού Αξιοπιστίας Λογισμικού Τα πιο γνωστά μοντέλα / μεθοδολογίες υπολογισμού αξιοπιστίας συστημάτων λογισμικού εμπίπτουν σε δύο βασικές ομάδες : Μοντέλα σποράς ελαττωμάτων (error seeding) Αυξητικά μοντέλα αξιοπιστίας (reliability growth models) error seeding – Είναι μέθοδος υπολογισμού του αριθμού των ελαττωμάτων που βρίσκονται στον κώδικα. Σε αυτή τη μεθοδολογία τα ελαττώματα εμπίπτουν σε δύο κατηγορίες – αυτά που υπάρχουν στον κώδικα και αυτά που εμείς ηθελημένα τοποθετούμε (και φυσικά γνωρίζουμε πόσα είναι). Ο αριθμός των ελαττωμάτων που υπάρχουν στον κώδικα υπολογίζεται από τον (θεωρούμενο σταθερό) λόγο των του αριθμού των δύο τύπων ελαττωμάτων, όπως αυτά ανακαλύπτονται κατά τον έλεγχο (testing) του συστήματος.

Αυξητικά Μοντέλα Αυτά τα μοντέλα υπολογίζουν τη βελτίωση της αξιοπιστίας ενός συστήματος καθώς ελαττώματα ανακαλύπτονται και διορθώνονται σαν αποτέλεσμα της διαδικασίας ελέγχου (testing) χρησιμοποιώντας μια συνάρτηση βελτίωσης (growth function). Οι ελεύθερες μεταβλητές (μεταβλητές εισόδου) είναι ο χρόνος (time) και οι δεσμευμένες μεταβλητές (αποτέλεσμα) είναι η αξιοπιστία (reliability), ο ρυθμός αστοχίας του συστήματος (system failure rate),ή ο αθροιστικός αριθμός ελαττωμάτων που έχουν εντοπιστεί μέχρι κάποια χρονική στιγμή Μεθοδολογίες Υπολογισμού Αξιοπιστίας Λογισμικού

Μια τυπική μέτρηση για τον υπολογισμό της αξιοπιστίας ενός συστήματος (αριθμός αστοχιών στη μονάδα του χρόνου) είναι η ένταση αστοχιών ( failure intensity ) που ορίζεται από τον ρυθμό : όπου  = χρόνος CPU ( σε ένα multitasking μηχάνημα ) ή ο πραγματικός χρόνος σε κάποιο embedded σύστημα). Μετρήσεις Αξιοπιστίας στα Αυξητικά Μοντέλα

 Π   Γραμμικό (βασικό) Μοντέλο Musa (Musa Basic model) Λογαριθμικό Μοντέλο Musa/Okomoto (Musa/Okomoto Logarithmic model) Αυξητικά Μοντέλα Αξιοπιστίας

Βασικές Υποθέσεις των Μοντέλων Αξιοπιστίας Λογισμικού Musa 1.Τα ελαττώματα στον κώδικα είναι ανεξάρτητα το ένα από το άλλο και κατανέμονται με ένα σταθερό ρυθμό εμφάνισης. 2.Ο χρόνος εκτέλεσης του συστήματος είναι μεγαλύτερος από το χρόνο εκτέλεσης μιας εντολής του προγράμματος. 3.Ο έλεγχος της λειτουργίας του συστήματος καλύπτει όλες τις λειτουργίες που το σύστημα θα προσφέρει κατά την χρήση του ( ‘test space’ covers ‘use space’ ). 4.Τα δεδομένα εισόδου και οι περιπτώσεις ελέγχου (test cases) επιλέγονται τυχαία. 5.Όλες οι αστοχίες παρατηρούνται. 6.Τα ελαττώματα που δημιουργούν την αστοχία επιδιορθώνονται αμέσως. Η εμφάνιση του ίδιου ελαττώματος δεν προσμετρείται δυο φορές.

Βασικό Μοντέλο Musa Η Ένταση Αστοχίας ( Failure Intensity ) - (FI) ορίζεται όπως είπαμε σαν ο αριθμός αστοχιών στη μονάδα του χρόνου. Το Βασικό Μοντέλο Musa θεωρεί ότι η ελάττωση της Έντασης Αστοχίας (παράγωγος σε σχέση με το συνολικό αριθμό αστοχιών μ) είναι σταθερή. Αυτό συνεπάγεται ότι η Ένταση Αστοχίας είναι μια συνάρτηση του μέσου συνολικού αριθμού αστοχιών που έχουμε παρατηρήσει μέχρι κάποια χρονική στιγμή (CPU time ή calendar time). Reference: Musa, Iannino, Okumoto, “Software Reliability: Measurement, Prediction, Application”, McGraw-Hill, 1987.

Η Ένταση Αστοχίας ορίζεται ως: Όπου 0 είναι η αρχική Ένταση Αστοχίας στην αρχή εκτέλεσης του συστήματος (πριν γίνει οποιαδήποτε διόρθωση ελαττωμάτων).  είναι ο (μέσος) συνολικός αριθμός αστοχιών μέχρι κάποια συγκεκριμένη στιγμή 0 είναι ο συνολικός αριθμός αστοχιών που περιμένουμε να έχουμε σε απεριόριστο χρόνο εκτέλεσης του προγράμματος Αντίστοιχα, ο μέσος συνολικός αριθμός αστοχιών σαν συνάρτηση του χρόνου εκτέλεσης είναι: Βασικό Μοντέλο Musa

Παράδειγμα : Ας θεωρήσουμε ότι ένα πρόγραμμα θα έχει 100 αστοχίες σε όλη τη λειτουργική του ζωή, και ότι μέχρι στιγμής έχουμε παρατηρήσει 50 αστοχίες, και ότι η αρχική ένταση αστοχίας είναι 10 αστοχίες ανά CPU hour. Τότε η υπολογιζόμενη παρούσα ένταση αστοχίας είναι : Ο (μέσος) συνολικός αριθμός αστοχιών μετά από 10 cpu ώρες λειτουργίας θα είναι: και για 100 CPU ώρες λειτουργίας:

Λογαριθμικό Μοντέλο Η ελάττωση της Έντασης Αστοχίας γίνεται μικρότερη (εκθετική μείωση) όσο ελαττώματα στον κώδικα ανακαλύπτονται και διορθώνονται. (  ) = 0 exp( -  ) όπου  είναι μια παράμετρος εξασθένησης της Έντασης Αστοχίας Αντίστοιχα ο (μέσος) συνολικός αριθμός αστοχιών σε κάποια χρονική στιγμή t είναι:

Παράδειγμα : ας θεωρήσουμε ότι 0 = 10 failures/cpu hour,  = 0.02/failure, καί ότι μέχρι τώρα έχουμε παρατηρήσει 50 αστοχίες. Τότε : Στις 10 cpu hours: Smaller than the Basic model Και στις 100 cpu hours: (περισσότερες αστοχίες από το Βασικό Μοντέλο)

Τα Μοντέλα Musa - Συνοπτικά Βασικό Μοντέλο  v 0 [1 – exp    /v 0   0 exp    /v 0  Λογαριθμικό Μοντέλο  ln  0     0    v0v0 Basic Log.  Basic Log.

Παράδειγμα Ερ. Ας θεωρήσουμε ότι ένα σύστημα θα έχει 100 αστοχίες σε όλη τη λειτουργική Του ζωή. Ας υποθέσουμε ότι η αρχική Ένταση Αστοχίας είναι 10 αστοχίες / CPU hour Και ότι η παρούσα Ένταση Αστοχίας είναι 3.68 αστοχίες / CPU hour. Εάν Θέλουμε να πετύχουμε Ένταση Αστοχίας του συστήματος να είναι Αστοχίες / CPU hour. Πόσες ώρες ακόμη θα πρέπει να ελέγξουμε το σύστημα Για να πετύχουμε το επιθυμητό επίπεδο Έντασης Αστοχίας? Απ.: Εάν θεωρήσουμε ότι έχουμε το Βασικό Μοντέλο, τότε  0 exp    /v 0  Στη χρονική στιγμή  1,    0 exp     /v 0  p Στη χρονική στιγμή  2,    0 exp     /v 0  f    -    (v 0 / 0 ).ln( p /  f ) v 0 = 100 faults, 0 = 10 failures/CPU-hr p = 3.68 failures/CPU-hr,  f = failure/CPU-hr = (    -    CPU-hr Συμπληρωματικός χρόνος ελέγχου

Ημερολογιακός Χρόνος Εκτέλεσης Συστήματος Ο ημερολογιακός χρόνος ( calendar time ) υπολογίζεται γνωρίζοντας την τιμή του λόγου : και τη τιμή του χρόνου εκτέλεσης του προγράμματος σε CPU hours. Ο ημερολογιακός χρόνος είναι χρήσιμος για τον γενικό προγραμματισμό του πλάνου για τη διάθεση του συστήματος στους χρήστες του (π.χ. Υπολογίζουμε την ημερομηνία στην οποία θα έχουμε πετύχει κάποια συγκεκριμένη τιμή στη Ένταση Αστοχίας).

Ο ημερολογιακός χρόνος στη πιο σύνθετή του μορφή βασίζεται και στη διαδικασία που ακολουθείται για τη διόρθωση των ελαττωμάτων καθώς και τις παρακάτω παραμέτρους : Τους διαθέσιμους υπολογιστικούς πόρους ; Το βαθμό με τον οποίο ένα πόρος χρησιμοποιείται

Για παράδειγμα, στην αρχή της διαδικασίας ελέγχου παρατηρούμε πολλές αστοχίες σε μικρά χρονικά διαστήματα μεταξύ τους ;  Τότε ο έλεγχος σταματά για να διορθώσουμε τα ελαττώματα στον κώδικα. Όσο ο έλεγχος προχωρά,  Τα χρονικά διαστήματα ανάμεσα σε αστοχίες γίνονται μεγαλύτερα,  Στο μεταξύ το προσωπικό που διορθώνει τα ελαττώματα δεν δουλεύει  Η ομάδα ελέγχου είναι τώρα η ομάδα που δημιοθργλει το «μποτιλιάρισμα»  Τελικά οι υπολογιστικοί πόροι είναι ο παράγων που καθορίζει την αποδοτικότητα της όλης διαδικασίας.

Χρήση Πόρων Ο Musa έδειξε ότι η χρήση των πόρων είναι γραμμικά ανάλογη του χρόνου εκτέλεσης του συστήματος και του μέσου συνολικού αριθμού αστοχιών. Εάν θεωρήσουμε ότι η μεταβλητή  r ορίζει τη χρήση (usage) κάποιου πόρου r, τότε Όπου  r είναι ο χρόνος χρήση του πόρου ανά CPU hour; Και  r είναι ο χρόνος χρήσης του πόρου ανά αστοχία

Συνοπτικά έχουμε Πόροι Χρήση ανά CPU hour Χρήση ανά αστοχία Διαθέσιμοι Πόροι Αξιοποίηση Πόρων Προσωπικό Εύρεσης Ελαττωμάτων Προσωπικό Διόρθωσης Ελαττωμάτων Υπολογιστικοί Πόροι

Παράδειγμα : Μια διαδικασία έλεγχου τρέχει για 10 CPU hours και αναγνωρίζει 34 αστοχίες ; Εάν η προσπάθεια ελέγχου για κάθε ώρα εκτέλεσης του συστήματος είναι 5 person hours, και κάθε αστοχία απαιτεί 2 hours για να ευρεθεί το αντίστοιχο ελάττωμα, τότε. Τότε ο συνολικός χρόνος εύρεσης του ελαττώματος είναι : = 5(10) + 2(34) = 118 person hr

Φάση Λειτουργίας του Συστήματος Όταν το σύστημα μπαίνει πλέον στη λειτουργική του φάση (released, operational phase), και δεν έχουμε κάποια αλλαγή στον κώδικα, τότε η ένταση αστοχιών παραμένει σταθερή. Και τα δύο μοντέλα που είδαμε θα ακολουθήσουν για τον υπολογισμό της αξιοπιστίας του συστήματος μια διαδικασία Poisson με παράμετρο την Ένταση Αξιοπιστίας λ.

Η Αξιοπιστία R και η Ένταση Αξιοπιστίας σχετίζονται από την εξίσωση: R(  ) = exp(  ) Όπως αναμένουμε η πιθανότητα να μην παρατηρήσουμε αστοχία σε κάποια χρονική στιγμή (αξιοπιστία) είναι χαμηλότερη για μεγαλύτερα χρονικά διαστήματα εκτέλεσης του συστήματος. Φάση Λειτουργίας

Σε πολλά προϊόντα λογισμικού η φάση λειτουργίας ενός συστήματος αποτελείται από μια σειρά εκδόσεων (releases) Φάση Λειτουργίας

Αξιοπιστία Συστημάτων (Παράλληλα Συστήματα) Ας θεωρήσουμε ότι έχουμε Q P υπο-συστήματα/ψηφίδες ( components ) με σταθερό δείκτη Έντασης Αστοχίας το καθένα και η αξιοπιστία τους υπολογίζεται σε κοινό ημερολογιακό χρόνο. Υποθέτουμε επίσης ότι για να λειτουργήσει σωστά το σύστημα, όλα τα (παράλληλα) υπο- σύστηματα θα πρέπει να λειτουργούν σωστά. Τότε η ολική Ένταση Αστοχίας είναι: Όπου k είναι η Ένταση Αστοχίας κάθε υπο-συστήματος.

Αξιοπιστία Συστημάτων (Παράλληλα Συστήματα) Όπως έχουμε δει R(  ) = exp(  ). Οπότε για χρόνο CPU (χρόνο εκτέλεσης) έχουμε: Εάν η μέση αξιοποίηση των υπολογιστικών πόρων στον Η/Υ Για το συγκεκριμένο σύστημα είναι ρ c τότε: Σε ημερολογιακό χρόνο

Τελικά η αξιοπιστία του συστήματος (σε σχέση με ημερολογιακό χρόνο) είναι:

Είναι επίσης πιθανό στα παραπάνω μοντέλα να θεωρήσουμε ότι το σύστημα που έτρεχε στον Η/Υ 1 που έχει ρυθμό εκτέλεσης εντολών r 1 μεταφέρεται στον Η/Υ 2 που έχει ρυθμό εκτέλεσης εντολών r 2  Τότε η ένταση αστοχίας στη μηχανή 2 είναι: