Έλεγχος Λογισμικού και Διαχείριση Επικινδυνότητας
(Διπλωματική Εργασία)

Ταγκαλάκη Βασιλική
M.Sc. στα Πληροφοριακά Συστήματα
Τμήμα Πληροφορικής
Οικονομικό Πανεπιστήμιο Αθηνών
Πατησίων 76, 10434, Αθήνα
E-mail: vasotag@aueb.gr

Φεβρουάριος, 2000

Περίληψη



Εισαγωγή

Το λογισμικό, ένα πολύπλοκο πνευματικό προϊόν, αναπόφευκτα προκύπτει από την ανάπτυξή του με ανεπιθύμητα ελαττώματα (defects), τα οποία είναι πιθανό να οφείλονται σε ενδογενείς και εξωγενείς αιτίες και των οποίων η μη ανακάλυψη και κατάλληλη αντιμετώπιση μπορεί να προκαλέσει συνέπειες που μπορούν να ποικίλουν από απλά ενοχλητικές έως και καταστροφικές.

Τεράστιες ποσότητες πόρων ξοδεύονται σε όλες τις σχετικές με τη τεχνολογία λογισμικού βιομηχανίες με σκοπό την αποφυγή αποτυχιών λογισμικού. Παρόλα αυτά, τελικά είναι αδύνατο να υπάρξει η εγγύηση ότι το λογισμικό είναι τέλειo, όπως είναι επίσης αδύνατο να προβλεφθεί και να εξαλειφθεί κάθε τι από τον εξωτερικό κόσμο που πιθανόν να απειλήσει το λογισμικό όσο αυτό εκτελείται

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

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

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


Επικινδυνότητα Λογισμικού

Σύμφωνα με τον David Gluch, η επικινδυνότητα είναι ένας συνδυασμός ενός μη επιθυμητού γεγονότος ή μιας αποτυχίας και των συνεπειών αυτού του γεγονότος ή της αποτυχίας στους χειριστές, στους χρήστες ή το περιβάλλον ενός συστήματος.

Όπως και ένα οποιοδήποτε άλλο έργο, έτσι και ένα έργο λογισμικού εμπεριέχει πολλούς και ποικίλους κινδύνους. Μόνο που οι κίνδυνοι που εμπλέκονται στη τεχνολογία λογισμικού είναι πολύ περισσότερο περίπλοκοι λόγω τριών κυρίως λόγων: (i) το λογισμικό είναι ένα εξαιρετικά πολύπλοκο πνευματικό δημιούργημα και η ανάπτυξή του δεν μπορεί να ορισθεί αυστηρά ως μία μηχανική διαδικασία, (ii) είναι πολύ περισσότερο προσανατολισμένο στον άνθρωπο (human-oriented) και (iii) υπάρχει έλλειψη καλών και αποτελεσματικών μεθόδων ανάλυσης επικινδυνότητας και ελέγχου αξιοπιστίας.


Διαχείριση Επικινδυνότητας Λογισμικού

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

Με άλλα λόγια, δεδομένου ότι τα προβλήματα είναι αναπόφευκτα, η διαχείριση επικινδυνότητας θέτει τα ερωτήματα "Τι ακριβώς μπορεί να πάει στραβά; Και αν συμβεί κάτι τέτοιο τι μπορεί να γίνει για να αντιμετωπιστεί;" Το πρώτο ερώτημα στοχεύει στο να βρει οτιδήποτε μπορεί να αποτύχει και να προκαλέσει μια σειρά αποτυχιών. Το δεύτερο ερώτημα έχει ως στόχο την παραγωγή εναλλακτικών τρόπων δράσης σε περιπτώσεις εμφανίσεως προβλημάτων

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

1)      Ανάλυση Επικινδυνότητας (Risk Analysis) η οποία με τη σειρά της αποτελείται από:

2)      Σχεδιασμός Διαχείρισης Επικινδυνότητας (Risk Management Planning)

3)      Επίλυση Επικινδυνότητας (Risk Resolution)

4)      Επίβλεψη Επικινδυνότητας (Risk Monitoring)


Σχέση Ελέγχου Λογισμικού και Διαχείρισης Επικινδυνότητας

Πριν από την παράδοση οποιουδήποτε προϊόντος ή εφαρμογής, είναι απαραίτητο να διεξάγεται απαραίτητα έλεγχος του λογισμικού, όπου αφενός μεν να ελέγχεται η ορθότητα των προϊόντων κάθε φάσης του κύκλου ζωής ανάπτυξής του σύμφωνα με την διαδικασία της επαλήθευσης (verification) και αφετέρου να εκτιμάται το κατά πόσο το λογισμικό ικανοποιεί τις απαιτήσεις (requirements) που έχουν τεθεί, δηλαδή να πραγματοποιείται η λεγόμενη διαδικασία της επικύρωσης (validation).

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

Αλλά ακόμα και η αναγνώριση σφαλμάτων, τις περισσότερες φορές, οδηγεί σε αλλαγές του κώδικα, πράγμα που μπορεί να καταλήξει σε βελτίωση της κατάστασης, αλλά μπορεί και να εισάγει επιπρόσθετα προβλήματα, ιδιαίτερα στην περίπτωση που πρόκειται για αλλαγές σε έναν κώδικα μεγάλου μεγέθους και υψηλής πολυπλοκότητας.

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

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


Παράγοντες Επικινδυνότητας Λογισμικού

Σε μία προσπάθεια καθορισμού της επικινδυνότητας του λογισμικού, σε σχέση πάντα με τον έλεγχο που πραγματοποιείται σε αυτό, προκύπτει ένα σύνολο παραγόντων που την επηρεάζουν άμεσα και το οποίο παρουσιάζεται παρακάτω:

1)      Κρισιμότητα Λογισμικού (CRIT)

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

CRIT = f (L (UO))    (1)

όπου : CRIT: η κρισιμότητα του λογισμικού
L(UO): η απώλεια που θα επέλθει λόγω του μη επιθυμητού αποτελέσματος (Loss if the outcome is unsatisfactory)

2)      Μέγεθος Λογισμικού (SIZE)

Ο έλεγχος που διεξάγεται σε ένα λογισμικό και κατ' επέκταση και η επικινδυνότητα που απομένει μετά την ολοκλήρωσή του, εξαρτάται άμεσα από το μέγεθός που αυτό έχει. Διότι όσο μεγαλύτερο είναι το μέγεθος του λογισμικού, τόσο μεγαλύτερη είναι και η πιθανότητα εμφάνισης σφαλμάτων και κατά συνέπεια και η πιθανότητα μη εντοπισμού ενός μέρους αυτών.

Χρησιμοποιούνται τρία διαφορετικά μεγέθη μέτρησης: (i) Object Points, που θεωρούνται οι οθόνες, τα reports και τα συστατικά μέρη που είναι εκφρασμένα σε γλώσσες τρίτης γενεάς (3GL Components), (ii) Unadjusted Function Points, που μετρούν το μέγεθος ενός έργου λογισμικού, με το να ποσοτικοποιούν την λειτουργικότητα της επεξεργασίας πληροφοριών που σχετίζεται με σημαντικά εξωτερικά δεδομένα ή εισόδους ελέγχου, εξόδους ή τύπους αρχείων και (iii) Γραμμές πηγαίου κώδικα (Source Lines of Code).

3)      Μέθοδος Ελέγχου (TESM)

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

Ένας πρώτος διαχωρισμός των μεθόδων ελέγχου γίνεται βάσει του αν κατά την διάρκεια του ελέγχου εκτελείται το πρόγραμμα, οπότε διεξάγεται δυναμικός έλεγχος (dynamic testing), ή δεν εκτελείται, οπότε πραγματοποιείται η λεγόμενη στατική ανάλυση (static analysis) Ένας δεύτερος διαχωρισμός βασίζεται στο αν υπάρχει ενδιαφέρον για την εσωτερική δομή του προγράμματος οδηγώντας σε δύο βασικές κατηγορίες: White-box testing και Black-box testing.

4)      Εμπειρία Ομάδας Ελέγχου (TEXP)

The effectiveness of software testing depends on the capability and the experience of the testing team; the more experienced the team is, particularly in similar with the one under development projects, the higher the probability of uncovering faults in the software. One way to categorize this factor is on the basis of time, even though it is not easy to set strict borders between the categories.

5)   Πολυπλοκότητα Λογισμικού (CPLX)

Η πολυπλοκότητα που έχει το λογισμικό αποτελεί έναν ακόμα παράγοντα που επηρεάζει την επικινδυνότητα που το χαρακτηρίζει. Γιατί βέβαια, όσο υψηλότερη είναι η πολυπλοκότητα του λογισμικού, τόσο μεγαλύτερη είναι και η πιθανότητα εμφάνισης μιας αποτυχίας, λόγω μη εύρεσης κάποιων σφαλμάτων κατά τη διάρκεια του ελέγχου.

Το επίπεδο πολυπλοκότητας του λογισμικού μπορεί να καθοριστεί με βάση ορισμένες κατηγορίες λειτουργιών του και πιο συγκεκριμένα βάσει των λειτουργιών ελέγχου, υπολογισμού, εξαρτώμενων από συσκευές, διαχείρισης δεδομένων και διαχείρισης διεπαφής χρήστη, βάσει της κατάταξης που ακολουθεί το Constructive Cost Model (COCOMO), το οποίο χρησιμοποιείται για την εκτίμηση κόστους ενός έργου λογισμικού.

6)      Συχνότητα Χρήσης (FREQ)

Η συχνότητα χρήσης αποτελεί έναν ακόμα σημαντικό παράγοντα που επηρεάζει την επικινδυνότητα του λογισμικού. Και αυτό διότι, όσο πιο συχνά χρησιμοποιείται μια εφαρμογή ή ένα προϊόν, τόσο περισσότερο αυξάνεται και η πιθανότητα να αναδειχθεί ένα σφάλμα του λογισμικού και κατ' επέκταση να προκύψει ένα μη επιθυμητό αποτέλεσμα.

Όμως δεν υπάρχει διαφοροποίηση ως προς τη συχνότητα χρήσης μόνο ανάμεσα σε διαφορετικά συστήματα λογισμικού, αλλά και μεταξύ των τμημάτων και του ίδιου του λογισμικού. Δηλαδή, υπάρχουν περιοχές οι οποίες είναι πιθανό να χρησιμοποιούνται πιο συχνά από, όπως υπάρχουν και στον κώδικα μονοπάτια των οποίων η προσπέλαση είναι συχνότερη από κάποιων άλλων.

7)      Χρόνος Ελέγχου (ΤΙΜΕ)

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

Όμως, ο χρόνος που διαρκεί ο έλεγχος δεν μπορεί να αποτελέσει απόδειξη για το πόσο πλήρης αυτός ήταν, μιας και υπάρχει η πιθανότητα διεξαγωγής εκτενούς ελέγχου, χωρίς να επιτυγχάνεται τελικά ικανοποιητική κάλυψη, λόγω κάποιων λανθασμένων επιλογών που έχουν παρθεί.

8)      Διαθέσιμοι Πόροι (RESO)

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

 

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

P(UO) = f(SIZE,TEXP,TESM,CPLX,FREQ,TIME,RESO)        (2)

όπου: P(UO) : η πιθανότητα να συμβεί ένα μη επιθυμητό αποτέλεσμα (probability of an unsatisfactory outcome)

Βάσει των παραγόντων που προαναφέρθηκαν, για την επικινδυνότητα που απομένει μετά την ολοκλήρωση του ελέγχου του λογισμικού θα ισχύει η παρακάτω σχέση:

R = P(UO) x CRIT                                                                      (3)

όπου: R : η επικινδυνότητα του λογισμικού CRIT όπως ορίσθηκε από τη σχέση (1)
P(UO) όπως ορίσθηκε από τη σχέση (2)


Συνολική Διαδικασία Διαχείρισης Επικινδυνότητας σε σχέση με τον Έλεγχο Λογισμικού

Σύμφωνα με τα όσα έως τώρα αναφέρθηκαν, προκύπτει μια συνολική εικόνα της όλης διαδικασίας διαχείρισης επικινδυνότητας του λογισμικού σε συσχέτιση πάντα με την φάση του ελέγχου του.

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

Στη συνέχεια, σύμφωνα με τα δεδομένα που υπάρχουν, γίνονται οι διάφορες επιλογές από την ομάδα ελέγχου, ή και από άλλα υπεύθυνα για το έργο άτομα και πραγματοποιείται ο έλεγχος του λογισμικού.

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

Εφόσον διασφαλιστεί το γεγονός ότι ικανοποιούνται και οι υπόλοιπες παράμετροι ποιότητας (όπως για παράδειγμα: λειτουργικότητα, αξιοπιστία, συντηρησιμότητα, αποδοτικότητα, κ.α.), έπεται ότι το σύστημα λογισμικού μπορεί να εγγυηθεί την ικανοποίηση του πελάτη (user satisfaction) και κατά συνέπεια είναι έτοιμο για παράδοση.

Εάν όμως η επικινδυνότητα που απομένει ξεπερνά τα όρια που έχουν τεθεί, πρέπει να παρθούν νέες αποφάσεις ώστε να διεξαχθεί περαιτέρω έλεγχος έως ότου τελικά αυτά επιτευχθούν, υπό την προϋπόθεση βέβαια ότι υπάρχουν τα χρονικά και οικονομικά περιθώρια που θα επιτρέψουν κάτι τέτοιο. Σε περίπτωση όμως που δεν υπάρχουν είτε τα χρονικά περιθώρια είτε οι απαιτούμενοι πόροι για τη συνέχιση του ελέγχου, οι υπεύθυνοι για το έργο αιτούνται στον παραλήπτη του προϊόντος για να τους δοθεί παράταση ή να τους παραχωρηθούν επιπλέον πόροι.

Εφόσον η αίτηση αυτή γίνει δεκτή τότε η ομάδα ελέγχου μπορεί να προχωρήσει σε περαιτέρω έλεγχο, διαφορετικά το προϊόν παραδίδεται όπως έχει, εις γνώση όμως των πελατών σχετικά με το επίπεδο επικινδυνότητας που έχει απομείνει.

Συμπεράσματα


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

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

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

Δεν πρέπει βέβαια σε καμία περίπτωση, να θεωρηθούν δεσμευτικοί οι συγκεκριμένοι παράγοντες. Ενώ δηλαδή θεωρείται ότι είναι απαραίτητο να ληφθούν υπόψη προκειμένου να προκύψει ένα ορθό αποτέλεσμα, δεν αποκλείεται η ύπαρξη και κάποιων άλλων επιπρόσθετων παραγόντων, οι οποίοι να παίζουν έναν εξίσου σημαντικό ρόλο στον προσδιορισμό της υπολειπόμενης επικινδυνότητας.

Πρέπει επίσης να σημειωθεί ότι οι παράγοντες που προέκυψαν στην πραγματικότητα αποτελούν ένα προστάδιο για την εύρεση ενός κατάλληλου μοντέλου επικινδυνότητας σε σχέση με τον έλεγχο λογισμικού, πράγμα που αν και αποτελούσε επιδίωξη της παρούσας εργασίας, τελικά δεν επιτευχθεί.

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


Μελλοντική Έρευνα

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

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

Επίσης, θα μπορούσε να πραγματοποιηθεί μοντελλοποίηση της επικινδυνότητας του λογισμικού σε σχέση πάντα με τον έλεγχο, ενώ παράλληλα ανοίγονται και προοπτικές δημιουργίας ενός αυτοματοποιημένου εργαλείου, το οποίο στηριζόμενο και πάλι στους ίδιους παράγοντες, αλλά πιθανόν και σε κάποιους επιπλέον, να παρέχει εκτίμηση του ποσοστού επικινδυνότητας που υπολείπεται μετά το πέρας του ελέγχου.

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

Μια άλλη περιοχή στην οποία θα μπορούσε να έχει εφαρμογή με επιτυχία κάτι τέτοιο, είναι αυτή των εταιριών που παρέχουν ασφάλιση που σχετίζεται με λογισμικό, μιας και σίγουρα θα ελάττωνε σημαντικά το ποσοστό του ρίσκου που διατίθεται να πάρει ο ασφαλιστής προκειμένου να εξασφαλίσει ένα χρήστη λογισμικού από απώλειες που πιθανόν να συμβούν εξαιτίας μιας αποτυχίας του συστήματος (software insurability).

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

Βιβλιογραφία - Αναφορές