ΕφαρμογεΣ Λογισμικου
Γ Γενικου Λυκειου - ΕπιλογηΣ

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

• Τι είναι όμως λογισμικό;
• Πόσα είδη λογισμικού υπάρχουν;
• Τι είναι η βάση δεδομένων και πώς λειτουργεί το λογισμικό διαχείρισης δεδομένων;

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

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

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

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

• Πώς γίνεται αυτό ιδιαίτερα όταν οι εφαρμογές είναι κατασκευασμένες από άλλους κατασκευαστές;

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

Με την εξάπλωση του διαδίκτυου (internet) οι εφαρμογές, είτε διαχείρισης δεδομένων είτε άλλων κατηγοριών, στράφηκαν στον Παγκόσμιο Ιστό, όσον αφορά στη διεπαφή με το χρήστη και στα συστήματα πολλών βαθμίδων, όσον αφορά στην αρχιτεκτονική των εξυπηρετητών. Παράλληλα η αρχιτεκτονική του διαδικτύου χρησιμοποιείται και για κλειστά ενδοεπιχειρησιακά δίκτυα (intranets), που φιλοξενούν ολόκληρο το Πληροφοριακό Σύστημα Διοίκησης μιας εταιρίας.

• Τι είναι ο Παγκόσμιος Ιστός και πως στάθηκε δυνατό να προβληθούν μέσω αυτού πληροφορίες από βάσεις δεδομένων;
• Θα ενοποιηθεί το γραφικό περιβάλλον εργασίας των προσωπικών υπολογιστών με τον Παγκόσμιο Ιστό;
• Ποιες αναμένεται να είναι οι εξελίξεις του άμεσου μέλλοντος στις εφαρμογές λογισμικού;

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

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

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

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

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

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

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

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

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

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

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

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

Η απάντηση που όλο και πιο συχνά δίνεται στα σύγχρονα περιβάλλοντα εργασίας για την αντιμετώπιση των πιο πάνω προβληματισμών, είναι η επιλογή ενός συστήματος διαχείρισης βάσεων δεδομένων, όπως έχει ήδη εξηγηθεί στο κεφάλαιο 1. Τα πιο διαδεδομένα από αυτά τα συστήματα βασίζονται στο λεγόμενο σχεσιακό πρότυπο (relational model), όπως αυτοπαρουσιάστηκε από τον Edgar Codd στις αρχές της δεκαετίας του 70 και παρουσιάστηκε επίσης στο κεφάλαιο 1. Σύμφωνα με το πρότυπο αυτό, τα δεδομένα οργανώνονται σε πίνακες, οι οποίοι είναι δομές που μοιάζουν με αρχεία. Όμως, οι δομές αυτές δεν αποθηκεύονται ως αυτόνομες αναγνωρίσιμες οντότητες, όπως τα αρχεία. Η αποθήκευση των δεδομένων τους γίνεται με τρόπο μη αντιληπτό από το χρήστη του συστήματος και με τη βοήθεια του μηχανισμού του σχεσιακού συστήματος βάσεων δεδομένων. Ο μηχανισμός αυτός διασφαλίζει τη συσχέτιση των πινάκων, έτσι ώστε να είναι δυνατή η λήψη δεδομένων από περισσότερους από ένα πίνακες, με σχετικά απλό τρόπο, χωρίς αναγκαστικά πολύπλοκο προγραμματισμό. Τα συστήματα αυτά αναμένεται να εξελιχθούν ακόμη περισσότερο τα επόμενα χρόνια, προσφέροντας δυνατότητες, που πριν λίγα χρόνια θα χαρακτηρίζονταν εξωπραγματικές.

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

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

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

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

• Ποια είναι, όμως, τα κριτήρια με τα οποία θα γίνει αυτή η επιλογή;
• Ποια ερωτήματα θα πρέπει προηγουμένως να απαντηθούν;

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

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

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

Τυπικά τμήματα στα οποία διασπάται μια εφαρμογή λογισμικού είναι τα τμήματα κώδικα (προγράμματος) που υλοποιούν τις φόρμες εισαγωγής δεδομένων, τους καταλόγους επιλογών (μενού), τις αναφορές (reports), τα ερωταπαντήματα (queries) κ.λ.π. Κάθε τμήμα μπορεί να ανατεθεί σε διαφορετικό προγραμματιστή ή ομάδα προγραμματιστών. Ιδιαίτερα σημαντικό είναι να προσδιοριστούν με ακρίβεια τα παραδοτέα κάθε ομάδας, ώστε να είναι δυνατή στη συνέχεια η σύνθεσή τους σε ενιαίο πρόγραμμα, απαλλαγμένο λογικών σφαλμάτων, επικαλύψεων, κενών και αντιφάσεων. Η παραγωγή υψηλής ποιότητας λογισμικού απαιτεί η προγραμματιστική ομάδα να έχει ένα καλά καθορισμένο σχέδιο (πλάνο) του έργου υλοποίησης, μια καλά οργανωμένη συγκρότηση σε ανθρώπινους πόρους και μια συνολική συνειδητοποίηση των καθηκόντων και των ευθυνών κάθε μέλους της ομάδας. Η ομάδα υλοποίησης θα πρέπει να έχει στη διάθεση της καλά ορισμένες απαιτήσεις του λογισμικού, προδιαγραφές αρχιτεκτονικού σχεδίου και μια λεπτομερή περιγραφή σχεδίασης. Επίσης κάθε μέλος της ομάδας θα πρέπει να κατανοεί τους στόχους και τις γενικές αρχές της υλοποίησης. Όμως, όλα τα παραπάνω εξαρτώνται σε μεγάλο βαθμό και από το πρότυπο (κύκλο) ανάπτυξης λογισμικού, που έχει υιοθετηθεί για την ανάπτυξη της εφαρμογής. Στο παρόν κεφάλαιο θα περιγραφούν οι βασικές αρχές που διέπουν την υλοποίηση σύμφωνα με τους γνωστότερους κύκλους ανάπτυξης λογισμικού καθώς και ορισμένες βασικές τεχνικές ανάπτυξης αξιόπιστου λογισμικού. Τέλος, θα δοθεί ένα εκτενές και αρκετά αναλυτικό παράδειγμα τμηματικής υλοποίησης λογισμικού, προκειμένου να γίνουν κατανοητές οι απαιτούμενες προς τούτο εργασίες.

Στο προηγούμενο κεφάλαιο είδαμε πώς είναι δυνατό να υλοποιηθεί τμηματικά μια εφαρμογή λογισμικού. Το ερώτημα που τίθεται στη συνέχεια είναι:
Πώς πρέπει να προχωρήσουμε στη σύνθεση των παραδοτέων προϊόντων των επιμέρους εργασιών, ώστε να δημιουργήσουμε μια ολοκληρωμένη εφαρμογή, απαλλαγμένη σφαλμάτων και αντιφάσεων μεταξύ των μερών που θα την απαρτίζουν;
Για γίνει δυνατή η σύνθεση των παραδοτέων προϊόντων των επιμέρους εργασιών, που περιγράφηκαν στο προηγούμενο κεφάλαιο, είναι αναγκαίο να ανατρέξουμε στα δομικά στοιχεία (δηλ. τις μονάδες (units)) των χαμηλότερων επιπέδων του σχεδίου της εφαρμογής και να μελετήσουμε τα λεπτομερή τους χαρακτηριστικά, που περιγράφονται αναλυτικά σε αυτά τα επίπεδα. Έτσι, ξεκινώντας από τα χαμηλότερα ιεραρχικά επίπεδα προχωρούμε στα ανώτερα, όπου συναντούμε τις μεγάλες ενότητες (τμήματα), στις οποίες έχει διασπαστεί η εφαρμογή, και τις οποίες είδαμε σε προηγούμενο κεφάλαιο. Η μέθοδος αυτή σύνθεσης μιας εφαρμογής ονομάζεται σύνθεση "από κάτω προς τα πάνω".
Ο λεπτομερής σχεδιασμός, που αναλυτικά περιγράφηκε στο κεφάλαιο 7, αποτελεί το ενδιάμεσο στάδιο ανάμεσα στα "χαμηλότερα επίπεδα σχεδίασης" (low level design) και την υλοποίηση.
Ένας επαρκής και λεπτομερής σχεδιασμός ελαχιστοποιεί τον αριθμό των ανεπιθύμητων εκπλήξεων κατά τη διάρκεια της υλοποίησης του προγράμματος.
Η σύνθεση του λογισμικού (δηλ. η σύνδεση των επιμέρους τμημάτων του) είναι ένα βασικό θέμα του λεπτομερούς σχεδιασμού.
Τέλος, ο σχεδιασμός του ελέγχου περιλαμβάνει τη διατύπωση των σκοπών του ελέγχου, την επιλογή των κριτηρίων ολοκλήρωσης, το σχεδιασμό της επέκτασης, την επιλογή συγκεκριμένων εργαλείων και τεχνικών που θα χρησιμοποιηθούν και περιγραφή δοκιμαστικών δεδομένων, σε συνδυασμό με προσδοκώμενα αποτελέσματα.

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

• Πώς, όμως, ανακαλύπτονται τα σφάλματα;
• Τι είδους σφάλματα είναι δυνατό να προκύψουν;

Οι έλεγχοι με δοκιμαστικά δεδομένα, οι έλεγχοι οριακών τιμών, οι έλεγχοι τύπου "black box" και "white box" και οι έλεγχοι οριακών περιπτώσεων είναι μερικές από τις πιο συνηθισμένες τεχνικές και στρατηγικές, που εφαρμόζονται για την αποκάλυψη των σφαλμάτων, που μπορεί να περιέχουν οι εφαρμογές λογισμικού.

Ο David Gelender, καθηγητής Πληροφορικής στο Πανεπιστήμιο Yale, αναφέρει στο καινούργιο του βιβλίο "The Aesthetics of Computing" (εκδόσεις Weidenfeld & Nicolson): "To κάποτε καινούργιο αεροδρόμιο του Ντένβερ, πέντε χρόνια τώρα περιμένει μάταια το τελικό του λογισμικό για να λειτουργήσει. Ένα αεροδρόμιο, δέκα φορές μεγαλύτερο από το Ελληνικό, δε μπορούσε να αρχίσει να λειτουργεί γιατί δεν ήταν δυνατό στους προγραμματιστές να βρουν που ήταν όλα αυτά τα λάθη στο προγραμματιζόμενο σύστημα της αυτόματης συλλογής και διανομής των αποσκευών, σε ένα δίκτυο με 100 υπολογιστές και 5000 ηλεκτρονικά μάτια επίβλεψης".

• Είναι πράγματι τόσο δύσκολος ο εντοπισμός και η διόρθωση των σφαλμάτων;
• Υπάρχουν διαδικασίες, μέθοδοι και εργαλεία που μπορούν να βοηθήσουν σ' αυτό;
• Ποιος θα εξασφαλίσει ότι η διόρθωση ενός σφάλματος δε θα δημιουργήσει νέα σφάλματα;
• Ποιος θα συντονίσει, θα ελέγξει και θα εποπτεύσει τις τροποποιήσεις στο λογισμικό;

Μερικές απαντήσεις σ' αυτά τα ερωτήματα δίνονται στις ενότητες που ακολουθούν. Άλλωστε, ας μη ξεχνάμε τον ισχυρισμό του DeMacro ότι "το μέσο λογισμικό προϊόν δεν είναι ποτέ απαλλαγμένο σφαλμάτων".

Στα προηγούμενα κεφάλαια έχουν περιγραφεί όλες οι απαραίτητες ενέργειες για την ανακάλυψη, τον εντοπισμό και τη διόρθωση των σφαλμάτων που υπάρχουν στις μονάδες του προγράμματος (modules), καθώς και στις διεπαφές (interfaces) μεταξύ των μονάδων. Έχει ολοκληρωθεί, δηλαδή, ο έλεγχος των μονάδων του προγράμματος (module testing), ο έλεγχος της συνένωσης των μονάδων (integration testing) καθώς και η διόρθωση των σφαλμάτων που εντοπίστηκαν κατά τον έλεγχο. Έτσι μέχρι στιγμής, μετά την ολοκλήρωση της σύνθεσης των μονάδων του συστήματος, έχει εξασφαλιστεί ότι ο κώδικας δουλεύει όπως ακριβώς επιδίωκαν οι προγραμματιστές και είναι απαλλαγμένος σφαλμάτων.

• Είναι, όμως, βέβαιο ότι το σύστημα δουλεύει σύμφωνα με τις απαιτήσεις που προσδιορίστηκαν στο στάδιο της ανάλυσης;
• Είναι βέβαιο ότι πληροί τους στόχους του;
• Είναι βέβαιο ότι ικανοποιεί τόσο τους πελάτες όσο και τους κατασκευαστές του; Μπορεί να θεωρηθεί ότι αποτελεί το τελικό προϊόν έτοιμο να παραδοθεί στον πελάτη;

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

Σύμφωνα με τον Pressman, δεν είναι ασυνήθιστο σε μια εταιρία ανάπτυξης λογισμικού να δαπανά το 20% ή 30% από όλη την προσπάθεια ανάπτυξης στην κατασκευή τεκμηρίωσης. Ο Dennis, σ' ένα άρθρο του στο "Computer World", αναφέρει ότι "οι περισσότεροι άνθρωποι συμφωνούν ότι η ποιότητα της τεκμηρίωσης για τον τελικό χρήστη συνεπάγεται την επιτυχία ή την αποτυχία ενός νέου προϊόντος λογισμικού. Τα εγχειρίδια είναι αυτά που βλέπουν πρώτα οι πελάτες και από αυτά διαμορφώνουν άποψη για όλο το πακέτο λογισμικού". Εξ άλλου, ο Bailey, στο βιβλίο του για τα ανθρώπινα σφάλματα στα συστήματα υπολογιστών αναφέρει ότι το 30% των ανθρώπινων σφαλμάτων αποδίδονται άμεσα στην κακής ποιότητας τεκμηρίωση.

• Είναι λοιπόν τόσο σημαντικός ο ρόλος της τεκμηρίωσης στο λογισμικό;
• Σε τι συνίσταται η τεκμηρίωση;
• Ποια είναι εκείνα τα εγχειρίδια τεκμηρίωσης που θα πρέπει να συνοδεύουν το κάθε προϊόν λογισμικού κατά την παράδοση του στον πελάτη;
• Πώς πρέπει να εκπαιδεύονται οι χρήστες;
• Πως αξιολογείται ένα προϊόν λογισμικού;

Αυτά είναι μερικά από τα ερωτήματα στα οποία απαντά το παρόν το κεφάλαιο.