ΕΠΑΛΗΘΕΥΣΗ ΚΑΙ ΕΠΙΚΥΡΩΣΗ ΣΤΗΝ ΤΕΧΝΟΛΟΓΙΑ ΛΟΓΙΣΜΙΚΟΥ

Τ.Ε.Ι. ΚΑΒΑΛΑΣ ΣΧΟΛΗ ΔΙΟΙΚΗΣΗΣ ΚΑΙ ΟΙΚΟΝΟΜΙΑΣ ΤΜΗΜΑ ΔΙΑΧΕΙΡΙΣΗΣ ΠΛΗΡΟΦΟΡΙΩΝ ΕΠΑΛΗΘΕΥΣΗ ΚΑΙ ΕΠΙΚΥΡΩΣΗ ΣΤΗΝ ΤΕΧΝΟΛΟΓΙΑ ΛΟΓΙΣΜΙΚΟΥ ΜΑΝΑΣΙΔΟΥ ΧΡΙΣΤΙΝΑ ΜΑΙΟΣ 2009 ΕΠΟΠΤΗΣ ΚΑΘΗΓΗΤΗΣ Μαρκουλίδης Αναστάσιος Εκπονηθείσα πτυχιακή εργασία απαραίτητη για την κτήση του βασικού πτυχίου

ΠΡΟΛΟΓΟΣ Με τη περάτωση αυτής της εργασίας, τελειώνει και μία όμορφη εμπειρία. Τα τέσσερα αυτά χρόνια ήταν όμορφα και οι στιγμές ανεξίτηλες. Το μεγαλύτερο μερίδιο της «επιτυχίας» μου φέρει η οικογένεια μου. Επόμενοι κατά σειρά οι καθηγητές μου με κάθε τους συμβουλή ή παρατήρηση. Τους ευχαριστώ θερμά όλους και εύχομαι να συμβάλουν στη γνώση και τη παιδεία ακόμη περισσότερων φοιτητών. Ιδιαίτερες ευχαριστίες στον επιβλέποντα καθηγητή μου κ. Μαρκουλίδη Αναστάσιο που πάσχισε μαζί μου για το καλύτερο δυνατό αποτέλεσμα Τέλος ευχαριστώ τους φίλους μου που με ανέχτηκαν και με ανέχονται ακόμα. Ευχαριστώ και δίνω το λόγο μου ότι θα συνεχίσω να σας κάνω υπερήφανους! Στους γονείς μου.. Πίνακας περιεχομένων

ΠΡΟΛΟΓΟΣ 4 ΚΕΦΑΛΑΙΟ 1: ΕΠΑΛΗΘΕΥΣΗ ΚΑΙ ΕΠΙΚΥΡΩΣΗ... 7 1.1 ΕΠΑΛΗΘΕΥΣΗ ΚΑΙ ΕΠΙΚΥΡΩΣΗ... 8 1.2 ΠΡΟΓΡΑΜΜΑΤΙΣΜΟΣ ΕΠΑΛΗΘΕΥΣΗΣ ΚΑΙ ΕΠΙΚΥΡΩΣΗΣ...15 1.3 ΕΠΙΘΕΩΡΗΣΕΙΣ ΛΟΓΙΣΜΙΚΟΥ...18 1.3.1 Επιθεωρήσεις προγράμματος... 21 1.4 ΑΥΤΟΜΑΤΟΠΟΙΗΜΕΝΗ ΤΕΧΝΙΚΗ ΑΝΑΛΥΣΗ...29 1.5 ΑΝΑΠΤΥΞΗ ΛΟΓΙΣΜΙΚΟΥ ΣΕ «ΚΑΘΑΡΟ ΔΩΜΑΤΙΟ»... 34 ΚΕΦΑΛΑΙΟ 2: ΔΟΚΙΜΗ ΛΟΓΙΣΜΙΚΟΥ... 40 2.1 ΔΟΚΙΜΗ ΛΟΓΙΣΜΙΚΟΥ...40 2.2 ΔΟΚΙΜΗ ΑΤΕΛΕΙΑΣ...42 2.2.1 Δοκιμή «μαύρων κουτιών»...44 2.2.2 Χωρισμός ισοδυναμίας... 46 2.2.3 Δομική δοκιμή... 51 2.2.4 Δοκιμή πορείας... 54 2.3 ΔΟΚΙΜΗ ΟΛΟΚΛΗΡΩΣΗΣ... 58 2.3.1 Η από επάνω προς τα κάτω και η από κάτω προς τα πάνω δοκιμή... 60 2.3.2 Δοκιμή διεπαφών...64 2.3.3 Δοκιμή πίεσης... 69 2.4 ΑΝΤΙΚΕΙΜΕΝΟΣΤΡΕΦΗΣ ΔΟΚΙΜΗ... 70 2.5 ΔΟΚΙΜΗ WORKBENCH...72 ΚΕΦΑΛΑΙΟ 3 : ΕΠΑΛΗΘΕΥΣΗ ΚΡΙΣΙΜΩΝ ΣΥΣΤΗΜΑΤΩΝ...76 3.1 ΕΠΙΣΗΜΕΣ ΜΕΘΟΔΟΙ ΚΑΙ ΚΡΙΣΙΜΑ ΣΥΣΤΗΜΑΤΑ... 77 3.2 ΕΠΙΚΥΡΩΣΗ ΑΞΙΟΠΙΣΤΙΑΣ... 81 3.2.1 Λειτουργικά σχεδιαγράμματα... 83 3.2.2 Πρόβλεψη αξιοπιστίας... 85 3.3 ΔΙΑΒΕΒΑΙΩΣΗ ΑΣΦΑΛΕΙΑΣ... 88 3.3.1 Επαλήθευση και επικύρωση...89 3.3.2. Επιχειρήματα ασφάλειας...90 3.3.3 Διαβεβαίωση διαδικασίας...94 3.3.4 Έλεγχος ασφάλειας χρόνου εκτέλεσης... 95 3.4 ΑΞΙΟΛΟΓΗΣΗ ΤΗΣ ΑΣΦΑΛΕΙΑΣ... 97 ΒΙΒΛΙΟΓΡΑΦΙΑ... 100 Κατάλογος εικόνων Εικόνα 1: Στατική και δυναμική επαλήθευση και επικύρωση 10

Εικόνα 2: Η διαδικασία διόρθωσης... 14 Εικόνα 3: Σχέδιο δοκιμής ως σύνδεση μεταξύ της ανάπτυξης και της δοκιμής... 16 Εικόνα 4: Η διαδικασία επιθεώρησης...24 Εικόνα 5: Η ανάπτυξη λογισμικού σε «καθαρό δωμάτιο»...35 Εικόνα 6: Μια επαυξητική αναπτυξιακή διαδικασία... 37 Εικόνα 7: Εξεταστικές φάσεις...41 Εικόνα 8: Η εξεταστική διαδικασία ατέλειας... 43 Εικόνα 9: Δοκιμή «μαύρων κουτιών»...45 Εικόνα 10: Χωρισμός ισοδυναμίας... 47 Εικόνα 11: Χωρίσματα ισοδυναμίας...48 Εικόνα 12: Δομική δοκιμή... 52 Εικόνα 13: Δυαδικές κατηγορίες ισοδυναμίας αναζήτησης... 54 Εικόνα 14: Γραφική παράσταση ροής για μια δυαδική ρουτίνα αναζήτησης... 57 Εικόνα 15: Επαυξητική δοκιμή ολοκλήρωσης...59 Εικόνα 16: Η από επάνω προς τα κάτω δοκιμή ολοκλήρωσης...61 Εικόνα 17: Η από κάτω προς τα πάνω δοκιμή ολοκλήρωσης...61 Εικόνα 18: Η δοκιμή διεπαφών... 65 Εικόνα 19: Η δοκιμή workbench... 74 Εικόνα 20: Η διαδικασία μέτρησης αξιοπιστίας... 81 Εικόνα 21: Ένα σχεδιάγραμμα λειτουργίας... 85 Εικόνα 22: Μοντέλο συνάρτησης ίσου βήματος για το μέγεθος της αξιοπιστίας. 86 Εικόνα 23: Άτυπο επιχείρημα ασφάλειας βασισμένο στην επίδειξη των αντιφάσεων... 94 Κατάλογος πινάκων Πίνακας 1: Η δομή ενός σχεδίου δοκιμής λογισμικού 18

Πίνακας 2: Ρόλοι στη διαδικασία επιθεώρησης...23 Πίνακας 3: Έλεγχοι επιθεωρήσεων...27 Πίνακας 4: Αυτόματοι στατικοί έλεγχοι ανάλυσης...30 Πίνακας 5: Στατική ανάλυση του LINT...33 Πίνακας 6: Η προδιαγραφή μιας ρουτίνας αναζήτησης...49 Πίνακας 7: Χωρίσματα ισοδυναμίας για τη ρουτίνα αναζήτησης...50 Πίνακας 8: Εφαρμογή της Java μιας δυαδικής μηχανής αναζήτησης... 53 Πίνακας 9: Κώδικας παράδοσης ινσουλίνης... 92 Πίνακας 10: Διοίκηση ινσουλίνης... 96 ΚΕΦΑΛΑΙΟ 1: ΕΠΑΛΗΘΕΥΣΗ ΚΑΙ ΕΠΙΚΥΡΩΣΗ

1.1 ΕΠΑΛΗΘΕΥΣΗ ΚΑΙ ΕΠΙΚΥΡΩΣΗ Η επαλήθευση και η επικύρωση είναι το όνομα που δίνεται στις διαδικασίες ελέγχου και ανάλυσης που εξασφαλίζουν ότι το λογισμικό προσαρμόζεται στην προδιαγραφή του και ικανοποιεί τις ανάγκες των πελατών που πληρώνουν για εκείνο το λογισμικό. Η επαλήθευση και η επικύρωση είναι μια διαδικασία κύκλου-ζωής. Αρχίζει με τις αναθεωρήσεις απαιτήσεων και συνεχίζεται μέσω των αναθεωρήσεων σχεδίου και των επιθεωρήσεων κώδικα στη δοκιμή προϊόντων. Πρέπει να υπάρξουν δραστηριότητες επαλήθευσης και επικύρωσης σε κάθε στάδιο της διαδικασίας λογισμικού. Αυτές οι δραστηριότητες ελέγχουν ότι το αποτέλεσμα αυτών των δραστηριοτήτων διαδικασίας είναι όπως διευκρινίζεται. Η επαλήθευση και η επικύρωση δεν είναι το ίδιο πράγμα παρά το ότι εύκολα μπορούν να παρερμηνευτούν. Η διαφορά μεταξύ τους εκφράζεται τελείως λακωνικά από τον Boehm (1979): Επικύρωση: Φτιάχνουμε το σωστό προϊόν; Επαλήθευση: Φτιάχνουμε το προϊόν σωστά; Αυτοί οι ορισμοί μας λένε ότι ο ρόλος της επαλήθευσης περιλαμβάνει τον έλεγχο ότι το λογισμικό προσαρμόζεται στην προδιαγραφή του. Πρέπει να ελέγξετε ότι το σύστημα καλύπτει τις συγκεκριμένες λειτουργικές και μη λειτουργικές απαιτήσεις του. Η επικύρωση, εντούτοις, είναι μια γενικότερη διαδικασία. Πρέπει να εξασφαλίσετε ότι το λογισμικό ικανοποιεί τις προσδοκίες του πελάτη. Η διαδικασία αυτή υπερβαίνει τον έλεγχο της προσαρμογής του συστήματος στην προδιαγραφή του, για να δείξει ότι το λογισμικό κάνει ακριβώς αυτό που αναμένει ο πελάτης με βάση αυτά που έχουν διευκρινιστεί από την αρχή. Η επικύρωση των απαιτήσεων των συστημάτων είναι πολύ σημαντική. Είναι εύκολο να γίνουν λάθη και παραλείψεις στις απαιτήσεις ενός

Πτυχιακή εργασία της Μανασίδου Χριστίνας συστήματος και σε τέτοιες περιπτώσεις, το τελικό λογισμικό προφανώς δεν θα ικανοποιήσει τις προσδοκίες του πελάτη. Ωστόσο, στην πραγματικότητα, η επικύρωση είναι σχεδόν απίθανο να ανακαλύψει όλα τα προβλήματα των απαιτήσεων. Μερικές ανεπάρκειες στις απαιτήσεις μπορούν μερικές φορές να ανακαλυφθούν όταν η εφαρμογή του συστήματος είναι έτοιμη για χρήση. Μέσα στις δύο διαδικασίες, δύο τεχνικές ελέγχου και ανάλυσης συστημάτων μπορούν να χρησιμοποιηθούν: 1. Οι επιθεωρήσεις λογισμικού αναλύουν και ελέγχουν τις αντιπροσωπεύσεις συστημάτων όπως το έγγραφο απαιτήσεων, τα διαγράμματα σχεδίου και τον κώδικα πηγής προγράμματος. Μπορούν να είναι εφαρμοσμένα καθ όλα τα στάδια της διαδικασίας. Οι επιθεωρήσεις μπορούν να συμπληρωθούν από κάποια αυτόματη ανάλυση του κειμένου πηγής ενός συστήματος ή άλλων σχετικών εγγράφων. Οι επιθεωρήσεις λογισμικού και οι αυτοματοποιημένες αναλύσεις είναι στατικές τεχνικές δεδομένου ότι δεν απαιτούν το σύστημα για να εκτελεσθούν. 2. Η δοκιμή λογισμικού περιλαμβάνει την εκτέλεση μιας εφαρμογής του λογισμικού με τα στοιχεία δοκιμής και την εξέταση των αποτελεσμάτων του λογισμικού και της λειτουργικής συμπεριφοράς της που ελέγχει ότι εκτελείται όπως απαιτείται. Η δοκιμή είναι μια δυναμική τεχνική επαλήθευσης και επικύρωσης επειδή λειτουργεί με μια εκτελέσιμη αντιπροσώπευση του συστήματος. Η Εικόνα 1 παρουσιάζει τη θέση των επιθεωρήσεων και της δοκιμής στη διαδικασία λογισμικού. Τα βέλη δείχνουν τα στάδια της διαδικασίας που οι τεχνικές μπορούν να χρησιμοποιηθούν. Επομένως, οι επιθεωρήσεις λογισμικού μπορούν να χρησιμοποιηθούν σε όλα τα στάδια της διαδικασίας λογισμικού. Η δοκιμή, παρ όλα αυτά, μπορεί να Σελ. 9 από 102

Κεφάλαιο 1: Επαλήθευση και επικύρωση χρησιμοποιηθεί μόνο όταν ένα πρωτότυπο ή ένα εκτελέσιμο πρόγραμμα είναι διαθέσιμο. Εικόνα 1: Στατική και δυναμική επαλήθευση και επικύρωση Οι τεχνικές επιθεώρησης περιλαμβάνουν τις επιθεωρήσεις προγράμματος, την αυτοματοποιημένη ανάλυση κώδικα πηγής και την επίσημη επαλήθευση. Αν και οι στατικές τεχνικές μπορούν μόνο να ελέγξουν την ανταπόκριση μεταξύ ενός προγράμματος και της προδιαγραφής του, δεν μπορούν να δείξουν ότι το λογισμικό είναι λειτουργικά χρήσιμο. Ούτε όμως, μπορούν να ελέγξουν τα μη λειτουργικά χαρακτηριστικά του λογισμικού όπως την απόδοση και την αξιοπιστία του. Επομένως, πάντα απαιτείται κάποια δοκιμή για να επικυρώσει ένα σύστημα. Αν και οι επιθεωρήσεις λογισμικού χρησιμοποιούνται ευρέως, η δοκιμή του προγράμματος είναι ακόμα η κυρίαρχη τεχνική επαλήθευσης και επικύρωσης. Οι τεχνικές περιλαμβάνουν τη δοκιμή του προγράμματος χρησιμοποιώντας στοιχεία όπως τα πραγματικά δεδομένα που υποβάλλονται σε επεξεργασία από το πρόγραμμα. Η ύπαρξη των ατελειών ή των ανεπαρκειών του προγράμματος προκύπτει με την εξέταση των αποτελεσμάτων και την έρευνα των ανωμαλιών. Η δοκιμή μπορεί να πραγματοποιηθεί κατά τη φάση της εφαρμογής, προκειμένου να Σελ. 10 από 102

Πτυχιακή εργασία της Μανασίδου Χριστίνας ελέγξει ότι το λογισμικό συμπεριφέρεται έτσι όπως έχει οριστεί από το σχεδιαστή και εφόσον η εφαρμογή είναι πλήρης. Υπάρχουν δύο ευδιάκριτοι τύποι δοκιμών που μπορούν να χρησιμοποιηθούν στα διάφορα στάδια της διαδικασίας λογισμικού: 1. Η δοκιμή της «ατέλειας» προορίζεται να βρει τις ασυνέπειες μεταξύ ενός προγράμματος και της προδιαγραφής του. Αυτές οι ασυνέπειες οφείλονται συνήθως στα ελαττώματα ή τις ατέλειες του προγράμματος. Οι δοκιμές έχουν ως σκοπό να αποκαλύψουν την παρουσία ατελειών στο σύστημα παρά να μιμηθούν τη λειτουργική χρήση της. 2. Η «στατιστική» δοκιμή χρησιμοποιείται για να εξετάσει την εκτέλεση του προγράμματος, την αξιοπιστία αυτού και για να ελέγξει πώς λειτουργεί υπό κανονικές συνθήκες λειτουργίας. Οι δοκιμές έχουν σχεδιαστεί να απεικονίσουν τις πραγματικές εισαγωγές χρηστών και τη συχνότητά τους. Μετά από την εφαρμογή των δοκιμών, μια εκτίμηση της λειτουργικής αξιοπιστίας του συστήματος μπορεί να γίνει με τον υπολογισμό του αριθμού των διακοπών του συστήματος. Η εκτέλεση του προγράμματος μπορεί να κριθεί με τη μέτρηση του χρόνου εκτέλεσης και του χρόνου απόκρισης του συστήματος δεδομένου ότι επεξεργάζεται τα στατιστικά στοιχεία δοκιμής. Φυσικά, δεν υπάρχει ένα αυστηρό όριο μεταξύ αυτών των προσεγγίσεων στη δοκιμή. Κατά τη διάρκεια της «δοκιμής ατέλειας», οι ελεγκτές θα πάρουν μια διαισθητική αίσθηση για την αξιοπιστία του λογισμικού. Κατά τη διάρκεια της «στατιστικής δοκιμής», είναι πιθανό ότι μερικές ατέλειες θα ανακαλυφθούν. Ο τελικός σκοπός της διαδικασίας επαλήθευσης και επικύρωσης είναι να καθιερωθεί η πεποίθηση ότι το σύστημα είναι «κατάλληλο για το σκοπό». Σελ. 11 από 102

Κεφάλαιο 1: Επαλήθευση και επικύρωση Αυτό δεν σημαίνει ότι το πρόγραμμα πρέπει να είναι απολύτως ατελές. Αντίθετα, σημαίνει ότι το σύστημα πρέπει να είναι αρκετά καλό για την προοριζόμενη χρήση του. Το επίπεδο απαραίτητης εμπιστοσύνης εξαρτάται από το σκοπό του συστήματος, τις προσδοκίες των χρηστών και το τρέχον περιβάλλον μάρκετινγκ: 1. Λειτουργία λογισμικού. Το επίπεδο εμπιστοσύνης που απαιτείται εξαρτάται από το πόσο σημαντικό είναι το λογισμικό σε μια οργάνωση. Παραδείγματος χάριν, το επίπεδο εμπιστοσύνης που απαιτείται για το λογισμικό που χρησιμοποιείται για να ελέγξει ένα ασφαλές σημαντικό σύστημα είναι πολύ υψηλότερο από αυτό που απαιτείται για ένα σύστημα λογισμικού πρωτοτύπων που έχει αναπτυχθεί για να επιδείξει μερικές νέες ιδέες. 2. Οι προσδοκίες χρηστών. Η αλήθεια είναι ότι πολλοί χρήστες έχουν χαμηλές προσδοκίες από το λογισμικού τους και δεν εκπλήσσονται όταν αποτυγχάνει κατά τη διάρκεια της χρήσης. Είναι πρόθυμοι να δεχτούν αυτές τις διακοπές του συστήματος όταν ξεπερνούν τα οφέλη της χρήσης έτσι ώστε να μην έχουμε σωστή εικόνα των μειονεκτημάτων. Όμως, η ανοχή των χρηστών σε αυτές τις ανεξήγητες, για αυτούς, διακοπές του συστήματος έχει μειωθεί από τη δεκαετία του '90. Είναι πλέον λιγότερο αποδεκτό να παραδοθούν τα αναξιόπιστα συστήματα και έτσι οι εταιρείες λογισμικού πρέπει να αφιερώσουν περισσότερο χρόνο και προσπάθεια στην επαλήθευση και την επικύρωση. 3. Περιβάλλον μάρκετινγκ. Όταν ένα σύστημα διατίθεται στην αγορά προς πώληση, οι πωλητές του συστήματος πρέπει να λάβουν υπόψη τα ανταγωνιστικά προγράμματα, τη τιμή που οι πελάτες είναι πρόθυμοι να πληρώσουν για ένα σύστημα και το απαραίτητο πρόγραμμα για την παράδοση εκείνου του συστήματος. Όταν μια εταιρεία έχει λίγους ανταγωνιστές, μπορεί να αποφασίσει να παραδώσει ένα πρόγραμμα προτού εξεταστεί και διορθωθεί πλήρως και αυτό επειδή θέλουν να είναι οι πρώτοι στην αγορά. Όταν οι Σελ. 12 από 102

Πτυχιακή εργασία της Μανασίδου Χριστίνας πελάτες δεν είναι πρόθυμοι να πληρώσουν αρκετά για το λογισμικό, μπορούν να είναι πρόθυμοι να ανεχτούν περισσότερα ελαττώματα. Όλοι αυτοί οι παράγοντες πρέπει να εξεταστούν πριν πάρουν την απόφαση για το πόση προσπάθεια πρέπει να ξοδευτεί στη διαδικασία επικύρωσης και επαλήθευσης. Κατά τη διάρκεια της επαλήθευσης και της επικύρωσης λογισμικού, ανακαλύπτονται οι ατέλειες στο πρόγραμμα το οποίο πρέπει έπειτα να τροποποιηθεί για να διορθώσει αυτές τις ατέλειες. Αυτή η διαδικασία είναι συχνά ενσωματωμένη μέσα σε άλλες δραστηριότητες επαλήθευσης και επικύρωσης. Εντούτοις, η δοκιμή (ή γενικότερα επαλήθευση και επικύρωση) και η διόρθωση είναι διαφορετικές διαδικασίες που δεν είναι απαραίτητο να ενσωματωθούν: > Η επαλήθευση και η επικύρωση είναι μια διαδικασία που καθιερώνει την ύπαρξη των ατελειών σε ένα σύστημα λογισμικού. > Η διόρθωση είναι μια διαδικασία που εντοπίζει και διορθώνει αυτές τις ατέλειες (Εικόνα 2). Δεν υπάρχει καμία απλή μέθοδος για τη διόρθωση ενός προγράμματος. Οι ειδικευμένοι διορθωτές ψάχνουν τα σχέδια στην έξοδο του ελέγχου στην οποίαν παρατηρείται η ατέλεια και χρησιμοποιούν τη γνώση του τύπου ατέλειας, του σχεδίου παραγωγής, της γλώσσας προγραμματισμού και της διαδικασίας προγραμματισμού για να εντοπίσουν την ατέλεια. Η γνώση της διαδικασίας είναι σημαντική. Οι διορθωτές ξέρουν τα κοινά λάθη των προγραμματιστών (όπως π.χ. η αποτυχία να αυξηθεί ένας μετρητής). Τα χαρακτηριστικά λάθη γλώσσας προγραμματισμού, όπως η εσφαλμένη κατεύθυνση δεικτών στην 0, μπορούν επίσης να εξεταστούν. Σελ. 13 από 102

Κεφάλαιο 1: Επαλήθευση και επικύρωση Εικόνα 2: Η διαδικασία διόρθωσης Η εντόπιση των λαθών σε ένα πρόγραμμα δεν είναι πάντα μια απλή διαδικασία δεδομένου ότι το σφάλμα δεν χρειάζεται απαραιτήτως να είναι στενά συνδεδεμένο με το σημείο που το πρόγραμμα απέτυχε. Για να εντοπιστεί ένα σφάλμα, ο αρμόδιος προγραμματιστής για τη διόρθωση μπορεί να χρειαστεί να σχεδιάσει τις πρόσθετες δοκιμές του προγράμματος που επαναλαμβάνουν το αρχικό ελάττωμα και που τον βοηθούν να ανακαλύψει την πηγή του σφάλματος στο πρόγραμμα. Η χειρωνακτική επισήμανση του προγράμματος, που μιμείται την εκτέλεση, μπορεί να είναι απαραίτητη. Σε μερικές περιπτώσεις, τα εργαλεία διόρθωσης που συλλέγουν τις πληροφορίες για την εκτέλεση του προγράμματος μπορούν να είναι χρήσιμα. Τα διαλογικά εργαλεία διόρθωσης είναι γενικά μέρος μιας ακολουθίας των εργαλείων γλωσσικής υποστήριξης που είναι ενσωματωμένα μέσα σε ένα σύστημα σύνταξης. Παρέχουν ένα εξειδικευμένο περιβάλλον χρόνου εκτέλεσης για το πρόγραμμα που επιτρέπει την πρόσβαση στον πίνακα συμβόλων μεταγλωττιστών και, από εκεί, στις τιμές των μεταβλητών του προγράμματος. Οι χρήστες μπορούν συχνά να ελέγξουν την εκτέλεση «αν τρέχει» με τον τρόπο τους. Αφότου έχει εκτελεσθεί κάθε δήλωση, οι τιμές των μεταβλητών μπορούν να εξεταστούν και πιθανά λάθη να ανακαλυφθούν. Αφότου έχει ανακαλυφθεί μια ατέλεια στο πρόγραμμα, πρέπει να διορθωθεί και το σύστημα πρέπει έπειτα να ξανά επικυρωθεί. Αυτός ο Σελ. 14 από 102

Πτυχιακή εργασία της Μανασίδου Χριστίνας τρόπος περιλαμβάνει τη νέα επιθεώρηση του προγράμματος ή την επανάληψη των λειτουργιών προηγούμενου δοκιμαστικού. Η δοκιμή οπισθοδρόμησης χρησιμοποιείται για να ελέγξει ότι οι αλλαγές που γίνονται σε ένα πρόγραμμα δεν έχουν τα νέα ελαττώματα στο σύστημα. Η εμπειρία έχει δείξει ότι ένα σχετικά μεγάλο μέρος των «επισκευών λαθών» είναι είτε ελλιπείς είτε είναι η εισαγωγή νέων λαθών στο πρόγραμμα. Σε γενικές γραμμές κατά τη διάρκεια της δοκιμής οπισθοδρόμησης, όλες οι δοκιμές πρέπει να επαναληφθούν μετά από κάθε διόρθωση ατέλειας. Αυτό είναι πάρα πολύ ακριβό. Ως τμήμα του σχεδίου δοκιμής, οι εξαρτήσεις μεταξύ των μερών του συστήματος και των δοκιμών που συνδέονται με κάθε μέρος πρέπει να προσδιοριστούν. Δηλαδή, πρέπει να υπάρξει ανιχνευσιμότητα από τις περιπτώσεις δοκιμής στα χαρακτηριστικά γνωρίσματα του προγράμματος που εξετάζεται. Εάν αυτή η ανιχνευσιμότητα είναι τεκμηριωμένη, μπορείτε έπειτα να τρέξετε ένα υποσύνολο των στοιχείων δοκιμής που έχουν τεθεί για να ελέγξουν το τροποποιημένο συστατικό. 1.2 ΠΡΟΓΡΑΜΜΑΤΙΣΜΟΣ ΕΠΑΛΗΘΕΥΣΗΣ ΚΑΙ ΕΠΙΚΥΡΩΣΗΣ Η επαλήθευση και η επικύρωση είναι μια ακριβή διαδικασία. Για μερικά μεγάλα συστήματα όπως τα real-time συστήματα με τους σύνθετους μη λειτουργικούς περιορισμούς, ο μισός προϋπολογισμός ανάπτυξης συστημάτων μπορεί να ξοδευτεί στην επαλήθευση και επικύρωση. Ο προσεκτικός προγραμματισμός απαιτείται για να πάρει τις περισσότερες από τις επιθεωρήσεις και τις δοκιμές και να ελέγξει τις δαπάνες της διαδικασίας επαλήθευσης και επικύρωσης. Ο προγραμματισμός της επικύρωσης και της επαλήθευσης ενός συστήματος λογισμικού πρέπει να αρχίσει νωρίς στην αναπτυξιακή διαδικασία. Το πρότυπο της ανάπτυξης λογισμικού που φαίνεται στην Εικόνα 3 δείχνει πώς τα σχέδια δοκιμής πρέπει να προέλθουν από την Σελ. 15 από 102

Κεφάλαιο 1: Επαλήθευση και επικύρωση Γ,, Γ γ γ Λ προδιαγραφή και το σχέδιο συστημάτων. Αυτό ονομάζεται μοντέλο Ε. Ακόμη, η Εικόνα 3 δείχνει επιδεικνύει πώς η δραστηριότητα επαλήθευσης και επικύρωσης αναλύει σε διάφορα στάδια με κάθε φάση που οδηγείται από τις δοκιμές που έχουν καθοριστεί για να ελέγξουν την προσαρμογή του προγράμματος με το σχέδιο και την προδιαγραφή της. Η διαδικασία προγραμματισμού E & Ε πρέπει: > να αποφασίσει σχετικά με την ισορροπία μεταξύ των στατικών και δυναμικών προσεγγίσεων στην επαλήθευση και επικύρωση, > να καταρτίσει τα πρότυπα και τις διαδικασίες για τις επιθεωρήσεις και τη δοκιμή λογισμικού, > να καθιερώσει τους πίνακες ελέγχου για να οδηγήσει τις επιθεωρήσεις του προγράμματος > και να καθορίσει το σχέδιο δοκιμής λογισμικού (Εικόνα 3). Εικόνα 3: Σχέδιο δοκιμής ως σύνδεση μεταξύ της ανάπτυξης και της δοκιμής. Η σχετική προσπάθεια που αφιερώνεται στις επιθεωρήσεις και τις δοκιμές εξαρτάται από τον τύπο συστήματος που έχει αναπτυχθεί και την 1 Ο αντίστοιχος αγγλικός όρος είναι V-model. Το V προκύπτει από το νθγΐίιοβίιοπ (Επαλήθευση), οπότε θεωρήθηκε σκόπιμο να χρησιμοποιηθεί το αντίστοιχο κεφαλαίο γράμμα του ελληνικού αλφάβητου. Σελ. 16 από 102

Πτυχιακή εργασία της Μανασίδου Χριστίνας οργανωτική πείρα. Όσο πιο κρίσιμο είναι ένα σύστημα, τόσο περισσότερη προσπάθεια πρέπει να αφιερωθεί στις στατικές τεχνικές επαλήθευσης. Ο προγραμματισμός δοκιμής ενδιαφέρεται για τον καθορισμό των προτύπων για την εξεταστική διαδικασία παρά την περιγραφή των δοκιμών προϊόντων. Τα σχέδια δοκιμής δεν είναι μόνο διοικητικά έγγραφα. Προορίζονται επίσης για τους μηχανικούς λογισμικού που συμμετέχουν στο σχεδιασμό και την πραγματοποίηση των δοκιμών συστημάτων. Επιτρέπουν στο τεχνικό προσωπικό να πάρει μια γενική εικόνα των δοκιμών συστημάτων και να τοποθετήσει την εργασία του πάνω σε αυτό το πλαίσιο. Τα σχέδια δοκιμής παρέχουν επίσης πληροφορίες στο προσωπικό που είναι αρμόδιο για την εξασφάλιση ότι οι κατάλληλοι πόροι υλικού και λογισμικού είναι διαθέσιμοι στην ομάδα. Τα σημαντικότερα συστατικά ενός σχεδίου δοκιμής παρουσιάζονται στον Πίνακα 1. Αυτό το σχέδιο πρέπει να συμπεριλάβει σημαντική πιθανότητα έτσι ώστε οι ολισθήσεις στο σχέδιο και την εφαρμογή να μπορούν να προσαρμοστούν και το προσωπικό που διατίθεται στη δοκιμή να μπορεί να επεκταθεί σε άλλες δραστηριότητες. Μια καλή περιγραφή των σχεδίων δοκιμής και της σχέσης τους με τα γενικότερα ποιοτικά σχέδια δίνεται από τους Frewin και Hatton (1986). Η εξεταστική διαδικασία. Μια περιγραφή των σημαντικότερων φάσεων της εξεταστικής διαδικασίας. Ανιχνευσιμότητα απαιτήσεων. Οι χρήστες ενδιαφέρονται για το σύστημα που καλύπτει τις απαιτήσεις του και η δοκιμή πρέπει να προγραμματιστεί έτσι ώστε όλες οι απαιτήσεις να εξετάζονται χωριστά. Δοκιμασμένα στοιχεία. Τα προϊόντα της διαδικασίας λογισμικού που πρόκειται να εξεταστούν πρέπει να διευκρινιστούν. Σελ. 17 από 102

Κεφάλαιο 1: Επαλήθευση και επικύρωση Εξεταστικό πρόγραμμα. Μια γενική εξεταστική κατανομή προγράμματος και των πόρων για αυτό το πρόγραμμα. Αυτό, προφανώς, συνδέεται με το γενικότερο πρόγραμμα ανάπτυξης προγράμματος. Διαδικασίες καταγραφής δοκιμής. Δεν είναι αρκετό να «τρέξει» απλά τις δοκιμές. Τα αποτελέσματα των δοκιμών πρέπει να καταγραφούν συστηματικά. Πρέπει να ελεγχθεί η εξεταστική διαδικασία για να ελέγξει ότι αυτό πραγματοποιείται σωστά. Απαιτήσεις υλικού και λογισμικού. Αυτό το τμήμα πρέπει να καθορίσει τα εργαλεία λογισμικού που απαιτούνται και θα χρησιμοποιηθούν. Περιορισμοί Οι περιορισμοί που έχουν επιπτώσεις στην εξεταστική διαδικασία όπως οι ελλείψεις προσωπικού πρέπει κατ εκτίμηση να προβλεφθούν σε αυτό το τμήμα. Πίνακας 1: Η δομή ενός σχεδίου δοκιμής λογισμικού. Όπως άλλα σχέδια, το σχέδιο δοκιμής δεν είναι ένα στατικό έγγραφο. Πρέπει να αναθεωρηθεί τακτικά. Όπως η δοκιμή είναι μια δραστηριότητα που εξαρτάται από την εφαρμογή που είναι πλήρης. Εάν μέρος ενός συστήματος είναι ελλιπές, δεν μπορεί να παραδοθεί για τη δοκιμή ολοκλήρωσης. Το σχέδιο πρέπει επομένως να αναθεωρηθεί για να ανακατανείμει τους ελεγκτές σε κάποια άλλη δραστηριότητα. 1.3 ΕΠΙΘΕΩΡΗΣΕΙΣ ΛΟΓΙΣΜΙΚΟΥ Η συστηματική δοκιμή προγράμματος απαιτεί έναν μεγάλο αριθμό δοκιμών για να αναπτυχθεί, να εκτελεσθεί και να εξεταστεί. Αυτό σημαίνει ότι η διαδικασία είναι χρονοβόρα και ακριβής. Κάθε δοκιμαστική λειτουργία τείνει να ανακαλύψει ένα ενιαίο ελάττωμα προγράμματος ή, στην καλύτερη περίπτωση, μόνο μερικά ελαττώματα. Ο λόγος για αυτό είναι ότι οι αποτυχίες που προκύπτουν από τα ελαττώματα προκαλούν συχνά φθορά κάποιων στοιχείων του συστήματος. Συνεπώς, μπορεί να είναι δύσκολο να Σελ. 18 από 102

Πτυχιακή εργασία της Μανασίδου Χριστίνας πει κανείς εάν οι ανωμαλίες παραγωγής είναι ένα αποτέλεσμα ενός νέου ελαττώματος ή μια παρενέργεια ενός υπάρχοντος ελαττώματος. Οι επιθεωρήσεις λογισμικού δεν απαιτούν από το πρόγραμμα να εκτελεστεί, έτσι μπορεί να χρησιμοποιηθούν ως τεχνική επαλήθευσης προτού να εκτελεστούν τα προγράμματα. Κατά τη διάρκεια μιας επιθεώρησης, εξετάζεται η προέλευση ενός συστήματος. Αυτό θα μπορούσε να είναι ένα πρότυπο συστημάτων, μια προδιαγραφή ή ένας κώδικας υψηλού επιπέδου γλώσσας. Χρησιμοποιείται η γνώση του συστήματος που αναπτύσσεται και η σημασιολογία της προέλευσης για να ανακαλυφθούν τα λάθη. Κάθε λάθος μπορεί να εξεταστεί μεμονωμένα χωρίς να υπάρχει ανησυχία για το τί επιπτώσεις θα έχει στη συμπεριφορά του συστήματος. Οι αλληλεπιδράσεις λαθών δεν είναι σημαντικές και ένα ολόκληρο συστατικό μπορεί να ελεγχθεί σε μια ενιαία σύνοδο. Οι επιθεωρήσεις έχουν αποδειχθεί μια αποτελεσματική τεχνική ανίχνευσης λάθους. Τα λάθη μπορούν να βρεθούν ευκολότερα μέσω της επιθεώρησης απ' ό, τι με την εκτενή δοκιμή προγράμματος. Αυτό καταδείχθηκε σε ένα πείραμα από τους Basili και Selby (1987) που συγκρίνουν εμπειρικά την αποτελεσματικότητα των επιθεωρήσεων και της δοκιμής. Διαπίστωσαν ότι η στατική αναθεώρηση κώδικα ήταν αποτελεσματικότερη και λιγότερο ακριβή από τη δοκιμή ατέλειας στην ανακάλυψη των ελαττωμάτων ενός προγράμματος. Οι Gilb και ο Graham (1993) έχουν βρει επίσης ότι το παραπάνω ισχύει. Ο Fagan (1986) ανέφερε ότι περισσότερο από το 60% των λαθών σε ένα πρόγραμμα μπορεί να ανιχνευθεί χρησιμοποιώντας τις άτυπες επιθεωρήσεις προγράμματος. Ο Mills (1987) προτείνει ότι μια κανονικότερη προσέγγιση, που χρησιμοποιεί τη μαθηματική επαλήθευση, μπορεί να ανιχνεύσει περισσότερο από 90% των λαθών σε ένα πρόγραμμα. Η διαδικασία επιθεώρησης μπορεί επίσης να εξετάσει άλλες ποιοτικές ιδιότητες όπως η συμμόρφωση με τα πρότυπα, τη φορητότητα και τη συντηρησιμότητα. Σελ. 19 από 102

Κεφάλαιο 1: Επαλήθευση και επικύρωση Παρακάτω, παρουσιάζονται δύο λόγοι για τους οποίους οι αναθεωρήσεις και οι επιθεωρήσεις είναι συνήθως αποτελεσματικότερες από δοκιμές για την ανακάλυψη των ατελειών στα συστατικά και τα υποσυστήματα: 1. Πολλές διαφορετικές ατέλειες μπορούν να ανιχνευθούν σε μια ενιαία σύνοδο επιθεώρησης. Το πρόβλημα με τη δοκιμή είναι ότι μπορεί συχνά να ανιχνεύσει μόνο ένα λάθος ανά δοκιμή επειδή οι ατέλειες μπορούν να προκαλέσουν συμφόρηση στο πρόγραμμα ή να παρεμποδίσουν τα συμπτώματα άλλων ατελειών του προγράμματος. 2. Επαναχρησιμοποιούν τη γνώση μιας γλώσσας προγραμματισμού. Στην ουσία, οι κριτικοί είναι πιθανό να έχουν δει τους τύπους των λαθών που εμφανίζονται συνήθως, ειδικότερα στις γλώσσες προγραμματισμού και στους τύπους εφαρμογών. Μπορούν, επομένως, να εστιάσουν σε αυτούς τους τύπους λαθών κατά τη διάρκεια της ανάλυσης. Αυτό δεν σημαίνει ότι οι επιθεωρήσεις πρέπει να αντικαταστήσουν τελείως τη δοκιμή συστημάτων. Μάλλον, πρέπει να χρησιμοποιηθούν ως αρχική διαδικασία επαλήθευσης για να βρουν τις περισσότερες ατέλειες. Οι επιθεωρήσεις του λογισμικού μπορούν να ελέγξουν την προσαρμογή με μια προδιαγραφή αλλά δεν μπορούν να επικυρώσουν τη δυναμική συμπεριφορά. Επιπλέον, είναι συχνά μη πρακτικό να επιθεωρηθεί ένα πλήρες σύστημα που είναι ενσωματωμένο σε διαφορετικά υποσυστήματα. Η δοκιμή είναι η μόνη πιθανή τεχνική επαλήθευσης και επικύρωσης στο επίπεδο συστημάτων. Η δοκιμή είναι επίσης απαραίτητη για την αξιολόγηση της αξιοπιστίας, την ανάλυση απόδοσης, την επικύρωση ενδιάμεσων με τον χρήστη και για να ελέγξει ότι οι απαιτήσεις λογισμικού είναι αυτό που ο χρήστης θέλει πραγματικά. Οι αναθεωρήσεις και η δοκιμή δεν ανταγωνίζονται τις τεχνικές επαλήθευσης και επικύρωσης. Έχουν τα πλεονεκτήματα και τα Σελ. 20 από 102

Πτυχιακή εργασία της Μανασίδου Χριστίνας μειονεκτήματά τους και πρέπει να χρησιμοποιηθούν μαζί με τη διαδικασία επαλήθευσης και επικύρωσης. Πράγματι, ο Gilb και ο Graham (1993) προτείνουν ότι μια από τις αποτελεσματικότερες χρήσεις των αναθεωρήσεων είναι να αναθεωρηθούν οι περιπτώσεις δοκιμών για ένα σύστημα. Οι αναθεωρήσεις μπορούν να ανακαλύψουν προβλήματα με αυτές τις δοκιμές και μπορούν να βοηθήσουν στο να σχεδιαστούν περισσότερο αποτελεσματικοί τρόποι να εξεταστεί το σύστημα. Είναι μερικές φορές δύσκολο να εισαχθούν επιθεωρήσεις στις παραδοσιακές οργανώσεις ανάπτυξης λογισμικού. Οι μηχανικοί λογισμικού με την εμπειρία της δοκιμής προγράμματος μπορούν να είναι απρόθυμοι να δεχτούν ότι αυτές οι τεχνικές μπορούν να είναι πιο αποτελεσματικές από ότι εξεταστικές για την ανίχνευση ατέλειας. Οι διευθυντές μπορεί να είναι αντίθετοι με αυτές τις τεχνικές επειδή απαιτούν επιπλέον δαπάνες κατά τη διάρκεια του σχεδίου και της ανάπτυξης και δεν επιθυμούν να διατρέξουν τον κίνδυνο ότι δεν θα υπάρξει αντίστοιχη αποταμίευση κατά τη διάρκεια της δοκιμής προγράμματος. Εντούτοις, οι επιθεωρήσεις λογισμικού μπορούν να εφαρμοστούν σε οποιαδήποτε έγγραφα που παράγονται κατά τη διάρκεια της διαδικασίας λογισμικού. Οι συγκρίσιμες τεχνικές επιθεώρησης μπορούν να εφαρμοστούν στις προδιαγραφές απαιτήσεων, τους λεπτομερείς ορισμούς σχεδίου, τα σχέδια δομών δεδομένων, τα σχέδια δοκιμής και την τεκμηρίωση χρηστών. 1.3.1 Επιθεωρήσεις προγράμματος Οι επιθεωρήσεις προγράμματος είναι αναθεωρήσεις των οποίων στόχος είναι η ανίχνευση ατέλειας προγράμματος. Η έννοια μιας τυποποιημένης διαδικασίας επιθεώρησης αναπτύχθηκε αρχικά στην IBM στη δεκαετία του '70 και περιγράφεται από τον Fagan (1976.1986). Είναι μια ευρέως χρησιμοποιούμενη μέθοδος επαλήθευσης προγράμματος. Από την αρχική μέθοδο του Fagan, διάφορες εναλλακτικές προσεγγίσεις στην επιθεώρηση Σελ. 21 από 102

Κεφάλαιο 1: Επαλήθευση και επικύρωση έχουν αναπτυχθεί (Gilb και Graham, 1993). Εντούτοις, αυτοί είναι βασισμένοι στην αρχική έννοια του Fagan, ότι δηλαδή μια ομάδα με μέλη με διαφορετικά προφίλ πρέπει να κάνει μια προσεκτική, γραμμή με γραμμή αναθεώρηση του κώδικα πηγής προγράμματος. Η βασική διαφορά μεταξύ των επιθεωρήσεων προγράμματος και άλλων τύπων ποιοτικών αναθεωρήσεων είναι ότι ο κύριος στόχος των επιθεωρήσεων είναι η ανίχνευση ατέλειας παρά η εξέταση των ευρύτερων ζητημάτων σχεδίου. Οι ατέλειες μπορούν να είναι είτε λογικά λάθη, ανωμαλίες στον κώδικα που μπορεί να δείξουν έναν λανθασμένο όρο ή μια μη συμμόρφωση με τα οργανωτικά ή τα πρότυπα προγράμματος. Σε αντίθεση, άλλοι τύποι αναθεωρήσεων μπορούν να ενδιαφερθούν για το πρόγραμμα, τις δαπάνες, την πρόοδο ενάντια στα καθορισμένα κύρια σημεία ή την αξιολόγηση εάν το λογισμικό είναι πιθανό ή όχι να συναντήσει οργανωτικούς στόχους. Η διαδικασία της επιθεώρησης είναι η επίσημη που πραγματοποιείται από μια μικρή ομάδα τουλάχιστον τεσσάρων ανθρώπων. Τα μέλη αυτής της ομάδας αναλύουν συστηματικά τον κώδικα και επισημαίνουν τις πιθανές ατέλειες. Στις αρχικές προτάσεις του Fagan, ο ίδιος πρότεινε τους ρόλους όπως αυτός του συντάκτη, του αναγνώστη, του ελεγκτή και του μεσολαβητή. Ο αναγνώστης διαβάζει τον κώδικα στην ομάδα επιθεώρησης, ο ελεγκτής επιθεωρεί τον κώδικα από μια εξεταστική προοπτική και ο μεσολαβητής οργανώνει τη διαδικασία. Δεδομένου ότι οι οργανώσεις έχουν αποκτήσει την απαιτούμενη εμπειρία με την επιθεώρηση, έχουν προκύψει άλλες προτάσεις για τους ρόλους των ομάδων. Σε μια συζήτηση για το πώς η επιθεώρηση εισήχθη επιτυχώς στη αναπτυξιακή διαδικασία της Hewlett Packard, οι Grady και Van Slack (1994) πρότειναν έξι ρόλους όπως φαίνεται στον Πίνακα 2. Οι διαφορετικοί ρόλοι μπορούν να υιοθετηθούν από το ίδιο πρόσωπο, έτσι το μέγεθος ομάδων μπορεί να ποικίλει από μια επιθεώρηση σε άλλη. Σελ. 22 από 102

Πτυχιακή εργασία της Μανασίδου Χριστίνας Ρόλος Περιγραφή Συντάκτης ή ιδιοκτήτης Υπεύθυνος για την παραγωγή του προγράμματος και των εγγράφων. Αρμόδιος για τον καθορισμό των ατελειών που ανακαλύπτονται κατά τη διάρκεια της διαδικασίας επιθεώρησης. Επιθεωρητής Βρίσκει τα λάθη, τις παραλείψεις και τις ασυνέπειες στα προγράμματα και τα έγγραφα. Προσδιορίζει επίσης τα ευρύτερα ζητήματα που είναι έξω από το πεδίο της ομάδας επιθεώρησης. Αναγνώστης Παραφράζει τον κώδικα ή το έγγραφο. Γ ραφέας Καταγράφει τα αποτελέσματα της επιθεώρησης. Πρόεδρος ή μεσολαβητής Διαχειρίζεται τη διαδικασία και διευκολύνει την επιθεώρηση. Καταγράφει τη διαδικασία αποτελεσμάτων και την οδηγεί στον κύριο μεσολαβητή. Κύριος μεσολαβητής Αρμόδιος για τις βελτιώσεις διαδικασίας επιθεώρησης, την ενημέρωση πινάκων ελέγχου, την ανάπτυξη προτύπων κ.λπ. Πίνακας 2: Ρόλοι στη διαδικασία επιθεώρησης Οι Grady και Van Slack αναφέρουν επίσης, ότι δεν υπάρχει πάντα μια ανάγκη για τον ρόλο του αναγνώστη. Από αυτή την άποψη, έχουν τροποποιήσει τη διαδικασία από αυτήν που προτείνεται αρχικά από τον Fagan, όπου ένα αναπόσπαστο τμήμα της διαδικασίας συμπεριλήφθηκε στο να διαβαστεί το πρόγραμμα. Επιπλέον, ο Gilb και ο Graham (1993) δεν σκέφτονται ότι απαιτείται ένας αναγνώστης. Προτείνουν ότι οι επιθεωρητές πρέπει να επιλεχτούν για να απεικονίσουν τις διαφορετικές απόψεις όπως η δοκιμή, ο τελικός χρήστης, η ποιοτική διαχείριση, κ.λπ. Προτού να αρχίσει μια επιθεώρηση προγράμματος, είναι ουσιαστικό να: 1. Υπάρχει μια ακριβής προδιαγραφή του κώδικα που επιθεωρείται. Είναι αδύνατο να επιθεωρηθεί ένα συστατικό σε επίπεδο Σελ. 23 από 102

Κεφάλαιο 1: Επαλήθευση και επικύρωση λεπτομέρειας που απαιτείται για να ανιχνευθούν οι ατέλειες χωρίς μια πλήρη προδιαγραφή. 2. Τα μέλη της ομάδας επιθεώρησης εξοικειώνονται με τα οργανωτικά πρότυπα. 3. Υπάρχει μια ενημερωμένη, συντακτικά σωστή έκδοση του κώδικα διαθέσιμη. Δεν υπάρχει κανένα σημείο στον κώδικα επιθεώρησης που είναι «σχεδόν ολοκληρωμένο» ακόμα κι αν μια καθυστέρηση προκαλέσει και τη διάσπαση προγράμματος. Μια πολύ γενική διαδικασία επιθεώρησης παρουσιάζεται στην Εικόνα 4. Αυτό προσαρμόζεται όπως απαιτείται από τις οργανώσεις χρησιμοποιώντας τις επιθεωρήσεις προγράμματος. Εικόνα 4: Η διαδικασία επιθεώρησης Ο μεσολαβητής είναι αρμόδιος για τον προγραμματισμό επιθεώρησης. Αυτό περιλαμβάνει την επιλογή μιας ομάδας επιθεώρησης, την οργάνωση μιας αίθουσας συνεδριάσεων και την εξασφάλιση ότι το υλικό που επιθεωρείται και οι προδιαγραφές του είναι πλήρεις. Το πρόγραμμα που επιθεωρείται παρουσιάζεται στην ομάδα κατά τη διάρκεια του σταδίου επισκόπησης όπου ο συντάκτης του κώδικα περιγράφει τι προορίζεται να κάνει το πρόγραμμα. Αυτό ακολουθείται μέχρι μια περίοδο μεμονωμένης προετοιμασίας. Κάθε μέλος της ομάδας μελετά την προδιαγραφή και το πρόγραμμα και ψάχνει για ατέλειες στον κώδικα. Σελ. 24 από 102

Πτυχιακή εργασία της Μανασίδου Χριστίνας Η ίδια η επιθεώρηση πρέπει να είναι σχετικά σύντομη (όχι περισσότερες από δύο ώρες) και πρέπει να ενδιαφερθεί αποκλειστικά για τον προσδιορισμό των ατελειών, των ανωμαλιών και της μη συμμόρφωσης με τα πρότυπα. Η ομάδα επιθεώρησης δεν πρέπει να προτείνει πώς αυτές οι ατέλειες πρέπει να διορθωθούν ούτε να προτείνουν αλλαγές σε άλλα συστατικά. Μετά από την επιθεώρηση, το πρόγραμμα τροποποιείται από το συντάκτη του για να διορθώσει τα προσδιορισμένα προβλήματα. Στο ακόλουθο στάδιο, ο μεσολαβητής πρέπει να αποφασίσει εάν μια δεύτερη επιθεώρηση του κώδικα απαιτείται. Εναλλακτικά, μπορεί να αποφασίσει ότι αυτή δεν απαιτείται και ότι οι ατέλειες έχουν καθοριστεί επιτυχώς. Το έγγραφο εγκρίνεται έπειτα από το μεσολαβητή για την απελευθέρωση. Η διαδικασία επιθεώρησης πρέπει πάντα να οδηγείται από έναν πίνακα ελέγχου των κοινών λαθών προγραμματιστών. Αυτό πρέπει να καθιερωθεί από μια συζήτηση με το πεπειραμένο προσωπικό και τακτικά ενημερωμένο αφού κερδίζει περισσότερη εμπειρία κατά τη διαδικασίας επιθεώρησης. Οι διαφορετικοί πίνακες ελέγχου πρέπει να προετοιμαστούν για τις διαφορετικές γλώσσες προγραμματισμού. Αυτός ο πίνακας ελέγχου ποικίλλει σύμφωνα με τη γλώσσα προγραμματισμού εξαιτίας των διαφορετικών επιπέδων ελέγχου που παρέχονται από το γλωσσικό μεταγλωττιστή. Παραδείγματος χάριν, ένας μεταγλωττιστής της Ada ελέγχει ότι οι λειτουργίες έχουν το σωστό αριθμό παραμέτρων, ο μεταγλωττιστής C όμως όχι. Οι πιθανοί έλεγχοι που ίσως έγιναν κατά τη διάρκεια της διαδικασίας επιθεώρησης παρουσιάζονται στον πίνακα 3. Οι Gilb και Graham (1993) υπογραμμίζουν ότι κάθε οργάνωση πρέπει να αναπτύξει τον δικό της πίνακα ελέγχου επιθεώρησης. Αυτό πρέπει να βασιστεί στα τοπικά πρότυπα και τις Σελ. 25 από 102

Κεφάλαιο 1: Επαλήθευση και επικύρωση πρακτικές και πρέπει να ενημερωθεί όπως βρίσκονται και οι νέοι τύποι ατελειών. Δεδομένου ότι μια οργάνωση αποκτά την εμπειρία της διαδικασίας επιθεώρησης, μπορεί να χρησιμοποιήσει τα αποτελέσματα εκείνης της διαδικασίας ως μέσο βελτίωσης της διαδικασίας. Μια ανάλυση των ατελειών που βρίσκονται κατά τη διάρκεια της επιθεώρησης μπορεί να γίνει. Η ομάδα επιθεώρησης και οι συντάκτες του κώδικα που επιθεωρήθηκε, μπορούν να προτείνουν λόγους για τους οποίους αυτές οι ατέλειες εμφανίστηκαν. Οπουδήποτε είναι δυνατόν, η διαδικασία πρέπει έπειτα να τροποποιηθεί για να αποβάλει τις ατέλειες έτσι ώστε να μην επαναληφθούν στα μελλοντικά συστήματα. Κατηγορία ελαττωμάτων Έλεγχος επιθεώρησης - στοιχείων Δηλώνονται όλες οι μεταβλητές προτού χρησιμοποιηθούν; Έχουν ονομαστεί όλες οι σταθερές; Θα έπρεπε το ανώτερο όριο των σειρών να είναι μέγεθος -1; Αν χρησιμοποιούνται strings, ορίζεται ρητά ένας οριοθέτης; Υπάρχει οποιαδήποτε περίπτωση υπερχείλισης απομονωτών; - ελέγχου Για κάθε υπό όρους δήλωση, είναι σωστή η συνθήκη; Οι σύνθετες δηλώσεις μπαίνουν σε παρένθεση σωστά; Εάν απαιτείται μια διακοπή μετά από οποιαδήποτε περίπτωση, έχει αυτή συμπεριληφθεί; - εισόδων, εξόδων Χρησιμοποιούνται όλες οι μεταβλητές εισαγωγής; Έχουν ορίσει όλες οι μεταβλητές εξαγωγής μία αξία προτού εξαχθούν; Σελ. 26 από 102

Πτυχιακή εργασία της Μανασίδου Χριστίνας Μπορούν απροσδόκητες τιμές εισαγωγής να προκαλέσουν την κατάρρευση του συστήματος; - διεπαφών Όλες οι κλήσεις λειτουργίας και μεθόδου έχουν το σωστό αριθμό παραμέτρων; Υπάρχει αντιστοιχία τύπων επίσημης και πραγματικής παραμέτρου; Είναι οι παράμετροι στη σωστή σειρά; Εάν τα συστατικά έχουν πρόσβαση στην κοινή μνήμη, έχουν το ίδιο μοντέλο με τη κοινή δομή μνήμης; - διαχείριση αποθήκευσης Εάν μια συνδεμένη δομή τροποποιείται, έχουν όλες οι συνδέσεις επανεκχωρηθεί σωστά; Εάν η δυναμική αποθήκευση χρησιμοποιείται, το διάστημα έχει διατεθεί σωστά; Το διάστημα απελευθερώνεται ρητά αφότου δεν απαιτείται πλέον; - διαχείρισης εξαίρεσης Όλοι οι πιθανοί όροι έχουν λήφθουν υπόψη; Πίνακας 3: Έλεγχοι επιθεωρήσεων Οι Gilb και Graham αναφέρουν ότι διάφορες οργανώσεις έχουν εγκαταλείψει τη δοκιμή μονάδων λόγω των επιθεωρήσεων. Έχουν διαπιστώσει ότι οι επιθεωρήσεις προγράμματος είναι τόσο αποτελεσματικές στην εύρεση λαθών έτσι ώστε οι δαπάνες της δοκιμής μονάδων δεν είναι δικαιολογήσιμες. Το μέγεθος του κώδικα που μπορεί να επιθεωρηθεί σε έναν δεδομένο χρόνο εξαρτάται από την εμπειρία της ομάδας επιθεώρησης, τη γλώσσα προγραμματισμού και τη περιοχή εφαρμογής. Όταν η διαδικασία επιθεώρησης μετρήθηκε στην IBM, ο Fagan έκανε τις ακόλουθες παρατηρήσεις: 1. Περίπου 500 δηλώσεις κώδικα πηγής ανά ώρα μπορούν να εξεταστούν κατά τη διάρκεια του σταδίου επισκόπησης. 2. Κατά τη διάρκεια της μεμονωμένης προετοιμασίας, περίπου 125 δηλώσεις κώδικα πηγής ανά ώρα μπορούν να εξεταστούν. Σελ. 27 από 102

Κεφάλαιο 1: Επαλήθευση και επικύρωση 3. Από 90 έως 125 δηλώσεις ανά ώρα μπορούν να επιθεωρηθούν κατά τη διάρκεια της συνεδρίασης. Αυτοί οι αριθμοί επιβεβαιώνονται από τα στοιχεία που συλλέγονται από την AT&T (Barnard και Price, 1994) όπου οι μετρήσεις της διαδικασίας επιθεώρησης παρουσίασαν συγκρίσιμες τιμές. Ο Fagan προτείνει ότι ο μέγιστος χρόνος που ξοδεύεται σε μια επιθεώρηση πρέπει να είναι περίπου δύο ώρες καθώς η αποδοτικότητα της διαδικασίας ανίχνευσης ατέλειας μειώνεται αρκετά μετά από εκείνο τον χρόνο. Η επιθεώρηση πρέπει επομένως να είναι μια συχνή διαδικασία, που πραγματοποιείται στα σχετικά μικρά τμήματα λογισμικού, κατά τη διάρκεια της ανάπτυξης προγράμματος. Με τέσσερις ανθρώπους που συμμετέχουν σε μια ομάδα επιθεώρησης, το κόστος 100 γραμμών κώδικα είναι κατά προσέγγιση ισοδύναμο με μιας ημέρας προσπάθεια ενός ατόμου. Αυτό υποθέτει ότι η ίδια η επιθεώρηση διαρκεί για μια ώρα και ότι κάθε μέλος περνά 1-2 ώρες να προετοιμαστεί για την επιθεώρηση. Οι εξεταστικές δαπάνες είναι πολύ μεταβλητές και εξαρτώνται από τον αριθμό ελαττωμάτων στο πρόγραμμα. Εντούτοις, η προσπάθεια που απαιτείται για την επιθεώρηση προγράμματος είναι πιθανώς λιγότερη από τη μισή προσπάθεια που θα απαιτούνταν για την ισοδύναμη δοκιμή ατέλειας. Η εισαγωγή της αξιολόγησης έχει επιπτώσεις στη διαχείριση του προγράμματος και η ευαίσθητη διαχείριση είναι σημαντική εάν η επιθεώρηση πρόκειται να γίνει αποδεκτή από τις ομάδες ανάπτυξης λογισμικού. Οι επιθεωρήσεις είναι μια δημόσια διαδικασία της ανίχνευσης λάθους έναντι της πιο ιδιωτικής εξεταστικής διαδικασίας και, αναπόφευκτα, λάθη που γίνονται από τα άτομα αποκαλύπτονται από ολόκληρη την ομάδα. Σελ. 28 από 102

Πτυχιακή εργασία της Μανασίδου Χριστίνας Οι διευθυντές πρέπει να εξασφαλίσουν ότι υπάρχει ένας σαφής χωρισμός μεταξύ των επιθεωρήσεων και των αξιολογήσεων προσωπικού. Τα αποτελέσματα επιθεώρησης που αποκαλύπτουν λάθη δεν πρέπει ποτέ να χρησιμοποιηθούν στις αξιολογήσεις της σταδιοδρομίας των μηχανικών. Οι αρχηγοί της ομάδας πρέπει να εκπαιδευθούν προσεκτικά για να διαχειριστούν τη διαδικασία και για να αναπτύξουν μια κουλτούρα όπου παρέχεται υποστήριξη όταν ανακαλύπτονται τα λάθη. 1.4 ΑΥΤΟΜΑΤΟΠΟΙΗΜΕΝΗ ΤΕΧΝΙΚΗ ΑΝΑΛΥΣΗ Οι στατικοί αναλυτές προγράμματος είναι εργαλεία λογισμικού που ανιχνεύουν το κείμενο πηγής ενός προγράμματος και ανιχνεύουν τα πιθανά ελαττώματα και τις ανωμαλίες. Δεν απαιτούν το πρόγραμμα να έχει εκτελεσθεί. Μάλλον, αναλύουν το κείμενο προγράμματος και αναγνωρίζουν έτσι τους διαφορετικούς τύπους δηλώσεων στο πρόγραμμα. Μπορούν έπειτα να ανιχνεύσουν εάν οι δηλώσεις διαμορφώνονται σωστά ή όχι, διεξάγουν τα συμπεράσματα για τη ροή ελέγχου στο πρόγραμμα και, σε πολλές περιπτώσεις, υπολογίζουν το σύνολο όλων των πιθανών τιμών για τα στοιχεία προγράμματος. Συμπληρώνουν τις εγκαταστάσεις ανίχνευσης λάθους που παρέχονται από το γλωσσικό μεταγλωττιστή. Η πρόθεση της αυτόματης στατικής ανάλυσης είναι να εφιστεί η προσοχή του ελεγκτή στις ανωμαλίες του προγράμματος όπως οι μεταβλητές που χρησιμοποιούνται χωρίς την έναρξη, μεταβλητές που είναι αχρησιμοποίητες, στοιχεία των οποίων η αξία θα μπορούσε να βγει εκτός υπολογισμού, κ.λπ. Μερικοί από τους ελέγχους που μπορούν να ανιχνευθούν από τη στατική ανάλυση παρουσιάζονται στον Πίνακα 4. Ενώ αυτοί δεν είναι απαραιτήτως λανθασμένοι όροι, υπάρχει συχνά η περίπτωση ότι πολλές από αυτές τις ανωμαλίες είναι ένα αποτέλεσμα των λαθών προγραμματισμού ή των παραλείψεων. Η αυτοματοποιημένη στατική ανάλυση χρησιμοποιείται καλύτερα με τις επιθεωρήσεις Σελ. 29 από 102

Κεφάλαιο 1: Επαλήθευση και επικύρωση λογισμικού. Παρέχει τις πρόσθετες πληροφορίες για την ομάδα επιθεώρησης. Κατηγορίες ελαττωμάτων Στατικός έλεγχος ανάλυσης - στοιχείων Μεταβλητές που χρησιμοποιούνται πριν από την έναρξη. Μεταβλητές που δηλώνονται αλλά δε χρησιμοποιούνται ποτέ. Μεταβλητές που ορίστηκαν δύο φορές αλλά δε χρησιμοποιήθηκαν ποτέ εντός των παρενθέσεων. Πιθανή παραβίαση συνδεδεμένης σειράς. Αδήλωτες μεταβλητές. - ελέγχου Απρόσιτος κώδικας. Απεριόριστοι κλάδοι στους βρόχους. - εισόδου, εξόδου Διπλή έξοδος μεταβλητών χωρίς την κατάλληλη ανάθεση. - διεπαφών Κακοί συνδυασμοί τύπων παραμέτρου. Κακοί συνδυασμοί αριθμού παραμέτρου. Η μη χρησιμοποίηση των αποτελεσμάτων. Μη καλούμενες λειτουργίες και διαδικασίες. - διαχείριση Δείκτες που δεν έχουν οριστεί. αποθήκευσης Αριθμητική δεικτών. Πίνακας 4: Αυτόματοι στατικοί έλεγχοι ανάλυσης. Τα στάδια που περιλαμβάνονται στη στατική ανάλυση περιλαμβάνουν: 1. Ανάλυση ροής ελέγχου. Αυτό το στάδιο προσδιορίζει και δίνει έμφαση στους βρόχους με πολλαπλάσια έξοδο ή τα σημεία εισόδων και στον απρόσιτο κώδικα. Ο απρόσιτος κώδικας είναι κώδικας που περιβάλλεται από τις απεριόριστες δηλώσεις «goto» ή αυτός που είναι σε έναν κλάδο μιας υπό όρους δήλωσης όπου ο όρος φύλαξης δεν μπορεί ποτέ να είναι αληθινός. 2. Το στοιχείο χρησιμοποιεί την ανάλυση. Αυτό το στάδιο δίνει έμφαση πώς οι μεταβλητές στο πρόγραμμα χρησιμοποιούνται. Ανιχνεύει τις Σελ. 30 από 102

Πτυχιακή εργασία της Μανασίδου Χριστίνας μεταβλητές που χρησιμοποιούνται χωρίς προηγούμενη έναρξη, μεταβλητές που γράφονται δύο φορές και μεταβλητές που δηλώνονται αλλά δεν χρησιμοποιούνται ποτέ. Η ανάλυση χρήσης στοιχείων ανακαλύπτει επίσης τις ατελέσφορες δοκιμές όπου ο όρος δοκιμής είναι περιττός. Οι περιττοί όροι είναι όροι των οποίων η αξία δεν αλλάζει ποτέ-είναι είτε πάντα αληθινοί είτε πάντα ψεύτικοι. 3. Ανάλυση διεπαφών. Αυτή η ανάλυση ελέγχει τη συνέπεια των δηλώσεων ρουτίνας και διαδικασίας και της χρήσης τους. Η ανάλυση διεπαφών μπορεί να ανιχνεύσει τα τυπικά λάθη στις αδύναμες γλώσσες όπως η FORTRAN και η Ο. Η διεπαφή μπορεί επίσης να ανιχνεύσει τις λειτουργίες και τις διαδικασίες που δηλώνονται και δεν καλούνται ποτέ ή αποτελέσματα που δεν χρησιμοποιούνται ποτέ. 4. Ανάλυση ροής πληροφοριών. Αυτή η φάση της ανάλυσης προσδιορίζει τις εξαρτήσεις μεταξύ των μεταβλητών εισαγωγής και των μεταβλητών εξαγωγής. Ενώ δεν ανιχνεύει τις ανωμαλίες, η παραγωγή των τιμών που χρησιμοποιούνται στο πρόγραμμα παρατίθενται ρητά. Οι λανθασμένες παραγωγές πρέπει επομένως να είναι ευκολότερες να ανιχνεύσουν κατά τη διάρκεια μιας επιθεώρησης ή μιας αναθεώρησης κώδικα. Η ανάλυση ροής πληροφοριών μπορεί επίσης να παρουσιάσει τους όρους που έχουν επιπτώσεις στην αξία μιας μεταβλητής. 5. Ανάλυση πορειών. Αυτή η φάση σημασιολογικής ανάλυσης προσδιορίζει όλες τις πιθανές πορείες μέσω του προγράμματος και καθορίζει τις δηλώσεις που εκτελούνται σε εκείνη την πορεία. Διευκρινίζει ουσιαστικά τον έλεγχο του προγράμματος και επιτρέπει σε κάθε πιθανό κατηγόρημα να αναλυθεί χωριστά. Η ανάλυση ροής πληροφοριών και η ανάλυση πορειών παράγουν απέραντες πληροφορίες. Αυτές οι πληροφορίες δεν δίνουν έμφαση στις ανωμαλίες αλλά απλώς παρουσιάζουν το πρόγραμμα από μια διαφορετική Σελ. 31 από 102

Κεφάλαιο 1: Επαλήθευση και επικύρωση άποψη. Λόγω των πολλών πληροφοριών που παράγονται, αυτές οι φάσεις στατικής ανάλυσης αφήνονται μερικές φορές από τη διαδικασία. Μόνο οι πρόωρες φάσεις, που ανιχνεύουν τις ανωμαλίες άμεσα, χρησιμοποιούνται. Οι στατικοί αναλυτές είναι ιδιαίτερα πολύτιμοι όταν χρησιμοποιείται μια γλώσσα προγραμματισμού όπως η C. Η C δεν έχει τους ακριβείς κανόνες τύπων και ο έλεγχος που ο μεταγλωττιστής της C μπορεί να κάνει είναι περιορισμένος. Επομένως, υπάρχουν διαπραγματεύσεις για τα λάθη των προγραμματιστών που μπορούν να ανακαλυφθούν αυτόματα από το εργαλείο ανάλυσης. Αυτό είναι ιδιαίτερα σημαντικό όταν χρησιμοποιείται η C (και η C++ επίσης) για την ανάπτυξη συστημάτων. Σε αυτήν την περίπτωση, η στατική ανάλυση μπορεί σημαντικά να μειώσει τις εξεταστικές δαπάνες. Τα συστήματα Unix και Linux περιλαμβάνουν έναν στατικό αναλυτή αποκαλούμενο LINT για τα προγράμματα C. Ο LINT παρέχει στατικό έλεγχο ο όποιος είναι ισοδύναμος με αυτόν που παρέχεται από το μεταγλωττιστή σε μια έντονα δακτυλογραφημένη γλώσσα όπως η JAVA. Ένα παράδειγμα παραγωγής εξόδου από τον LINT περιγράφεται στον Πίνακα 5. Εδώ, οι εντολές παρουσιάζονται στο σχόλιο με πλάγιους χαρακτήρες. Η πρώτη εντολή απαριθμεί το πρόγραμμα. Καθορίζει μια λειτουργία με μια παράμετρο αποκαλούμενη printarray, κατόπιν καλεί αυτήν την λειτουργία με τρεις παραμέτρους. Οι μεταβλητές i και c δηλώνονται, αλλά δεν ορίζονται ποτέ οι τιμές τους. Η τιμή που επιστρέφεται από τη λειτουργία δεν χρησιμοποιείται ποτέ. Σελ. 32 από 102

Πτυχιακή εργασία της Μανασίδου Χριστίνας 138% more lint_ex.c #include <stdio.h> Printarray (Anarray) Int Anarray; { Printf( /od, Anarray); } Main() { Int Anarray[5]; int i; char c; Printarray (Anarray,i,c); Printarray (Anarray); } 139% cc lint_ex.c 140% lint_ex.c Lint_ex.c(10): warning: c may be used before set Lint_ex.c(10): warning: I may be used before set Printarray: variable # of args.lint_ex.c(4)::lint_ex.c(10) Printarray, arg 1 used inconsistently lint_ex.c(4)::lint_ex.c(10) Printarray, arg 1 used inconsistently lint_ex.c(4)::lint_ex.c(11) Printf returns value which is always ignored Πίνακας 5: Στατική ανάλυση του LINT Η γραμμή που αριθμείται 139 παρουσιάζει την σύνταξη αυτού του προγράμματος χωρίς τα λάθη που αναφέρονται από το μεταγλωττιστή C. Αυτό ακολουθείται από μια κλήση του στατικού αναλυτή LINT που ανιχνεύει και εκθέτει τα λάθη του προγράμματος. Ο στατικός αναλυτής δείχνει ότι οι κλιμακωτές μεταβλητές c και i έχουν χρησιμοποιηθεί αλλά δεν έχουν βγάλει κάποιο αποτέλεσμα και ότι η printarray έχει κληθεί με έναν διαφορετικό αριθμό επιχειρημάτων από αυτά που δηλώνονται. Προσδιορίζει επίσης την ασυμβίβαστη χρήση του πρώτου επιχειρήματος σε printarray και το γεγονός ότι η αξία λειτουργίας δεν χρησιμοποιείται ποτέ. Η ανάλυση βασισμένη σε εργαλεία δεν μπορεί Σελ. 33 από 102

Κεφάλαιο 1: Επαλήθευση και επικύρωση να αντικαταστήσει ως εκεί μερικούς τύπους λαθών που οι στατικοί αναλυτές δεν μπορούν να ανιχνεύσουν. Παραδείγματος χάριν, μπορούν να ανιχνεύσουν τις αρχικές μεταβλητές αλλά δεν μπορούν να ανιχνεύσουν τις ενάρξεις που είναι ανακριβείς. Στις αδύναμα δακτυλογραφημένες γλώσσες όπως η C, οι στατικοί αναλυτές μπορούν να ανιχνεύσουν τις λειτουργίες που έχουν τους λανθασμένους αριθμούς και τους τύπους επιχειρημάτων αλλά αυτοί δεν μπορούν να ανιχνεύσουν τις καταστάσεις όπου ένα ανακριβές επιχείρημα του σωστού τύπου έχει περάσει σε μια λειτουργία. Δεν υπάρχει καμία αμφιβολία ότι, για τις γλώσσες όπως η C, η στατική ανάλυση είναι μια αποτελεσματική τεχνική για την ανακάλυψη λαθών σε ένα πρόγραμμα. Εντούτοις, με τις σύγχρονες γλώσσες προγραμματισμού όπως την JAVA, οι γλωσσικοί σχεδιαστές έχουν αφαιρέσει μερικά επιρρεπή λάθη σε γλωσσικά χαρακτηριστικά γνωρίσματα. Όλες οι μεταβλητές πρέπει να δηλωθούν στην αρχή, δεν υπάρχουν goto δηλώσεις έτσι ο απρόσιτος κώδικας είναι λιγότερο πιθανό να δημιουργηθεί τυχαία και η διαχείριση αποθήκευσης είναι αυτόματη. Αυτή η προσέγγιση της αποφυγής λάθους παρά την ανίχνευση λάθους είναι αποτελεσματικότερη στη βελτίωση της αξιοπιστίας του προγράμματος. Επομένως, η αυτόματη στατική ανάλυση μπορεί να μην είναι οικονομικώς αποδοτική για τα προγράμματα της JAVA. 1.5 ΑΝΑΠΤΥΞΗ ΛΟΓΙΣΜΙΚΟΥ ΣΕ «ΚΑΘΑΡΟ ΔΩΜΑΤΙΟ» Η ανάπτυξη λογισμικού σε «καθαρό δωμάτιο» (cleanroom software development) είναι μια φιλοσοφία ανάπτυξης λογισμικού που βασίζεται στην αποφυγή των ατελειών λογισμικού με τη χρησιμοποίηση μιας αυστηρής διαδικασίας επιθεώρησης. Ο στόχος αυτής της προσέγγισης στην ανάπτυξη λογισμικού είναι ένα λογισμικό χωρίς ατέλειες. Το όνομα «καθαρό δωμάτιο» προήλθε κατ'αναλογίαν προς τις μονάδες επεξεργασίας ημιαγωγών. Σε αυτές τις μονάδες οι ατέλειες αποφεύγονται Σελ. 34 από 102

Πτυχιακή εργασία της Μανασίδου Χριστίνας με την κατασκευή σε ένα εξαιρετικά-καθαρό περιβάλλον. Έχει αντικαταστήσει τη δοκιμή μονάδων των τμημάτων συστημάτων από τις επιθεωρήσεις για να ελέγξει τη συνέπεια αυτών των συστατικών με τις προδιαγραφές τους. Ένα πρότυπο της διαδικασίας «καθαρού δωματίου», που προσαρμόζεται από την περιγραφή που δίνεται από Linger (1994) παρουσιάζεται στην Εικόνα 5 παρακάτω. Εικόνα 5: Η ανάπτυξη λογισμικού σε «καθαρό δωμάτιο». Η προσέγγιση «καθαρών δωματίων» στη ανάπτυξη λογισμικού είναι βασισμένη σε πέντε βασικά χαρακτηριστικά: 1. Επίσημη προδιαγραφή. Το λογισμικό που αναπτύσσεται διευκρινίζεται τυπικά. Ένα πρότυπο κράτος-μετάβασης που παρουσιάζει απαντήσεις συστημάτων στα ερεθίσματα χρησιμοποιείται για να εκφράσει την προδιαγραφή. 2. Επαυξητική ανάπτυξη. Το λογισμικό χωρίζεται στις αυξήσεις που αναπτύσσονται και επικυρώνονται χωριστά χρησιμοποιώντας τη διαδικασία καθαρών δωματίων. Αυτές οι αυξήσεις διευκρινίζονται, με την εισαγωγή πελατών, σε ένα πρώτο στάδιο στη διαδικασία. Σελ. 35 από 102

Κεφάλαιο 1: Επαλήθευση και επικύρωση 3. Δομημένος προγραμματισμός. Μόνο ένας περιορισμένος αριθμός των κατασκευασμάτων αφαίρεσης ελέγχου και στοιχείων χρησιμοποιείται. Η αναπτυξιακή διαδικασία προγράμματος είναι μια διαδικασία του σταδιακού καθαρισμού της προδιαγραφής. Ένας περιορισμένος αριθμός των κατασκευασμάτων χρησιμοποιείται και ο στόχος είναι να εφαρμοστεί η ακρίβεια-συντήρηση των μετασχηματισμών στην προδιαγραφή για να δημιουργήσει τον κώδικα προγράμματος. 4. Στατική επαλήθευση. Το αναπτυγμένο λογισμικό ελέγχεται στατικά χρησιμοποιώντας τις αυστηρές επιθεωρήσεις λογισμικού. Δεν υπάρχει καμία εξεταστική διαδικασία μονάδων ή ενότητας για τα τμήματα κώδικα. 5. Στατιστική δοκιμή του συστήματος. Η ενσωματωμένη αύξηση λογισμικού εξετάζεται στατιστικά, για να καθορίσει την αξιοπιστία της. Αυτές οι στατιστικές δοκιμές είναι βασισμένες σε ένα λειτουργικό σχεδιάγραμμα που είναι παράλληλο με την προδιαγραφή συστημάτων όπως φαίνεται στην εικόνα 6 παραπάνω. Η επαυξητική ανάπτυξη, που παρουσιάζεται στην εικόνα 6, περιλαμβάνει την παραγωγή και την παράδοση του λογισμικού στις ιδιαίτερες αυξήσεις. Μια αύξηση μπορεί να εκτελεσθεί από τις εντολές χρηστών και είναι ένα χρήσιμο, περιορισμένο σύστημα στο δικαίωμα της. Οι χρήστες ανατροφοδοτούν τις εκθέσεις του συστήματος και προτείνουν τις αλλαγές που απαιτούνται. Η επαυξητική ανάπτυξη είναι σημαντική επειδή ελαχιστοποιεί τη διάσπαση που προκαλείται στην αναπτυξιακή διαδικασία από τις ζητούμενες απαιτήσεις των πελατών και τις αλλαγές αυτών. Σελ. 36 από 102