Τεχνολογία Λογισμικού

Σμαραγδάκης Γιάννης ΕΚΠΑ

Κεφάλαιο 1:

Εισαγωγή στην Τεχνολογία Λογισμικού

Στόχοι του κεφαλαίου

Οι στόχοι αυτού του κεφαλαίου είναι να καθορίσουμε τί είναι

“τεχνολογία λογισμικού” , να συζητήσουμε τα ιδιαίτερα χαρακτηριστικά
του καλώς κατασκευασμένου λογισμικού και να εισάγουμε την έννοια
της “διαδικασίας παραγωγής λογισμικού” (software process).

Θα αναφέρουμε διάφορα μοντέλα της διαδικασίας παραγωγής

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

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

λογισμικού που βασίζονται σε παραδοτέα (deliverable-based process
models) και σε κινδύνους που ενέχονται σ’αυτή τη διαδικασία (risk-
based process models). Τέλος συζητιέται η σχέση αυτών των μοντέλων
με τα μοντέλα της διαδικασίας παραγωγής λογισμικού που αναφέρθηκαν
στις προηγούμενες ενότητες.

ΠΕΡΙΕΧΟΜΕΝΑ
1. ΕΙΣΑΓΩΓΗ -------------------------------------------------------------------------------------------------- 2

2. ΚΑΛΩΣ ΚΑΤΑΣΚΕΥΑΣΜΕΝΟ ΛΟΓΙΣΜΙΚΟ ------------------------------------------------------ 3

3. Η ΔΙΑΔΙΚΑΣΙΑ ΠΑΡΑΓΩΓΗΣ ΛΟΓΙΣΜΙΚΟΥ ---------------------------------------------------------- 5

Τ Ο Μ Ο Ν Τ Ε Λ Ο Κ Α Τ Α Ρ Ρ Α Κ Τ Η ---------------------------------------------------- 6
Ε Ξ Ε Ρ Ε Υ Ν Η Τ Ι Κ Ο Σ Π Ρ Ο Γ Ρ Α Μ Μ Α Τ Ι Σ Μ Ο Σ ----------------------------------------- 9

4. ΜΟΝΤΕΛΑ ΔΙΟΙΚΗΣΗΣ ΤΗΣ ΔΙΑΔΙΚΑΣΙΑΣ ΑΝΑΠΤΥΞΗΣ ΛΟΓΙΣΜΙΚΟΥ -------------------- 10

1
1. ΕΙΣΑΓΩΓΗ

Δεν θα ήταν υπερβολή αν έλεγε κανείς ότι, με τα νέα δεδομένα στη

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

 Η τεχνολογία λογισμικού αφορά κυρίως συστήματα λογισμικού που

παράγονται απο ομάδες ανθρώπων και όχι από μεμονωμένα άτομα.
 Χρησιμοποιούνται αρχές μηχανολογίας (engineering).
 Περιλαμβάνονται τεχνικές και μη τεχνικές όψεις .
 Δεν απαιτούνται μόνο τεχνικές γνώσεις από τα άτομα που
απασχολούνται με τη παραγωγή του λογισμικού, αλλά και η
δυνατότητα να επικοινωνούν αυτά μεταξύ τους ανταλλάσοντας
απόψεις γραπτώς ή προφορικώς.
 Δίνεται ιδιαίτερη σημασία στη διοίκηση του όλου έργου (project
management).
 Δίνεται ιδιαίτερη προσοχή στα προβλήματα που απασχολούν τους
χρήστες και σχετίζονται με το λογισμικό που διαχειρίζονται.

Με τον όρο λογισμικό δεν εννοούμε μόνο το πρόγραμμα που

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

Ο όρος τεχνολογία λογισμικού (software engineering)

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

Οι πρώτες εμπειρίες σχετικά με την παραγωγή μεγάλων πακέτων

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

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

2. ΚΑΛΩΣ ΚΑΤΑΣΚΕΥΑΣΜΕΝΟ ΛΟΓΙΣΜΙΚΟ

Mε τον όρο τεχνολογία λογισμικού δεν αναφερόμαστε μόνο στη

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

1. Το λογισμικό θα πρέπει να είναι συντηρήσιμο. Επειδή ένα λογισμικό

γίνεται αντικείμενο συνεχών αλλαγών θα πρέπει αυτές οι αλλαγές
που παρατηρούνται να καταγράφονται και να τεκμηριώνονται ώστε να
γίνονται χωρίς ανώφελο κόστος.
2. Το λογισμικό θα πρέπει να είναι αξιόπιστο. Θα πρέπει επομένως να
δουλεύει όπως οι χρήστες απαιτούν και να μη καταρρέει πιο συχνα
από ότι αναφέρουν οι προδιαγραφές του.
3. Το λογισμικό θα πρέπει να είναι αποδοτικό. Με το όρο
αποδοτικό(efficient), εννοούμε ότι το σύστημα δεν θα πρέπει να
σπαταλάει τους πόρους του συστήματος όπως π.χ μνήμη, κύκλοι
μηχανής. Αντιθέτως θα πρέπει να επιδιώκουμε την αξιοποίηση των
πόρων στο μεγαλύτερο δυνατό βαθμό.
4. Το λογισμικό θα πρέπει να προσφέρει το κατάλληλο interface για τον
χρήστη. Με το κατάλληλο interface επιτυγχάνεται μεγαλύτερη
αξιοποίηση του λογισμικού.

Το κόστος είναι ένας από τους σημαντικότερους παράγοντες που θα

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

Είναι δύσκολο να βελτιστοποιηθούν όλοι οι παραπάνω παράγοντες που

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

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

ΚΟΣΤΟΣ

ΑΠΟΔΟΣΗ

Σχήμα 1 : Γραφική παράσταση κόστους προς απόδοση

Έτσι πολλές φορές χρειάζεται να βελτιστοποιηθεί ένα χαρακτηριστικό σε

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

4
3. Η ΔΙΑΔΙΚΑΣΙΑ ΠΑΡΑΓΩΓΗΣ ΛΟΓΙΣΜΙΚΟΥ

Ο προσδιορισμός της “κρίσης του λογισμικού” στο 1960 και η άποψη

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

Πρόκειται για το μοντέλο ‘καταρράκτη’, το οποίο έγινε δεκτό με

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

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

ΣΧΕΔΙΑΣΜΟΣ
ΣΥΣΤΗΜΑΤΟΣ
ΚΑΙ ΛΟ Γ Ι Σ ΜΙΚΟΥ

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

ΟΛΟΚΛΗΡΩΣΗ ΚΑΙ
ΕΛΕΓΧΟΣ ΣΥΣΤ/ΤΟΣ

ΛΕΙΤΟΥΡΓΙΑ ΚΑΙ ΣΥΝΤΗΡΗΣΗ

ΤΟΥ ΣΥΣΤΗΜΑΤΟΣ

Σχήμα 2 : Το μοντέλο καταρράκτη για τη διαδικασία

παραγωγής λογισμικού

Το όνομα ‘καταρράκτης’ προκύπτει από την κάθετη μετάβαση που

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

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

1. Μοντέλο καταρράκτη (Waterfall approach). Η διαδικασία παραγωγής

λογισμικού θεωρείται ότι αποτελείται από κάποια βήματα, τα οποία
αναλύονται παρακάτω αναλυτικότερα.
2. Εξερευνητικός προγραμματισμός (Exploratory programming) . H
προσέγγιση αυτή περιλαμβάνει τη κατασκευή ενός αρχικού
συστήματος και την υποβολή του στη συνέχεια σε συνεχείς
τροποποιήσεις ώστε να φτάσει σε ένα ικανοποιητικό σημείο. Το
μοντέλο αυτό χρησιμοποιείται για την ανάπτυξη μοντέλων
συστημάτων τεχνητής νοημοσύνης κυρίως γιατί δεν είναι δυνατόν σε
τέτοια συστήματα να κάνει κανείς προσδιορισμό απαιτήσεων, βήμα
που απaιτείται στο μοντέλο καταρράκτη.
3. Πρωτοτυποποίηση (Prototyping). Αυτή η προσέγγιση είναι παρόμοια
με την προηγούμενη, με τη διαφορά ότι εδώ ο στόχος είναι να
καθοριστούν οι απαιτήσεις του συστήματος. Στη συνέχεια , το
σύστημα αναπτύσσεται από την αρχή με ποιοτικό τρόπο.
4. Τυπικός μετασχηματισμός (Formal transformation). Σ’αυτή την
προσέγγιση αναπτύσσεται ένας τυπικός προσδιορισμός του
συστήματος και αυτός ο προσδιορισμός μετασχηματίζεται σε ένα
πρόγραμμα, με έναν τρόπο που να διασφαλίζεται η ορθότητά του.
5. Συναρμολόγηση του συστήματος απο επαναχρησιμοποιήσημα
κομμάτια . Αυτή η τεχνική υποθέτει ότι το σύστημα συντίθεται από
κομμάτια τα οποία ήδη υπάρχουν. Η διαδικασία δηλαδή αφορά
περισσότερο μια συναρμολόγηση παρά κατασκευή όπως τη
θεωρούμε συνήθως.

Οι τρεις πρώτες μεθοδοι χρησιμοποιούνται κατά κόρον για τη κατασκευή

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

ΤΟ ΜΟΝΤΕΛΟ ΚΑΤΑΡΡΑΚΤΗ

Υπάρχουν πολλές ποικιλίες αυτού του μοντέλου . Μερικές φορές λέγεται

και “μοντέλο κύκλου ζωής λογισμικού”. Όλες οι πικοιλίες αυτού του
μοντέλου μπορούν να ενσωματωθούν στο μοντέλο καταρράκτη (Σχ. 2) ,
τα στάδια του οποίου είναι τα εξής:

6
1. Ανάλυση και προσδιορισμός των απαιτήσεων . Οι υπηρεσίες, στόχοι
και περιορισμοί του συστήματος καθορίζονται μετά από συζήτηση με
τους ανθρώπους που θα χρησιμοποιήσουν το σύστημα. Μετά
ορίζονται με τρόπο κατανοητό και από τις δύο πλευρές.
2. Σχεδιασμός συστήματος και λογισμικού . Καθορίζεται μια γενική
αρχιτεκτονική του συστήματος χωρίζοντας τις απαιτήσεις του
συστήματος σε hardware ή software απαιτήσεις. Ο software
σχεδιασμός έχει να κάνει με την παρουσίαση του λειτουργιών
λογισμικού που απαιτούνται και που πρέπει να μεταφραστούν σε
εκτελέσιμα προγράμματα.
3. Υλοποίηση και έλεγχος ενοτήτων (units) . Κατά τη διάρκεια αυτού του
σταδίου, το λογισμικό υλοποιείται ως ένα σύνολο από προγράμματα
και ενότητες προγραμμάτων. Κάθε ενότητα πρέπει να ελεγχθεί ώστε
να διαπιστωθεί ότι πληρεί τις προδιαγραφές τους.
4. Ολοκλήρωση και έλεγχος του συστήματος . Σε αυτό το στάδιο το
σύστημα χτίζεται από τις επιμέρους ενότητες και ελέγχεται ως
ολοκληρωμένο πλέον σύστημα. Μετά τον έλεγχο μπορεί να
παραδοθεί στο χρήστη.
5. Λειτουργία και συντήρηση . Το σύστημα εγκαθίσταται και
χρησιμοποιείται. Συντήρηση σημαίνει διόρθωση των λαθών που δεν
είχαν ανακαλυφθεί σε προηγούμενα στάδια του σχεδιασμού,
βελτίωση των προγραμμάτων και βελτίωση των υπηρεσιών του
συστήματος όσο παρουσιάζονται νέες απαιτήσεις .

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

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

Το προτελευταίο στάδιο περιλαμβάνει τον έλεγχο του ολοκληρωμένου

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

7
κατασκευάζουμε σωστά το προϊόν), η δε επικύρωση (validation) εξετάζει
αν το προιόν που παράγεται είναι το σωστό.
Kατά τη διάρκεια του τελευταίου στάδιου (λειτουργία & συντήρηση),
επιστρέφονται πληροφορίες στα προηγούμενα στάδια. Σε αυτό το
στάδιο λάθη και παραλήψεις βγαίνουν στην επιφάνεια και αναγνωρίζεται
η ανάγκη για νέες λειτουργίες. Συντήρηση λογισμικού (software
maintenance) ονομάζεται η διαδικασία υλοποίησης αυτών των
αλλαγών, και επαναλαμβάνεται όσες φορές χρειαστεί.

Όπως αναφέρθηκε προηγουμένως, ένας από τους στόχους της

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

Μείωση του συνολικού κόστους του σχεδιασμού επιτυγχάνεται από μια

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

% Κόστος φάσης
Τύπος
συστήματος Απαιτήσεις/ Υλοποίηση Ελεγχος
σχεδιασμός

Συστήματα 46 20 34
εντολών και
ελέγχου

Λειτουργικά 33 17 50
συστήματα
Επιστημονικά 44 26 30
συστήματα
Επιχειρησιακά 44 28 28
συστήματα

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

Το μοντέλο του καταρράκτη έχει δεχτεί αρκετές κριτικές από τους

ειδικούς. Μία από αυτές είναι ότι δεν έχει καμία σχέση με τις
πραγματικές δραστηριότητες. Επίσης, πρόβλημα στο μοντέλο είναι ότι
δεν υπάρχει η έννοια της επανάληψης στη διαδικασία παραγωγής
λογισμικού. Επίσης, όπως αναφέρθηκε και πιο πάνω, αναγκαζόμαστε
συχνά να “παγώνουμε” τις απαιτήσεις του συστήματος αρκετά νωρίς, με
αποτέλεσμα συχνά η λειτουργικότητα του συστήματος να μην είναι η
αναμενόμενη. Το μοντέλο του εξερευνητικού προγραμματισμού
(exploratory programming) και η πρωτοτυποποίηση (prototyping)
προσπαθούν να αποφύγουν αυτά τα μειονεκτήματα.

ΕΞΕΡΕΥΝΗΤΙΚΟΣ ΠΡΟΓΡΑΜΜΑΤΙΣΜΟΣ

Το μοντέλο αυτό στηρίζεται στην ιδέα της ανάπτυξης μιας πρώτης

υλοποίησης. Με συνεχείς εκθέσεις της πρώτης αυτής ιδέας για το
σύστημα στον χρήστη, και με εμπλουτισμό της με τα σχόλια και τις
παρατηρήσεις του, φτάνει αυτή σε ένα ικανοποιητικό σημείο. Αυτή η
προσέγγιση θεωρείται κατάλληλη για συστήματα των οποίων δεν είναι
εύκολο να καθοριστούν με λεπτομέρεια οι απαιτήσεις. Τέτοια συστήματα
θεωρουνται τα συστήματα τεχνητής νοημοσύνης . Το κλειδί για την
επιτυχία της προσέγγισης αυτής είναι η χρήση τεχνικών που
επιτρέπουν γρήγορες εναλλαγές στο σύστημα, μέσα από τις οποίες
αυτό θα εξελίσσεται.
H έννοια της επαλήθευσης (verification) δεν υφίσταται σε αυτό το
μοντέλο, γιατί αυτή έχει νόημα μόνο όταν το προγραμμα συγκρίνεται με
τις προδιαγραφές του. Ετσι η ιδέα του σωστού προγράμματος
διαγράφεται. Η διαδικασία της επικύρωσης (validation) θα πρέπει να
δείχνει την επάρκεια του προγράμματος και όχι τη συμμόρφωση του με
τις προδιαγραφές. Βέβαια η έννοια της επάρκειας δεν είναι μετρήσιμη
και μόνο υποκειμενικές κρίσεις για αυτή μπορούν να γίνουν.
Τρεις είναι οι βασικοί λόγοι για τους οποίους το μοντέλο αυτό
χρησιμοποιείται περισσότερο για συστήματα τεχνητής νοημοσύνης και
λιγότερο για μεγαλύτερα συστήματα. :

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

Τα παραπάνω χαρακτηριστικά δεν κρίνουν το μοντέλο ως

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

4. ΜΟΝΤΕΛΑ ΔΙΟΙΚΗΣΗΣ ΤΗΣ ΔΙΑΔΙΚΑΣΙΑΣ ΑΝΑΠΤΥΞΗΣ

ΛΟΓΙΣΜΙΚΟΥ

Η αποδοτική διοίκηση της διαδικασίας παραγωγής λογισμικού βασίζεται

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

ΕΝΕΡΓΕΙΑ ΕΓΓΡΑΦΑ ΕΞΟΔΟΥ

Ανάλυση απαιτήσεων Μελέτη σκοπιμότητας

Περίγραμμα απαιτήσεων

Προσδιορισμός απαιτήσεων Προδιαγραφές απαιτήσεων

10
Προδιαγραφές συστήματος Λειτουργικές προδιαγραφές
Τεστ αποδοχής προδιαγραφών
Πρόχειρο εγχειρίδιο χρήστη

Αρχιτεκτονικός σχεδιασμός Προδιαγραφές σχεδιασμού

αρχιτεκτονικής
Προδιαγραφές ελέγχου

Σχεδιασμός Interface Προδιαγραφές Interface

Προδιαγραφές ελέγχου
ολοκλήρωσης

Λεπτομερής σχεδιασμός Προδιαγραφές σχεδιασμού

Προδιαγραφές ελέγχου τμημάτων
του συστήματος

Κωδικοποίηση Κώδικας προγράμματος

Ελεγχος ενοτήτων Αναφορές ελέγχου ενοτήτων

Ελεγχος τμημάτων Αναφορές ελέγχου τμημάτων

Ελεγχος ολοκλήρωσης Αναφορά ελέγχου ολοκλήρωσης

Τελικό εγχειρίδιο χρήστη

Ελεγχος συστήματος Αναφορα ελέγχου συστήματος

Ελεγχος αποδοχής Τελικό σύστημα

Μερικά από τα προβλήματα του μοντέλου προσανατολισμένου στη

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

 Το χρονικό σημείο απαίτησης παραγωγής εγγράφων από τη διοίκηση

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

 Η ανάγκη δημιουργίας και αποδοχής εγγράφων περιορίζει τη

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

 Η ιδέα ότι η έξοδος ενός στάδιου πρέπει να ενεργεί σαν είσοδος για το
επόμενο υπονοεί ότι η όλη διαδικασία ακολουθεί γραμμική εξελιξη,

11
 γεγονός που δεν ισχύει πάντα αφού ένα στάδιο λαμβάνει υπόψη του
όχι μόνο το προηγούμενο αλλά και επόμενα στάδια.

 Ο χρόνος που απαιτείται για να επαληθευτεί ένα έγγραφο είναι

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

Το μοντέλο καταρράκτη που βασίζεται στην παραγωγή εγγράφων έχει

υιοθετηθεί από τους περισσότερους κατασκευαστές λογισμικού.
Επομένως δεν είναι εύκολο να αγνοηθεί ως μέθοδος εξαιτίας των
προβλημάτων που παρουσιάζει. Θα ήταν χρήσιμο αν υπήρχε μια
μέθοδος που συμπεριελάμβανε όλα τα μοντέλα που αναπτύχθηκαν
προηγουμένως και ικανοποιούσε τις απαιτήσεις των προμηθευτών
λογισμικού. Επί του παρόντος το καλύτερο μοντέλο είναι το μοντέλο risk
based ή σπιράλ του Boehm (Σχήμα 3).

Το κύριο χαρακτηριστικό του μοντέλου είναι η αποτίμηση κάποιων

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

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

Κάθε κύκλος του σπιράλ αρχίζει με την επεξεργασία στόχων όπως η

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

12
Αποφάσισε στόχους, Αποτίμησε τα εναλλακτικά σενάρια ,
εναλλακτικά σενάρια, προσδιόρισε και αντιμετώπισε τους
περιορισμούς κινδύνους

Ανάλυση κινδύνων
(ΑΚ)

ΑΚ Λειτουργικό
πρωτότυπο

ΑΚ
Πρωτότυπο
Πρωτότυπο 3
ΑΚ
Πρωτ. 2
Αναθεώρηση 1
Σχέδιο Απαιτήσεων Προσομοιώσεις, Μοντέλα, Benchmarks
Σχέδιο κύκλου Θεώρηση της
ζωής λειτουργίας Απαιτήσεις
λογισμικού
Σχέδιο Σχεδιασμός Λεπτομερής
Επαλήθευση προιόντος Σχεδιασμός
Ανάπτυξης
απαιτήσεων
Σχέδιο Κώδικας
Ολοκλήρωσης και
Σχεδιασμός Έλεγχος
Ελέγχου
Ε&Ε Ενοτήτων
Έλεγχος
Ολοκλήρωσης
Έλεγχος
Αποδοχής
Σχεδίασε την επόμενη φάση
Υπηρεσία
Ανάπτυξε και επικύρωσε το
προιόν του επόμενου
επιπέδου

Σχήμα 3 : Το μοντέλο σπιράλ του BOEHM

Το επόμενο βήμα είναι η αποτίμηση των ρίσκων με περισσότερη

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

Δεν είναι απαραίτητο να χρησιμοποιηθεί ένα μόνο μοντέλο για όλους

τους κύκλους του σπιράλ. Μπορούμε σε κάθε κύκλο να αλλάζουμε το
μοντέλο. Π.χ το μοντέλο πρωτοτυποποίησης (prototyping) μπορεί να
χρησιμοποιηθεί σε ένα κύκλο σπιράλ για να ξεκαθαριστούν τα ρίσκα
που αφορούν τις απαιτήσεις του συστήματος και στη συνέχεια να
χρησιμοποιηθεί ένα συμβατικό μοντέλο καταρράκτη για τη κατασκευή
του συστήματος. Επίσης για κομμάτια που αφορούν συστήματα με
απαιτήσεις για υψηλή ασφάλεια χρησιμοποιείται το μοντέλο τυπικού
μετασχηματισμού (formal transformation), ενώ για το σχεδιασμό του
user interface μπορεί να χρησιμοποιηθεί το μοντέλο που αφορά
επαναχρησιμοποιήσιμα κομμάτια.
Για την καλύτερη χρήση του μοντέλου σπιράλ προτείνεται η
συμπλήρωση μιας πρότυπης φόρμας για κάθε κύκλο του σπιράλ. Π.χ αν

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

Στόχοι Ανάπτυξη καταλόγου με

επαναχρησιμοποιήσιμα συστατικά
λογισμικού

Περιορισμοί Μέσα σε ένα χρόνο

Υποστήριξη υπαρχόντων τύπων συστατικών
Συνολικό κόστος λιγότερο από $100000

Εναλλακτικές λύσεις Ανάπτυξη καταλόγου ειδικού σκοπού

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

Ρίσκα Πιθανότητα αποτυχίας εξαιτίας των

περιορισμών
Η λειτουργία του καταλόγου μπορεί να μην
είναι η κατάλληλη

Ανάλυση ρίσκων Ανάπτυξη πρωτότυπου καταλόγου για τη

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

Αποτελέσματα Τα συστήματα ανάκτησης πληροφοριών δεν

είναι ευέλικτα
Οι απαιτήσεις δεν ικανοποιούνται
(*)
Το πρωτότυπο που αναπτύχθηκε σε ΣΔΒΔ
μπορεί να επεκταθεί σε ένα πλήρες σύστημα
Κατάλογοι ειδικού σκοπού μπορεί να μην είναι
οικονομικά συμφέροντες

Πλάνα Ανάπτυξη καταλόγου χρησιμοποιώντας ΣΔΒΔ

με περαιτέρω επέκταση του πρωτότυπου και
user interface

Δέσμευση Χρηματοδότηση για ακόμη 12 μήνες ανάπτυξη

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

(*)
: ΣΔΒΔ = Σύστημα Διαχείρησης Βάσης Δεδομένων

15
Κεφάλαιο 2: Τεκμηρίωση

Στόχοι του κεφαλαίου

Το κεφάλαιο ασχολείται με τα έγγραφα/τεκμήρια τα οποία θα πρέπει να

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

Τα έγγραφα που σχετίζονται με ένα σύστημα λογισμικού θα πρέπει να

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

ΠΕΡΙΕΧΟΜΕΝΑ
2.1 ΚΑΤΗΓΟΡΟΠΟΙΗΣΗ ΕΓΓΡΑΦΩΝ ........................................................................................ 17
2.1.1 ΤΕΚΜΗΡΙΩΣΗ ΔΙΑΔΙΚΑΣΙΑΣ .................................................................................. 17
2.1.2 ΤΕΚΜΗΡΙΩΣΗ ΠΡΟΙΟΝΤΟΣ..................................................................................... 18
Τ Ε Κ Μ Η Ρ Ι Ω Σ Η Χ Ρ Η Σ Τ Η ................................................................................................................... 18
2.2 ΠΟΙΟΤΗΤΑ ΤΕΚΜΗΡΙΩΝ ................................................................................................... 21
2.2.1 ΔΟΜΗ ΤΕΚΜΗΡΙΩΝ ............................................................................................... 22
2.2.2 ΠΡΟΤΥΠΑ (STANDARDS) ΤΕΚΜΗΡΙΩΝ ................................................................ 23
Π Ρ Ο Τ Υ Π Α Δ Ι Α Δ Ι Κ Α Σ Ι Α Σ ( P R O C E S S S T A N D A R D S ) .............................................................. 23
Π Ρ Ο Τ Υ Π Α Π Ρ Ο Ϊ Ο Ν Τ Ο Σ ( P R O D U C T S T A N D A R D S ) .............................................................. 23
Π Ρ Ο Τ Υ Π Α Α Ν Τ Α Λ Λ Α Γ Η Σ ( I N T E R C H A N G E S T A N D A R D S ) ................................................ 24
2.2.3 ΤΥΠΟΣ ΓΡΑΨΙΜΑΤΟΣ ........................................................................................... 25
2.3 ΠΡΟΕΤΟΙΜΑΣΙΑ ΚΕΙΜΕΝΟΥ .................................................................................... 25

16
2.1 ΚΑΤΗΓΟΡΟΠΟΙΗΣΗ ΕΓΓΡΑΦΩΝ

Τα έγγραφα που σχετίζονται με ένα σύστημα εμπίπτουν σε δύο κατηγορίες:

1. Τεκμηρίωση διαδικασίας (process documentation)

Αυτά τα έγγραφα καταγράφουν τη διαδικασία ανάπτυξης και συντήρησης του
λογισμικού. Χρησιμοποιούνται κατά τη διάρκεια δημιουργίας του
λογισμικού.
2. Τεκμηρίωση προϊόντος (product documentation).
Χωρίζονται σε τεκμηρίωση συστήματος (system documentation) και
τεκμηρίωση χρήστη (user documentation). Η πρώτη κατηγορία αφορά
έγγραφα που περιγράφουν την εφαρμογή από τη οπτική γωνία των
κατασκευαστών και συντηρητών, ενώ η δεύτερη κατηγορία αφορά
έγγραφα που περιγράφουν την εφαρμογή από την άποψη του χρήστη.
Τα έγγραφα αυτά που έχουν τη μορφή εγχειριδίων, χρησιμοποιούνται
αφ’ότου κατασκευαστεί το λογισμικό.

2.1.1 ΤΕΚΜΗΡΙΩΣΗ ΔΙΑΔΙΚΑΣΙΑΣ

Η τεκμηρίωση αυτή παράγεται ώστε να πετυχαίνεται η διαχείριση της

ανάπτυξης του συστήματος. Οι κατηγορίες των τεκμηρίων αυτών είναι οι
ακόλουθες:

 Πλάνα (plans), προβλέψεις (estimations) και προγράμματα (schedules).

Παράγονται από τους διευθυντές της ανάπτυξης λογισμικού, και
χρησιμοποιούνται για να προβλέπουν και να ελέγχουν τη διαδικασία
κατασκευής λογισμικού.
 Αναφορές. Αναφέρουν τον τρόπο με τον οποίο οι υπάρχουσες πηγές
χρησιμοποιήθηκαν κατά τη διαδικασία παραγωγής του λογισμικού.
 Πρότυπα (standards). Aναφέρουν πώς θα υλοποιηθεί η διαδικασία
παραγωγής λογισμικού. Αυτά μπορούν να αναπτυχθούν με τη χρήση
εθνικών και διεθνών προτύπων, ή προτύπων του οργανισμού και να
περιγράφονται λεπτομερώς.
 Φύλλα εργασίας (working papers). Σ’αυτά συνήθως καταγράφονται ιδέες
και σκέψεις των μηχανικών που κατασκευάζουν το σύστημα, σχετικές με
πιθανές στρατηγικές υλοποίησης και προβλήματα που έχουν εντοπιστεί.
Θεωρούνται το σημαντικότερο είδος τεχνικών εγγράφων που αφορά
επικοινωνία μεταξύ των μηχανικών. Εδώ , μπορεί ακόμη να σκιαγράφεται
και η λογική για αποφάσεις σχεδιασμού.

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

Το χαρακτηριστικό των παραπάνω εγγράφων είναι ότι οι πληροφορίες που

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

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

2.1.2 ΤΕΚΜΗΡΙΩΣΗ ΠΡΟΙΟΝΤΟΣ

Αυτή η κατηγορία τεκμηρίων ασχολείται με την περιγραφή του λογισμικού

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

ΤΕΚΜΗΡΙΩΣΗ ΧΡΗΣΤΗ

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

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

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

18
2. Οι διαχειριστές του συστήματος χειρίζονται το σύστημα λειτουργώντας είτε
ως χειριστές (operators), αν το σύστημα αποτελεί ένα mainframe system,
είτε ως διαχειριστές δικτύου, όταν το σύστημα περιλαμβάνει ένα δίκτυο από
σταθμούς εργασίας, είτε ως εξειδικευμένοι μηχανικοί λογισμικού που
διορθώνουν τα προβλήματα που παρουσιάζονται στους χρήστες.

Για να εξυπηρετηθούν όλες οι κατηγορίες τελικών χρηστών, θα πρέπει να

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

1. Λειτουργική περιγραφή του συστήματος. Αναφέρει τις απαιτήσεις του

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

2. Εισαγωγικό εγχειρίδιο. Εδώ περιγράφεται πώς ξεκινά κανείς με το

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

3. Εγχειρίδιο αναφοράς του συστήματος. Περιγράφει τις υπηρεσίες του

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

4. Εγχειρίδιο εγκατάστασης του συστήματος . Προορίζεται για τους

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

5. Εγχειρίδιο του διαχειριστή του συστήματος . Περιγράφει τα μηνύματα που

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

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

Kατασκευαστές Διαχειριστές Νέοι χρήστες Έμπειροι Διαχειριστές

του συστήματος συστήματος χρήστες συστήματος

Λειτουργική Εγχειρίδιο Εισαγωγικό Εγχειρίδιο Εγχειρίδιο

περιγραφή εγκατάστασης εγχειρίδιο αναφοράς διαχειριστή

Περιγραφή των Πώς θα Εκκίνηση Λεπτομέρειες Πώς θα λει-

Παρεχόμενων εγκατασταθεί του όλων των τουργήσει και
υπηρεσιών το σύστημα συστήματος λειτουργιών θα συντηρηθεί
του συστ. το σύστημα

Σχήμα 2.1 : Τεκμηρίωση χρήστη

ΤΕΚΜΗΡΙΩΣΗ ΣΥΣΤΗΜΑΤΟΣ

Η τεκμηρίωση συστήματος περιλαμβάνει όλα τα έγγραφα που περιγράφουν

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

 To τεκμήριο των απαιτήσεων του συστήματος όπως επίσης και την

αντίστοιχη δικαιολόγηση.
 Τεκμήριο που περιγράφει την αρχιτεκτονική του συστήματος.

20
 Για κάθε πρόγραμμα του συστήματος, περιγραφή της αντίστοιχης
αρχιτεκτονικής του.
 Για κάθε συστατικό, μια προδιαγραφή και μια περιγραφή του σχεδιασμού.
 Λίστες με τον κώδικα των προγραμμάτων. Θα πρέπει να υπάρχουν τα
απαραίτητα σχόλια σε δυσκολονόητα σημεία, όπως επίσης και
δικαιολόγηση της μεθόδου που χρησιμοποιείται .
 Έγγραφα επικύρωσης (validation documents), που περιγράφουν τον τρόπο
που κάθε πρόγραμμα επικυρώνεται και τον τρόπο που η επικύρωση
συνδέεται με τις απαιτήσεις.
 Ενας οδηγός συντήρησης του συστήματος (system maintenance guide) ,
που περιγράφει γνωστά προβλήματα σχετικά με το σύστημα, περιγράφει
ποια τμήματα του συστήματος είναι εξαρτώμενα απο το λογισμικό, ποια
από το υλικό, και πώς η απαίτηση για εξέλιξη του συστήματος έχει ληφθεί
υπόψη στον σχεδιασμό του.

Πολλές φορές τα τεκμήρια που παράγονται δεν ακολουθούν πλήρως τις

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

2.2 ΠΟΙΟΤΗΤΑ ΤΕΚΜΗΡΙΩΝ

Συνήθως τα τεκμήρια που ακολουθούν την παραγωγή ενός λογισμικού είναι

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

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

21
2.2.1 ΔΟΜΗ ΤΕΚΜΗΡΙΩΝ

Η δομή ενός εγγράφου εξαρτάται προφανώς από το περιεχόμενό του. Εδώ θα

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

1. Κάθε έγγραφο, ανεξαρτήτως μεγέθους, θα πρέπει να έχει ένα εξώφυλλο, το

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

Collaborative Support for Systems Design

ACTIVE DISPLAYS

Title: Active Displays

Project: MRC 842317
Document Identifier: CSSD/CS/WD/17
Document type: Technical working paper
Version :1.2 Date : 20th December 1990
Author :Ian Sommerville
Inspected: N/A. Approved: N/A
Submitted to CM: CM identifier

Distribution: Project list

Confidentiality: Commercial
Keywords: User interface,display update, agents

 Lancaster University 1990

Σχήμα 2.2: Από το βιβλίο του I. Sommerville : S/W Engineering

2. Έγγραφα των οποίων το μέγεθος είναι αρκετά μεγάλο, θα πρέπει να

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

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

3. Η χρήση ενός ευρετηρίου (index) στο έγγραφο διευκολύνει πολύ την

αναζητηση πληροφορίας.

4. Ενα γλωσσάρι (glossary) κρίνεται επίσης χρήσιμο όταν εμπλέκονται πολλοί

τεχνικοί όροι, ιδιαίτερα αν το έγγραφο απευθύνεται σε ένα ευρύ κοινό .

2.2.2 ΠΡΟΤΥΠΑ (STANDARDS) ΤΕΚΜΗΡΙΩΝ

Τα πρότυπα τεκμηρίων χρησιμοποιούνται για να εξασφαλιστεί η ποιότητα

τους. Αυτά τα πρότυπα κατηγοροποιούνται ως εξής:

1. Πρότυπα διαδικασίας. Ορίζουν τη διαδικασία που θα πρέπει να

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

ΠΡΟΤΥΠΑ ΔΙΑΔΙΚΑΣΙΑΣ (PROCESS STANDARDS)

Καθορίζουν τη διαδικασία που θα ακολουθηθεί για παραγωγή εγγράφων.

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

Η αναμενόμενη ποιότητα του εγγράφου είναι πάντα σε εξάρτηση με το τύπο

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

ΠΡΟΤΥΠΑ ΠΡΟΪΟΝΤΟΣ (PRODUCT STANDARDS)

Tα διάφορα τεκμήρια που παράγονται κατά τη διάρκεια ανάπτυξης λογισμικού

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

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

 Πρότυπα Αναγνώρισης Εγγράφων (document identification standards).

Λόγω των πλείστων εγγράφων που παράγονται, χρειάζεται ένας τρόπος να
αναγνωρίζονται με μοναδικό τρόπο. Για επίσημα έγγραφα, τον τρόπο
αναγνώρισης διαλέγει ο configuration manager. Για ανεπίσημα έγγραφα
τον τρόπο αναγνώρισης τον ορίζει ο διευθυντής του έργου (project
manager).
 Πρότυπα Δομής Εγγράφων (document structure standards). Καθορίζουν τη
δομή που πρέπει να έχει κάθε έγγραφο. Επίσης καθορίζουν τις συμβάσεις
σχετικά με την αρίθμηση των σελίδων, τα σημειώματα στην αρχή και το
τέλος (header και footer) κάθε σελίδας, καθώς και την αρίθμηση των
τομέων και υποκεφαλαίων των εγγράφων.
 Πρότυπα Παρουσίασης Εγγράφων (document presentation standards).
Αυτά καθορίζουν ένα συγκεκριμένο τρόπο παρουσίασης των εγγράφων,
που είναι συνήθως χαρακτηριστικός του συγκεκριμένου οργανισμού.
Συμβάλλουν σημαντικά στην εξασφάλιση της ποιότητας των εγγράφων.
Καθορίζουν, μεταξύ άλλων, τη γραμματοσειρά που θα χρησιμοποιηθεί, τον
τρόπο που θα τονιστεί με χρώμα κάποιο κομμάτι του έγγραφου, κ.α.
 Πρότυπα Ενημέρωσης Εγγράφων (document update standards).
Καθορίζουν τον τρόπο με τον οποίο θα ξεχωρίζουν οι διάφορες αλλαγές
που υφίσταται το έγγραφο. Π.χ., η χρήση ενός διαφορετικού χρώματος θα
υποδεικνύει μια νέα έκδοση του εγγράφου, και κάποιο ειδικό σύμβολο θα
σημειώνεται για τις σβησμένες ή αλλαγμένες παραγράφους.

ΠΡΟΤΥΠΑ ΑΝΤΑΛΛΑΓΗΣ (INTERCHANGE STANDARDS)

Η σημασία αυτών των προτύπων είναι συνεχώς αυξανόμενη αφού συχνά

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

Στα πρότυπα ανταλλαγής ορίζονται όλοι οι περιορισμοί και τα πρότυπα που

θα πρέπει να υιοθετούνται κατά τη συγγραφή του αυθεντικού εγγράφου. Π.χ.,
κάποιο σύνολο μακρο-εντολών σε περίπτωση που χρησιμοποιείται ένας
μορφοποιητής κειμένου (text formatting system) ή κάποιος συγκεκριμένος
τύπος σελίδας (style sheet) σε περίπτωση που χρησιμοποιείται επεξεργαστής
κειμένου για τη δημιουργία του εγγράφου. Αυτά πρέπει να εφαρμόζονται στο
εργαλείο συγγραφής (επεξεργαστής κειμένου, μορφοποιητής κειμένου, κλπ),
ώστε να γίνει σωστά η ανάκτηση του κειμένου.

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

2.2.3 ΤΥΠΟΣ ΓΡΑΨΙΜΑΤΟΣ

H καλή τεκμηρίωση απαιτεί καλό γράψιμο. Μερικές γενικές κατευθύνσεις είναι

οι ακόλουθες :

 Η χρήση ενεργητικής αντι παθητικής φωνής.

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

Ένα έγγραφο κατά τη διάρκεια γραφής του υπόκειται σε συνεχείς αλλαγές,

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

2.3 ΠΡΟΕΤΟΙΜΑΣΙΑ ΚΕΙΜΕΝΟΥ

Η προετοιμασία των κειμένων αυτοματοποιείται με διάφορα εργαλεία

λογισμικού. Η διαδικασία κατηγοροποιείται ως εξής:

1. Κατασκευή εγγράφων. Επεξεργαστές εγγράφων, πακέτα σχεδιασμού κ.α

2. Εξευγενιστές (polishing) εγγράφων. Ελεγχος σωστού συλλαβισμού και

στυλ εγγράφου.

3. Παραγωγή εγγράφων. Πακέτα Desktop publishing κ.α

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

25
Το εργαλείο που χρησιμοποιείται περισσότερο για παραγωγή κειμένου είναι
ένα σύστημα γραψίματος που μπορεί να είναι επεξεργαστής κειμένου (word
processor) ή μορφοποιητής κειμένου (text formatter). Συνήθως ένα τέτοιο
εργαλείο δίνει τη δυνατότητα στο χρήστη να δει στην οθόνη του τερματικού
του το έγγραφο όπως θα το έβλεπε εκτυπωμένο. Παρέχονται ασφαλώς
δυνατότητες μορφοποίησης του εγγράφου.

Οι μορφοποιητές εγγράφων όπως οι TROFF, Latex μεταφράζουν ένα

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

Συχνά στα έγγραφα περιλαμβάνονται και διαγράμματα. Αυτά μπορούν να

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

Το στάδιο εξευγενισμού (polishing) του εγγράφου περιλαμβάνει τον έλεγχο

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

Με τη χρήση των Desktop publishers το τελευταίο αυτό στάδιο επεξεργασίας

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

Όπως συμπεραίνει κανείς εύκολα, σε όλη τη πορεία κατασκευής λογισμικού

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

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

Η διαχείριση των εγγράφων επιτυγχάνεται με κάποια βάση δεδομένων,

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

27
Κεφάλαιο 3 : Προδιαγνωστική Μελέτη και Μελέτη
Σκοπιμότητας

Σκοπός του κεφαλαίου

Η μεθοδολογία κατάρτισης και το ακριβές περιεχόμενο μιάς μελέτης σκοπιμότητας

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

ΠΕΡΙΕΧΟΜΕΝΑ

3.1. Διαπίστωση προβλήματος

Κ.1.1. Ενδείξεις για περαιτέρω διερεύνηση του προβλήματος
Κ.1.2. Αντιμετώπιση του προβλήματος
3.2. Κατάρτιση Προδιαγνωστικής Μελέτης
Κ.2.1. Αντικείμενο
Κ.2.2. Ανάθεση Έργου Προδιαγνωσικής Μελέτης
Κ.2.3. Προϊόν Προδιαγνωστικής Μελέτης
3.3. Κατάρτιση Μελέτης Σκοπιμότητας
Κ.3.1. Γενικά
Κ.3.2. Στόχος της Μελέτης Σκοπιμότητας
Κ.3.3. Περιεχόμενα της Μελέτης Σκοπιμότητας
3.4. Κύρια Σημεία

35
3.1 Διαπίστωση Προβλήματος

Ο βαθμός αρτιότητας λειτουργίας ενός οργανισμού προσδιορίζεται από τιμές που

παίρνουν ορισμένα βασικά χαρακτηριστικά, τα κυριότερα από τα οποία είναι:

α. Αποτελεσματικότητα (Effectiveness)

Εκφράζει το μέτρο κατά το οποίο ο οργανισμός αναποκρίνεται στην

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

β. Αποδοτικότητα (Efficiency)

Εκφράζει το μέτρο επιτυχίας του συνδυασμού των πόρων (ανθρώπων,

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

γ. Αξιοπιστία (Reliability)

Εκφράζει το μέτρο κατά το οποίο ο Οργανισμός πετυχαίνει τους στόχους

του με συνέπεια.

δ. Ευελιξία (Flexibility) - Ικανότητα Προσαρμογής (Adaptability)

Εκφράζει την ικανότητα του Οργανισμού να ανταποκρίνεται και να

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

Ένας Οργανισμός έχει πληροφοριακό πρόβλημα, όταν ο μετασχηματισμός

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

α. Τη διατάραξη της εύρυθμης λειτουργίας του Οργανισμού

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

36
 1. ΔΙΑΠΙΣΤΩΣΗ
ΠΡΟΒΛΗΜΑΤΩΝ

2. ΠΡΟΔΙΑΓΝΩΣΤΙΚΗ
ΜΕΛΕΤΗ

ΤΕΡΜΑΤΙΣΜΟΣ
ΧΡΕΙΑΖΕΤΑΙ OXI
ΕΡΓΟΥ
ΜΗΧΑΝΟΓΡΑΦΗΣΗ
;

ΝΑΙ

3. ΜΕΛΕΤΗ
ΣΚΟΠΙΜΟΤΗΤΑΣ

4. ΕΚΤΕΛΕΣΗ ΕΡΓΟΥ ΜΕΧΡΙ

ΚΑΙ ΤΟ ΓΕΝΙΚΟ 8. ΕΚΠΑΙΔΕΥΣΗ
ΣΧΕΔΙΑΣΜΟ

6. ΕΝΕΡΓΕΙΕΣ ΓΙΑ ΤΗΝ

7. ΠΡΟΕΤΟΙΜΑΣΙΑ ΓΙΑ ΤΗΝ
ΠΡΟΜΗΘΕΙΑ ΤΟΥ 5. ΛΕΠΤΟΜΕΡΗΣ ΑΝΑΛΥΣΗ
ΕΓΚΑΤΑΣΤΑΣΗ ΚΑΙ ΛΕΙΤΟΥΓΊΑ
ΕΞΟΠΛΙΣΜΟΥ ΚΑΙ ΠΡΟΓΡΑΜΜΑΤΙΣΜΟΣ
ΤΟΥ ΣΥΣΤΉΜΑΤΟΣ

9. ΛΕΙΤΟΥΡΓΙΑ

10. ΑΞΙΟΛΟΓΗΣΗ

Σχήμα Κ.1 Διαδικασία Προσδιορισμού Προβλήματος και Ανάλυσης Έργου

Σχεδιασμού και Ανάπτυξης Πληροφοριακού Συστήματος

3.1.1. Ενδείξεις για περαιτέρω διερεύνηση του προβλήματος

Μία από τις συνηθισμένες αιτίες δημιουργίας πληροφοριακού προβλήματος

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

1. Η αύξηση του όγκου των πρωτογενών πληροφοριών που απαιτούν επεξεργασία

2. Η αλλαγή των απαιτήσεων σε πληροφορίες

3. Η απαίτηση για τη μείωση του χρόνου επεξεργασίας, που συνήθως εμφανίζεται σε

συνδυασμό με την απαίτηση για βελτίωση της ποιότητας των αποτελεσμάτων της
επεξεργασίας (μείωση λαθών).

4. Η προβληματική λειτουργία του συστήματος επικοινωνίας των εσωτερικών

λειτουργιών, τόσο μεταξύ τους όσο και με το περιβάλλον.

37
5. Το υψηλό υπαλληλικό κόστος, τα λάθη των επεξεργασιών και η εκτέλεση
περιττών επεξεργασιών.

6. Η μείωση της αποτελεσματικότητας (Effectiveness) του Οργανισμού.

7. Η αδυναμία εκτέλεσης εργασιών ή ολόκληρων λειτουργιών με τα συμβατικά

υπαλληλικά μέσα.

3.1.2. Αντιμετώπιση του προβλήματος

Γενικά, το πρόβλημα της επεξεργασίας των πληροφοριών μπορεί να λυθεί είτε με

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

1. Ο όγκος των πληροφοριών για επεξεργασία

2. Η πολυπλοκότητα της επεξεργασίας.
3. Η συχνότητα της επεξεργασίας.
4. Η αλγοριθμική επαναληπτική μορφή της επεξεργασίας.
5. Το κόστος επεξεργασίας και αποθήκευσης.
6. Οι απαιτήσεις σε χρόνο αντίδρασης.
7. Η σημαντικότητα και συχνότητα των λαθών.

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

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

3.2 Κατάρτιση Προδιαγνωστικής Μελέτης

Κ.2.1. Αντικείμενο

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

Στην πραγματικότητα, η μελέτη αυτή απαντάει στο ερώτημα: «Είναι σκόπιμη η

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

38
ένα έγγραφο, το οποίο πολλές φορές είτε δεν προσδιορίζει το πραγματικό πρόβλημα
είτε το προσδιορίζει ανεπαρκώς.

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

3.2.2. Ανάθεση Έργου Προδιαγνωστικής Μελέτης

Φορείς που μπορεί να αναλάβουν το έργο της προδιαγνωστικής μελέτης είναι:

Ι. Εξωτερικοί Σύμβουλοι και Ειδικοί

Οι εξωτερικοί σύμβουλοι παρουσιάζουν το βασικό πλεονέκτημα ότι

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

 Η εκτέλεση όλων των φάσεων ανάπτυξης του νέου συστήματος ή

 Η διεξαγωγή μόνο της προδιαγνωστικής μελέτης, οπότε οι επόμενες
φάσεις θα εκτελεστούν από:
α) Στελέχη του οργανισμού ή
β) Από άλλους εξωτερικούς συμβούλους ή
γ) Από μικτές ομάδες

ΙΙ. Στελέχη του Οργανισμού

Στην περίπτωση που ο οργανισμός διαθέτει στελέχη έμπειρα σε αντίστοιχα

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

ΙΙΙ. Μικτές Ομάδες

Οι μικτές ομάδες αποτελούνται από εξωτερικούς συμβούλους και από

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

39
3.2.3. Προϊόν Προδιαγνωστικής Μελέτης

Το αποτέλεσμα της προδιαγνωστικής μελέτης είναι η εισήγηση, με βάση τις

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

Στην περίπτωση που η προδιαγνωστική μελέτη εισηγείται την εκτέλεση επόμενων

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

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

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

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

1. Η επανάληψη ορισμένων εργασιών αυξάνει τις πιθανότητες σχεδιασμού ενός

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

3.3 Κατάρτιση Μελέτης Σκοπιμότητας

3.3.1. Γενικά

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

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

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

3.3.2. Στόχος της Μελέτης Σκοπιμότητας

Ο στόχος της μελέτης σκοπιμότητας είναι:

1. Να περιγράψει την υπάρχουσα κατάσταση και να εντοπίσει τα κύρια πρβλήματά

της
2. Να περιγράψει εναλλακτικές λύσεις (πληροφοριακά συστήματα) για τη στήριξη
των λειτουργιών του Οργανισμού.
3. Για κάθε εναλλακτική λύσει να εκτιμήσει:
 Τον προβλεπόμενο χρόνο και κόστος υλοποίησης.
 Τα απαιτούμενα μέσα και προσωπικό (συνολική εκτίμηση κόστους).
 Τα προσδοκώμενα οφέλη.
 Τους κρίσιμους παράγοντες επιτυχίας.
4. Να δώσει εκτίμηση των:
 Χρόνου για την υλοποίηση των προτεινόμενων λύσεων
 Κόστους των προτεινόμενων λύσεων.
 Διαδικασιών των κυρίων φάσεων και των προτεραιοτήτων για την υλοποίηση
των προτεινόμενων λύσεων.
 Μέσων για την υλοποίηση των προσπαθειών.
 Γενικής συμπεριφοράς της προτεινόμενης λύσης (χρόνοι απόκρισης,
ευκολοχρησία, απλοποίηση διαδικασιών).

3.3.3. Περιεχόμενα της Μελέτης Σκοπιμότητας

Η μελέτη σκοπιμότητας συντάσσεται ανάλογα με το μέγεθος του Πληροφοριακού

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

Έτσι τα περιεχόμενα της μελέτης σκοπιμότητας πρέπει, στο ελάχιστο, να

περιλαμβάνουν τα ακόλουθα:

1. Περιγραφή της Υπάρχουσας Κατάστασης. Κύρια προβλήματα.

2. Εναλλακτικές λύσεις. Προτεινόμενα Πληροφοριακά Συστήματα.
3. Διαδικασίες - Κύριες φάσεις - Προτεραιότητες Υλοποίησης.
4. Χρονοδιάγραμμα Υλοποίησης.
5. Απαιτούμενα Μέσα (Υλικό, Λογισμικό, Στελέχωση, Εγκαταστάσεις, Αναλώσιμα,
Εκπαίδευση).
6. Προϋπολογισμό Συνολικού Κόστους Μέσων και Οφέλη.
7. Κινδύνους για πιθανή αποτυχία του Πληροφοριακού Συστήματος
8. Δυνατότητες Επέκτασης
9. Συμβατότητα και Επικοινωνίες με Υπάρχοντα Συστήματα
10. Αναμενόμενη συμπεριφορά του νέου Συστήματος σύμφωνα με κάποιο φορτίο
(εκτιμήσεις)

Θα ήταν χρήσιμο όλα τα παραπάνω να εκφράζονται ποσοτικά.

41
Κύρια Σημεία

 Ενας Οργανισμός θεωρείται ότι αντιμετωπίζει πληροφοριακό πρόβλημα όταν

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

 Η ύπαρξη πληροφοριακού προβλήματος στον Οργανισμό οδηγεί στη σύνταξη

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

 Η προδιαγνωστική μελέτη καταρτίζεται από ομάδες που συνίστανται από

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

 Εάν το αποτέλεσμα της προδιαγνωστικής μελέτης είναι ότι είναι σκόπιμη η

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

 Για μικρού μεγέθους συστήματα, η προδιαγνωστική μελέτη και η μελέτη

σκοπιμότητας μπορεί να ταυτίζονται.

42
Κεφάλαιο 4: Οι Προδιαγραφές των Απαιτήσεων

4.1 Ο σκοπός των προδιαγραφών απαιτήσεων

Στα επόμενα θα εξετάσουμε το περιεχόμενο ενός παραδείγματος προδιαγραφής

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

 Σε κάποιο σημείο, οι απαιτήσεις πρέπει να προδιαγραφούν - Αν η

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

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

 Αν οι προδιαγραφές απαιτήσεων και η υλοποίηση του συστήματος δεν

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

 Όταν τελικά συμφωνηθούν μεταξύ προμηθευτή και πελάτη, οι

προδιαγραφές απαιτήσεων μπορούν να γίνουν το πρώτο συμφωνημένο
έγγραφο (σημείο αναφοράς) για το έργο.

Έχοντας αποδεχτεί την ελκυστικότητα της παραγωγής μιας

προδιαγραφής απαιτήσεων ως το πρώτο βήμα στο έργο, είναι αναγκαίο να

43
οριστούν τα όρια ενός τέτοιου εγγράφου. Η μέριμνα μας είναι να
προδιαγράψουμε τι απαιτείται γιά να πετύχει το προτεινόμενο σύστημα - σε
πολλές περιπτώσεις, αυτό είναι ουσιαστικά το ίδιο με το πώς το σύστημα θα
φανεί στον τελικό χρήστη. Η σημαντική λέξη είναι το ‘τι’.
Οι προδιαγραφές απαιτήσεων δεν είναι ένα έγγραφο σχεδιασμού του
συστήματος. Δεν ασχολείται με λεπτομέρειες της υλοποίησης (εκτός από το
σχετικά επιφανειακό επίπεδο της διαίρεσης εργασίας ανάμεσα σε υλικό,
λογισμικό και χειριστή) αλλά με το να δηλώσει καθαρά και επακριβώς τι
πρέπει να υλοποιηθεί. Είναι προδιαγραφές από τις οποίες προχωρά ο
σχεδιασμός του συστήματος.

4.2 Το περιεχόμενο των προδιαγραφών απαιτήσεων

Εντός των αναπόφευκτων περιορισμών που τίθενται λόγω του

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

ΕΝΑ ΣΥΣΤΗΜΑ ΠΟΥ ΘΑ ΕΠΙΤΡΕΠΕΙ ΤΗΝ ΑΠΟΘΗΚΕΥΣΗ ΚΑΙ

ΑΝΑΚΤΗΣΗ ΟΝΟΜΑΤΩΝ ΚΑΙ ΑΡΙΘΜΩΝ ΤΗΛΕΦΩΝΟΥ

Ο φοιτητής μπορεί να αναγνωρίσει στο παράδειγμα αυτό παρόμοιο

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

Λειτουργίες : Μια άποψη του συστήματος από το ‘μάτι του

χρήστη’, που αντιμετωπίζει όλες τις όψεις της
διεπαφής του χρήστη.

44
Κατανομή : Περιγραφή και κατανομή των ευθυνών, για κάθε
μια από τις λειτουργίες που έχουν οριστεί, σε
υλικό/λογισμικό/χειριστή.

Περιορισμοί: Οποιαδήποτε συγκεκριμένα όρια στον πως θα

λειτουργεί το σύστημα μαζί με το βαθμό
σπουδαιότητάς τους.

Πρότυπα : Ορισμός των υπαρχόντων - δηλαδή των γνωστών

και τεκμηριωμένων - τεχνικών που πρέπει να
εφαρμοστούν στην ανάπτυξη του συστήματος.

Ποιότητα : Λεπτομέρειες των διαδικασιών ελέγχου της

ποιότητας με τις οποίες θα παρακολουθείται και θα
ελέγχεται η πρόοδος και η ποιότητα του έργου.

Χρονοδιάγραμμα : Στόχοι ανάπτυξης - τι αναμένεται να είναι έτοιμο

πότε.

Τώρα εξετάζουμε κάθε ένα από αυτά τα τμήματα στη σειρά,

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

4.2.1 ΛΕΙΤΟΥΡΓΙΕΣ

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

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

(i) Ο τύπος της πληροφορίας που θα παρέχεται στο σύστημα, και το μέσο
εισόδου που θα χρησιμοποιηθεί (π.x. πληκτρολόγιο, έγγραφο, σήμα).

(ii) Η ενέργεια του συστήματος στις πληροφορίες που παρέλαβε, δηλαδή

λεπτομέρειες της ‘επεξεργασίας’ που θα γίνει. Όπου είναι
εφαρμόσιμο, πρέπει να περιλαμβάνονται πληροφορίες όπως ελάχιστα

45
 μήκη για αντικείμενα χαρακτήρων και βαθμός ακριβείας για
αριθμητικούς υπολογισμούς.

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

(iv) Τι πρέπει να αποτρέπει το σύστημα (π.x. αποδοχή άκυρων

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

(v) Ο φόρτος που πρέπει να διαχειρίζεται το σύστημα, συνήθως από την

άποψη μέσων και χείριστων περιπτώσεων (π.x. συχνότητες άφιξης
δεδομένων, όγκος δεδομένων που απαιτείται on-line).

(vi) Η ταχύτητα με την οποία απαιτείται το σύστημα να εκτελεί τις

αναφερόμενες λειτουργίες (π.x. χρόνος απόκρισης σε ένα τερματικό,
χρόνος εκτέλεσης για ένα πρόγραμμα)

(vii) Πιθανές απαιτήσεις για επαναδιαμόρφωση ή επεκτάσεις (π.x. αλλαγές

στις τοποθεσίες ή αριθμούς ή τερματικά).

(viii) Μια ένδειξη της απαιτούμενης διαθεσιμότητας του συστήματος (π.x.

συνεχώς διαθέσιμο, ποτέ τις Κυριακές), μαζί με τα όρια αξιοπιστίας
που απαιτείται (π.x. βαθμός υποβάθμισης ή απώλειας της υπηρεσίας,
αποδεκτή συχνότητα και διάρκεια βλαβών).

(ix) Απαιτήσεις για αποδοχή του ολοκληρωμένου συστήματος (να

δηλώνονται ρητά, αν και μπορεί να υπονοούνται από τα παραπάνω).

Ας σκιαγραφήσουμε αυτήν την λίστα περιεχομένων για τις

λειτουργικές προδιαγραφές επιστρέφοντας στην αρχική μας απαίτηση:

ΕΝΑ ΣΥΣΤΗΜΑ ΠΟΥ ΘΑ ΕΠΙΤΡΕΠΕΙ ΤΗΝ ΑΠΟΘΗΚΕΥΣΗ ΚΑΙ

ΑΝΑΚΤΗΣΗ ΟΝΟΜΑΤΩΝ ΚΑΙ ΑΡΙΘΜΩΝ ΤΗΛΕΦΩΝΟΥ

Μια εισαγωγική παράγραφος στο τμήμα των λειτουργιών είναι

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

ΕΝΑ ΣΥΣΤΗΜΑ ΕΥΡΕΤΗΡΙΟΥ ΤΗΛΕΦΩΝΩΝ ΕΝΟΣ ΧΡΗΣΤΗ,

ΒΑΣΙΣΜΕΝΟ ΣΕ ΔΙΣΚΟ ΠΟΥ ΘΑ ΥΠΟΣΤΗΡΙΖΕΙ ΤΗΝ ΑΠΟΘΗΚΕΥΣΗ
ΚΑΙ ΑΝΑΚΤΗΣΗ ΟΝΟΜΑΤΩΝ ΚΑΙ ΑΡΙΘΜΩΝ ΤΗΛΕΦΩΝΟΥ. ΤΡΕΙΣ

46
ΜΕΓΑΛΕΣ ΛΕΙΤΟΥΡΓΙΕΣ ΠΡΕΠΕΙ ΝΑ ΠΡΟΣΦΕΡΟΝΤΑΙ: ΠΡΟΣΘΗΚΗ
ΝΕΩΝ ΑΝΤΙΚΕΙΜΕΝΩΝ ΣΤΟ ΕΥΡΕΤΗΡΙΟ, ΤΡΟΠΟΠΟΙΗΣΗ
ΥΠΑΡΧΟΝΤΩΝ ΑΝΤΙΚΕΙΜΕΝΩΝ, ΚΑΙ ΑΝΑΖΗΤΗΣΗ ΣΤΟ
ΕΥΡΕΤΗΡΙΟ ΕΝΟΣ ΑΝΤΙΚΕΙΜΕΝΟΥ ΠΟΥ ΔΙΝΕΤΑΙ. ΠΡΕΠΕΙ ΝΑ
ΕΝΣΩΜΑΤΩΘΟΥΝ ΜΗΧΑΝΙΣΜΟΙ ΠΛΗΡΟΥΣ ΕΠΙΚΥΡΩΣΗΣ ΤΩΝ
ΔΕΔΟΜΕΝΩΝ ΚΑΙ ΧΕΙΡΙΣΜΟΥ ΛΑΘΩΝ.
Εδώ εξετάζουμε το περιεχόμενο, ομαδοποιημένο όπως παραπάνω στα
(i) έως (ix) :

(i) Μέσα Εισόδου

 Το μέσο εισόδου που θα χρησιμοποιηθεί για όλες τις λειτουργίες είναι

το πληκτρολόγιο.

Πληροφορίες που θα εισάγονται

 Οι πληροφορίες θα πρέπει να δίνονται στο σύστημα από τον χρήστη ως

ακολούθως:

ΠΡΟΣΘΗΚΗ : όνομα και αριθμός τηλεφώνου.

ΤΡΟΠΟΠΟΙΗΣΗ : όνομα ή αριθμός τηλεφώνου της εγγραφής που
θα τροποποιηθεί, ακολουθούμενα από τις
λεπτομέρειες των αλλαγών που θα γίνουν
ΑΝΑΖΗΤΗΣΗ : όνομα ή αριθμός τηλεφώνου για το οποίο θα
γίνει η αναζήτηση.

(ii) Επεξεργασία

 Η εισαγωγή των δεδομένων πρέπει να επικυρώνεται πριν γίνουν

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

ΠΡΟΣΘΗΚΗ :
μια συνδυασμένη εγγραφή με όνομα/αριθμό
τηλεφώνου θα προστίθεται στην βάση
δεδομένων.
ΤΡΟΠΟΠΟΙΗΣΗ : ακολουθώντας την είσοδο του αναθεωρημένου
αντικειμένου δεδομένων, η τροποποιημένη
εγγραφή με όνομα/αριθμό τηλεφώνου θα
προστίθεται στην βάση με την αρχική εγγραφή
να σβήνεται.
ΑΝΑΖΗΤΗΣΗ : η βάση ψάχνεται για το ζητούμενο αντικείμενο,
και ανακτάται ολόκληρη η εγγραφή με
όνομα/αριθμό τηλεφώνου.

47
 Ακρίβεια

 Όλες οι συγκρίσεις συμβολοσειρών πρέπει να γίνονται

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

(iii) Μέσα εξόδου

 Το μέσο εξόδου που θα χρησιμοποιηθεί για όλες τις λειτουργίες πρέπει να

είναι είτε η οθόνη είτε ο εκτυπωτής.

Πληροφορίες που θα είναι έξοδος

 Οι πληροφορίες χρειάζεται να είναι έξοδος από το σύστημα στον χρήστη

ως ακολούθως:

ΠΡΟΣΘΗΚΗ : Μια ένδειξη ότι η λειτουργία διεξήχθη επιτυχώς.

ΤΡΟΠΟΠΟΙΗΣΗ : Μια ένδειξη ότι η αρχική εγγραφή έχει
τροποποιηθεί επιτυχώς, μαζί με επιβεβαίωση του
περιεχομένου της τροποποιημένης εγγραφής.
ΑΝΑΖΗΤΗΣΗ : Όνομα και αριθμός τηλεφώνου από κάθε εγγραφή
που ταιριάζει με τη συμβολοσειρά αναζήτησης
που δόθηκε. Αν το μέσο εξόδου είναι η οθόνη,
τότε πρέπει να δοθεί έλεγχος στον χρήστη για να
επιτραπεί έξοδος ενός βήματος.

(iv) Αναγνώριση λαθών του συστήματος

 Όλα τα λάθη που προκαλούνται από κακή λειτουργία είτε του υλικού
είτε του μόνιμου λογισμικού υποστήριξης (π.x. λειτουργικά
συστήματα) θα ανιχνεύονται, και θα αναφέρονται στον χρήστη.

 Βλάβες κατά τη διάρκεια μεταφοράς δεδομένων από/προς τον δίσκο

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

Αναγνώριση των λαθών του χρήστη

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

ΠΡΟΣΘΗΚΗ : Προσπάθεια παράλειψης είτε ονόματος ή

αριθμού τηλεφώνου.
Αποτυχία στην προσθήκη νέου αντικειμένου
επειδή η βάση είναι γεμάτη.
ΤΡΟΠΟΠΟΙΗΣΗ: Προσπάθεια παράλειψης αντικειμένου για
αναζήτηση.
Αποτυχία στην εύρεση υποψήφιου αντικειμένου
δεδομένων στην βάση.
Προσπάθεια παράλειψης είτε ονόματος ή
αριθμού τηλεφώνου στην εισαγωγή της
απαιτούμενης τροποποίησης.
ΑΝΑΖΗΤΗΣΗ : Προσπάθεια παράλειψης του αντικειμένου
δεδομένων για αναζήτηση.
Αποτυχία στην εύρεση υποψήφιου αντικειμένου
δεδομένων στην βάση.

 Θα πρέπει να είναι δυνατό για τον χρήστη να εγκαταλείψει κάθε

λειτουργία καθώς αυτή εκτελείται, με την ακεραιότητα της βάσης να
διατηρείται.

Ως εδώ καλά. Πριν συνεχίσουμε όμως, ας πάμε πίσω στον

αναθεωρημένο πρόλογο που προτείναμε σαν εισαγωγή για το τμήμα των
λειτουργιών αυτών των προδιαγραφών απαιτήσεων. Αυτό ανέφερε
εσκεμμένα :

ΕΝΑ ΣΥΣΤΗΜΑ ΕΥΡΕΤΗΡΙΟΥ ΤΗΛΕΦΩΝΩΝ ΕΝΟΣ ΧΡΗΣΤΗ,…

Πώς θα ήταν αναγκαίο να αλλάξουν τα πράγματα αν η προδιαγραφή

ήταν για ένα σύστημα ΠΟΛΛΩΝ ΧΡΗΣΤΩΝ ; Αν, για παράδειγμα, θέλαμε
ένα σύστημα που θα χρησιμοποιηθεί από το τμήμα ΄Αναζητήσεις
Ευρετηρίου΄ μιας εθνικής υπηρεσίας τηλεφώνων;

Λοιπόν, για ένα σύστημα πολύ περιορισμένης λειτουργικότητας, τα

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

49
λαμβάνεται από κάθε χρήστη, και το γεγονός ότι μπορεί να υπάρχουν πολλοί
τέτοιοι χρήστες που λαμβάνουν την ίδια εικόνα είναι μικρής σημασίας.
Όμως, αυτό δεν μπορούμε να το πούμε καθώς εξετάζουμε και τα
υπόλοιπα τμήματα (v) έως (ix). Το περιεχόμενο εδώ θα εξαρτάται πολύ από
το αναμενόμενα επίπεδα της ταυτόχρονης χρήσης στην οποία θα υποβληθεί
το σύστημα. Για αυτό το λόγο, τα παραδείγματα δεν θα αντιμετωπίσουν
μόνο την απλή απαίτηση που χρησιμοποιήσαμε έως τώρα, αλλά θα
προσπαθήσουμε επίσης να δείξουμε πως χρειάζεται να επεκτείνουμε την
προδιαγραφή απαιτήσεων για να αντιμετωπίσουμε κάτι πιο πολύπλοκο.
Όπου είναι απαραίτητο περιλαμβάνονται σχόλια σε αγκύλες [] για
επιπρόσθετες εξηγήσεις.
Προσέξτε επίσης ότι όπου θα εμφανιζόταν μια αριθμητική τιμή στις
προδιαγραφές απαιτήσεων θα χρησιμοποιούμε την ένδειξη . . x. . , αφού
ακόμα και σε αυτό το απλό παράδειγμα οι πιθανότητες είναι πολλές. (Ένας
χρήστης στο σπίτι, ας πούμε , περιμένουμε να προσδιορίσει την ανάγκη να
κρατήσει ένα σχετικά μικρό ποσό δεδομένων - αλλά ένας ιδιόμορφος
χρήστης μπορεί να θέλει να αυτοματοποιήσει το ψάξιμο με το χέρι στις
σελίδες ενός ολόκληρου Χρυσού Οδηγού). Ας αρκεστούμε να πούμε ότι θα
πρέπει να καθοριστεί μια τιμή ανάλογου μεγέθους για τους σκοπούς της
προδιαγραφής.

(v) Φόρτος Συστήματος

 Το σύστημα θα πρέπει να μπορεί να υποστηρίξει έως . .x. . τερματικά.

[σύστημα πολλών χρηστών (multi user)]

 Το σύστημα πρέπει να μπορεί να κρατήσει on-line . .x. . εγγραφές με

όνομα/αριθμό τηλεφώνου.

 Κατά τη διάρκεια μιας ώρας λειτουργίας θα χρειαστεί να

διεκπεραιωθεί ένα σύνολο από :
. .xx. .(μέσος όρος), . .x. . (ανώτατο όριο) λειτουργίες ΠΡΟΣΘΗΚΗ
. .xx. .(μέσος όρος), . .x. . (ανώτατο όριο) λειτουργίες
ΤΡΟΠΟΠΟΙΗΣΗ
. .xx. .(μέσος όρος), . .x. . (ανώτατο όριο) λειτουργίες ΑΝΑΖΗΤΗΣΗ

[για ένα σύστημα πολλών χρηστών, θα είναι αναγκαίο να ορίσουμε την

κατανομή των μέσων και ανώτατων παραπάνω τιμών κατά μήκος του
αριθμού των τερματικών]

(vi) Απόδοση

 Οι απαιτήσεις απόδοσης όσον αφορά τους χρόνους απόκρισης για

διάφορες λειτουργίες έχουν ως ακολούθως :

50
 λειτουργία ΠΡΟΣΘΗΚΗ: μέσος όρος. .x. . δευτερόλεπτα,
μέγιστο . .x. . δευτερόλεπτα
λειτουργία ΤΡΟΠΟΠΟΙΗΣΗ: μέσος όρος. .x. . δευτερόλεπτα,
μέγιστο . .x. . δευτερόλεπτα
λειτουργία ΑΝΑΖΗΤΗΣΗ: μέσος όρος. .x. . δευτερόλεπτα,
μέγιστο . .x. . δευτερόλεπτα

 Η παραπάνω απαίτηση εφαρμόζεται στην ταυτόχρονη λειτουργία έως .

.x. . τερματικών. [για σύστημα πολλών χρηστών]

(vii) Επέκταση/Επαναδιαμόρφωση

 Αναμένεται ότι μέσα στα επόμενα . .x. . χρόνια το σύστημα θα

χρειαστεί να ικανοποιήσει τις ακόλουθες απαιτήσεις ανάπτυξης:

Αύξηση . .x. .% των αποθηκευμένων ονομάτων/ αριθμών τηλεφώνου.

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

[Η απαίτηση θα μπορούσε να συνεχίσει τώρα με ένα από τους δυο

ακόλουθους τρόπους

ΕΙΤΕ:

 Πρέπει να υπάρχει επαρκής διαθέσιμη χωρητικότητα όσον αφορά την

κύρια και δευτερεύουσα αποθήκευση και επαρκής ισχύ του
επεξεργαστή για να εξυπηρετήσει μια επέκταση τέτοιου μεγέθους
(μπορούν να δίνονται νούμερα)

Ή:

 Πρέπει να είναι δυνατό να υλοποιηθεί μια τέτοια επέκταση με

βελτίωση του συστήματος που παραδόθηκε για να ικανοποιήσει την
αρχική απαίτηση.]

(viii) Διαθεσιμότητα συστήματος

 Το σύστημα απαιτείται να λειτουργεί σε 24-ωρη, 7-ήμερη βάση.

 Τα επίπεδα εμπιστοσύνης πρέπει να είναι τουλάχιστον . .x. .%

του χρόνου σε μια περίοδο . .x. . μηνών λειτουργίας.

51
 Η ανάκαμψη από μια ολοκληρωτική πτώση του λογισμικού πρέπει να
παίρνει το πολύ . .x. . λεπτά.

 Αρχειοθέτηση της βάση από/προς μέσα αποθήκευσης μακράς

διάρκειας πρέπει να είναι δυνατή παράλληλα με την κανονική
λειτουργία.

[Αυτή θα ήταν το είδος προσδοκίας για ένα μεγάλο σύστημα που

χρειάζεται να είναι μονίμως on-line. Ο χρήστης που θέλει να
χρησιμοποιήσει το σύστημα στο σπίτι με αυτόν τον τρόπο θα μπορούσε
να προδιαγράψει την ίδια ακριβώς απαίτηση φυσικά - οι μόνες
διαφορές είναι αυτές της κλίμακας.]

(ix) Αποδοχή

[Πολλά από αυτά που είπαμε πριν θα επαναληφθούν σε αυτό το τμήμα,

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

Όταν ολοκληρωθεί το σύστημα, ένας έλεγχος αποδοχής με 3

φάσεις θα χρησιμοποιηθεί ως ακολούθως:

 Φάση 1: Οι τυπικοί έλεγχοι εγκατάστασης του προμηθευτή, μετά

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

 Φάση 2: Ο πελάτης ή ο αντιπρόσωπος του πελάτη θα εκτελέσει

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

 Φάση 3: Ο πελάτης ή ο αντιπρόσωπος του πελάτη θα

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

52
4.2.2 ΚΑΤΑΝΟΜΗ

[Καθεμιά από τις λειτουργίες που ορίζονται πρέπει να κατανέμεται στο

κατάλληλο στοιχείο του συστήματος - υλικό, λογισμικό ή χειριστή. Στην πράξη
συχνά το υλικό και το λογισμικό αντιμετωπίζονται χωριστά, με τις εργασίες
του χειριστή να ορίζονται κατάλληλα μέσα σε κάθε περιοχή. Κατά συνέπεια
μπορούν να παραχθούν ξεχωριστά έγγραφα σχεδιασμού υλικού και λογισμικού
χωρίς να ξανασυναντώνται αυτά τα δύο μέχρι το επίπεδο ολοκλήρωσης του
συστήματος, όπου στο σημείο αυτό τα δύο αυτά πρέπει να τοποθετηθούν μαζί.
Δεδομένου ότι αυτές οι λεπτομέρειες των διεπαφών ανάμεσα στο υλικό και το
λογισμικό εμφανίζονται σε ένα, και κατά προτίμηση και στα δύο έγγραφα,
αυτή η προσέγγιση είναι πλήρως αποδεκτή.]
π.x. αντιμετωπίζοντας μία λειτουργία ΠΡΟΣΘΗΚΗ / ΤΡΟΠΟΠΟΙΗΣΗ /
ΑΝΑΖΗΤΗΣΗ η κατανομή έχει ως ακολούθως:

ΥΛΙΚΟ:  Ολόκληρη η βάση δεδομένων θα χρειαστεί να είναι

on-line όσο το σύστημα βρίσκεται σε λειτουργία.

 Αποτυχία μιας πρόσβασης στο δίσκο κατά τη

διάρκεια μιας λειτουργίας
ΠΡΟΣΘΗΚΗ/ΤΡΟΠΟΠΟΙΗΣΗ/ΑΝΑΖΗΤΗΣΗ
πρέπει να προκαλέσει έναν κώδικα λάθους
ανιχνεύσιμου από το λογισμικό ο οποίος θα του
δώσει τη δυνατότητα να ενεργοποιήσει διορθωτική
ενέργεια ή ενέργεια ανάκαμψης, και μια
οπτική/ακουστική προειδοποίηση στο χειριστή στην
περίπτωση οποιουδήποτε λάθους που μπορεί να
επιδιορθωθεί με την παρέμβαση του, π.x. ο οδηγός
δίσκου να είναι εκτός σύνδεσης.

ΛΟΓΙΣΜΙΚΟ:  Η επεξεργασία των δεδομένων εισόδου και η

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

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

53
λεπτομέρειες για βάσεις δεδομένων ή αρχεία δεδομένων που υπάρχουν την
παρούσα στιγμή.]

 Το σύστημα θα χρησιμοποιεί μία απλή βάση δεδομένων θα που περιέχει

εγγραφές με όνομα/αριθμό τηλεφώνου.

 Αυτή η βάση δεδομένων θα χρειαστεί να είναι μέρος του συστήματος που

θα παραδοθεί..

[ΕΙΤΕ]

.. τα περιεχόμενα του να δημιουργούνται με είσοδο δεδομένων από το υπάρχον

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

[ΕΙΤΕ]

.. τα περιεχόμενα του να δημιουργούνται με μεταφορά δεδομένων από την

υπάρχουσα συλλογή ..x.. εύκαμπτων δίσκων 8 ιντσών.

4.2.3 ΠΕΡΙΟΡΙΣΜΟΙ

[Στο κεφάλαιο αυτό αντιμετωπίζονται τεχνικοί και διαχειριστικοί περιορισμοί.

Τυπικές κατηγορίες στο κεφάλαιο αυτό θα περιλάμβαναν -

Περιβάλλον θερμοκρασίες, επίπεδο υγρασίας ..

Πόροι απαιτούμενη διαθέσιμη χωρητικότητα
χρόνου/μνήμης ΚΜΕ (Cpu time/memory)
Χρονοδιάγραμμα προθεσμίες, σημεία προόδου ..
Κόστος όχι περισσότερο από ..
]

 Το σύστημα πρέπει να τρέχει σε ένα περιβάλλον γραφείου, [Το

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

54
 Όταν η on-line βάση δεδομένων έχει εκκινηθεί, το 50% του διαθέσιμου
χώρου του δίσκου θα πρέπει να παραμείνει αχρησιμοποίητο, έτσι ώστε να
εξυπηρετήσει μελλοντική επέκταση.

 Το υλοποιημένο σύστημα θα πρέπει να παραδοθεί μέσα σε ..x.. μήνες από

την ημερομηνία του συμβολαίου.

 Ο προϋπολογισμός γι’ αυτό το έργο είναι ..x.. δρχ. [δηλ. αν θες τη

δουλειά, μη ζητήσεις περισσότερα από αυτά!]

[Πέρα από τον προσδιορισμό ενός περιορισμού, είναι συχνά κατάλληλο να

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

Για παράδειγμα, ένας πιο ελαστικός δεύτερος από τους τέσσερις

παραπάνω περιορισμούς είναι ο εξής:

 Όταν η on-line βάση δεδομένων έχει εκκινηθεί, περίπου 50% - και όχι
λιγότερο από 40%, - του διαθέσιμου χώρου του δίσκου θα πρέπει να
παραμείνει αχρησιμοποίητο, έτσι ώστε να εξυπηρετήσει μελλοντική
επέκταση.

4.2.4 ΠΡΟΤΥΠΑ

[Ένα πρότυπο μπορεί να θεωρηθεί σαν ένα άλλο είδος περιορισμού - που
επιβάλλεται, στην πραγματικότητα, στο σχεδιασμό και την υλοποίηση. Με
άλλα λόγια, σε αυτό το σημείο των προδιαγραφών απαιτήσεων περιλαμβάνεται
ένα τμήμα προτύπων που θα δηλώνει ότι, στον ένα ή στον άλλο βαθμό, ο
σχεδιαστής/αναλυτής συστημάτων/προγραμματιστής πρέπει να κάνουν τη
δουλειά τους με ένα συγκεκριμένο τρόπο.
Αχά! λες, αλλά πώς αυτό συμβιβάζεται με την προηγούμενη
κατηγορηματική επιμονή ότι οι προδιαγραφές απαιτήσεων δεν είναι ένα
έγγραφο σχεδιασμού; Απλό. Οι προδιαγραφές απαιτήσεων εξυπηρετούν στο να
ορίσουν το πλαίσιο για τo έργο, μέσα στο οποίο ο σχεδιαστής και λοιποί έχουν
πράγματι πλήρη ελευθερία. Ένα πρότυπο εξυπηρετεί στην ισχυροποίηση του
πλαισίου, τίποτα περισσότερο.

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

 Όλα τα προγράμματα θα γραφτούν σε Pascal, με τον πηγαίο και τον

αντικείμενο κώδικα να είναι αντικείμενα που μπορούν να παραδοθούν.

4.2.5 ΠΟΙΟΤΗΤΑ

Αυτό το κεφάλαιο θα καλύψει απαιτήσεις για έλεγχο και εξασφάλιση

ποιότητας σε όλη τη διάρκεια του κύκλου ζωής της έργου.
Η διαφορά εδώ είναι ότι η απαίτηση θα είναι της μορφής «οι
προμηθευτές πρέπει να πουν τι πρόκειται να κάνουν σχετικά με ..», αντί «οι
προμηθευτές πρέπει ..». Στην πιο απλή μορφή της η απαίτηση θα είναι ότι ο
προμηθευτής θα πρέπει να ορίσει τον Κώδικα Πρακτικής τον οποίο θα
ακολουθήσει. Για να αποφευχθεί η πιθανότητα να ληφθεί μια εντελώς γενική
απάντηση («θα κάνουμε ότι κάνουμε πάντα»), πρέπει να τεθούν συγκεκριμένα
σημεία τα οποία χρειάζεται να προσδιορισθούν συγκεκριμένα. Τα ακόλουθα
είναι μια αντιπροσωπευτική λίστα περιοχών που αναμένεται να καλύψει μια
τέτοια απάντηση:

 Δομή της διοίκησης του έργου, το επίπεδο εξειδίκευσης που θα απαιτηθεί

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

56
 Πρόγραμμα σχεδιασμού του έργου - πότε θα λάβουν χώρα τα διάφορα
συμβάντα και με ποια σειρά.

 Διαδικασίες ελέγχου της προόδου του έργου - πώς θα παρακολουθείται η

ανάπτυξη του έργου, πότε, και πόσο συχνά.

 Πρόγραμμα και στρατηγική ελέγχου - ποιες πλευρές του συστήματος θα

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

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

 Παρακολούθηση/Διαχείριση συστατικών του λογισμικού - πώς θα

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

Θα επιστρέψουμε στο αντικείμενο της Επιβεβαίωσης Ποιότητας σε άλλο

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

Κάποιες πιθανές δηλώσεις, πέρα από κάποια απαίτηση για έναν

ορισμένο Κώδικα Πρακτικής, θα μπορούσαν να έχουν ως εξής:

 Πρέπει να καθοριστεί σαφής πολιτική σχετικά με τον επανέλεγχο και την

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

 Πρέπει να δοθεί πρόγραμμα αναθεώρησης σχεδιασμού λογισμικού, και να

σχετιστεί με τον αναμενόμενο κύκλο ανάπτυξης λογισμικού.

 Θα πρέπει να οριστεί ενδιάμεση τεκμηρίωση, αφού αυτή είναι το

αντικείμενο αλλά και το εγκεκριμένο αποτέλεσμα των
προγραμματισθέντων αναθεωρήσεων σχεδιασμού.

 Το σχέδιο ελέγχου πρέπει να περιλαμβάνει ορόσημα ελέγχου. Αυτοί

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

57
4.2.6 ΧΡΟΝΟΔΙΑΓΡΑΜΜΑ ΑΝΑΠΤΥΞΗΣ

[Ένα χρονοδιάγραμμα ανάπτυξης συστήματος θα πρέπει να είναι επίσης μέρος

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

 Παράδοση του συστήματος απαιτείται μέσα σε ..x.. μήνες από την

υπογραφή του συμβολαίου.

4.3 Επικύρωση απαιτήσεων

Ως εδώ έχουμε δώσει έμφαση στο προφανές αλλά συχνά παρα-

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

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

 Να εξασφαλίσουν ότι οι προδιαγραφές είναι πλήρεις. Οτιδήποτε θέλει ο

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

Σε αυτό πλαίσιο, οποιοδήποτε τμήματ των προδιαγραφών αναφέρεται σε

επέκταση/επαναδιαμόρφωση (πχ 4.2.1(vii) στο παραπάνω παράδειγμα)
πρέπει να εξετάζεται πολύ προσεκτικά.

 Να εξασφαλίσουν ότι οι προδιαγραφές είναι συνεπείς. Οι απαιτήσεις, αν

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

Σαν ένα αποδεκτά ακραίο παράδειγμα, το 4.2.1α παραπάνω προσδιορίζει ότι

για μια λειτουργία ΠΡΟΣΘΗΚΗ, ένα όνομα και ένας αριθμός τηλεφώνου
θα είναι είσοδος. Αν η λειτουργία ΤΡΟΠΟΠΟΙΗΣΗ που ακολουθεί είχε
προσδιορίσει την είσοδο του ονόματος ή της διεύθυνσης του αντικειμένου
που επρόκειτο να τροποποιηθεί, οι δύο απαιτήσεις θα ήταν ασυνεπείς - το
σύστημα κρατά αριθμούς τηλεφώνων ή διευθύνσεις ή και τα δύο; Το να
βρεθεί ότι είχαν αρχικοποιηθεί στο δίσκο λάθος πληροφορίες για
ολόκληρο τον τηλεφωνικό κατάλογο του Λονδίνου θα ήταν ατυχές.

 Να εξασφαλίζουν ότι οι προδιαγραφές είναι ρεαλιστικές. Απλά, δεν

υπάρχει λόγος να περιλαμβάνεται στις προδιαγραφές μια απαίτηση που
δεν είναι δυνατό να υλοποιηθεί. Το να ζητηθεί η λειτουργία
ΑΝΑΖΗΤΗΣΗ να πρέπει να βρίσκει έναν αριθμό τηλεφώνου ενός
ονόματος που ο δε μπορεί να θυμηθεί χρήστης, για παράδειγμα, θα ήταν
μη ρεαλιστική - τουλάχιστο μέχρι να φτάσει στην αγορά λογισμικό με
μαντικές ικανότητες.

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

ΣΕΞ Σ’ αγαπώ !!! ΓΑΜΟΣ

Οι ίδιες λέξεις, αλλά με τελείως διαφορετικό νόημα !

Οι προδιαγραφές φυσικής γλώσσας, λοιπόν, δεν βοηθούν πάντα την

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

«Όλες οι συγκρίσεις συμβολοσειρών πρέπει να γίνονται χρησιμοποιώντας

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

Αυτό σημαίνει ότι αν το αποθηκευμένο όνομα είναι ΠΑΠΑΓΕΩΡ-

ΓΑΚΟΠΟΥΛΟΣ τότε το μόνο πιθανό ταίριασμα είναι όταν ο χρήστης εισάγει
τους 18 χαρακτήρες αυτού του ονόματος; Ή αν «ολόκληρο το αντικείμενο
δεδομένων σαν είσοδο από τον χρήστη» είναι ΠΑΠΑ ή ΠΑΠΑΓΕ αυτό θα
παράγει το ταίριασμα; Τι γίνεται όταν το αντικείμενο εισόδου είναι

60
ΓΕΩΡΓΑΚΟ ή ΠΟΥΛΟΣ - δεν ταιριάζουν «με τους χαρακτήρες του
αποθηκευμένου αντικειμένου»;
Επιπρόσθετα, υπάρχει η αναπόφευκτη επίδραση της χρήσης φυσικής
γλώσσας που προκαλεί διαφορετικά στοιχεία των απαιτήσεων να
αναμειγνύονται μαζί έτσι ώστε να μην φαίνεται η διαφορά μεταξύ τους. Είναι
το πρόβλημα «Θέλω να πας στο σούπερ μάρκετ την Τετάρτη - α ναι, και την
Πέμπτη, έχουν μια ειδική προσφορά τις Πέμπτες - και να αγοράσεις κανά δυο
κιλά μανταρίνια και σκόρδα» : Τι πρέπει να αγοραστεί και πότε; Ένα κιλό κάθε
μέρα; Ένα κιλό μανταρίνια την Τετάρτη, και ένα κιλό σκόρδα ειδικής
προσφοράς την Πέμπτη; Καταλαβαίνετε τι εννοώ.
Χρησιμοποιώντας το παράδειγμα του καταλόγου τηλεφώνων ξανά, ένα
λάθος θα βρεθεί στην εκτέλεση της λειτουργίας αναζήτησης στο (βλέπε
4.2.1iv):

«προσπάθεια παράλειψης αντικειμένου για αναζήτηση.»

Αλλά πως συμβιβάζεται αυτό με το κριτήριο αναζήτησης που

αναφέραμε μόλις πριν;

«Όλες οι συγκρίσεις συμβολοσειρών πρέπει να γίνονται χρησιμοποιώντας

ολόκληρο το αντικείμενο δεδομένων σαν είσοδο από τον χρήστη.»

Ένα κενό αντικείμενο δεδομένων θα χρησιμοποιηθεί για μια αναζήτηση

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

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

<αντικείμενο δεδομένων> ορίζεται_ως (<όνομα> Ή <αριθμός

τηλεφώνου>) ΚΑΙ ΟΧΙ <κενό>
χρησιμοποιώντας αυτό τον ορισμό σε μια ακόλουθη προδιαγραφή για την
αναζήτηση -

ΛΕΙΤΟΥΡΓΙΑ ΑΝΑΖΗΤΗΣΗΣ

ΕΙΣΑΓΩΓΗ <αντικείμενο δεδομένων του χρήστη>

ΑΝ
<αντικείμενο δεδομένων του χρήστη> είναι_ένα
<αντικείμενο δεδομένων>
ΤΟΤΕ
ΑΝ
όλοι_οι_χαρακτήρες_του <αντικείμενο
δεδομένων του χρήστη> =
αρχικοί_χαρακτήρες_του <αντικείμενο
βάσης>
ΤΟΤΕ
σύγκριση_εντάξει
ΑΛΛΙΩΣ
ανάφερε_ένα_λάθος
ΑΛΛΙΩΣ ανάφερε_ένα_λάθος

Ένας συμβολισμός σαν αυτόν, που μειώνει τη γλώσσα προδιαγραφών σε

λιγότερους όρους από ότι χρησιμοποιεί (ΑΝ, ΤΟΤΕ), κάθε ένας από τους
οποίους έχει ένα καθολικό νόημα σε όλους τους αναγνώστες, μαζί με έναν
απλό κανόνα ότι όλοι οι άλλοι όροι που επινοούνται από τον προδιαγραφέα
(π.x. <αντικείμενο δεδομένων> ,όλοι_οι_χαρακτήρες_του, σύγκριση_εντάξει)
πρέπει να ορίζονται μέσα στην προδιαγραφή, είναι η ουσία μιας τυπικής
μεθόδου. Αν προσθέσετε σε αυτό τις προφανείς δυνατότητες της επεξεργασίας
από υπολογιστή το όνειρο ενός μέσου για την επίτευξη πλήρως επικυρωμένων
προδιαγραφών απαιτήσεων έρχεται μάλλον κοντά στην πραγματοποίηση του.

4.4 Περίληψη

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

 Το λειτουργικό κομμάτι των προδιαγραφών απαιτήσεων καλύπτει την

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

 Τα μη λειτουργικά κομμάτια των προδιαγραφών απαιτήσεων θα

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

 Η επικύρωση των προδιαγραφών απαιτήσεων πρέπει να γίνεται πριν την

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

 Η χρήση της φυσικής γλώσσας για τις προδιαγραφές απαιτήσεων κάνει

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

63
Κεφάλαιο 5: Πρωτοτυποποίηση Λογισμικού

 ΣΚΟΠΟΣ ΤΟΥ ΚΕΦΑΛΑΙΟΥ

Μια σημαντική τεχνική επικύρωσης απαιτήσεων είναι η γρήγορη πρωτοτυποποίηση.

Ένα πρωτότυπο λογισμικού συστήματος μπορεί να αναπτυχθεί από ένα περίγραμμα
προδιαγραφής. Οι χρήστες πειραματίζονται με το πρωτότυπο για να καθορίσουν και
να βελτιώσουν την προδιαγραφή.
Αυτό το κεφάλαιο ασχολείται με
 τα πλεονεκτήματα της πρωτοτυποποίησης,
 τις ενέργειες που εμπλέκονται σ’ αυτήν και
 τα προβλήματα διαχείρισης που μπορεί να εμφανιστούν.
Εξετάζεται
 ο ρόλος της πρωτοτυποποίησης στη διαδικασία του λογισμικού και
 η throw-away πρωτοτυποποίηση συγκρίνεται με τον εξερευνητικό
προγραμματισμό και την επαυξητική ανάπτυξη.
Eπίσης αναφέρονται εν συντομία μερικές τεχνικές πρωτοτυποποίησης δηλαδή:
 οι τυπικές εκτελέσιμες γλώσσες προδιαγραφών,
 οι υψηλού επιπέδου γλώσσες,
 οι γλώσσες τέταρτης γενιάς και
 η πρωτοτυποποίηση με επαναχρησιμοποιήσιμα συστατικά.
Το τελευταίο μέρος του κεφαλαίου ασχολείται με την πρωτοτυποποίηση διεπαφής
(interface) χρήστη και συμπεραίνει ότι ο σχεδιασμός διεπαφής με κέντρο το χρήστη
που βασίζεται στην πρωτοτυποποίηση είναι ο πιο αποτελεσματικός τρόπος για να
αναπτυχθούν ικανοποιητικές διεπαφές.

 ΠΕΡΙΕΧΟΜΕΝΑ

5.1 Πρωτοτυποποίηση στην διαδικασία ανάπτυξης λογισμικού

5.2 Τεχνικές πρωτοτυποποίησης

5.3 Πρωτοτυποποίηση διεπαφής χρήστη

 Πρωτοτυποποίηση Λογισμικού

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

Ένας τρόπος να υπολογίζουμε τη δυσκολία την οποία έχουν οι χρήστες στην

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

Η πρωτοτυποποίηση λογισμικού είναι αρκετά διαφορετική από την πρωτοτυποποίηση

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

Τα πλεονεκτήματα ανάπτυξης ενός πρωτοτύπου κατά τα αρχικά στάδια ανάπτυξης

λογισμικού είναι:

1. Μπορεί να αναγνωρίζονται οι παρανοήσεις μεταξύ των σχεδιαστών

λογισμικού και των χρηστών καθώς παρουσιάζονται οι λειτουργίες του
συστήματος.
2. Μπορεί να εντοπιστούν οι ελλείψεις στις προσφερόμενες λειτουργίες.
3. Μπορεί να αναγνωρίζονται και να διορθώνονται οι δύσκολες στη χρήση ή
οι συγκεχυμένες υπηρεσίες των χρηστών.
4. Καθώς αναπτύσσεται το πρωτότυπο, το προσωπικό που ασχολείται με την
ανάπτυξη του λογισμικού, μπορεί να βρει ελλιπείς ή και ασύμβατες
απαιτήσεις.
5. Ένα σύστημα που δουλεύει, παρότι περιορισμένο, είναι διαθέσιμο να
δείχνει γρήγορα στη διοίκηση το πραγματοποιήσιμο και τη χρησιμότητα
της εφαρμογής.
6. Το πρωτότυπο εξυπηρετεί και ως βάση για συγγραφή της προδιαγραφής
για ένα ποιοτικό σύστημα παραγωγής.

Παρότι ο αρχικός σκοπός πρωτοτυποποίησης είναι να επικυρώσει τις απαιτήσεις

λογισμικού, οι Ince και Hekmatpour (1987) έδειξαν ότι το πρωτότυπο λογισμικού έχει
κι άλλες χρήσεις:

65
 Πρωτοτυποποίηση Λογισμικού

1. Μπορεί να χρησιμοποιηθεί στην εκπαίδευση χρηστών πριν την παράδοση του

ποιοτικού συστήματος παραγωγής.
2. Μπορεί να χρησιμοποιηθεί κατά τη διάρκεια ελέγχου για να «τρέξει» ‘back-to-
back’ tests. Αυτό σημαίνει ότι οι ίδιοι έλεγχοι υποβάλλονται και στο πρωτότυπο
και στο ίδιο το σύστημα. Αν και τα δύο συστήματα δώσουν το ίδιο αποτέλεσμα
πιθανότατα σημαίνει ότι ο έλεγχος δεν εντόπισε λάθος στο σύστημα. Αν τα
αποτελέσματα είναι διαφορετικά, αυτό μπορεί να σημαίνει ότι υπάρχει κάποιο
λάθος στο σύστημα. Κουραστικές, χειρονακτικές εξετάσεις των αποτελεσμάτων
ελέγχου μπορεί να μειωθούν χρησιμοποιώντας αυτήν την τεχνική. Οι έλεγχοι back-
to-back αναφέρονται στο αντίστοιχο κεφάλαιο περί ελέγχου.

Ένας τρόπος να δούμε την πρωτοτυποποίηση είναι ως μια τεχνική μείωσης

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

Υπάρχουν τέσσερα στάδια στην ανάπτυξη πρωτοτύπου:

1. Καθορισμός σκοπών πρωτοτύπου

2. Επιλογή των λειτουργιών που θα συμπεριληφθούν στο πρωτότυπο και λήψη
αποφάσεων σχετικά με το ποιες μη λειτουργικές απαιτήσεις πρέπει να
πρωτοτυποποιηθούν.
3. Ανάπτυξη πρωτοτύπου
4. Αξιολόγηση του πρωτοτύπου.

Οι σκοποί της πρωτοτυποποίησης πρέπει να γίνονται σαφείς πριν ξεκινήσει η

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

Το επόμενο στάδιο στη διαδικασία είναι ν’ αποφασιστεί τι θα μπει και, ίσως

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

πιο συνήθης πρακτική στην ανάπτυξη πρωτοτύπου είναι να μετριάζουμε τις μη

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

Το τελικό στάδιο της διαδικασίας είναι η αξιολόγηση πρωτοτύπου. Οι Ince και

Hekmatpour (1987) υπέδειξαν ότι αυτό είναι το σημαντικό στάδιο στην
πρωτοτυποποίηση. Κατά τη διάρκεια αυτού του σταδίου πρέπει να ληφθεί μέριμνα
για την εκπαίδευση των χρηστών και οι στόχοι του πρωτοτύπου πρέπει να
χρησιμοποιηθούν για να παραχθεί ένα πλάνο αξιολόγησης.

Πρέπει να αφήνεται επαρκής χρόνος για να εξοικειωθούν οι χρήστες με το

σύστημα και να σταθεροποιηθούν σ’ ένα τύπο χρήσης κι έτσι να ανακαλύψουν λάθη
απαιτήσεων και παραλείψεις.

Το μεγαλύτερο τεχνικό πρόβλημα που σχετίζεται με την πρωτοτυποποίηση

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

1. Ο σχεδιασμός, ο υπολογισμός κόστους και η εκτίμηση σχεδίου

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

Ένα σύνηθες επιχείρημα εναντίον της πρωτοτυποποίησης είναι ότι το κόστος

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

Αυτό μπορεί να είναι αλήθεια για κάποια συστήματα, αλλά η αποτελεσματική

πρωτοτυποποίηση αυξάνει την ποιότητα λογισμικού και ως εκ τούτου μπορεί να
δώσει σ’ αυτούς που αναπτύσσουν λογισμικό ένα πλεονέκτημα απέναντι στους
67
 Πρωτοτυποποίηση Λογισμικού

ανταγωνιστές τους. Η εμπειρία στις Η.Π.Α. και τη Μεγάλη Βρετανία στις βιομηχανίες
αυτοκινήτων που απέτυχαν να επενδύσουν σε ποιοτικές διαδικασίες στις δεκαετίες
του ΄60 και του ΄70 και που έχασαν ένα μεγάλο μέρος της αγοράς από τα καλύτερης
ποιότητας Ιαπωνικά αυτοκίνητα, δείχνει παραστατικά ότι η φιλοσοφία «φτιάξε το
φτηνό και διόρθωσέ το αργότερα» μπορεί να είναι πολύ πιο ακριβή μακροπρόθεσμα.

Όπως αναφέρθηκε στο κεφάλαιο 1, η πρωτοτυποποίηση είναι μια τεχνική

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

5.1 Πρωτοτυποποίηση στην επεξεργασία λογισμικού

Το θεμελιώδες πρόβλημα που αντιμετωπίζουν οι χρήστες που καθορίζουν ένα

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

Σχήμα 5.1 Εξερευνητικός προγραμματισμός και πρωτοτυποποίηση

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

Ένας τρόπος να αντιμετωπιστεί αυτή η δυσκολία είναι να χρησιμοποιήσουμε

μια εξερευνητική προσέγγιση στην ανάπτυξη συστημάτων. Αυτό σημαίνει να
παρουσιάσουμε στο χρήστη ένα σύστημα που ξέρει ότι είναι ημιτελές και μετά να
τροποποιούμε και να επεκτείνουμε αυτό το σύστημα καθώς θα ξεκαθαρίουν οι
πραγματικές απαιτήσεις του χρήστη. Εναλλακτικά, μια σκόπιμη απόφαση μπορεί να
είναι να κατασκευαστεί ένα πρωτότυπο ‘throw - away’ ως βάση για τη σύλληψη των
απαιτήσεων. Μετά την αξιολόγηση, το πρωτότυπο πετιέται και κατασκευάζεται εξ’
αρχής ένα σύστημα παραγωγής.

Η διάκριση μεταξύ αυτών των δύο προσεγγίσεων είναι ότι ο εξερευνητικός

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

Τεχνητής Νοημοσύνης δεν μπορούν να είναι εντελώς συγκεκριμένα). Αντίθετα, η

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

Ένα μοντέλο της διαδικασίας ανάπτυξης λογισμικού που βασίζεται σε ένα

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

Καθορισμός του περιγράμματος Ανάπτυξη πρωτοτύπου Αξιολόγηση Προδιαγραφή

των προδιαγραφών πρωτοτύπου συστήματος

Συστατικά

Σχεδιασμός και υλοποίηση Επικύρωση

συστήματος συστήματος

Σχήμα 5.2 Πρωτοτυποποίηση στη διαδικασία λογισμικού

Το μοντέλο διαδικασίας στο σχήμα 5.2 υποθέτει ότι το πρωτότυπο

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

Αντί να παραχθεί μια προδιαγραφή από το πρωτότυπο, καμιά φορά

προτείνεται η προδιαγραφή συστήματος να είναι η υλοποίηση του ίδιου του
πρωτοτύπου. Η οδηγία στον εργολήπτη του λογισμικού έπρεπε να είναι απλά «γράψε
ένα σύστημα σαν αυτό». Υπάρχουν αρκετά προβλήματα σ’ αυτήν την προσέγγιση:

69
 Πρωτοτυποποίηση Λογισμικού

1. Σημαντικά χαρακτηριστικά του συστήματος μπορεί να έχουν μείνει

εσκεμμένα έξω από το πρωτότυπο για να απλοποιήσουν τη γρήγορη
ανάπτυξη. Στην πραγματικότητα, μπορεί να μην είναι εφικτό να
συμπεριληφθούν στο πρωτότυπο μερικά από τα πιο σημαντικά μέρη του
συστήματος, όπως ζωτικά χαρακτηριστικά ασφάλειας.
2. Μια υλοποίηση είναι μια ακατάλληλη βάση για συμβόλαιο μεταξύ
πελάτη και εργολήπτη. Το επακόλουθο συμβόλαιο μπορεί πιθανότατα να
μην έχει νομική βάση.
3. Μη λειτουργικές απαιτήσεις όπως αυτές που αφορούν στην αξιοπιστία,
στην ακεραιότητα και στην ασφάλεια δεν μπορούν να εκφραστούν
κατάλληλα σε μια υλοποίηση πρωτοτύπου.
4. Ο χρήστης μπορεί να μη χρησιμοποιεί το πρωτότυπο με τον ίδιο τρόπο
όπως ένα εν ενεργεία σύστημα. Αυτό μπορεί να είναι εξαιτίας της
έλλειψης εξοικείωσης με το σύστημα ή εξαιτίας κάποιων
χαρακτηριστικών του πρωτοτύπου. Για παράδειγμα, αν το πρωτότυπο
είναι αργό, οι χρήστες μπορεί να προσαρμόσουν τον τρόπο δουλειάς τους
και αποφεύγοντας κάποια χαρακτηριστικά του συστήματος να
προσαρμοστούν σε αργούς χρόνους απάντησης. Όταν εφοδιάζονται με
κάλύτερη απάντηση, μπορεί να χρησιμοποιούν το σύστημα με ένα
διαφορετικό τρόπο και να κάνουν χρήση λειτουργιών οι οποίες δεν έχουν
αξιολογηθεί.

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

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

1. Σημαντικά χαρακτηριστικά του συστήματος, όπως η απόδοση , η

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

Ένα εναλλακτικό μοντέλο που επιχειρεί να συνδιάσει τα πλεονεκτήματα του

εξερευνητικού προγραμματισμού με τον έλεγχο που απαιτείται για μεγάλης κλίμακας
ανάπτυξη αναφέρθηκε από τον Mills (1980). Αυτή χαρακτηρίστηκε επαυξητική
ανάπτυξη (σχήμα 5.3) και αφορά στην ανάπτυξη των απαιτήσεων και παράδοση
συστήματος με τμηματικό τρόπο. Έτσι, καθώς παραδίδεται ένα τμήμα του
συστήματος, ο χρήστης μπορεί να πειραματίζεται μ’ αυτό και να ανατροφοδοτεί τα
70
 Πρωτοτυποποίηση Λογισμικού

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

Η τμηματική ανάπτυξη αναιρεί τα προβλήματα των συνεχών αλλαγών που

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

Η τμηματική ανάπτυξη είναι πιο διαχειρίσιμη από το εξερευνητικό

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

Καθορισμός παραδοτέων
συστήματος

Προδιαγραφή τμήματος Ανάπτυξη τμήματος του Επικύρωση ανάπτυξης

συστήματος συστήματος

Παράδοση τμήματος Όχι Ολοκλήρωση

συστήματος συστήματος:

Ναι

Παράδοση
ολοκληρωμένου
συστήματος

Σχήμα 5.3 Βαθμιαία ανάπτυξη συστήματος

5.2 Τεχνικές πρωτοτυποποίησης

Οι τεχνικές πρωτοτυποποίησης συστήματος πρέπει να επιτρέπουν τη γρήγορη

ανάπτυξη ενός πρωτότυπου συστήματος. Επειδή το κόστος του προσωπικού είναι το
71
 Πρωτοτυποποίηση Λογισμικού

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

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

Υπάρχουν αρκετές τεχνικές που έχουν χρησιμοποιηθεί για την

πρωτοτυποποίηση συστήματος. Αυτές συμπεριλαμβάνουν:

72
 Πρωτοτυποποίηση Λογισμικού

1. Εκτελέσιμες γλώσσες προδιαγραφών

2. Γλώσσες πολύ υψηλού επιπέδου
3. Υψηλού επιπέδου γλώσσες προσανατολισμένες στην εφαρμογή
(γλώσσες τέταρτης γενιάς)
4. Σύνθεση με επαναχρησιμοποιούμενα συστατικά

Καθένα απ’ αυτά περιγράφεται παρακάτω.

5.2.1 Εκτελέσιμες γλώσσες προδιαγραφών

Η τυπική προδιαγραφή συστημάτων λογισμικού είναι το θέμα των τριών

επόμενων κεφαλαίων. Μια τυπική προδιαγραφή είναι ένα μαθηματικό μοντέλο
συστήματος που μπορεί να είναι εκτελέσιμο. Αυτό εξαρτάται από την εξάλειψη
γενικότητας από την προδιαγραφή (για παράδειγμα, δεν μπορούν να υποστηριχτούν
άπειρα σύνολα) και έχει αναπτυχθεί ένας σημαντικός αριθμός από εκτελέσιμες
τυπικές γλώσσες προδιαγραφής (Henderson και Minkowitz, 1986, Lee και Sluizer,
1985, Gallimore, 1989). O Diller (1990) μίλησε για τεχνικές animation τυπικών
προδιαγραφών γραμμένες σε Ζ, τη γλώσσα προδιαγραφής που περιγράφεται σε
επόμενο κεφάλαιο.

Το πλεονέκτημα αυτής της μεθόδου ανάπτυξης πρωτοτύπου είναι ότι το

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

Υπάρχουν τρία προβλήματα με αυτή την προσέγγιση στην ανάπτυξη

πρωτοτύπου:

73
 Πρωτοτυποποίηση Λογισμικού

1. Οι διεπαφές γραφικών των χρηστών δεν μπορούν να πρωτοτυποποιηθούν

χρησιμοποιώντας αυτήν την τεχνική. Μολονότι, μοντέλα διεπαφών
γραφικών μπορούν τυπικά να προδιαγραφούν (Took, 1986), αυτά δεν
μπορούν συστηματικά να υποστούν animation χρησιμοποιώντας
ισχύοντα παραθυρικά συστήματα.
2. Η ανάπτυξη πρωτοτύπου μπορεί να μην είναι ιδιαίτερα γρήγορη. Η
τυπική προδιαγραφή απαιτεί μια λεπτομερή ανάλυση συστήματος και
μπορεί να αφιερωθεί πολύς χρόνος στη λεπτομερή μοντελοποίηση των
λειτουργιών του συστήματος που απορρίπτονται μετά την αξιολόγηση
πρωτοτύπου.
3. Το εκτελέσιμο σύστημα είναι συνήθως αργό και αναποτελεσματικό. Οι
χρήστες μπορεί να παίρνουν μια λανθασμένη εντύπωση του συστήματος
και να συμβιβάζονται με αυτή την ‘καθυστέρηση’ κατά τη διάρκεια της
αξιολόγησης. Μπορεί να μη χρησιμοποιούν το σύστημα με τον ίδιο τρόπο
και να χρησιμοποιούν μια πιο αποτελεσματική μέθοδο. Γι’ αυτό οι
χρήστες μπορεί να καθορίζουν ένα διαφορετικό σύνολο απαιτήσεων απ’
αυτά που θα προτείνονταν αν ήταν διαθέσιμο ένα γρηγορότερο
πρωτότυπο.

Τα δύο πρώτα προβλήματα μπορούν να αντιμετωπιστούν με χρήση γλωσσών

συναρτησιακού προγραμματισμού για την ανάπτυξη του συστήματος. Μια
συναρτησιακή γλώσσα είναι μια τυπική γλώσσα που βασίζεται στην έκφραση του
συστήματος ως μια μαθηματική λειτουργία (function). Η αξιολόγηση αυτής της
λειτουργίας (η οποία προφανώς αναλύεται σε πολλές άλλες λειτουργίες) είναι
ισοδύναμη με την εκτέλεση ενός προγράμματος. Παραδείγματα πρακτικών
συναρτησιακών γλωσσών είναι η Miranda (Turner, 1985) και η ML (Wikstrom,
1988). Έχουν αναπτυχθεί υψηλής ποιότητας εφαρμογές και με τις δύο γλώσσες και
επίσης και οι δύο έχουν χρησιμοποιηθεί για την ανάπτυξη μη τετριμμένων
πρωτοτύπων συστήματος.

Οι συναρτησιακές γλώσσες μπορεί επίσης να κατηγοριοποιηθούν ως γλώσσες

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

5.2.2 Γλώσσες πολύ υψηλού επιπέδου

Οι πολύ υψηλού επιπέδου γλώσσες (μερικές φορές παραπλανητικά

αποκαλούμενες πέμπτης γενιάς) είναι γλώσσες προγραμματισμού με ενυπάρχουσες
δυναμικές δομές δεδομένων και υψηλού επιπέδου χαρακτηριστικά όπως η
οπισθοδρόμηση (backtracking). Το σύστημα της γλώσσας περιλαμβάνει πολλές
υπηρεσίες οι οποίες κανονικά πρέπει να χτιστούν από πιο πρωτόγονες δομές σε
74
 Πρωτοτυποποίηση Λογισμικού

γλώσσες όπως η Pascal ή η ADA. Παραδείγματα γλωσσών πολύ υψηλού επιπέδου

είναι η LISP (που στηρίζεται σε δομές λίστας), η Prolog (που βασίζεται στη λογική),
Smalltalk (που βασίζεται στα αντικείμενα), APL (που βασίζεται στα διανύσματα) και
SETL (που βασίζεται στα σύνολα). Είναι χρήσιμες γλώσσες για πρωτοτυποποίηση
επειδή τα δυναμικά τους χαρακτηριστικά κάνουν δυνατή την ταχεία ανάπτυξη
συστημάτων.

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

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

ΓΛΩΣΣΑ ΤΥΠΟΣ ΠΕΔΙΟ ΕΦΑΡΜΟΓΗΣ

Smalltalk Αντικειμενοστραφής Διεπαφές χρήστη
Prolog Λογική Συμβολική επεξεργασία
LISP Συναρτησιακή Συμβολική επεξεργασία
Miranda Συναρτησιακή Συμβολική επεξεργασία
SETL Βασισμένη σε Σύνολα Συμβολική επεξεργασία
APL Μαθηματική Επιστημονικά συστήματα
4 GL s Βάση Δεδομένων Επιχειρησιακά συστήματα
RAPID/USE Γραφική Επιχειρησιακά συστήματα
Gist/REFINE Ευρέως φάσματος Συμβολική επεξεργασία
LOOPS Ευρέως φάσματος Όπως η LISP + Διεπαφές χρήστη

Σχήμα 5.4

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

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

Ο Gomaa (1983) έχει αναφέρει την επιτυχημένη χρήση της APL ως γλώσσα
πρωτοτυποποίησης. Περιγράφει τα πλεονεκτήματα της ανάπτυξης ενός πρωτοτύπου
για ένα σύστημα διαχείρισης διαδικασιών και πληροφοριών. Τα κόστη ανάπτυξης
πρωτοτύπου ήταν μικρότερα του 10% του συνολικού κόστους. Στην ανάπτυξη του
τελικού συστήματος ποιότητας παραγωγής, δεν εμφανίστηκαν καθόλου προβλήματα
καθορισμού απαιτήσεων. Το έργο ολοκληρώθηκε εγκαίρως και η παράδοση στους
χρήστες ολοκληρώθηκε ομαλά.

Ένα από τα πιο ισχυρά συστήματα πρωτοτυποποίησης για διεπαφές χρήστη

(και άλλες λειτουργίες) είναι το σύστημα της Smalltalk (Goldberg Smalltalk
75
 Πρωτοτυποποίηση Λογισμικού

(Goldberg και Robson, 1983) . Η Smalltalk είναι μια αντικειμενοστραφής γλώσσα

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

1. Η αντικειμενοστραφής φύση της γλώσσας σημαίνει ότι τα συστήματα

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

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

Μια κατηγορία γλωσσών προγραμματισμού που έχουν προσχεδιαστεί, είναι οι

καλούμενες πολυπαραδειγματικές (multi-paradigm) ή ευρέως φάσματος (wide-
spectrum) γλώσσες προγραμματισμού. Παραδείγματα τέτοιων γλωσσών είναι οι Gist
(Balzer, 1982), EPROL (Hekmatpour & Ince, 1988) και LOOPS (Stefik, 1986).

Μια γλώσσα ευρέως φάσματος, είναι μια γλώσσα προγραμματισμού που

συνδυάζει ένα μεγάλο αριθμό φιλοσοφιών. Οι περισσότερες γλώσσες είναι
βασισμένες σε μια μόνο φιλοσοφία. Η Pascal είναι προστακτική (imperative) γλώσσα,
η LISP είναι βασισμένη σε συναρτήσεις και λίστες, η Prolog είναι βασισμένη στα
γεγονότα και τη λογική κ.ο.κ. Αντιθέτως, μια γλώσσα ευρέως φάσματος δεν είναι
περιορισμένη και μπορεί να περιέχει αντικείμενα, λογικό προγραμματισμό,
προστακτικές δομές κ.ο.κ. Παρόλο που υπήρξε ενδιαφέρον για τέτοιες γλώσσες, τα
πρακτικά προβλήματα ανάπτυξης αποτελεσματικών εφαρμογών οδήγησαν στη
διαθεσιμότητα λίγων εμπορικών προϊόντων τέτοιων γλωσσών.

Η Gist και το εμπορικό της παράγωγο, η REFINE (Smith, 1985) είναι ίσως η
πιο αναπτυγμένη γλώσσα στην οποία ο χρήστης γράφει μια τυπική, εκτελέσιμη
προδιαγραφή του συστήματος που θα πρωτοτυποποιηθεί. Η προδιαγραφή βελτιώνεται
από το χρήστη με αυτοματοποιημένη βοήθεια για να παραχθεί ένα εκτελέσιμο
πρωτότυπο συστήματος. Η Gist συμπεριλαμβάνει έννοιες από το λογικό
76
 Πρωτοτυποποίηση Λογισμικού

προγραμματισμό, το συναρτησιακό προγραμματισμό και από γλώσσες προστακτικού

προγραμματισμού. Ο επεξεργαστής Gist δημιουργεί μια υλοποίηση της εφαρμογής σε
LISP.

Ως εναλλακτική λύση της χρήσης γλώσσας ευρέως φάσματος είναι να

υιοθετηθεί μια μικτή γλώσσα για την ανάπτυξη πρωτοτύπου. Διαφορετικά τμήματα
του συστήματος προγραμματίζονται σε διαφορετικές γλώσσες και εγκαθιδρύεται ένα
πλαίσιο επικοινωνίας μεταξύ των τμημάτων αυτών. Η Zave (1989) περιγράφει αυτή
την προσέγγιση ανάπτυξης στην πρωτοτυποποίηση ενός συστήματος τηλεφωνικού
δικτύου. Χρησιμοποιήθηκαν τέσσερις διαφορετικές γλώσσες: η Prolog για την
πρωτοτυποποίηση της βάσης δεδομένων, η Awk (Aho, 1988) για τιμολόγηση, η CSP
(Hoare, 1985) για την προδιαγραφή πρωτοκόλλου και η PAISLey (Zave & Schell,
1986) για την εκτέλεση προσομοίωσης.

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

5.2.3 Γλώσσες τέταρτης γενιάς

Για κάποιες κατηγορίες εφαρμογών, ειδικότερα γι’ αυτές που αφορούν

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

Οι γλώσσες τέταρτης γενιάς είναι επιτυχημένες γιατί υπάρχει μεγάλη

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

77
 Πρωτοτυποποίηση Λογισμικού

Το επιχείρημα που προβάλλουν οι πωλητές αυτών των προϊόντων είναι ότι η

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

Η χρήση γλωσσών τέταρτης γενιάς για την ανάπτυξη συστημάτων

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

Γεννήτρια Φύλλα
αναφορών επεξεργασίας

Γλώσσα ερωταποκρίσεων Γεννήτρια

βάσης δεδομένων οθονών

Σύστημα διαχείρισης βάσης

δεδομένων

Σχήμα 5.5 Γλώσσες τέταρτης γενιάς

Παρόλο που η χρήση γλωσσών 4ης γεννιάς μειώνει σαφώς το κόστος

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

Οι γλώσσες τέταρτης γενιάς μπορούν να χρησιμοποιηθούν μαζί με εργαλεία

CASE για την ανάπτυξη πρωτοτύπου. Μερικά εργαλεία CASE ενσωματώνονται με
γλώσσες τέταρτης γενιάς και η χρήση τέτοιων συστημάτων έχει το πλεονέκτημα ότι η
τεκμηρίωση παράγεται στον ίδιο χρόνο με το πρωτότυπο σύστημα. Ένα πρώτο
παράδειγμα μιας τέτοιας ενσωμάτωσης συνόλου εργαλείων CASE και γλώσσας
τέταρτης γενιάς ήταν το σύστημα RAPID/USE που περιγράφεται από τον Wasserman
(1986).

H RAPID/USE κατασκευάστηκε στηριζόμενη σε μια σχεσιακή βάση

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

χρηστών. Συμπεριλαμβάνει συγκρίσιμες υπηρεσίες μ’ αυτές που περιέχονται στα

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

5.2.4 Σύνθεση επαναχρησιμοποιούμενων συστατικών

Είναι φανερό ότι ύπαρξη βιβλιοθήκης επαναχρησιμοποιούμενων συστατικών

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

Ίσως το καλύτερο παράδειγμα αυτής της προσέγγισης πρωτοτυποποίησης

είναι η γλώσσα προγραμματισμού κελύφους (shell programming language), σε πολλές
παραλλαγές, κάτω από UNIX (Bourne, 1978). Το κέλυφος του UNIX είναι μια
γλώσσα εντολών που περιέχει δομές ανακύκλωσης και κατασκευής αποφάσεων.
Παρέχει υπηρεσίες για συνδυασμό εντολών που λειτουργούν σε αρχεία και σειρές
string. Τα επαναχρησιμοποιήσιμα συστατικά είναι εντολές UNIX όπως ‘grep’, ‘sort’,
‘find’ κ.ο.κ. Η γενικού σκοπού φύση των αρχείων UNIX που είναι ροές απλών
χαρακτήρων, η μεταχείριση των συσκευών I/O σαν αρχεία, η υπηρεσία pipe και οι
υπηρεσίες ελέγχου της γλώσσας προγραμματισμού του κελύφους συνδυάζονται για
να φτιάξουν ένα ισχυρό σύστημα για σύνθεση συστατικών.

Αποθήκη επαναχρησιμοποιούμενων Προδιαγραφή συστήματος

δομικών συστατικών

Κατάλογος συστατικών Σύστημα σύνθεσης Εκτελέσιμο

συστατικών πρωτότυπο

Σχήμα 5.6 Σύνθεση επαναχρησιμοποιήσιμων δομικών στοιχείων

Εντούτοις, η πρωτοτυποποίηση με χρήση του κελύφους είναι περιορισμένη

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

Αυτή η προσέγγιση πρωτοτυποποίησης μπορεί φανερά να συνδυαστεί με

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

79
 Πρωτοτυποποίηση Λογισμικού

ως γλώσσες πρωτοτυποποίησης οφείλεται τόσο στις βιβλιοθήκες

επαναχρησιμοποιούμενων συστατικών όσο και στις ενσωματωμένες υπηρεσίες.

5.3 Πρωτοτυποποίηση διεπαφής χρήστη

Με την εμφάνιση των γραφικών διεπαφών χρήστη, όπως απεικονίζονται από

την Apple Macintoch, το περιβάλλον Windows για IBM PC s και συμβατές μηχανές
και το σύστημα X-Windows, η προσπάθεια που αφορά την προδιαγραφή, το
σχεδιασμό και την ανάπτυξη της διεπαφής χρήστη αντιπροσωπεύει ένα πολύ
σημαντικό τμήμα του κόστους της ανάπτυξης του συστήματος. ΄Οπως συζητήθηκε σε
άλλο κεφάλαιο, δεν είναι αποδεκτό από τους σχεδιαστές να επιβάλουν την άποψή
τους περί μιας αποδεκτής διεπαφής στους χρήστες και γι’ αυτό ο χρήστης πρέπει να
πάρει μέρος στη διαδικασία σχεδιασμού της διεπαφής. Αυτή η συνειδητοποίηση
οδήγησε σε μια προσέγγιση σχεδιασμού που καλείται σχεδιασμός
προσανατολισμένος στο χρήστη (Norman & Draper, 1986) και που εξαρτάται από την
πρωτοτυποποίηση διεπαφής και την ανάμιξη του χρήστη κατά το στάδιο σχεδιασμού
της διεπαφής.

Εδώ ο σχεδιασμός δε σημαίνει, φυσικά, το σχεδιασμό λογισμικού, αλλά την

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

Μερικές από τις τεχνικές που περιγράφτηκαν στην παράγραφο 5.2 είναι
κατάλληλες για την πρωτοτυποποίηση διεπαφής χρήστη. Οι πολύ υψηλού επιπέδου
γλώσσες όπως η Smalltalk και η LISP έχουν πολλά συστατικά της διεπαφής ως
τμήματα του συστήματος. Αυτά πολύ συχνά μπορούν να τροποποιούνται ώστε να
αναπτύσουν τη συγκεκριμένη διεπαφή που απαιτείται για μια εφαρμογή. Τα
συστήματα γλωσσών τέταρτης γενιάς συνήθως περιλαμβάνουν υπηρεσίες ορισμού
οθονών, όπου τα πρότυπα οθονών μπορούν να οριοθετηθούν διαλέγοντας και
τοποθετώντας από κάποια πεδία. Όλο και περισσότερο αναπτύσσονται παρεμφερείς
υπηρεσίες (Harbert, 1990) για χρήση με γραφικές διεπαφές.

80
 Πρωτοτυποποίηση Λογισμικού

Εντολές χρήστη Εμφάνιση διεπαφής χρήστη Εντολές εφαρμογής

Διεπαφή χρήστη Σύστημα διαχείρισης Εφαρμογή

Χρήστης
διεπαφής χρήστη

Εμφάνιση Εφαρμογή προδιαγραφής

προδιαγραφής εντολής

Σχήμα 5.7 Σύστημα διαχείρισης διεπαφής χρηστών

Άλλα συστήματα δημιουργίας διεπαφών βασίζονται σε συστήματα διαχείρισης

διεπαφών (Myers, 1988) που παρέχουν τις βασικές υπηρεσίες διεπαφής, όπως την
επιλογή από μενού, εμφάνιση αντικειμένου κ.ο.κ. Αυτά τα συστήματα
παρεμβάλλονται ανάμεσα στην εφαρμογή και τη διεπαφή χρήστη (σχήμα 5.7) και
παρέχουν διευκολύνσεις για τον καθορισμό οθόνης και την προδιαγραφή διαλόγου.
Αυτές οι υπηρεσίες μπορεί να είναι βασισμένες στα διαγράμματα μετάβασης
κατάστασης για προδιαγραφές εντολών (Jacob, 1986) ή στις τυπικές γραμματικές για
το σχεδιασμό διαλόγου (Browne, 1986). Μια μελέτη εργαλείων για το σχεδιασμό
διεπαφής χρήστη δόθηκε από τον Myers (1989).
Aπό την πλευρά της τεχνολογίας λογισμικού, είναι σημαντικό οι υπεύθυνοι
του έργου να συνειδητοποιήσουν ότι η πρωτοτυποποίηση της διεπαφής χρήστη είναι
ένα ουσιαστικό κομμάτι της διαδικασίας και αντίθετα με την πρωτοτυποποίηση της
λειτουργικότητας του συστήματος, μερικές φορές είναι αποδεκτή η παρουσίαση ενός
πρωτοτύπου διεπαφής ως προδιαγραφή συστήματος. Πράγματι, εξαιτίας της
δυναμικής φύσης των διεπαφών χρήστη, οι προδιαγραφές σε χαρτί δεν είναι αρκετά
καλές για την έκφραση των απαιτήσεων της διεπαφής.

 ΚΥΡΙΑ ΣΗΜΕΙΑ

 Η πρωτοτυποποίηση είναι μια τεχνική για να βοηθήσει στην εδραίωση και

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

81
 Πρωτοτυποποίηση Λογισμικού

 Για κάποιες εφαρμογές ή τμήματα εφαρμογών, όπως η διεπαφή χρήστη, είναι

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

82
ΚΕΦΑΛΑΙΟ 6: ΣΧΕΔΙΑΣΜΟΣ ΚΑΙ ΧΡΟΝΟΠΡΟΓΡΑΜΜΑΤΙΣΜΟΣ
ΤΟΥ ΕΡΓΟΥ

 ΣΚΟΠΟΣ ΤΟΥ ΚΕΦΑΛΑΙΟΥ

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

 ΠΕΡΙΕΧΟΜΕΝΑ

6.1 Ορόσημα στο έργο

6.2 Ανάλυση επιλογών
6.3 Χρονοπρογραμματισμός του έργου

82
 Σχεδιασμός και χρονοπρογραμματισμός του έργου

Η αποτελεσματική διοίκηση ενός έργου λογισμικού στηρίζεται στον λεπτομερή

σχεδιασμό της προόδου του έργου, προβλέποντας προβλήματα που ίσως προκύψουν
και προετοιμάζοντας προκαταβολικά πιθανές λύσεις για τα προβλήματα αυτά. Ένα
σχέδιο, καταρτισμένο στην αρχή του έργου, θα πρέπει να χρησιμοποιείται σαν οδηγός
του έργου. Αυτό το αρχικό σχέδιο δεν είναι στατικό αλλά πρέπει να μεταβάλλεται
καθώς το έργο προοδεύει και γίνονται διαθέσιμες περισσότερες πληροφορίες.
Ο ψευδοκώδικας που φαίνεται στο σχήμα 6.1 είναι μια περιγραφή της
διαδικασίας σχεδιασμού του έργου. Δείχνει ότι ο σχεδιασμός του έργου είναι μια
επαναληπτική διαδικασία που ολοκληρώνεται μόνο αφού το ίδιο το έργο
ολοκληρωθεί.
Η διαδικασία σχεδιασμού ξεκινά με μια εκτίμηση των περιορισμών
(απαιτούμενη ημερομηνία παράδοσης, διαθέσιμο προσωπικό, ολικός
προϋπολογισμός, κλπ.) που επηρεάζουν το έργο. H εκτίμηση αυτή πραγματοποιείται
σε συνδυασμό με παραμέτρους του έργου όπως η δομή, το μέγεθος και οι διαδικασίες
διανομής. Στη συνέχεια ορίζονται τα ορόσημα του έργου και το τί ακριβώς θα
παραδοθεί.
Η διαδικασία στη συνέχεια εισέρχεται σε ένα βρόγχο. Σχεδιάζεται ένα
χρονοδιάγραμμα για το έργο, και οι δραστηριότητες που ορίστηκαν σε αυτό ξεκινούν
ή τους δίνεται προτεραιότητα για να συνεχιστούν. Επειδή οι αρχικές εκτιμήσεις για
τις παραμέτρους του έργου αποτελούν προβλέψεις, το σχέδιο χρειάζεται πάντα
αλλαγές.
Καθώς γίνονται διαθέσιμες περισσότερες πληροφορίες, ο διοικητής του έργου
επιθεωρεί τις υποθέσεις για το έργο και προσδιορίζει πώς αυτές το επηρεάζουν. Αν η
επιρροή τους είναι να καθυστερήσουν το έργο, ίσως χρειαστεί να
επαναδιαπραγματευτούν οι περιορισμοί και οι όροι που διέπουν το τί θα παραδοθεί με
τον πελάτη. Αν αυτή η επαναδιαπραγμάτευση είναι ανεπιτυχής και δεν επιτρέψει να
τηρηθεί το χρονοδιάγραμμα, ίσως είναι αναγκαίο να ξεκινήσει μια τεχνική
επιθεώρηση του έργου. Σκοπός της επιθεώρησης αυτής είναι να καθορίσει αν είναι
βιώσιμη κάποια εναλλακτική προσέγγιση που συμφωνεί με τους περιορισμούς και
ικανοποιεί το χρονοδιάγραμμα.
Φυσικά, ο σοφός διοικητής του έργου δεν υποθέτει ότι όλα θα πάνε καλά.
Προβλήματα κάποιας μορφής προκύπτουν σχεδόν πάντα κατά τη διάρκεια ενός έργου
και οι αρχικές υποθέσεις και ο χρονοπρογραμματισμός θα πρέπει να είναι
συντηρητικά. Θα πρέπει να προβλέπονται αρκετά απρόοπτα από το σχεδιασμό ώστε
να μη χρειάζεται να επαναδιαπραγματεύονται οι περιορισμοί και τα ορόσημα του
έργου σε κάθε επανάληψη του σχεδιαστικού βρόγχου.
Το σχέδιο της ανάπτυξης του λογισμικού είναι μόνο ένα από τα σχέδια που
πρέπει να γίνουν για ένα έργο. Άλλα σχέδια που ίσως χρειάζονται είναι:
 Ένα σχέδιο ελέγχου (testing plan)
 Ένα σχέδιο διοίκησης των συστατικών (configuration management)
 Ένα σχέδιο ανάπτυξης και εκπαίδευσης προσωπικού.
 Ένα σχέδιο συντήρησης

83
 Σχεδιασμός και χρονοπρογραμματισμός του έργου

Ορισμός των περιορισμών κάτω από τους οποίους πρέπει να πραγματοποιηθεί το έργο
Πραγματοποίηση αρχικών υποθέσεων για τις παραμέτρους του έργου
Ορισμός των ορόσημων του έργου και των παραδοτέων
While το έργο δεν έχει ολοκληρωθεί ή ακυρωθεί loop
Σχεδιασμός του χρονοδιαγράμματος του έργου
Εκκίνηση δραστηριοτήτων με βάση το χρονοδιάγραμμα
Καθυστέρηση (μικρή)
Επιθεώρηση της προόδου του έργου
Αναθεώρηση των εκτιμήσεων για τις παραμέτρους του έργου
Εφαρμογή των αναθεωρήσεων στο χρονοδιάγραμμα του έργου
Επαναδιαπραγμάτευση των περιορισμών του έργου και των παραδοτέων
If (ανακύπτουν προβλήματα) then
Εκκίνηση τεχνικής επιθεώρησης και πραγματοποίηση πιθανών αναθεωρήσεων
end if
end loop

Σχήμα 6.1 Η διαδικασία σχεδιασμού του έργου

Η εξασφάλιση της επικύρωσης, η διοίκηση της διαμόρφωσης και η

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

6.1 Ορόσημα του έργου

Η αποτελεσματική διοίκηση στηρίζεται στην πληροφορία. Επειδή το λογισμικό δεν

είναι κάτι χειροπιαστό, η πληροφορία αυτή μπορεί να παρέχεται μόνο από έγγραφα
τα οποία περιγράφουν τις εργασίες που έχουν έρθει εις πέρας. Δίχως αυτή την
πληροφορία χάνεται ο έλεγχος του έργου και δεν μπορούν να ενημερωθούν οι
εκτιμήσεις του κόστους και τα χρονοδιαγράμματα.
Όταν σχεδιάζεται ένα έργο, θα πρέπει να εγκαθίστανται μια σειρά από
ορόσημα, όπου ορόσημο είναι ένα τελικό σημείο μιας δραστηριότητας της
διαδικασίας ανάπτυξης λογισμικού. Σε κάθε ορόσημο, θα πρέπει να παρουσιάζεται
στη διοίκηση μια τυπική αναφορά της προόδου του έργου. Απροσδιόριστα ορόσημα,
που είναι αδύνατο να αποφασιστεί ομόφωνα αν επιτεύχθηκαν, είναι άχρηστα για τη
διοίκηση του έργου.
Ένα καλό ορόσημο χαρακτηρίζεται από έτοιμη τεκμηρίωση, για παράδειγμα:
«Πλήρης σχεδίαση υψηλού επιπέδου» ή «Σχηματισμένο σχέδιο ελέγχου». Τα
ορόσημα δεν θα πρέπει να είναι απροσδιόριστα. Ένα φτωχό ορόσημο, για
παράδειγμα, είναι το «Κώδικας πλήρης κατά 80%». Δεν υπάρχει αντικειμενικός
τρόπος για να πει κανείς ότι το 80% του κώδικα ολοκληρώθηκε.
Για να οριστούν ορόσημα, η διαδικασία ανάπτυξης λογισμικού που
ακολουθείται για κάποιο συγκεκριμένο έργο, θα πρέπει να χωριστεί σε

84
 Σχεδιασμός και χρονοπρογραμματισμός του έργου

δραστηριότητες κατάλληλου μεγέθους και κάθε μια από αυτές τις δραστηριότητες να
συσχετιστεί με ένα ορόσημο. Για παράδειγμα, το σχήμα 6.2 δείχνει δραστηριότητες
που εμπλέκονται στον προσδιορισμό των απαιτήσεων του συστήματος, όταν ως μέσο
για την ανάλυση των απαιτήσεων χρησιμοποιείται η πρωτοτυποποίηση. Στο σχήμα
φαίνονται τα κύρια ορόσημα κάθε δραστηριότητας. Μπορούν επίσης να οριστούν
βοηθητικά ορόσημα για κάθε ένα από αυτά, ανάλογα με το μέγεθος του έργου.
Δεν χρειάζεται να ορισθούν ορόσημα για κάθε δραστηριότητα του έργου.
Ένας προσεγγιστικός κανόνας είναι ότι τα ορόσημα θα πρέπει να προγραμματίζονται
σε διαστήματα δύο ή τριών εβδομάδων, αν και στην πράξη μπορεί να υπάρξουν
διαφορές έως και 100%, ανάλογα με τη διαδικασία ανάπτυξης λογισμικού που
ακολουθείται.
Ένας καλός λόγος για την ευρεία αποδοχή του μοντέλου του καταρράκτη
στην ανάπτυξη λογισμικού είναι ότι επιτρέπει τον άμεσο ορισμό ορόσημων κατά τη
διάρκεια του έργου. Εναλλακτικές προσεγγίσεις, όπως ο εξερευνητικός
προγραμματισμός, είναι τέτοιες, ώστε ο ορισμός ορόσημων να είναι μια πιο δύσκολη
και λιγότερο αξιόπιστη διαδικασία. Κατά συνέπεια, παρ’ όλες τις γνωστές του
αδυναμίες, κάποια παραλλαγή του μοντέλου του καταρράκτη θα συνεχίσει
πιθανότατα να είναι το διαδικαστικό μοντέλο για μεγάλα έργα λογισμικού.

Δραστηριότητες

Μελέτη Σκιαγράφηση Ανάπτυξη Μελέτη Προσδιορισμός

σκοπιμότητας απαιτήσεων πρωτοτύπου σχεδιασμού απαιτήσεων

Αναφορά Αναφορά
εκτίμησης Σκιαγράφηση
σκοπιμότητας Ορισμός Προσδιορισμός
πρωτοτύπου αρχιτεκτονικού
(Feasibility απαιτήσεων (Prototype απαιτήσεων
σχεδιασμού
Report) evaluation report)

Σχήμα 6.2 Ορόσημα προσδιορισμού απαιτήσεων

6.2 Ανάλυση επιλογών

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

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

85
 Σχεδιασμός και χρονοπρογραμματισμός του έργου

Το πρώτο στάδιο της διαδικασίας σχεδιασμού θα πρέπει να είναι ο ορισμός

γενικών στόχων για τον οργανισμό και ειδικών στόχων για το έργο. Οι ειδικοί για το
έργο στόχοι θα πρέπει να είναι υψηλή ικανότητα συντήρησης, μικρό κόστος, υψηλή
αξιοπιστία, κλπ. Στόχοι του οργανισμού μπορούν να είναι η παραγωγή
επαναχρησιμοποιήσιμων συστατικών, η ανάπτυξη και υποστήριξη συγκεκριμένων
περιοχών ειδίκευσης (γιατί αυτές ίσως οδηγήσουν σε μελλοντικά συμβόλαια), και η
προώθηση της καριέρας συγκεκριμένων μελών του προσωπικού.
Συνήθως μπορεί να γίνει ένα σύνολο επιλογών που μερικώς ή συνολικά
επιτυγχάνει τους στόχους του έργου. Οι διαφορετικές επιλογές που έχει στη διάθεση
του ο διοικητής του έργου μπορούν να βαθμολογηθούν με βάση τους στόχους του
έργου. Αυτή η βαθμολόγηση είναι περισσότερο σχετική παρά απόλυτη. Οι επιλογές
βαθμολογούνται συγκριτικά με μια ιδεατή «καλύτερη» επιλογή. Το βαθμολογικό
σύστημα θα πρέπει να λαμβάνει υπ’ όψη του και τη βαρύτητα των στόχων του έργου.
Η βαρύτητα μπορεί να είναι είτε θετική είτε αρνητική έτσι ώστε να αυξάνεται ή να
μειώνεται το κόστος ή τα οφέλη από μια συγκεκριμένη επιλογή. Για παράδειγμα, η
υψηλή αξιοπιστία πρέπει να είναι απώτερος στόχος και να επιτυγχάνεται ανεξάρτητα
από τους άλλους στόχους. Για αυτό θα πρέπει να της δίνεται μεγαλύτερη βαρύτητα
απ’ ότι στην εκπαίδευση του προσωπικού, για παράδειγμα.
Υποθέστε ότι υπάρχουν τρεις εναλλακτικές προσεγγίσεις στην ανάπτυξη ενός
προϊόντος. Οι στόχοι και η βαθμολόγηση κάθε επιλογής φαίνονται στο σχήμα 6.3. Για
απλότητα, η βαρύτητα των στόχων δεν έχει συμπεριληφθεί. Μερικοί από τους
βαθμούς έχουν εκφρασθεί ως ποσοστά. Για παράδειγμα, η επαναχρησιμοποίηση είναι
το ποσοστό των συστατικών του συστήματος που πιθανώς να ξαναχρησιμοποιηθούν
και η αποδοτικότητα έχει εκφρασθεί σαν ποσοστό της πιο αποδοτικής επιλογής. Οι
υπόλοιπες βαθμολογίες είναι απόλυτες, όπως το κόστος και η αξιοπιστία που
μπορούν να ποσοτικοποιηθούν σαν ποσοστό εμφανίσεων αποτυχίας του συστήματος.

Επιλογή Κόστος Διάρκεια Αξιοπιστία Επαναχρησιμοποίηση Μεταφερσιμότητα Αποδοτικότητα

εκατ. (μήνες) (%) (%)
δρχ.
Α 1.2 33 5 40 90 0.35
Β 0.8 30 9 40 75 0.75
Γ 1.75 36 13 30 30 1
Σχήμα 6.3 Διάφορες επιλογές για το έργο

Τίθεται λοιπόν το ερώτημα πώς, δεδομένης αυτής της ανάλυσης, ο διοικητής

του έργου μπορεί να αποφασίσει για το ποια επιλογή θα πρέπει να ακολουθηθεί. Μια
πιθανή προσέγγιση είναι η χρησιμοποίηση πολικών γράφων, που προκύπτουν από
τεχνικές που χρησιμοποιούνται στην εκτίμηση των επιδόσεων ηλεκτρονικών
υπολογιστών (Ferrari, 1978). Ο Bohem (1981) δείχνει πως μπορούν επίσης να
χρησιμοποιηθούν για να γίνουν συγκρίσεις μεταξύ πολλαπλών μεταβλητών και να
εκτιμηθούν οι επιλογές έργων ανάπτυξης λογισμικού.
Ένας πολικός γράφος είναι ένας γράφος με έναν αριθμό ακτινικών αξόνων.
Κάθε άξονας αντιστοιχεί σε κάποιον από τους στόχους που πρόκειται να επιτευχθούν.
Οι συγκεκριμένες επιλογές παρασταίνονται γραφικά στον κατάλληλο άξονα. Η
επιλογή που προσφέρει την καλύτερη συνολική ανταπόδοση είναι εκείνη που
περικλείει το χωρίο με το μεγαλύτερο εμβαδόν. Ο πολικός γράφος για τις επιλογές
του σχήματος 6.3 φαίνεται στο σχήμα 6.4.
Τα περισσότερο επιθυμητά επιτεύγματα θα πρέπει να σημειώνονται στα άκρα
των αντίστοιχων αξόνων και τα λιγότερα επιθυμητά στις αρχές τους. Για παράδειγμα,

86
 Σχεδιασμός και χρονοπρογραμματισμός του έργου

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

Υπόμνημα:
Επιλογή Α

Επιλογή Β

Επιλογή Γ

Διάρκεια
Αξιοπιστία

Επαναχρησιμοποίηση
Κόστος

Μεταφερσιμότητα Αποδοτικότητα

Σχήμα 6.4 Πολικός γράφος για τις επιλογές του έργου

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

87
 Σχεδιασμός και χρονοπρογραμματισμός του έργου

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

Επιλογή Μέγιστο κόστος Ελάχιστο κόστος Ανταπόδοση

(δρχ.) (δρχ.) (δρχ.)
Α 100.000 40.000 60.000
Β 70.000 55.000 15.000
Σχήμα 6.5 Κόστος Επιλογών

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

διευθύνων του έργου; Ξεκάθαρα, αν όλα πάνε καλά, η επιλογή Α οδηγεί στο
μικρότερο κόστος έργου, αλλά αν δεν πάνε όλα καλά είναι η πιο ακριβή επιλογή που
μπορεί να επιλέξει κανείς.
Η στρατηγική μέγιστου-ελάχιστου είναι μια συντηρητική στρατηγική που
στοχεύει στην ελαχιστοποίηση των εξόδων. Υποτίθεται ότι το μέγιστο παρά το
ελάχιστο κόστος έργου είναι πιο πιθανό, οπότε η ανταπόδοση θα είναι αρνητική.
Επιλέγεται το έργο με την ελάχιστη ανταπόδοση. Στο παραπάνω παράδειγμα, το
ελάχιστο κόστος είναι 15.000 δολάρια, άρα θα πρέπει να προτιμηθεί η επιλογή Β.
Μια εναλλακτική στρατηγική είναι μια αισιόδοξη στρατηγική (μέγιστου-μέγιστου) που
προτιμά την επιλογή που προσφέρει το μεγαλύτερο κέρδος (θετική ανταπόδοση). Η
στρατηγική μέγιστου-μέγιστου υποθέτει ότι το κόστος του έργου είναι πιθανότερο να
είναι το ελάχιστο. Στο παράδειγμα, η στρατηγική μέγιστου-μέγιστου θα έκανε την
επιλογή Α.
Καμία από αυτές τις στρατηγικές δε λαμβάνει υπ’ όψη της τη σχετική
σημασία των κερδών ή των εξόδων. Έτσι, αν τα πιθανά κέρδη της επιλογής Α ήταν
ανεπαίσθητα μεγαλύτερα από τα κέρδη της επιλογής Β αλλά τα έξοδα ήταν, ας πούμε,
δέκα φορές μεγαλύτερα, η στρατηγική μέγιστου-μέγιστου θα έκανε την επιλογή Α
εκεί όπου βέβαια η πλειοψηφία των διοικητών θα προτιμούσε την ασφαλέστερη
εναλλακτική επιλογή.
Οι προσεγγίσεις αυτές δε λαμβάνουν υπ’ όψη τους το ρίσκο, που μπορεί να
εκφραστεί σαν τη πιθανότητα ότι δεν θα γίνει υπέρβαση του υπολογισμένου κόστους.
Το άθροισμα των πιθανοτήτων κάθε πιθανής έκβασης θα πρέπει να είναι 1. Σε
περιπτώσεις πλήρους αβεβαιότητας, η πιθανότητα κάθε έκβασης είναι ίδια. Σε
περιπτώσεις όπου έχουμε να προτιμήσουμε μεταξύ δύο επιλογών, όπως στο σχήμα
6.5, η πιθανότητα που σχετίζεται με κάθε πιθανή κατάσταση θα πρέπει να είναι 0.5.
Αν κάθε έκβαση στο σχήμα 6.5 είναι ισοπίθανη, το πιθανό κόστος κάθε
επιλογής μπορεί να υπολογιστεί ως εξής:

Επιλογή Α: Πιθανό κόστος = (0,5 x $100.000) + (0,5 x $40.000) =

$70.000
Επιλογή Β: Πιθανό κόστος = (0,5 x $70.000) + (0,5 x $55.000) =
$62.500

Με βάση αυτά τα νούμερα, η επιλογή Β θα πρέπει να προτιμηθεί σαν η πιο

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

88
 Σχεδιασμός και χρονοπρογραμματισμός του έργου

να ανατεθούν σχετικές υποκειμενικές εκτιμήσεις σε κάθε πιθανή έκβαση και να

χρησιμοποιηθούν οι εκτιμήσεις αυτές στην ανάλυση επιλογών.
Για παράδειγμα, ας υποθέσουμε ότι η εκτίμηση της πιθανότητας να επιτύχει η
επιλογή Α το ελάχιστος κόστος είναι 65% και της πιθανότητας να φτάσει το μέγιστο
κόστος είναι 35%. Για την επιλογή Β, οι αντίστοιχες εκτιμήσεις είναι 70% και 35%.
Ξανακάνοντας τον υπολογισμό φαίνεται ότι η επιλογή Β θα πρέπει και πάλι να
προτιμηθεί σαν η καλύτερη επιλογή.

Επιλογή Α: Πιθανό κόστος = (0,65 x $40.000) + (0,35 x $100.000)

= $61.000
Επιλογή Β: Πιθανό κόστος = (0,7 x $55.000) + (0,3 x $70.000) =
= $59.500

Φυσικά, αυτή η απλουστευμένη ανάλυση είναι περισσότερο ένας οδηγός παρά

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

6.3 Χρονοπρογραμματισμός του έργου

Ο χρονοπρογραμματισμός του έργου είναι ένα από τα δυσκολότερα καθήκοντα της

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

89
 Σχεδιασμός και χρονοπρογραμματισμός του έργου

απρόβλεπτων προβλημάτων. Επομένως τα χρονοδιαγράμματα πρέπει να

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

6.4 Ραβδογράμματα και δίκτυα δραστηριοτήτων

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

90
 Σχεδιασμός και χρονοπρογραμματισμός του έργου

Σαν εξήγηση αυτών των συμβολισμών, θεωρείστε το σύνολο των

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

Εργασία Διάρκεια (μέρες) Εξαρτήσεις

Τ1 8
Τ2 15
Τ3 15 Τ1
Τ4 10
15 10 Τ2,Τ4
Τ6 5 Τ1,Τ2
Τ7 20 Τ1
Τ8 25 Τ4
Τ9 15 Τ3,Τ6
Τ10 15 Τ5,Τ7
Τ11 7 Τ9
Τ12 10 Τ11

Σχήμα 6.6 Διάρκεια εργασιών και εξαρτήσεις

Από το σχήμα 6.6 μπορούμε να δούμε ότι η εργασία Τ3 εξαρτάται από την
εργασία Τ1. Αυτό σημαίνει ότι η εργασία Τ1 πρέπει να ολοκληρωθεί πριν ξεκινήσει η
Τ3. Για παράδειγμα, Τ1 ίσως είναι η προετοιμασία της σχεδίασης λογισμικού και Τ3
η υλοποίηση αυτού του σχεδιασμού. Πριν αρχίσει η υλοποίηση, πρέπει να έχει
ολοκληρωθεί ο σχεδιασμός.
Φυσικά στην πράξη οι χρόνοι που υπολογίστηκαν για τη διάρκεια των
εργασιών του σχήματος 6.6 θα περιλαμβάνουν κάποια απρόοπτα για να
αντισταθμίσουν απρόβλεπτες καθυστερήσεις. Η συνεκτίμηση λαθών και απρόσμενων
καθυστερήσεων είναι ένα ζωτικό γεγονός για τη διοίκηση έργων και θα πρέπει πάντα
να θεωρούνται αποδεκτές παραλείψεις για εκτιμήσεις της διάρκειας του έργου.
Δεδομένων των εξαρτήσεων και της εκτιμούμενης διάρκειας των εργασιών,
μπορούν να παραχθούν διάφορες γραφικές αναπαραστάσεις του χρονοδιαγράμματος
του έργου. Ένα παράδειγμα είναι ένα δίκτυο δραστηριοτήτων που δείχνει τις
εξαρτήσεις των εργασιών (Σχήμα 6.7). Δείχνει ποιες δραστηριότητες μπορούν να
πραγματοποιηθούν παράλληλα και ποιες πρέπει να εκτελεσθούν σειριακά εξαιτίας
κάποιας εξάρτησης με προηγούμενη δραστηριότητα.

91
 Σχεδιασμός και χρονοπρογραμματισμός του έργου

14/7/88 15 μέρες 15 μέρες

Μ1 Τ3 Τ9
8 μέρες
4/8/88
Τ1
5 μέρες 25/8/88
Μ4
25/7/88
Τ6 Μ6

4/7/88 Μ3
7 μέρες
20 μέρες
Εκκίνηση Τ11
15 μέρες Τ7

Τ2 5/9/88
11/8/88
Μ8
Μ7
25/7/88

Μ2 10 μέρες 15 μέρες 10 μέρες

Τ5 Τ10 Τ12

10 μέρες
18/7/88 25 μέρες 19/9/88

Τ4 Μ5 Τ8 Λήξη

Σχήμα 6.7 Δίκτυο δραστηριοτήτων

Η υποδιαίρεση εργασιών σε μονάδες διάρκειας μικρότερης της μιας ή δύο

εβδομάδων δεν είναι χρήσιμη. Περαιτέρω υποδιαίρεση σημαίνει ότι θα πρέπει να
δαπανηθεί ένα δυσανάλογο ποσό χρόνου για την αναθεώρηση των εκτιμήσεων και
των διαγραμμάτων. Είναι χρήσιμο επίσης να τεθεί ένα μέγιστο ποσό χρόνου για κάθε
εργασία που να μην υπερβαίνει τις 10-12 εβδομάδες.
Οι τετράγωνοι κόμβοι του σχήματος 6.7 αναπαριστούν εργασίες που η
διάρκεια τους φαίνεται πάνω από τον αντίστοιχο κόμβο. Οι στρογγυλεμένοι κόμβοι
αναπαριστούν ολοκλήρωση δραστηριοτήτων ή ορόσημα του έργου. Αυτά
υποσημειώνονται με την αναμενόμενη ημερομηνία ολοκλήρωσης των
δραστηριοτήτων από τις οποίες εξαρτώνται.
Πριν το έργο προχωρήσει από ένα ορόσημο προς ένα άλλο, όλα τα
«μονοπάτια» που οδηγούν σε αυτό πρέπει να έχουν ολοκληρωθεί. Για παράδειγμα η
εργασία Τ9, στο σχήμα 6.7, δε μπορεί να προχωρήσει πριν ολοκληρωθούν οι εργασίες
Τ3 και Τ6 και επιτευχθεί το ορόσημο Μ4.
Η διάρκεια ενός έργου μπορεί να υπολογιστεί λαμβάνοντας υπ’ όψη το
μεγαλύτερο μονοπάτι στο γράφημα (ή δίκτυο) δραστηριοτήτων (κρίσιμο μονοπάτι).
Στο σχήμα 6.7 το κρίσιμο μονοπάτι αναπαρίσταται με σκιασμένους κόμβους. Το
κρίσιμο μονοπάτι είναι η σειρά των δραστηριοτήτων από την οποία εξαρτάται όλο το
χρονοδιάγραμμα του έργου. Κάθε καθυστέρηση στην ολοκλήρωση οποιασδήποτε
από τις κρίσιμες δραστηριότητες προκαλεί ανάλογη καθυστέρηση στο έργο. Παρ’ όλα
αυτά καθυστερήσεις σε δραστηριότητες που δε βρίσκονται στο κρίσιμο μονοπάτι δεν
προκαλούν κατ’ ανάγκη συνολική καθυστέρηση. Για παράδειγμα, καθυστέρηση της
εργασίας Τ8 στο σχήμα 6.7 πιθανότατα δε θα είχε κανένα αντίκτυπο στην ημερομηνία
ολοκλήρωσης του έργου. Από το ραβδόγραμμα που φαίνεται στο σχήμα 6.8,
μπορούμε να δούμε ότι η εργασία Τ8 μπορεί να καθυστερήσει έως και 4 εβδομάδες
δίχως να επηρεάσει το χρονοδιάγραμμα.

92
 Σχεδιασμός και χρονοπρογραμματισμός του έργου

4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

Εκκίνηση

T4
T1
T2
M1

T7
T3
T8
M3

M2

T6
T5
M4

T9
M7

T10
M6

T11
M8

T12

Τέλος

Σχήμα 6.8 Ραβδόγραμμα δραστηριοτήτων

Τα διαγράμματα PERT είναι μια πιο εκλεπτυσμένη μορφή γραφημάτων

δραστηριοτήτων όπου, αντί να γίνεται μια μόνο εκτίμηση για τη διάρκεια μιας
εργασίας γίνονται απαισιόδοξες, πιθανώς, και αισιόδοξες εκτιμήσεις. Επομένως δεν
υφίσταται μόνο ένα αλλά πολλά δυνατά κρίσιμα μονοπάτια, που εξαρτώνται από τις
μεταθέσεις των εκτιμήσεων για κάθε εργασία. Το γεγονός αυτό καθιστά την ανάλυση
του κρίσιμου μονοπατιού ιδιαίτερα πολύπλοκη έτσι ώστε να πρέπει να γίνει
αυτόματα.
Εκτός από τη χρησιμοποίηση γραφημάτων δραστηριοτήτων για εκτιμήσεις, η
διοίκηση θα πρέπει να χρησιμοποιεί αυτά τα διαγράμματα και όταν αναθέτει εργασίες
για το έργο. Τα γραφήματα αυτά μπορούν συχνά να παρέχουν γνώσεις για τις
εξαρτήσεις των εργασιών που δεν είναι διαισθητικά προφανείς. Σε μερικές
περιπτώσεις, ίσως είναι δυνατό να μεταβληθεί η σχεδίαση του συστήματος, ώστε να
μειωθεί το «μήκος» του κρίσιμου μονοπατιού. Η χρονική διάρκεια του έργου μπορεί
τότε να μειωθεί εξαιτίας της λιγότερης ποσότητας χρόνου που σπαταλάται
περιμένοντας εργασίες να ολοκληρωθούν.
Με την ευρεία χρήση των προσωπικών υπολογιστών, είναι συνήθης πρακτική
να χρησιμοποιούνται εργαλεία για την αυτόματη παραγωγή και συντήρηση δικτύων
δραστηριοτήτων. Το σχήμα 6.7 παράχθηκε με ένα εργαλείο διοίκησης έργων (project
management tool) και, δοθείσης μιας αρχικής ημερομηνίας και της διάρκειας των
εργασιών, οι ημερομηνίες ολοκλήρωσης όλων των εργασιών υπολογίστηκαν

93
 Σχεδιασμός και χρονοπρογραμματισμός του έργου

αυτόματα. Επιπρόσθετα, άλλες αναπαραστάσεις του χρονοδιαγράμματος μπορούν να

υπολογιστούν με ελάχιστη προσπάθεια.
Το σχήμα 6.8 δείχνει ένα ραβδόγραμμα (ή Gantt διάγραμμα) που επιδεικνύει
το «ημερολόγιο» ενός έργου και το πως διάφορες εργασίες ξεκινούν και
ολοκληρώνονται σε διάφορες ημερομηνίες.
Μερικές από τις εργασίες στο σχήμα 6.8 ακολουθούνται από μια σκιασμένη
ράβδο. Αυτό υποδεικνύει ότι υπάρχει κάποια ελαστικότητα στην ημερομηνία
ολοκλήρωσης αυτών των εργασιών. Αν μια εργασία δεν ολοκληρωθεί εγκαίρως, το
κρίσιμο μονοπάτι δεν θα επηρεαστεί μέχρι το τέλος της περιόδου που σημαδεύεται
από τη σκιασμένη ράβδο. Οι εργασίες που βρίσκονται στο κρίσιμο μονοπάτι δεν
έχουν περιθώρια λάθους.
Εκτός από τα χρονοδιαγράμματα, οι διοικητές έργων πρέπει να λαμβάνουν
υπ’ όψη τους την ανάθεση πόρων, και συγκεκριμένα, την κατανομή προσωπικού στις
διάφορες εργασίες. Το σχήμα 6.9 προτείνει μια κατανομή των προγραμματιστών στις
εργασίες που παρουσιάζονται στο σχήμα 6.7.
Η κατανομή εργασιών μπορεί επίσης να υποστεί επεξεργασία από εργαλεία
υποστήριξης διοίκησης έργων και να παραχθεί έτσι ένα ραβδόγραμμα που δείχνει τις
χρονικές περιόδους κατά τις οποίες το προσωπικό εργάζεται στο έργο. (Σχήμα 6.10)
Δεν χρειάζεται όλο το προσωπικό να απασχολείται στο έργο καθ’ όλη τη
διάρκεια του. Κατά τη διάρκεια μεσολαβούντων περιόδων μέλη της ομάδας
ανάπτυξης μπορεί να βρίσκονται σε διακοπές, να εργάζονται σε άλλα έργα, να
παρακολουθούν εκπαιδευτικά σεμινάρια ή να εμπλέκονται σε άλλες δραστηριότητες.
Οι μεγάλοι οργανισμοί συνήθως προσλαμβάνουν έναν αριθμό ειδικών και
αυτοί οι ειδικοί εργάζονται στο έργο όπως απαιτείται. Αυτό μπορεί να προκαλέσει
προβλήματα στο χρονοδιάγραμμα. Αν ένα έργο καθυστερήσει όσο ένας ειδικός
εργάζεται σε αυτό, μπορεί να υπάρξει ένα διαδιδόμενο αποτέλεσμα και να
καθυστερήσουν και άλλα έργα επειδή ο ειδικός δεν είναι διαθέσιμος.

Εργασία Προγραμματιστής
Τ1 Γιάννα
Τ2 Άννα
Τ3 Γιάννα
Τ4 Κώστας
Τ5 Μαρία
Τ6 Άννα
Τ7 Δημήτρης
Τ8 Κώστας
Τ9 Γιάννα
Τ10 Άννα
Τ11 Κώστας
Τ12 Κώστας
Σχήμα 6.9 Κατανομή προσωπικού

Αναπόφευκτα, τα αρχικά χρονοδιαγράμματα μπορεί να είναι λανθασμένα και,

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

94
 Σχεδιασμός και χρονοπρογραμματισμός του έργου

το γράφημα δραστηριοτήτων και πιθανώς να ξανατμηματοποιηθούν μεταγενέστερες

εργασίες με στόχο να μειωθεί το μήκος του κρίσιμου μονοπατιού.

4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

Κώστας Τ4
T8

T11
T12
Γιάννα Τ1
T3
T9

Άννα Τ2
T6

Τ10

Δημήτρης Τ7

Μαρία Τ5

Σχήμα 6.10 Κατανομή Προσωπικού

95
 Σχεδιασμός και χρονοπρογραμματισμός του έργου

 ΚΥΡΙΑ ΣΗΜΕΙΑ

 Η αποτελεσματική διοίκηση ενός έργου λογισμικού βασίζεται σε καλό σχεδιασμό

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

 ΑΝΑΦΟΡΕΣ

Software Engineering Econmics. Πρόκειται για ένα καλό γενικό κείμενο πάνω στη
διοίκηση επιχειρίσεων, το οποίο περιέχει θαυμάσια κεφάλαια σχετκά με την ανάλυση
ρίσκων. (Β.W. Boehm, 1981, Prenice-Hall.)

Software Engineering Concepts. Ένα γενικό κείμενο για τεχνολογία λογισμικού το

οποίο περιέχει ένα ιδιαίτερα καλό κεφάλαιο πάνω στον σχεδιασμό έργων. (R.E.
Fairley, 1985, McGraw Hill.)

Managing the Software Process. To κεφάλαιο 6 αυτού του βιβλίου αποτελεί μία καλή
περιγραφή του σχεδιασμού έργων γενικότερα, αν και δεν είναι ιδιαίτερα λεπτομερές.
(W.S. Humphries, 1989, Addison-Wesley.)

96
 ΚΕΦΑΛΑΙΟ 7: ΔΙΟΙΚΗΣΗ ΕΡΓΩΝ ΛΟΓΙΣΜΙΚΟΥ

 ΣΚΟΠΟΣ ΤΟΥ ΚΕΦΑΛΑΙΟΥ

Οι στόχοι αυτού του κεφαλαίου είναι να παρουσιαστούν οι εργασίες που

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

 ΠΕΡΙΕΧΟΜΕΝΑ

7.1 Διοικητικές δραστηριότητες

7.2 Διοικητικές δομές λογισμικού
7.3 Προγραμματιστική παραγωγικότητα

97
 Διοίκηση έργων λογισμικού

Η αποτυχία πολλών μεγάλων έργων λογισμικού τη δεκαετία του 60 και τα πρώτα

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

1. Το προϊόν δεν είναι χειροπιαστό. Ο υπεύθυνος ενός ναυπηγικού έργου ή ένας

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

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

98
 Διοίκηση έργων λογισμικού

7.1 ΔΙΟΙΚΗΤΙΚΕΣ ΔΡΑΣΤΗΡΙΟΤΗΤΕΣ

Είναι αδύνατον να γραφτεί μια σταθερή περιγραφή των εργασιών ενός

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

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

Το πρώτο στάδιο ενός έργου λογισμικού μπορεί να αφορά τη σύνταξη μιας

προσφοράς για την ανάληψη του έργου. Αυτό γίνεται:
 είτε το έργο αναπτύσσεται κατ’ εντολή κάποιου πελάτη,
 είτε καθορίζεται από κάποιο άλλο τμήμα του οργανισμού,
 είτε αποτελεί εσωτερική δραστηριότητα
Η προσφορά εκθέτει ένα περίγραμμα της δουλειάς του έργου, εκτιμήσεις για το
κόστος και το χρονοδιάγραμμα, και μια δικαιολόγηση του γιατί το συμβόλαιο του
έργου θα πρέπει να κατακυρωθεί στο συγκεκριμένο οργανισμό ή ομάδα.
Η σύνταξη προσφορών είναι ένα κρίσιμο θέμα αφού η ευημερία πολλών
μεγάλων οργανισμών παραγωγής λογισμικού βασίζεται στην ύπαρξη ικανού αριθμού
αποδεκτών προσφορών και επικυρωμένων συμβολαίων. Δεν μπορούν να υπάρξουν
γενικές οδηγίες για το θέμα αυτό, καθώς η ικανότητα σύνταξης προσφορών
αποκτάται με την εμπειρία. Αποτελεί άλλωστε μέρος ολόκληρης της δραστηριότητας
προβολής της επιχείρησης και είναι έξω από τους σκοπούς αυτού του βιβλίου. Ο
Aron (1983) περιλαμβάνει μια πραγματεία στη σύνταξη αναφορών που συνιστάται
στους ενδιαφερόμενους αναγνώστες.
Ο σχεδιασμός και ο χρονοπρογραμματισμός ενός έργου είναι οι κύριες
δραστηριότητες (δραστηριότητες-κλειδιά) για τη διοίκησή του και καλύπτονται σε
επόμενα κεφάλαια.
Η παρακολούθηση ενός έργου είναι μια συνεχής δραστηριότητα. Ο υπεύθυνος
πρέπει να παρακολουθεί την πρόοδο του έργου και να συγκρίνει πραγματική και
προγραμματισμένη εξέλιξη και κόστος. Παρ’ όλο που οι περισσότεροι οργανισμοί
διαθέτουν τυπικούς μηχανισμούς παρακολούθησης, ένας ικανός υπεύθυνος μπορεί
συχνά να σχηματίσει μια καθαρή εικόνα του τι συμβαίνει με μια άτυπη συζήτηση με
προσωπικό του έργου.
Δραστηριότητες άτυπης παρακολούθησης μπορούν συχνά να
χρησιμοποιηθούν για να προβλέψουν ενδεχόμενα προβλήματα αφού μπορούν να
αποκαλύψουν δυσκολίες καθώς εκείνες συμβαίνουν. Για παράδειγμα, καθημερινές
συζητήσεις με μέλη του προσωπικού μπορούν να αποκαλύψουν ένα συγκεκριμένο
πρόβλημα στον εντοπισμό κάποιου ελαττώματος στο λογισμικό. Από το να περιμένει
ο υπεύθυνος λογισμικού ώσπου να αναφερθεί μια παρέκκλιση από το
χρονοδιάγραμμα, μπορεί να αναθέσει σε κάποιον ειδικό το πρόβλημα ή μπορεί να
αποφασίσει ότι θα πρέπει να γίνει διαφορετικός προγραμματισμός παρακάμπτοντας
το τμήμα του κώδικα που παρουσιάζει το πρόβλημα.

99
 Διοίκηση έργων λογισμικού

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

1. Ο ολικός προϋπολογισμός μπορεί να αποκλείει τη χρήση υψηλόμισθου

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

Ο υπεύθυνος λογισμικού κατά την επιλογή προσωπικού για το έργο πρέπει να

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

100
 Διοίκηση έργων λογισμικού

7.2 ΔΙΟΙΚΗΤΙΚΕΣ ΔΟΜΕΣ ΕΡΓΩΝ ΛΟΓΙΣΜΙΚΟΥ

Η παραδοσιακή διοικητική οργάνωση είναι ιεραρχική με τα άτομα σε κάθε

επίπεδο της ιεραρχίας να αναφέρονται στο επόμενο επίπεδο. Τυπικά, ένας διοικητής
μπορεί να είναι υπεύθυνος για 12-15 υπαλλήλους. Οι διοικητικές δομές έργων
λογισμικού είναι επίσης ιεραρχικές αλλά οι υπεύθυνοι λογισμικού θα πρέπει να
χειρίζονται λιγότερους υπαλλήλους λόγω της πολυπλοκότητας των έργων
λογισμικού.
Η διοικητική δομή ενός μεγάλου οργανισμού ο οποίος αναλαμβάνει
ταυτόχρονα την ανάπτυξη ενός αριθμού έργων λογισμικού, μπορεί να είναι όπως στο
σχήμα 7.1.
Θα πρέπει να υπάρχει ένας ανώτατος διευθυντής ή αντιπρόεδρος υπεύθυνος
γαι την ανάπτυξη λογισμικού. Σε αυτόν το διευθυντή θα πρέπει να αναφέρονται ένας
αριθμός από υπεύθυνους προγράμματος. Κάθε υπεύθυνος προγράμματος έργων είναι
υπεύθυνος για μια συγκεκριμένη περιοχή ανάπτυξης, όπως η ανάπτυξη συστημάτων
για εργασιακούς χώρους, συστήματα εναέριας κυκλοφορίας, ανάπτυξη
εξειδικευμένων εργαλείων, κ.λ.π. Κάθε έργο το οποίο αναπτύσσεται έχει το δικό του
υπεύθυνο ο οποίος αναφέρεται στο διευθυντή προγράμματος. Μέσα σε κάθε έργο,
ίσως να υπάρχει ένας αριθμός από αρχηγούς ομάδων υπεύθυνων για τη διοίκηση
ανεξάρτητων υποέργων.
Το σχήμα δείχνει τη λειτουργία της εξασφάλισης ποιότητας σαν ξεχωριστή
από τη διοίκηση ανεξάρτητων έργων. Η εξασφάλιση ποιότητας θα πρέπει να έχει το
δικό της διοικητή, και ένας αριθμός από ομάδες ελέγχου της ποιότητας θα
αναφέρονται σε αυτό το διοικητή. Αυτές οι ομάδες λειτουργούν σε συνεργασία με τις
ομάδες που έχουν αναλάβει τα ανεξάρτητα έργα, αλλά για να διατηρήσουν την
ανεξαρτησία τους δεν αναφέρονται στους υπεύθυνους αυτών των ανεξάρτητων
έργων. Η εξασφάλιση της ποιότητας του λογισμικού συζητείται σε άλλο κεφάλαιο.

7.2.1 ΟΡΓΑΝΩΣΗ ΟΜΑΔΩΝ ΠΡΟΓΡΑΜΜΑΤΙΣΜΟΥ

Τα έργα λογισμικού δεν θα πρέπει να αντιμετωπίζονται από μια μόνο μεγάλη

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

101
 Διοίκηση έργων λογισμικού

Διευθυντής
λογισμικού

Διευθύνων Διευθύνων Διευθύνων

προγράμματος προγράμματος ποιοτικού ελέγχου

Διευθύνων Διευθύνων Διευθύνων Ομάδα Ομάδα Ομάδα

έργου έργου έργου Ποιοτικού Ποιοτικού Ποιοτικού
έλεγχου 1 έλεγχου 2 έλεγχου 3
Διευθύνοντες έργων λογισμικού

Αρχηγός Αρχηγός Αρχηγός Αρχηγός

ομάδας ομάδας ομάδας ομάδας

Σχήμα 7.1 : Διοικητική δομή έργου λογισμικού

Τα μεγέθη των ομάδων προγραμματισμού θα πρέπει να είναι σχετικά μικρά.

Όταν χρησιμοποιούνται μικρές ομάδες, τα προβλήματα επικοινωνίας μειώνονται.
Ολόκληρη η ομάδα μπορεί να καθήσει γύρω από ένα τραπέζι για μια συνάντηση και
τα μέλη μπορούν να συναντώνται ακόμα και στα γραφεία τους. Δε χρειάζεται να
εγκαθιδρυθούν πολύπλοκες δομές επικοινωνίας. Έτσι, εκτός και αν οι συνθήκες είναι
ιδιάζουσες, μια ομάδα δεν θα πρέπει να έχει πάνω από οκτώ (8) άτομα.
Αν ένα έργο είναι τόσο μεγάλο ώστε να μην μπορεί να αντιμετωπιστεί από μια
μόνο ομάδα στο διαθέσιμο χρόνο, θα πρέπει να χρησιμοποιηθούν πολλές τέτοιες
ομάδες. Θα πρέπει να δουλεύουν ανεξάρτητα, με κάθε ομάδα να αντιμετωπίζει ένα
σημαντικό κομμάτι του έργου με αυτόνομο τρόπο. Η αρχιτεκτονική του συστήματος
θα πρέπει να σχεδιαστεί έτσι ώστε η διεπαφή μεταξύ των υποσυστημάτων που
αναπτύσσονται από τις ανεξάρτητες ομάδες να είναι απλές και καλά ορισμένες.
Εκτός από το να ελαχιστοποιούν τα προβλήματα επικοινωνίας, οι μικρές
ομάδες προγραμματισμού έχουν έναν αριθμό άλλων πλεονεκτημάτων:
1. Μπορεί να αναπτυχθεί ένα πρότυπο ποιότητας της ομάδας. Επειδή αυτό το
πρότυπο ανακηρύσσεται ομόφωνα, είναι πιο πιθανό να παρατηρηθεί από το να
επιβληθούν εξωτερικά πρότυπα στην ομάδα.
2. Τα μέλη της ομάδας δουλεύουν στενά μαζί. Τα μέλη της ομάδας μπορούν να
διδαχτούν το ένα από το άλλο. Αναστολές που προκαλούνται από άγνοια
ελαχιστοποιούνται, αφού η αμοιβαία μάθηση παροτρύνεται.
3. Μπορεί να εφαρμοστεί μη εγωιστικός προγραμματισμός. Τα προγράμματα
θεωρούνται ιδιοκτησία της ομάδας παρά προσωπική ιδιοκτησία.
4. Τα μέλη της ομάδας τείνουν να γνωρίζουν την δουλειά του καθενός. Συνέχεια
μπορεί να διατηρηθεί ακόμα και αν ένα μέλος της ομάδας φύγει.

Οι μικρές ομάδες προγραμματισμού συνήθως οργανώνονται με άτυπο τρόπο. Παρ’

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

102
 Διοίκηση έργων λογισμικού

επίπεδο γίνεται από παλιότερα μέλη της ομάδας αλλά ο σχεδιασμός σε χαμηλό
επίπεδο, είναι υπευθυνότητα του μέλους το οποίο ανέλαβε το συγκεκριμένο καθήκον.
Οι άτυπες ομάδες μπορούν να είναι πολύ επιτυχείς, ιδίως σε εκείνες στις
οποίες η πλειοψηφία των μελών είναι έμπειρα και ανταγωνιστικά. Η ομάδα
λειτουργεί με δημοκρατικό τρόπο, παίρνοντας ομόφωνες αποφάσεις. Ψυχολογικά,
αυτό βελτιώνει το πνεύμα της ομάδας με αποτέλεσμα αύξηση της συνεκτικότητας
και της απόδοσης. Αν η ομάδα αποτελείται κυρίως από άπειρα και μη ανταγωνιστικά
μέλη, η έλλειψη τυπικότητας μπορεί να αποτελέσει κώλυμα. Δεν υπάρχει κάποιος
ορισμένος αρχηγός για να διευθύνει τη δουλειά, κάτι που δημιουργεί έλλειψη
συντονισμού μεταξύ των μελών της ομάδας και πιθανή αποτυχία του έργου.
Ένα πρόβλημα που συχνά κάνει την εμφάνιση του είναι η έλλειψη έμπειρων
μελών στις ομάδες. Οι ομάδες συνήθως αποτελούνται από σχετικά άπειρους
μηχανικούς πληροφορικής. Σε μερικούς οργανισμούς ανάπτυξης λογισμικού, ικανό
τεχνολογικά προσωπικό φτάνει σε ένα “επίπεδο καριέρας” σχετικά γρήγορα.
Προχωρόντας μακρύτερα, το προσωπικό αυτό πρέπει να επωμιστεί διοικητικές
υπευθυνότητες, κάτι που απαιτεί διαφορετικές ικανότητες. Ικανοί μηχανικοί
λογισμικού δεν κάνουν απαραίτητα ικανούς διευθύνοντες λογισμικού. Η προαγωγή
τέτοιων ατόμων σε διοικητικές θέσεις συχνά σημαίνει ότι χρήσιμες τεχνικές
ικανότητες χάνονται.
Για να αξιοποιούνται αυτές οι ικανότητες των έμπειρων και ανταγωνιστικών
προγραμματιστών, θα πρέπει να τους ανατίθενται υπευθυνότητες και επιβραβεύσεις
ανάλογες με αυτές που θα λάμβανε κάποιος σε μια διοικητική θέση. Για να
αποφεύγονται απώλειες τεχνικών ικανοτήτων από κάποιο έργο, κάποιο οργανισμοί
ανέπτυξαν παράλληλες τεχνικές και διοικητικές δομές καριέρας ίδιας αξίας. Καθώς η
καριέρα ενός μηχανικού αναπτύσσεται, αυτός/ή μπορεί να εξειδικευτεί είτε σε
τεχνικές είτε σε διοικητικές δραστηριότητες και μπορεί να μετακινηθεί μεταξύ τους
δίχως απώλεια της θέσης του στην εταιρία (status) ή μισθού.

7.2.2 ΟΜΑΔΕΣ ΥΠΟ ΑΡΧΗΓΟ ΠΡΟΓΡΑΜΜΑΤΙΣΤΗ

Μια εναλλακτική οργάνωση ομάδων προγραμματισμού στην άτυπη

δημοκρατική ομάδα προτάθηκε από τον Baker (1972) και περιγράφηκε επίσης, σε μια
λίγο διαφορετική μορφή, από τον Brooks (1975) και τον Aron (1974). Η ανάπτυξη
αυτής της προσέγγισης είχε σαν κίνητρο έναν αριθμό από συλλογισμούς:
1. Τα έργα έτειναν να στελεχωθούν από σχετικά άπειρα άτομα όπως είδαμε
και παραπάνω.
2. Η περισσότερη προγραμματιστική δουλειά είναι γραφειοκρατική, έχοντας
να κάνει με τη διαχείριση μεγάλων ποσών πληροφορίας.
3. Η επικοινωνία μεταξύ πολλών ατόμων είναι χρονοβόρα και σαν συνέπεια
μειώνει την παραγωγικότητα των προγραμματιστών.

Η ομάδα με αρχηγό προγραμματιστή βασίζεται στην αξιοποίηση των έμπειρων και

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

103
 Διοίκηση έργων λογισμικού

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

Δεξαμενή ειδικών

Αρχηγός
προγραμματιστής Εφεδρικός
προγραμματιστής

Βιβλιοθηκάριος Eξωτερική
επικοινωνία
Σχήμα 7.2 Μια ομάδα με αρχηγό προγραμματιστή

Ο πυρήνας μιας ομάδας με αρχηγό προγραμματιστή αποτελείται από τα εξής μέλη:

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

Ανάλογα με το μέγεθος και τον τύπο της εφαρμογής, μπορούν να προστεθούν και
άλλοι ειδικοί στην ομάδα προσωρινά ή μόνιμα. Αυτοί μπορεί να περιλαμβάνουν:
1. Έναν διαχειριστή του έργου (project administrator) που απαλλάσσει τον αρχηγό
προγραμματιστή από καθήκοντα διαχείρισης.
2. Έναν “σιδερά” (toolsmith) που είναι υπεύθυνος για την παραγωγή εργαλείων
λογισμικού για την υποστήριξη του έργου.
3. Έναν συντάκτη τεκμηρίωσης ο οποίος παίρνει την τεκμηρίωση του λογισμικού
από τον αρχηγό και τον εφεδρικό προγραμματιστή και το ετοιμάζει για έκδοση.
4. Έναν ειδικό για το σύστημα/γλώσσα που είναι εξοικειωμένος με τα
χαρακτηριστικά της συγκεκριμένης γλώσσας προγραμματισμού και του
συστήματος που χρησιμοποιούνται και του οποίου ο ρόλος είναι να συμβουλεύει
τον αρχηγό προγραμματιστή για το πως να χρησιμοποιήσει τις ευκολίες που του
παρέχονται.
5. Έναν δοκιμαστή του οποίου καθήκον είναι να αναπτύσσει αντικειμενικές
περιπτώσεις ελέγχου για να πιστοποιεί τη δουλειά του αρχηγού προγραμματιστή.
6. Έναν ή περισσότερους προγραμματιστές υποστήριξης που γράφουν κώδικα για
κάποια σχεδίαση του αρχηγού προγραμματιστή. Αυτοί οι προγραμματιστές

104
 Διοίκηση έργων λογισμικού

υποστήριξης είναι απαραίτητοι σε μεγάλα έργα όπου χρειάζεται μεγάλη ποσότητα

λεπτομερούς προγραμματισμού η οποία δεν μπορεί γίνει μόνο από τον αρχηγό και
τον εφεδρικό προγραμματιστή.

Ο κύριος σκοπός για τη χρησιμοποίηση ομάδας με αρχηγό προγραμματιστή είναι να

αυξηθεί η παραγωγικότητα. Μετρήσεις από τον Baker (1972) και τους Walston και
Felix (1977) δείχνουν ότι οι ομάδες με αρχηγό προγραμματιστή είναι περίπου
διπλάσια παραγωγικές από ομάδες οργανωμένες με άλλους τρόπους. Παρ’ όλα αυτά,
αυτή η οργάνωση ίσως να μην είναι αποτέλεσμα της οργάνωσης της ομάδας. Οι
αρχηγοί προγραμματιστές ίσως είναι απλά πολύ καλοί προγραμματιστές οι οποίοι θα
απέδιδαν πολύ περισσότερο σε ομάδες οποιασδήποτε οργάνωσης.
Ο Schneiderman (1980) σημειώνει ότι ίσως υπάρξουν ψυχολογικά
προβλήματα κατά την εισαγωγή ομάδων με αρχηγό προγραμματιστή. Αυτά
προκύπτουν από τη θέση του αρχηγού προγραμματιστή, ο οποίος είναι ο κινητήριος
μοχλός του έργου. Αν το έργο είναι επιτυχές, αυτός/ή καρπώνεται την επιτυχία. Τα
υπόλοιπα μέλη της ομάδας ίσως αισθάνονται ότι δεν έχουν συγκεκριμένες λειτουργίες
και χολωμένα με τη θέση του αρχηγού προγραμματιστή.
Ένα άλλο πρόβλημα είναι ότι η επιτυχία ενός έργου εξαρτάται από ένα ή δυο
άτομα τα οποία συνεργάζονται στενά. Αν αρρωστήσουν και οι δύο ταυτόχρονα (κάτι
πολύ συνηθισμένο το χειμώνα) ή φύγουν και οι δύο, το έργο ίσως εγκαταλειφθεί,
αφού δεν θα υπάρχει άλλος στην ομάδα τους ή στον οργανισμό που θα μπορεί να
αναλάβει το ρόλο τους και να διατηρήσει το χρονοπρογραμματισμό του έργου.
Ένα άλλο πρόβλημα πολιτικής στη χρησιμοποίηση ομάδων με αρχηγό
προγραμματιστή περιγράφεται από τον Yourdon (1979). Σε μεγάλους οργανισμούς
ίσως είναι αδύνατον να ενταχθεί η ομάδα αρχηγού προγραμματιστή στην υπάρχουσα
δομή του οργανισμού και να ανταμοιφθεί ικανοποιητικά ο αρχηγός
προγραμματιστής. Η εισαγωγή ομάδων με αρχηγό προγραμματιστή μπορεί να
σημαίνει αναδιοργάνωση του προσωπικού και αυτό ίσως πολεμηθεί. Ίσως σταθεί
αδύνατο να προσληφθούν αρχηγοί προγραμματιστές με κατάλληλα προσόντα για να
εργαστούν σε συγκεκριμένες περιοχές εφαρμογών.

7.3 ΠΡΟΓΡΑΜΜΑΤΙΣΤΙΚΗ ΠΑΡΑΓΩΓΙΚΟΤΗΤΑ

Η εκτίμηση της προγραμματιστικής παραγωγικότητας είναι σημαντική για

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

105
 Διοίκηση έργων λογισμικού

Δεν είναι δυνατή η απ’ ευθείας παραγωγή ενός τύπου που επιτρέπει τη
μέτρηση των παραγόμενων λειτουργιών ανά ώρα, αν και οι Albrecht και
Gaffney(1983) πρότειναν τη χρήση “σημείων λειτουργιών” (function points) σαν
μέσα μέτρησης της παραγωγικότητας. Πρέπει βέβαια να υποστηρίζονται από την
ανθρώπινη κρίση και διαίσθηση για να εκτιμήσουν την πραγματική παραγωγικότητα
της διαδικασίας.
Η παραγωγικότητα δεν μπορεί να μετρηθεί για όλο τον κύκλο ζωής
λογισμικού, γι αυτό μετριέται μόνο κατά το στάδιο της παραγωγής του λογισμικού.
Αν παραχθεί γρήγορα κακής ποιότητας λογισμικό, αυτοί που το ανέπτυξαν μπορεί να
φαίνονται περισσότερο παραγωγικοί από προγραμματιστές που παράγουν αξιόπιστα
και εύκολο να διατηρηθούν συστήματα.
Οι μονάδες παραγωγικότητας που εκφράζονται σε ποσότητα/χρόνο δεν
λαμβάνουν υπ’ όψη τους την ποιότητα του ολοκληρωμένου συστήματος. Υπονοούν
ότι περισσότερο σημαίνει πάντα και καλύτερο και δεν λαμβάνουν υπ’ όψη τους το
γεγονός ότι φαινομενικά μεγαλύτερη παραγωγικότητα κατά την ανάπτυξη μπορεί
τελικά να εμπεριέχει αυξημένο κόστος συντήρησης του συστήματος.
Διάφορες μονάδες έχουν χρησιμοποιηθεί σαν μέτρα προγραμματιστικής
παραγωγικότητας:
 Γραμμές πηγαίου κώδικα που γράφονται από κάθε προγραμματιστή/μήνα.
 Εντολές εκτελέσιμου κώδικα που παράγονται από κάθε
προγραμματιστή/μήνα.
 Σελίδες τεκμηρίωσης που γράφονται από κάθε προγραμματιστή/μήνα.
 Περιπτώσεις ελέγχου που γράφονται και εκτελούνται ανά
προγραμματιστή/μήνα.

Το περισσότερο χρησιμοποιημένο μέτρο παραγωγικότητας είναι οι γραμμές πηγαίου

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

Χρόνος ανάλυσης

Χρόνος σχεδίασης

Παραγωγή κώδικα

Χρόνος ελέγχου

Χρόνος ανάπτυξης

Σχήμα 7.3 : Χρόνος ανάπτυξης συστήματος

106
 Διοίκηση έργων λογισμικού

Ο Jones(1978) σημειώνει ότι υπάρχουν πολλά προβλήματα με αυτό το μέτρο

παραγωγικότητας. Το βασικότερο από αυτά είναι το να καθορίσει κανείς επακριβώς
τι εννοείται λέγοντας γραμμή κώδικα. Τα προγράμματα αποτελούνται από δηλώσεις,
εκτελέσιμες εντολές και σχόλια, και μπορούν επίσης να περιλαμβάνουν
μακροεντολές που εκτείνονται σε πολλές γραμμές κώδικα. Μερικές τεχνικές
μέτρησης θεωρούν μόνο τις εκτελέσιμες εντολές, μερικές τις εκτελέσιμες εντολές και
τις δηλώσεις των δεδομένων. Μερικές μετρούν κάθε μη κενή γραμμή προγράμματος,
ανεξάρτητα του περιεχομένου της. Εξαιτίας αυτών των παραδοχών, τα εκδοθέντα
μέτρα της προγραμματιστικής παραγωγικότητας δε μπορούν να συγκριθούν άμεσα.
Ένα άλλο πρόβλημα που αναδεικνύεται όταν χρησιμοποιούνται γλώσσες όπως
η Pascal είναι το πως θα πρέπει να αντιμετωπίζονται γραμμές οι οποίες περιέχουν
παραπάνω από μια εντολή. Αν τέτοιες γραμμές αντιμετωπίζονται σαν μια γραμμή,
μεγαλύτερη παραγωγικότητα μπορεί προφανώς να επιτευχθεί με συνετή χρήση νέων
γραμμών! Παρ’ όλα αυτά, όσο χρησιμοποιείται μια συνεπής τεχνική μέτρησης των
γραμμών κώδικα, δεν έχει ουσιαστική σημασία ποιά προσέγγιση υιοθετείται.
Μια πιο σοβαρή συνέπεια της χρησιμοποίησης γραμμών κώδικα/μήνα σαν
μέτρο παραγωγικότητας είναι τα εμφανή πλεονεκτήματα στην παραγωγικότητα τα
οποία φαίνεται να προκύπτουν όταν χρησιμοποιείται κώδικας assembly. Το
πρόβλημα συμβαίνει επίσης, σε μικρότερο βαθμό, όταν συγκρίνονται προγράμματα
γραμμένα σε διαφορετικές γλώσσες υψηλού επιπέδου. Αν οι γραμμές κώδικα/μήνα
χρησιμοποιούνται σαν ακατέργαστο μέτρο παραγωγικότητας, φαίνεται ότι ο
προγραμματισμός σε γλώσσα χαμηλού επιπέδου είναι πιο παραγωγικός από τον
προγραμματισμό σε γλώσσα υψηλού επιπέδου για συγκρίσιμα συστήματα. Όσο
περισσότερο “εκφραστική” είναι η γλώσσα προγραμματισμού, τόσο πιο μικρή είναι η
φαινόμενη παραγωγικότητα.
Αυτό το παράδοξο απορρέει από το γεγονός ότι όλες οι εργασίες που
σχετίζονται με τη διαδικασία του προγραμματισμού (σχεδιασμός, τεκμηρίωση,
έλεγχος κ.λ.π.) υποτιμούνται σε σχέση με την εργασία της συγγραφής του κώδικα,
παρά το γεγονός ότι ο χρόνος συγγραφής του κώδικα είναι πολύ λιγότερος από το
μισό του συνολικού χρόνου που χρειάζεται για να ολοκληρωθεί το έργο (βλ. σχ. 7.4).
Το μέτρο δίνει υπέρμετρη έμφαση στην παραγωγή κώδικα και θεωρεί τα άλλα στάδια
του κύκλου ζωής λογισμικού λιγότερο σημαντικά. Ο χρόνος ανάλυσης, σχεδιασμού
και τεκμηρίωσης είναι ανεξάρτητα γλώσσας και τα προγράμματα γραμμένα σε
γλώσσα χαμηλού επιπέδου έχουν περισσότερες γραμμές κώδικα από αντίστοιχα σε
γλώσσα υψηλού επιπέδου. Διαιρώντας παραγώμενο κώδικα με το χρόνο ανάπτυξης
παίρνουμε ένα βεβιασμένο αποτέλεσμα.
Για παράδειγμα, θεωρείστε ένα σύστημα που μπορεί να κωδικοποιηθεί σε
5000 γραμμές κώδικα assembly ή 1500 γραμμές γλώσσας υψηλού επιπέδου. Ο
χρόνος ανάπτυξης για τις διάφορες φάσεις φαίνεται στο σχήμα 7.5.

Γλώσσα χαμηλού επιπέδου

Ανάλυση Σχεδιασμός Κωδικοποίηση Πιστοποίηση

Γλώσσα υψηλού επιπέδου

Ανάλυση Σχεδιασμός Κωδικοποίηση Πιστοποίηση

Σχήμα 7.4 : Χρόνοι ανάπτυξης με χαμηλού και υψηλού επιπέδου γλώσσες

προγραμματισμού

107
 Διοίκηση έργων λογισμικού

Ανάλυση Σχεδιασμός Κωδικοποίηση Έλεγχος Τεκμηρίωση

Κώδικας assembly 3 εβδομ. 5 εβδομάδες 8 εβδομάδες 10 εβδ 2 εβδομάδες

Γλώσσα υψηλού 3 εβδομ. 5 εβδομάδες 4 εβδομάδες 6 εβδομ 2 εβδομάδες

επιπέδου
Μέγεθος Προσπάθεια Παραγωγικότητα

Κώδικας assembly 5000 γραμμές 28 εβδομάδες 714

Γλώσσα υψηλού 1500 γραμμές 20 εβδομάδες 300

επιπέδου

Σχήμα 7.5 : Χρόνος ανάπτυξης συστήματος

Ο προγραμματιστής της assembly παρουσιάζει παραγωγικότητα 714 γραμμές/

μήνα και ο προγραμματιστής σε γλώσσα υψηλού επιπέδου λιγότερο από το μισό, 300
γραμμές/μήνα. Όμως το κόστος ανάπτυξης για τη γλώσσα υψηλού επιπέδου είναι
μικρότερο και το σύστημα παράγεται σε λιγότερο χρόνο. Εξαιτίας αυτού του
παράδοξου, απαιτούνται διαφορετικά πρότυπα παραγωγικότητας για κάθε γλώσσα
προγραμματισμού και δε θα πρέπει να γίνονται συγκρίσεις παραγωγικότητας μεταξύ
έργων κωδικοποιημένων σε διαφοτερικές γλώσσες.
Για να αποφευχθούν κάποια προβλήματα που σχετίζονται με τη
χρησιμοποίηση των γραμμών κώδικα ανά μήνα για τη μέτρηση της παραγωγικότητας,
μια εναλλακτική μέθοδος χρησιμοποιεί τον αριθμό των εντολών εκτελέσιμου κώδικα
που παράγονται ανά προγραμματιστή/μήνα. Αυτή η μονάδα είναι πιο αντικειμενική
από τις γραμμές κώδικα αφού δεν υπάρχει δυσκολία στον ορισμό του τι σημαίνει
εντολή εκτελέσιμου κώδικα. Παρ’ όλα αυτά, υπάρχουν επίσης μειονεκτήματα στη
χρησιμοποίηση αυτού του μέτρου παραγωγικότητας:
1 Είναι δύσκολο να εκτιμηθεί ο λόγος πηγαίου/εκτελέσιμου κώδικα με τους
περισσότερους μεταγλωτιστές. Αυτό σημαίνει ότι ο εκτελέσιμος
κώδικας/μήνα δεν είναι χρήσιμος για την εκτίμηση της παραγωγικότητας
πριν πραγματικά να παραχθεί ο κώδικας.
2 Η ποσότητα του εκτελέσιμου κώδικα που παράγεται από ένα
προγραμματιστή εξαρτάται από την τεχνοτροπία (στυλ) με την οποία γίνεται
ο προγραμματισμός στη γλώσσα υψηλού επιπέδου. Ένας προγραμματιστής ο
οποίος προσέχει ιδιαίτερα την παραγωγή κώδικα και παράγει “σφικτό”
κώδικα είναι φαινομενικά λιγότερο παραγωγικός από ένα προγραμματιστή
που προγραμματίζει με τέτοιο τρόπο ώστε να παράγονται μεγάλα εκτελέσιμα
προγράμματα.

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

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

108
 Διοίκηση έργων λογισμικού

ενός προγραμματιστή. Για μεγάλα, πολύπλοκα επί μέρους συστήματα η

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

7.3.1 ΠΑΡΑΓΟΝΤΕΣ ΠΟΥ ΕΠΗΡΕΑΖΟΥΝ ΤΗΝ ΠΑΡΑΓΩΓΙΚΟΤΗΤΑ

Μια μελέτη που έγινε από τον Sackman (1968) έδειξε ότι οι ατομικές
διαφορές στην παραγωγικότητα μπορούν να είναι πολύ μεγάλες. Οι καλύτεροι
προγραμματιστές μπορούν να είναι και δέκα φορές πιο παραγωγικοί από τους
χειρότερους. Αυτός ο παράγων ικανότητας είναι πολύ πιθανόν να είναι κυρίαρχος σε
ατομικές συγκρίσεις παραγωγικότητας. Αναλόγως, οι παράγοντες που συζητούνται
παρακάτω σχετίζονται μόνο με ομάδες προγραμματιστών που αποτελούνται από
προγραμματιστές με εύρος ικανοτήτων.
Οι Walston και Felix (1977) έκαναν μια έρευνα παραγωγικότητας για να
προσδιορίσουν τη βελτίωση στην παραγωγικότητα από τη χρησιμοποίηση
μεθοδολογιών όπως η από πάνω προς τα κάτω (top down) ανάπτυξη, ο δομημένος
προγραμματισμός, κ.λ.π. Συνέλεξαν δεδομένα από περισσότερο από 60 έργα που
εκτείνονταν από απλά εμπορικά προγράμματα γραφείου σε μεγάλα συστήματα
ελέγχου διαδικασιών. Επέλεξαν 68 μεταβλητές για ανάλυση και προσδιόρισαν 29 από
αυτές σαν σημαντικά συσχετιζόμενες με την παραγωγικότητα. Αυτές οι μεταβλητές
περιελάμβαναν χαρακτηριστικά του υπό ανάπτυξη συστήματος, την εμπειρία αυτών
που ανέπτυσσαν τα συστήματα, περιορισμούς στο υλικό, τη χρήση νέων τεχνολογιών
ανάπτυξης συστημάτων, περιορισμούς στο σχεδιασμό των προγραμμάτων και την
ποσότητα της τεκμηρίωσης που απαιτούνταν.
Ο πιο σημαντικός παράγοντας που επηρεάζει την παραγωγικότητα ήταν η
πολυπλοκότητα της διεπαφής του χρήστη. Έργα με χαμηλή πολυπλοκότητα διεπαφής
του χρήστη παρουσίαζαν παραγωγικότητα της τάξης των 500 γραμμών/
προγραμματιστή ανά μήνα, τη στιγμή που έργα με υψηλή πολυπλοκότητα διεπαφής
του χρήστη παράγονταν με ρυθμό 124 γραμμών/προγραμματιστή ανά μήνα.
Άλλοι σημαντικοί παράγοντες είναι ο βαθμός συμμετοχής των χρηστών στον
καθορισμό των απαιτήσεων και η εμπειρία της ομάδας προγραμματισμού. Όπου δε
συμμετείχε ο χρήστης στον καθορισμό των απαιτήσεων, η παραγωγικότητα
μετρήθηκε στις 491 γραμμές/ προγραμματιστή ανά μήνα, αλλά εκεί όπου ήταν
σημαντική η συμμετοχή του χρήστη έπεσε στις 205 γραμμές/μήνα. Ομάδες με αρκετή
εμπειρία παρήγαγαν με ρυθμό 410 γραμμές/ προγραμματιστή ανά μήνα εκεί όπου
άπειρες παρήγαγαν με ρυθμό 132 γραμμές/ προγραμματιστή.
Τα αποτελέσματα στην παραγωγικότητα της πολυπλοκότητας της διεπαφής
του χρήστη και της εμπειρίας της ομάδας είναι διαισθητικά προφανή παρά το ότι η
μελέτη των Walston και Felix ήταν χρήσιμη στο να δείξει τη σημασία τους. Θα
μπορούσε επίσης να περιμένει κανείς ότι αν ο χρήστης είχε μικρότερη συμμετοχή
στον καθορισμό των απαιτήσεων η παραγωγικότητα θα ήταν μεγαλύτερη, παρ’ όλο
που σε αυτήν την περίπτωση το τελικό προϊόν ίσως να μην κάλυπτε τις ανάγκες του.
Οι μεθοδολογίες σχεδίασης και προγραμματισμού, όπως ο δομημένος
προγραμματισμός, οι αναθεωρήσεις του σχεδιασμού και του κώδικα, και η από πάνω
προς τα κάτω σχεδίαση, είχαν θετική επίδραση στην παραγωγικότητα, αν και όχι

109
 Διοίκηση έργων λογισμικού

τόσο μεγάλη όσο οι παράγοντες που συζητήθηκαν προηγουμένως. Παρ’ όλα αυτά, οι
βελτιώσεις στην παραγωγικότητα που απορρέουν από τη χρήση αυτών των τεχνικών
θα πρέπει να θεωρηθούν σαν μια επιβράβευση (bonus). Η κύρια λειτουργία τους είναι
να βελτιώσουν την αξιοπιστία και τη συντηρησιμότητα του λογισμικού.
Ένας άλλος παράγοντας που προφανώς επηρεάζει την παραγωγικότητα είναι η
ποσότητα του χρόνου που ένας μηχανικός λογισμικού πραγματικά αφιερώνει
εργαζόμενος στην ανάπτυξη λογισμικού. Αγνοώντας τις διακοπές και πιθανές
ασθένειες, κάθε μέλος μιας ομάδας ανάπτυξης λογισμικού ξοδεύει χρόνο στην
εκπαίδευση, στην παρουσία σε συνεδριάσεις και σε καθήκοντα διαχείρισης. Αν ένα
έργο περιλαμβάνει νέες τεχνικές, θα χρειαστεί εκπαίδευση, αν το έργο περιλαμβάνει
περισσότερες από μια γεωγραφικές τοποθεσίες, ξοδεύεται χρόνος σε μετακινήσεις και
όσο μεγαλύτερη είναι η ομάδα, τόσο περισσότερος χρόνος ξοδεύεται στην
επικοινωνία. Ο McCue (1978) ανακάλυψε ότι το 20% με 30% ενός μηχανικού μπορεί
να ξοδευτεί σε μη “παραγωγικές” δραστηριότητες.

 ΚΥΡΙΑ ΣΗΜΕΙΑ:
 Η καλή διοίκηση των έργων λογισμικού είναι απαραίτητη αν τα έργα της
τεχνολογίας λογισμικού πρόκειται να αναπτυχθούν μέσα στα όρια του
προϋπολογισμού και του χρονοπρογραμματισμού.
 Η διοίκηση λογισμικού είναι διαφορετική από άλλες μορφές τεχνολογικής
διοίκησης επειδή το λογισμικό δεν είναι χειροπιαστό, επειδή δεν είναι
επακριβώς κατανοητή η διαδικασία παραγωγής λογισμικού και επειδή τα
περισσότερα έργα λογισμικού είναι καινοφανή και πρωτοποριακά.
 Ένας υπεύθυνος λογισμικού έχει διάφορους ρόλους αλλά οι πιο σημαντικές
δραστηριότητες του είναι ο σχεδιασμός του έργου, η εκτίμηση και ο
χρονοπρογραμματισμός.
 Έχουν υιοθετηθεί διάφορες οργανώσεις ομάδων ανάπτυξης. Οι
δημοκρατικές ομάδες εργάζονται καλά όταν αποτελούνται από έμπειρο και
ανταγωνιστικό προσωπικό. Οι ομάδες με αρχηγό προγραμματιστή
προσπαθούν να χρησιμοποιήσουν με τον καλύτερο τρόπο ένα σπάνιο μέσο,
συγκεκριμένα, την προγραμματιστική ικανότητα.
 Ο κύριος παράγοντας στην προγραμματιστική παραγωγικότητα είναι η
ικανότητα του προγραμματιστή σαν άτομο.
 Συγκρίσεις μεταξύ διαφορετικών γλωσσών προγραμματισμού με κριτήριο
τις γραμμές κώδικα ανά μήνα δεν θα πρέπει να γίνονται.
 Τα υπάρχοντα μέτρα προγραμματιστικής παραγωγικότητας δεν λαμβάνουν
υπ’ όψη τους την ποιότητα του τελικού προϊόντος

110
 Διοίκηση έργων λογισμικού

 ΛΕΞΙΚΟ ΟΡΩΝ

Παρακολούθηση έργου: Project monitoring

Υπεύθυνος έργου ή διευθύνων έργου: Project manager
Εξειδικευμένα εργαλεία: Case tools
Διεπαφή: Interface
Συνάντηση: meeting
Περιπτώσεις ελέγχου: Test cases
Εκτελέσιμος κώδικας: Object code

 ΑΝΑΦΟΡΕΣ

IEE/BCS Software Engineering J. Ένα ειδικό άρθρο από ένα περιοδικό, το οποίο
αναφέρεται σε θέματα τεχνολογίας λογισμικού. Η πρώτη ενότητα περιλαμβάνει
αρκετά papers σχετικά με τη διοίκηση έγων λογισμικού. Συνίσταται ιδιαίτερα το
paper του Rock.

The Mythical Man Month (F.P. Brooks, 1975, Addison-Wesley) Mία ενδιαφέρουσα
και καλογραμμένη αναφορά των προβλημάτων διοίκησης που εμφανίστηκαν κατά
την ανάπτυξη ενός από τα πρώτα πολύ μεγάλα έργα λογισμικού, το IBM OS/360
λειτουργικό σύστημα. Ο συγγραφέας της αναφοράς ήταν και διοικητής (manager)
σ’αυτό το έργο, από όπου αποκόμισε πολύ εμπειρία.

The Program Development Process : Part 2 - The Programming Team : Ένα άλλο
κείμενο που αναφέρεται στη διοίκηση λογισμικού, από συγγραφέα του οποίου η
εμπειρία είναι στην IBM. Πρόκειται για ένα πολύ ενδιαφέρον βιβλίο, όχι τόσο
διασκεδαστικό όσο του Brook, ωστόσο εξίσου πολύτιμo συμπλήρωμα σ’αυτό το
κεφάλαιο.

Principles of Software Engineering Management (T. Gilb, 1988, Addison-Wesley)

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

111
 ΚΕΦΑΛΑΙΟ 8: AΞΙΟΠΙΣΤΙΑ ΛΟΓΙΣΜΙΚΟΥ

 ΣΚΟΠΟΣ ΤΟΥ ΚΕΦΑΛΑΙΟΥ

Αντικείμενο αυτού του κεφαλαίου είναι ο καθορισμός, ποιοτικά και ποσοτικά,

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

 ΠΕΡΙΕΧΟΜΕΝΑ

8.1 Μετρικές της αξιοπιστίας

8.2 Προσδιορισμός της αξιοπιστίας λογισμικού
8.3 Στατιστικός έλεγχος
8.4 Μοντελοποίηση ανάπτυξης αξιοπιστίας

112
 Αξιοπιστία λογισμικού

Καθώς οι εφαρμογές των υπολογιστών γίνονται όλο και περισσότερο

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

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

Από την άλλη μεριά, ας θεωρήσουμε ένα ανάλογο σύστημα λογισμικού, το

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

Η αξιοπιστία είναι ένα δυναμικό χαρακτηριστικό συστήματος, το οποίο είναι

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

Τα ελαττώματα λογισμικού δεν είναι μόνο ελαττώματα προγράμματος. Μη

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

Υπάρχει μια πολύπλοκη σχέση μεταξύ της αξιοπιστίας του παρατηρούμενου

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

113
 Αξιοπιστία λογισμικού

αντιλαμβανόμενη αξιοπιστία. Η δουλειά τους δείχνει ότι, για τα προϊόντα που

μελετήθηκαν, η απομάκρυνση του 60% των ελαττωμάτων του προϊόντος θα οδηγήσει
σε βελτίωση της αξιοπιστίας κατά μονάχα 3%.

Αυτό παρουσιάζεται στο σχήμα 8.1, το οποίο προέρχεται από τον Littlewood
(1990), και το οποίο παρουσιάζει ένα σύστημα λογισμικού σαν μία αντιστοίχιση ενός
συνόλου εισόδων σε ένα σύνολο εξόδων. Ένα πρόγραμμα έχει πολλές πιθανές
εισόδους (για απλότητα, συνδυασμοί και ακολουθίες εισόδων θεωρούνται σα μια
μοναδική είσοδος). Το πρόγραμμα ανταποκρίνεται σε αυτές τις εισόδους παράγοντας
μία έξοδο ή ένα σύνολο εξόδων. Κάποιες από αυτές τις εισόδους (παρουσιάζονται με
τη σκιασμένη έλλειψη στο σχήμα 8.1) προκαλούν αποτυχίες συστήματος, όπου
παράγονται από το πρόγραμμα λανθασμένες έξοδοι. Η αξιοπιστία του προϊόντος
σχετίζεται με την πιθανότητα, σε μια συγκεκριμένη εκτέλεση του προγράμματος, η
είσοδος στο σύστημα να είναι μέλος του συνόλου των εισόδων που προκαλούν
λανθασμένη έξοδο.

Είσοδοι που προκαλούν

λανθασμένες εξόδους
Σύνολο εισόδου
Ie

Πρόγραμμα

Λανθασμένες έξοδοι

Σύνολο εξόδου Oe

Σχήμα 8.1
Ένα σύστημα σαν μια αντιστοίχιση
εισόδου/εξόδου

Είναι πιθανό ότι θα υπάρχει ένας μικρός αριθμός μελών του I e , τα οποία είναι
περισσότερο πιθανά να επιλεγούν από ότι κάποια άλλα. Η αξιοπιστία του

114
 Αξιοπιστία λογισμικού

προγράμματος σχετίζεται συνεπώς με αυτή την πιθανότητα κι όχι τόσο με τη μέση

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

Η αξιοπιστία εξαρτάται από το πώς χρησιμοποιείται το λογισμικό κι έτσι δεν

μπορεί να προσδιοριστεί απόλυτα. Ο κάθε χρήστης χρησιμοποιεί το πρόγραμμα με
διαφορετικούς τρόπους, κι έτσι ελαττώματα που επηρεάζουν την αξιοπιστία του
συστήματος μπορεί να μην εκδηλωθούν ποτέ για κάποιον χρήστη κάτω από
διαφορετικό τρόπο εργασίας (σχήμα 8.2). Η αξιοπιστία μπορεί να προσδιοριστεί με
ακρίβεια μόνο αν έχει επίσης προσδιοριστεί το φυσιολογικό λειτουργικό προφίλ του
λογισμικού (normal software operational profile—βλέπε παράγραφο 8.3).

Καθώς η αξιοπιστία σχετίζεται με την πιθανότητα να συμβεί ένα λάθος κατά

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

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

Για να γίνει το λογισμικό πολύ αξιόπιστο, πρέπει να περιέχει επιπλέον, συχνά

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

115
 Αξιοπιστία λογισμικού

Πιθανές
είσοδοι

Χρήστης 1 Λανθασμένες
είσοδοι

Χρήστης 3
Χρήστης 2

Σχήμα 8.2
Πρότυπα χρήσης λογισμικού

Κόστος

100% Αξιοπιστία

Σχήμα 8.3
Κόστος συναρτήσει της αξιοπιστίας

Αυξάνοντας την αξιοπιστία ενός προγράμματος, συνήθως το επιβραδύνουμε.

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

116
 Αξιοπιστία λογισμικού

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

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

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

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

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

5. Η μη αποδοτικότητα είναι προβλέψιμη. Τα προγράμματα χρειάζονται πολύ χρόνο

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

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

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

Η αξιοπιστία προϊόντος είναι δύσκολο να προσδιοριστεί ποσοτικά και μπορεί

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

Μία καλά διαχειριζόμενη, προτυποποιημένη διαδικασία συμβάλλει στην

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

117
 Αξιοπιστία λογισμικού

ουσιαστική αν πρόκειται να παραχθεί αξιόπιστο λογισμικό αλλά δεν εξασφαλίζει την

αξιοπιστία του προϊόντος.

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

Ένα αξιόπιστο σύστημα πρέπει να συμμορφώνεται με τις προδιαγραφές του

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

8.1 Μετρικές της Αξιοπιστίας

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

Αντίθετα, οι αποτυχίες ενός συστατικού του λογισμικού είναι προσωρινές.

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

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

1. Πιθανότητα αποτυχίας λόγω υπερβολικών απαιτήσεων (Probability of Failure

on Demand): Είναι ένα μέτρο της πιθανότητας να συμπεριφερθεί το σύστημα με
έναν μη αναμενόμενο τρόπο όταν ζητούνται από αυτό συγκεκριμένες απαιτήσεις.
Είναι περισσότερο σχετικό με συστήματα κρίσιμης ασφάλειας και με “non-stop”
118
 Αξιοπιστία λογισμικού

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

συστήματα, αυτό που είναι πιό σημαντικό είναι η πιθανότητα να μη λειτουργήσει
το σύστημα όπως αναμενόταν, και όχι τόσο το να μετρήσουμε μιά εμφάνιση της
αποτυχίας.
2. Ρυθμός εμφάνισης αποτυχιών (Rate of Failure Occurrence—ROCOF) : Είναι
ένα μέτρο της συχνότητας της εμφάνισης μη αναμενόμενης συμπεριφοράς. Για
παράδειγμα, εάν το ROCOF είναι 2/100 αυτό δείχνει ότι είναι πιθανό να
συμβούν 2 αποτυχίες σε κάθε 100 λειτουργικές χρονικές μονάδες. Κατάλληλες
χρονικές μονάδες αναφέρονται παρακάτω. Αυτή είναι πιθανά η πιο χρήσιμη
μονάδα μέτρησης της αξιοπιστίας.
3. Μέσος χρόνος ζωής (Mean Time to Failure—MTTF) : Είναι ένα μέτρο του
χρόνου μεταξύ παρατηρούμενων αποτυχιών. Αυτή η μονάδα είναι ανάλογη με
την αντίστοιχη μονάδα που χρησιμοποιείται για την εκτίμηση της αξιοπιστίας
του υλικού, όπου αντανακλά το χρόνο ζωής των συστατικών του συστήματος. Σε
συστήματα λογισμικού, τα συστατικά δεν φθείρονται και έπειτα από μια
αποτυχία, συνήθως συνεχίζουν να λειτουργούν. Επομένως ο μέσος χρόνος ζωής
είναι χρήσιμος στον υπολογισμό της αξιοπιστίας του λογισμικού μόνο όταν το
σύστημα είναι σταθερό και δεν γίνονται αλλαγές σε αυτό. Σε αυτή την
περίπτωση παρέχει μία ένδειξη του πόσο το σύστημα θα παραμείνει σε
λειτουργία πριν να συμβεί κάποια αποτυχία.
4. Διαθεσιμότητα (Availability) : Είναι ένα μέτρο του πόσο πιθανό είναι να είναι το
σύστημα διαθέσιμο προς χρήση. Για παράδειγμα, διαθεσιμότητα 998/1000
σημαίνει ότι σε κάθε 1000 χρονικές μονάδες, το σύστημα είναι πιθανό να είναι
διαθέσιμο για τις 998 από αυτές. Αυτό το μέτρο είναι περισσότερο κατάλληλο
για συστήματα όπως τηλεπικοινωνιακά συστήματα, όπου ο χρόνος επιδιόρθωσης
ή επανεκκίνησης είναι σημαντικός και η απώλεια υπηρεσιών κατά τη διάρκεια
αυτού του χρόνου είναι ουσιαστική.
Καμιά μετρική δεν είναι γενικά κατάλληλη και η συγκεκριμένη μετρική που
χρησιμοποιείται πρέπει να εξαρτάται από την περιοχή λειτουργίας της εφαρμογής και
την αναμενόμενη χρήση του συστήματος. Για μεγάλα συστήματα, μπορεί να
χρησιμοποιηθούν διαφορετικές μετρικές της αξιοπιστίας για τα διαφορετικά μέρη του
συστήματος.

Ο χρόνος είναι ένας παράγοντας σε όλες αυτές τις μετρικές και πρέπει να
επιλεχτούν κατάλληλες χρονικές μονάδες. Οι χρονικές μονάδες μπορεί να είναι
ημερολογιακός χρόνος, χρόνος απασχόλησης της CPU για τη συγκεκριμένη
εφαρμογή (processor time) ή μπορεί να είναι μερικές διακριτές μονάδες, όπως ένας
αριθμός από δοσοληψίες (transactions). Εξαρτάται από την εφαρμογή και από το πώς
αντιλαμβάνονται οι χρήστες του συστήματος το χρόνο. Για συστήματα που
βρίσκονται σε συνεχή χρήση, μπορεί να είναι κατάλληλο να χρησιμοποιηθεί
ημερολογιακός χρόνος. Για συστήματα που χρησιμοποιούνται περιοδικά αλλά είναι
αδρανή για τον περισσότερο χρόνο (για παράδειγμα, ένα σύστημα αυτόματης
τραπεζικής μηχανής—bank auto-teller), η πιο κατάλληλη χρονική μονάδα είναι ένας
αριθμός από δοσοληψίες.

Οι μετρικές της αξιοπιστίας βασίζονται στην πιθανότητα της αποτυχίας του

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

119
 Αξιοπιστία λογισμικού

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

Άλλα είδη αποτυχιών μπορεί να είναι καταστροφικά και μπορεί να

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

8.2 Προσδιορισμός της Αξιοπιστίας Λογισμικού

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

Το επιθυμητό επίπεδο αξιοπιστίας πρέπει πάντα να περιέχεται στις

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

Δυστυχώς, πολλοί αναλυτές απαιτήσεων έχουν μικρή γνώση της θεωρίας της
αξιοπιστίας και αναφέρουν τις απαιτήσεις αξιοπιστίας με έναν υποκειμενικό, άσχετο
ή μη μετρήσιμο τρόπο. Για παράδειγμα, δηλώσεις όπως “Το λογισμικό πρέπει να
είναι όσο πιο αξιόπιστο γίνεται” δεν έχουν νόημα. Δήθεν ποσοτικές δηλώσεις όπως
“Το λογισμικό δεν πρέπει να εμφανίζει περισσότερα από Ν ελαττώματα/1000
γραμμές” είναι ισοδύναμα άσχετο. Όχι μόνο είναι αδύνατο να μετρηθεί ο αριθμός των
ελαττωμάτων/1000 γραμμές κώδικα (πώς μπορεί κάποιος να πει ότι όλα έχουν
ανακαλυφθεί;), αλλά και η δήλωση δεν σημαίνει τίποτα από την άποψη της δυναμικής
συμπεριφοράς του συστήματος. Όπως έχει ήδη αναφερθεί, αξιόπιστη λειτουργία κατά
την παρουσία ελαττωμάτων είναι αρκετά πιθανή.

Τα είδη των αποτυχιών που μπορεί να συμβούν είναι εξειδικευμένα σε σχέση

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

120
 Αξιοπιστία λογισμικού

προδιαγραφές αξιοπιστίας, πρέπει να αναγνωρίσει τις διαφορετικές τάξεις αποτυχιών

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

Κατηγορία αποτυχίας Περιγραφή

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

Σχήμα 8.4
Ταξινόμηση αποτυχιών

Τα βήματα που ακολουθούνται για τη δημιουργία των προδιαγραφών

αξιοπιστίας είναι τα ακόλουθα :

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

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

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

Σαν ένα παράδειγμα προδιαγραφών αξιοπιστίας, ας θεωρήσουμε το

παράδειγμα της αυτόματης τραπεζικής μηχανής (bank auto-teller). Το σχήμα 8.5
παρουσιάζει μερικές πιθανές κατηγορίες αποτυχιών και έναν πιθανό προσδιορισμό
της αξιοπιστίας για αυτό το σύστημα. Είναι ένα αρκετά μικρό σύστημα κι έτσι δεν
είναι κατάλληλο για να αναγνωριστούν υποσυστήματα με διαφορετικές απαιτήσεις
αξιοπιστίας.

121
 Αξιοπιστία λογισμικού

Κατηγορία αποτυχίας Παράδειγμα Αξιοπιστία

Μόνιμη Δεν μπορεί να διαβαστεί η 1 στις 100.000 συναλλαγές
μαγνητική ταινία της
κάρτας
Προσωρινή, μη Αδυναμία ανάγνωσης της 1 στις 10.000 συναλλαγές
προκαλούσα αλλοίωση μαγνητικής ταινίας από
μία συγκεκριμένη κάρτα
Προσωρινή, προκαλούσα Κάρτες που έχουν εκδοθεί 1 στα 20.000.000
αλλοίωση από ξένες τράπεζες συναλλαγές
προκαλούν καταστροφή
της βάσης δεδομένων
Μη ανακτήσιμη, μη Βλάβη του λογισμικού η 1 στις 30.000 συναλλαγές
προκαλούσα αλλοίωση οποία ξεκινά τη διαδικασία
επιστροφής κάρτας
Ανακτήσιμη, προκαλούσα Απώλεια των δεδομένων 1 στις 50.000 συναλλαγές
αλλοίωση εισόδου του χρήστη
Ανακτήσιμη, μη Απώλεια των δεδομένων 1 στις 5.000 συναλλαγές
προκαλούσα αλλοίωση της μαγνητικής ταινίας

Σχήμα 8.5
Παραδείγματα προδιαγραφών
αξιοπιστίας

Οι απαιτήσεις αξιοπιστίας στο σχήμα 8.5 είναι οι αυθαίρετες εκτιμήσεις του

συγγραφέα του τι πρέπει να είναι η αξιοπιστία του συστήματος. Οι απόλυτες τιμές δεν
είναι ιδιαίτερα σημαντικές αλλά βασίζονται σε ένα σύνολο περίπου 100.000
συναλλαγών τη μέρα με το 5% αυτών να είναι συναλλαγές από “ξένες” τράπεζες. Οι
σχετικές τιμές είναι σημαντικές. Τα ελαττώματα που προκαλούν αλλοίωση πρέπει να
είναι σπάνια. Έτσι, μόνο μία μόνιμη αποτυχία αλλά 10 προσωρινές αποτυχίες την
ημέρα είναι αποδεκτές. Το ελάττωμα, που προκαλεί μη ανακτήσιμες αλλοιώσεις στη
βάση δεδομένων, δεν πρέπει να εκδηλώνεται περισσότερο από μία φορά κάθε 4.000
μέρες.

Οι specifiers πρέπει να είναι προσεχτικοί να μην προδιαγράφουν απαιτήσεις

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

122
 Αξιοπιστία λογισμικού

Αυτό σημαίνει ότι ο συνολικός εκτιμούμενος αριθμός των εκτελέσεων του

συστήματος είναι περίπου 31014 . Δεν έχει νόημα να προδιαγράψουμε ότι η
πιθανότητα αποτυχίας θα πρέπει να είναι 1/1015 (επιτρέποντας κάποιον ασφαλή
παράγοντα, ας πούμε) καθώς δεν υπάρχει πρακτικός τρόπος κατά τον οποίο θα
επικυρωθεί αυτή η αξιοπιστία στο αναπτυγμένο σύστημα λογισμικού.

Δυστυχώς, οι πληροφορικοί που ασχολούνται με την τεχνολογία λογισμικού

(software engineers) πρέπει συχνά να εργάζονται με ατελείς προδιαγραφές και δεν
μπορούν να αποφύγουν την ευθύνη για την παραγωγή αξιόπιστων συστημάτων.
Εκτός από το να ικανοποιεί τις συμφωνημένες προδιαγραφές, ένα πρόγραμμα δεν
πρέπει ποτέ να παράγει “λανθασμένες” εξόδους ανεξάρτητα από την είσοδο (καθόλου
έξοδος είναι συνήθως καλύτερη από λανθασμένη έξοδο), δεν πρέπει ποτέ να επιτρέπει
στον εαυτό του να αλλοιωθεί, πρέπει να πραγματοποιεί σημαντικές και χρήσιμες
ενέργειες σε μη αναμενόμενες καταστάσεις και θα πρέπει να αποτυγχάνει
ολοκληρωτικά μόνο όταν είναι αδύνατη περαιτέρω διαδικασία. Η αποτυχία δεν πρέπει
να επηρεάζει τα άλλα συστατικά του συστήματος. Τεχνικές ανάπτυξης, όπως ο
αμυντικός προγραμματισμός (defensive programming) πρέπει να εφαρμοστούν για
την παραγωγή αξιόπιστων συστημάτων.

8.3 Στατιστικός Έλεγχος (Statistical Testing)

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

1. Καθόρισε το λειτουργικό προφίλ του λογισμικού. Το λειτουργικό προφίλ είναι το

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

2. Επέλεξε ή δημιούργησε ένα σύνολο δεδομένων που ανταποκρίνονται στο

λειτουργικό προφίλ.

3. Εφάρμοσε αυτές τις περιπτώσεις ελέγχου στο πρόγραμμα, καταγράφοντας το

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

4. Μετά την παρατήρηση ενός στατιστικά σημαντικού αριθμού αποτυχιών, η

αξιοπιστία του λογισμικού μπορεί να υπολογιστεί.

Ο στατιστικός έλεγχος συνδυάζεται συχνά με τη μοντελοποίηση ανάπτυξης

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

123
 Αξιοπιστία λογισμικού

διάρκεια της διαδικασίας ελέγχου καθώς ανακαλύπτονται οι αποτυχίες και

επισκευάζεται το υποκείμενο ελάττωμα που προκαλεί την αποτυχία.

Αυτή η εννοιολογικά ελκυστική προσέγγιση στην εκτίμηση της αξιοπιστίας

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

Το λειτουργικό προφίλ του λογισμικού αντανακλά το πώς θα χρησιμοποιηθεί

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

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

Ο στατιστικός έλεγχος, όπως υποδηλώνει το όνομά του, σχετίζεται με τη

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

124
 Αξιοπιστία λογισμικού

Πιθανό-
τητα
εισόδου

…
Κατηγορία εισόδου

Σχήμα 8.6
Ένα τυπικό
λειτουργικό προφίλ

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

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

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

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

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

125
 Αξιοπιστία λογισμικού

συστήματα κρίσιμης ασφάλειας πρέπει να περιλαμβάνουν χαρακτηριστικά που τα

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

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

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

8.4 Μοντελοποίηση Ανάπτυξης Αξιοπιστίας

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

Τα μοντέλα ανάπτυξης αξιοπιστίας χρησιμοποιούνται κατά την διάρκεια της

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

Το απλούστερο μοντέλο ανάπτυξης αξιοπιστίας είναι ένα μοντέλο λειτουργίας

με βήματα (step function model) όπου η αξιοπιστία αυξάνει με μία σταθερή
προσαύξηση κάθε φορά που πραγματοποιείται επιδιόρθωση ενός ελαττώματος. Ένα
τέτοιο μοντέλο παρουσιάστηκε για πρώτη φορά από τους Jelinski και Moranda (1972)
και η μορφή του παρουσιάζεται στο σχήμα 8.7.

Υπάρχουν δύο προβλήματα με αυτό το μοντέλο. Υποθέτει ότι οι

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

126
 Αξιοπιστία λογισμικού

της αξιοπιστίας απ’ ότι η επισκευή των ελαττωμάτων που εκδηλώνονται πολύ
περιστασιακά.

ROCOF

t1 t2 t3 t4 t5 Χρόνος

Σχήμα 8.7
Μοντέλο λειτουργίας σταθερού βήματος για
την ανάπτυξη της αξιοπιστίας

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

ROCOF Παρατήρησε διαφορετικές βελτιώσεις της αξιοπιστίας

Η επιδιόρθωση του ελαττώματος προσθέτει

νέο ελάττωμα και ελαττώνει την αξιοπιστία

t1 t2 t3 t4 t5
Χρόνος
Σχήμα 8.8
Μοντέλο λειτουργίας τυχαίου βήματος για
την ανάπτυξη της αξιοπιστίας

127
 Αξιοπιστία λογισμικού

Το μοντέλο των Littlewood και Verrall επιτρέπει αρνητική ανάπτυξη της

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

Ο Littlewood (1990) αποδεικνύει ότι δεν υπάρχει ένα καθολικά εφαρμόσιμο

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

Για τη χρήση ενός μοντέλου ανάπτυξης αξιοπιστίας, το λογισμικό ελέγχεται

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

Όταν έχει επιτευχθεί η καλύτερη καμπύλη που προσεγγίζει τα σημεία του

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

128
 Αξιοπιστία λογισμικού

Αξιοπιστία

  = Μετρούμενη αξιοπιστία

Καμπύλη μοντέλου
 αξιοπιστίας προσέγγισης
σημείου




Απαιτού-
μενη
αξιοπιστία

Εκτιμούμενος χρόνος Χρόνος

της επίτευξης της
αξιοπιστίας

Σχήμα 8.9
Πρόβλεψη της
αξιοπιστίας

Μια ολοκληρωμένη συζήτηση πάνω στα μοντέλα ανάπτυξης αξιοπιστίας

απαιτεί γνώση θεωρίας στατιστικής και είναι έξω από τους σκοπούς αυτού του
κεφαλαίου. Ένα σύγγραμμα από τους Abdel-Ghaly et al. (1986) συγκρίνει τα διάφορα
μοντέλα ανάπτυξης αξιοπιστίας που έχουν παρουσιαστεί και ο Littlewood (1990)
περιγράφει και συγκρίνει οκτώ διαφορετικά μοντέλα ανάπτυξης αξιοπιστίας.
Εμπειρία από τη χρήση των μοντέλων ανάπτυξης αξιοπιστίας περιγράφεται από τον
Ehrlich et al. (1990).

 ΣΗΜΕΙΑ ΚΛΕΙΔΙΑ

 Το πιο σημαντικό δυναμικό χαρακτηριστικό ενός συστήματος λογισμικού είναι η

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

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

129
 Αξιοπιστία λογισμικού

 Υπάρχουν πολλοί τρόποι του ποσοτικού προσδιορισμού της αξιοπιστίας. Η

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

 Οι προδιαγραφές αξιοπιστίας είναι συχνά μη ολοκληρωμένες αλλά οι

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

 Ο στατιστικός έλεγχος χρησιμοποιείται για την εκτίμηση της αξιοπιστίας

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

 Τα μοντέλα ανάπτυξης αξιοπιστίας είναι ένας τρόπος εκτίμησης της μεταβολής της
αξιοπιστίας καθώς αναπτύσσεται ένα προϊόν. Δεν πρέπει να υποθέτουν ότι η
αξιοπιστία πάντα αυξάνει με αλλαγές στο σύστημα.

 ΑΝΑΦΟΡΕΣ

Software Reliability Handbook. Αντίθετα με τον τίτλο του, αυτό το βιβλίο έχει πολύ
ευρύτερη εμβέλεια από απλά θέματα αξιοπιστίας. Περιέχει επίσης θαυμάσιες
ενότητες πάνω στις μετρικές και την εξασφάλιση ποιότητας. (P. Rook (ed.), 1990,
Elsevier.)

‘Quantifying software validation: When to stop testing’. Πρόκειται για ένα υπέροχο
άρθρο, που εισάγει τις έννοιες του στατιστικού έλεγχου και της αύξησης της
αξιοπιστίας, και δείχνει πώς αυτές μπορούν να χρησιμοποιηθούν στην κατάστρωση
σχεδίου ελέγχου. Παρέχει λεπτομέρειες σχετικά με πραγματικές εμπειρίες πάνω στον
στατιστικό έλεγχο. (J.D. Musa and A. Frank Ackerman, IEEE Software, 6 (3), 1989.)

Software Reliability: Measurement, Prediction, Application. Αυτό το βιβλίο είναι μία

λεπτομερής περιγραφή της μοντελοποίησης αξιοπιστίας τόσο από μία πρακτική όσο
και από μία θεωρητική άποψη. Εξετάζει σε βάθος τις ιδέες που εισήχθηκαν στο
παραπάνω άρθρο. (J.D. Musa, A. Iannino and K. Okumoto, 1987, McGraw-Hill.)

130
 Επαλήθευση και Επικύρωση

ΚΕΦΑΛΑΙΟ 9: ΕΠΑΛΗΘΕΥΣΗ ΚΑΙ ΕΠΙΚΥΡΩΣΗ

(Verification and Validation)

Σκοπός του κεφαλαίου

Ο σκοπός αυτού του κεφαλαίου, είναι να κάνει μια γενική θεώρηση της διαδικασίας
της επαλήθευσης και της επικύρωσης και να εισάγει τον έλεγχο σαν μία μέθοδο
επικύρωσης. Ο έλεγχος είναι μια διαδικασία πολλαπλών σταδίων τα οποία
αναπτύσσονται στο πρώτο μέρος αυτού του κεφαλαίου. Καλύπτεται ο
προγραμματισμός και ο σχεδιασμός του ελέγχου ενώ προτείνεται και ένα γενικό
περίγραμμα για τα σχέδια ελέγχου. Στο τελευταίο μέρος αυτού του κεφαλαίου,
περιγράφεται μια ποικιλία από στρατηγικές ελέγχου συμπεριλαμβανόμενων του
top-down, bottom-up, thread και stress ελέγχου.

ΠΕΡΙΕΧΟΜΕΝΑ
9.1. Η διαδικασία ελέγχου.
9.2. Σχεδιασμός ελέγχου.
9.3 Στρατηγικές ελέγχου.
9.3.1. Top-down έλεγχος
9.3.2. Bottom-up έλεγχος
9.3.3. Thread έλεγχος
9.3.4. Stress έλεγχος

131
 Επαλήθευση και Επικύρωση

Η επαλήθευση και η επικύρωση ενός συστήματος λογισμικού είναι μια συνεχιζόμενη

διαδικασία μέσα από κάθε στάδιο της διαδικασίας λογισμικού. Η επαλήθευση και η
επικύρωση (E&E), είναι ένας γενικός όρος για τον έλεγχο των διαδικασιών, οι
οποίες διαβεβαιώνουν ότι το λογισμικό ικανοποιεί τις απαιτήσεις και οι απαιτήσεις
ικανοποιούν τις ανάγκες του τελικού χρήστη του λογισμικού. Η E&E, είναι μια
διαδικασία που γίνεται κατά τη διάρκεια όλου του κύκλου ζωής λογισμικού.
Ξεκινάει με την ανασκόπηση των απαιτήσεων και συνεχίζει διαμέσου κανονικών και
δομημένων ανασκοπήσεων για να ολοκληρώσει τον έλεγχο. Έχει δύο
αντικειμενικούς στόχους:
1. Την ανεύρεση των ατελειών του συστήματος.
2. Την εκτίμηση του αν ή όχι το σύστημα είναι χρησιμοποιήσιμο όταν βρίσκεται σε
κατάσταση λειτουργίας.

Η σημαντική διαφορά μεταξύ της επαλήθευσης και της επικύρωσης συνοψίζεται

περιληπτικά από τον Boehm στα εξής :

 Επικύρωση : Χτίζουμε το σωστό προϊόν;

 Επαλήθευση : Χτίζουμε το προϊόν σωστά;

Η Επαλήθευση περιλαμβάνει έλεγχο ότι το πρόγραμμα συμμορφώνεται με τις

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

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

ΣΤΑΤ ΙΚΗ
ΕΠΑΛΗΘΕΥΣΗ

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

ΔΥΝΑΜΙΚΗ
ΠΡΩΤΟΤΥΠΟ ΕΠΙΚΥΡΩΣΗ

Σχήμα 9.1 Στατική και δυναμική επαλήθευση και επικύρωση

132
 Επαλήθευση και Επικύρωση

Οι στατικές τεχνικές συμπεριλαμβάνουν επίβλεψη του προγράμματος, ανάλυση και

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

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

Για να επιτευχθούν οι δύο στόχοι της διαδικασίας E&E υπάρχουν δύο ειδών έλεγχοι :

1. Στατιστικοί έλεγχοι: τα τεστ έχουν σχεδιαστεί έτσι ώστε να καθρεφτίζουν τη

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

2. Έλεγχοι ατελειών: τα τεστ έχουν σχεδιαστεί για να αποκαλύπτουν την παρουσία

των ατελειών στο σύστημα.

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

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

Ο έλεγχος των ατελειών και η αποσφαλμάτωση (debugging), μερικές φορές

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

Υπάρχουν διάφορα στάδια στην διαδικασία αποσφαλμάτωσης (Σχήμα 9.2). Οι

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

133
 Επαλήθευση και Επικύρωση

Σχεδίαση
Εντοπισμός Επιδιόρθωσης Επιδόρθωση Επανέλεγχος
Λάθους Λάθους Λάθους Προγράμματος

Σχήμα 9.2 Η διαδικασία Αποσφαλμάτωσης

Ο μηχανικός που κάνει την αποσφαλμάτωση πρέπει να παράγει παραδοχές σχετικές

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

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

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

9.1. Η ΔΙΑΔΙΚΑΣΙΑ ΕΛΕΓΧΟΥ

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

Η διαδικασία ελέγχου αποτελείται από πέντε στάδια (Σχήμα 9.3) :

1. Έλεγχος μονάδας (units): Μεμονωμένα συστατικά ελέγχονται για να

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

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

134
 Επαλήθευση και Επικύρωση

διαδικασίες και συναρτήσεις. Ένα module εκφράζει συσχετιζόμενα συστατικά

έτσι ώστε να μπορεί να ελεχθεί χωρίς άλλα modules συστήματος.

3. Έλεγχος υποσυστήματος : Αυτή η φάση αφορά έλεγχο συλλογών από modules τα

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

4. Έλεγχος συστήματος : Τα υποσυστήματα ολοκληρώνονται ώστε να απαρτίζουν

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

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

Έλεγχος Έλεγχος Έλεγχος Έλεγχος Έλεγχος

Μονάδας Module Υποσυστήματος Συστήματος Αποδοχής

Έλεγχος Συστατικών Έλεγχος Ολοκλήρωσης Έλεγχος Χρήστη

Σχήμα 9.3 Τα στάδια ελέγχου

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

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

135
 Επαλήθευση και Επικύρωση

ΕΛΕΓΧΟΣ
ΜΟΝΑΔΑΣ

ΕΛΕΓΧΟΣ
MODULE

ΕΛΕΓΧΟΣ
ΥΠΟΣΥΣΤΗΜΑΤΟΣ

ΕΛΕΓΧΟΣ
ΣΥΣΤΗΜΑΤΟΣ

ΕΛΕΓΧΟΣ
ΑΠΟΔΟΧΗΣ

Σχήμα 9.4 Η διαδικασία ελέγχου

Γενικά, η ακολουθία των δραστηριοτήτων ελέγχου είναι: έλεγχος συστατικών,

έλεγχος ολοκλήρωσης (integration testing) και έλεγχος αποδοχής. Όμως, επειδή οι
ατέλειες μπορεί να ανακαλυφθούν σε οποιοδήποτε στάδιο, απαιτούν τροποποιήσεις
προγράμματος προκειμένου να διορθωθούν και αυτό ίσως να απαιτεί την επανάληψη
άλλων σταδίων στην διαδικασία ελέγχου (Σχέδιο 9.4). Τα λάθη στα συστατικά του
προγράμματος, για παράδειγμα, μπορεί να έρθουν στο φως σε ένα μετέπειτα στάδιο
της διαδικασίας ελέγχου. Γι'αυτό η διαδικασία είναι επαναληπτική, με πληροφορίες οι
οποίες ανατροφοδοτούνται από τελευταία στάδια σε νωρίτερα στάδια της
διαδικασίας.

Κατά την επιδιόρθωση ατελειών του προγράμματος μπορεί να εισαχθούν ή να

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

9.2. ΣΧΕΔΙΑΣΜΟΣ ΕΛΕΓΧΟΥ

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

Ο σχεδιασμός του ελέγχου ασχολείται περισσότερα με το να θέσει κάποια πρότυπα

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

136
 Επαλήθευση και Επικύρωση

Το σχέδιο ελέγχου πρέπει να παρέχει αρκετά περιθώρια, έτσι ώστε να μπορούν να

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

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

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

Η προετοιμασία του σχεδίου ελέγχου θα πρέπει να ξεκινά όταν οι απαιτήσεις του

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

137
 Επαλήθευση και Επικύρωση

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

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

Αντικείμενα προς έλεγχο

Τα προϊόντα από την διαδικασία λογισμικού τα οποία επρόκειτο να ελεχθούν πρέπει
να συγκεκριμενοποιηθούν.

Χρονοπρογραμματισμός του ελέγχου

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

Διαδικασίες καταγραφής των tests

Δεν είναι αρκετό απλά να «τρέχουμε» τα tests. Τα αποτελέσματά τους πρέπει να
καταγράφονται συστηματικά. Πρέπει να είναι δυνατό να ελέγχουμε την διαδικασία
ελέγχου ώστε να εξασφαλίζουμε ότι έχει εκτελεστεί σωστά.

Απαιτήσεις υλικού και λογισμικού

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

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

Σχήμα 9.5: Περιεχόμενα Σχεδίου Ελέγχου

Οι έλεγχοι μονάδων και modules μπορεί να είναι υπευθυνότητα των

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

Καθώς είναι φυσιολογικό χαρακτηριστικό για τους ανθρώπους, να νιώθουν μια

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

138
 Επαλήθευση και Επικύρωση

διαβεβαιώσει ότι τα συστατικά έχουν ελεχθεί κανονικά. Μερικά από τα συστατικά

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

Προδιαγραφές Προδιαγραφή Σχεδιασμός Λεπτομερής

Απαιτήσεων Συστήματος Συστήματος Σχεδιασμός

Σχέδιο ελέγχου Σχέδιο Ελέγχου Ανάπτυξη κώδικα

Σχέδιο Ελέγχου
Ολοκλήρωσης Ολοκλήρωσης μονάδων, modules
Αποδοχής
Συστήματος Υποσυστημάτων και ελέγχοι αυτών

Έλεγχος Έλεγχος
Έλεγχος
Υπηρεσία Ολοκλήρωσης Ολοκλήρωσης
Αποδοχής
Συστήματος Υποσυστημάτων

Σχήμα 9.6: Συστατικά Σχεδίου Ελέγχου

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

9.3 ΣΤΡΑΤΗΓΙΚΕΣ ΕΛΕΓΧΟΥ

Υπάρχουν πολλές στρατηγικές ελέγχου πού μπορούν να υιοθετηθούν. Κάθε

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

Οι στρατηγικές ελέγχου περιλαμβάνουν :

1. Έλεγχο top-down
2. Έλεγχο bottom-up
3. Έλεγχο thread
4. Έλεγχο stress

Οποιαδήποτε στρατηγική υιοθετηθεί, είναι πάντα λογικό να υιοθετείται μια

επαυξητική προσέγγιση του ελέγχου του υποσυστήματος και του συστήματος. Αντί

139
 Επαλήθευση και Επικύρωση

να πάρουμε όλα τα modules, να τα συνδυάσουμε και μετά να αρχίσουμε τον έλεγχο,

το σύστημα πρέπει να χτιστεί σε τμήματα. Κάθε τμήμα πρέπει να ελέγχεται πριν να
προστεθεί το επόμενο τμήμα στο σύστημα.

Στο παράδειγμα του σχήματος 9.7, οι έλεγχοι Τ1, Τ2, και Τ3 τρέχουν αρχικά στο
σύστημα που συντίθεται από τα Module Α και Module Β. Μετά την ολοκλήρωση
(integration) του Module C, επαναλαμβάνονται οι ίδιοι έλεγχοι με την προσθήκη και
του ελέγχου Τ4. Στη συνέχεια oλοκληρώνεται το Module D και επαναλάμβανονται οι
προηγούμενοι έλεγχοι στο νέο ολοκληρωμένο σύστημα με την προσθήκη και του
ελέγχου Τ5. Καθώς προστίθενται νέα modules, πρέπει να προστεθούν νέοι έλεγχοι
στο σύνολο των ελέγχων.

T1
A
T1
A
T1 T2
A T2 B

T2 B T3
T3
B C
T3 T4
C
T4
D
T5

Σχήμα 9.7: Επαυξητικός Έλεγχος

Η διαδικασία πρέπει να συνεχιστεί μέχρι όλα τα modules να έχουν ολοκληρωθεί σε

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

9.3.1. Top-down έλεγχος

Ο έλεγχος αυτός αρχίζει με τον έλεγχο των υποσυστημάτων, ενώ modules του
χαμηλότερου επιπέδου αναπαρίστανται σαν stubs. Αυτά είναι απλά συστατικά τα
οποία έχουν τα ίδια χαρακτηριστικά με τα modules (επειδή τα πραγματικά modules
δεν είναι ακόμη διαθέσιμα). Μετά την ολοκλήρωση του ελέγχου των
υποσυστημάτων, συνεχίζεται ο έλεγχος των modules με τον ίδιο τρόπο. Οι
συναρτήσεις αναπαρίστανται από stubs. Τελικά τα συστατικά του προγράμματος
αντικαθίστανται από πραγματικό κώδικα ο οποίος ελέγχεται (Σχήμα 9.8).

140
 Επαλήθευση και Επικύρωση

ΕΠΙΠΕΔΟ 1 ΕΠΙΠΕΔΟ 1
ΑΚΟΛΟΥΘΙΑ ΕΛΕΓΧΟΥ

ΕΠΙΠΕΔΟ 2 ΕΠΙΠΕΔΟ 2 ΕΠΙΠΕΔΟ 2 ΕΠΙΠΕΔΟ 2

STUBS EΠΙΠΕΔΟΥ 1 STUBS ΕΠΙΠΕΔΟΥ 2

Σχήμα 9.8: Έλεγχος top-down

Ο top-down έλεγχος πρέπει να χρησιμοποιείται κατά την top-down ανάπτυξη

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

Με τη χρήση αυτής της τεχνικής, μη εντοπισθέντα λάθη σχεδιασμού μπορούν να

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

Ο top-down έλεγχος έχει και το περαιτέρω πλεονέκτημα ότι, ένα περιορισμένο αλλά
εν λειτουργία σύστημα, είναι διαθέσιμο σε ένα αρχικό στάδιο ανάπτυξης συστήματος.
Αυτή είναι μια σημαντική ψυχολογική ενθάρρυνση γι'αυτούς που έχουν να κάνουν
με την κατασκευή του συστήματος, και επίσης μπορεί να αιτιολογήσει στη διοίκηση
του οργανισμού τη σκοπιμότητα του συστήματος. Η επικύρωση, σαν ξεχωριστή
διαδικασία από την επαλήθευση, μπορεί να ξεκινήσει κατά τα πρώτα στάδια της
διαδικασίας ελέγχου καθώς μπορεί να διατεθεί στους χρήστες ένα σύστημα που
δουλεύει (μερικώς).

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

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

141
 Επαλήθευση και Επικύρωση

μη ρεαλιστικό να δημιουργήσουμε μια τυχαία λίστα και να επιστρέψουμε αυτό το

αντικείμενο. Τα συστατικά της λίστας πρέπει να ανταποκρίνονται στα στοιχεία του
πίνακα. Είναι εξίσου μη ρεαλιστικό για τον προγραμματιστή να εισάγει την
δημιουργημένη λίστα καθώς αυτό απαιτεί γνώση της εσωτερικής αναπαράστασης των
δεικτών. Γι' αυτό η ρουτίνα που εκτελεί την μετατροπή του πίνακα σε λίστα πρέπει να
υπάρχει πριν γίνει ο top-down έλεγχος.

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

9.3.2. Bottom-up έλεγχος

Ο Bottom-up έλεγχος είναι το αντίστροφο του top-down. Αφορά έλεγχο modules στα
χαμηλότερα επίπεδα στην ιεραρχία και μετά έλεγχο προς τα ανώτερα επίπεδα της
ιεραρχίας των modules μέχρις ότου ελεγχθεί το τελικό module (Σχήμα 9.9). Τα
πλεονεκτήματα αυτής της τεχνικής είναι τα μειονεκτήματα της top-down και
αντιστρόφως.

TEST
DRIVERS

ΕΠΙΠΕΔΟ Ν ΕΠΙΠΕΔΟ Ν ΕΠΙΠΕΔΟ Ν ΕΠΙΠΕΔΟ Ν ΕΠΙΠΕΔΟ Ν ΑΚΟΛΟΥΘΙΑ

ΕΛΕΓΧΟΥ

TEST
DRIVERS

ΕΠΙΠΕΔΟ Ν-1 ΕΠΙΠΕΔΟ Ν-1 ΕΠΙΠΕΔΟ Ν-1

Σχήμα 9.9: Έλεγχος Bottom-up

Όταν χρησιμοποιείται bottom-up έλεγχος, πρέπει να γράφονται test drivers για να

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

Εάν η top-down ανάπτυξη συνδυαστεί με τον bottom-up έλεγχο, όλα τα τμήματα του
συστήματος πρέπει να έχουν υλοποιηθεί πρίν αρχίσει ο έλεγχος. Αρχιτεκτονικά λάθη
δεν θα ανακαλυφθούν μέχρις ότου ελεγχθεί ένα μεγάλο μέρος του συστήματος. Η
διόρθωση αυτών των λαθών ίσως να έχει να κάνει με ξαναγράψιμο και επανέλεγχο
των modules των χαμηλότερων επιπέδων του συστήματος.

Εξαιτίας αυτού του προβλήματος, ο bottom-up έλεγχος επικρίθηκε από τους

υποστηριχτές της top-down ανάπτυξης λογισμικού το 1970. Πάντως μια αυστηρή
top-down διαδικασία ανάπτυξης λογισμικού συμπεριλαμβάνοντας έλεγχο είναι μια μη

142
 Επαλήθευση και Επικύρωση

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

να επαναχρησιμοποιηθούν. Ο bottom-up έλεγχος των κρίσιμων συστατικών
συστήματος χαμηλού επιπέδου είναι πάντα αναγκαίος.

9.3.3. Thread έλεγχος

Τα συστήματα πραγματικού χρόνου συχνά φτιάχνονται από ένα πλήθος από

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

Τα συστήματα πραγματικού χρόνου είναι δύσκολο να ελεχθούν λόγω των πολύ

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

Θεωρείστε το σύστημα πραγματικού χρόνου το οποίο αποτελείται από πέντε

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

Το πρώτο στάδιο στη διαδικασία ελέγχου είναι να ελεγχθεί κάθε διαδικασία

ξεχωριστά. Στο μοντέλο του συστήματος που παρουσιάζεται στο Σχήμα 9.10, οι
διαδικασίες Ρ1, Ρ2, Ρ3, Ρ4, και Ρ5 θα πρέπει αρχικά να ελεγχθούν ξεχωριστά και να
αποσφαλματωθούν μέχρις ότου κάθε διαδικασία εμφανίζεται να ικανοποιεί τις
προδιαγραφές της. Μπορούν να χρησιμοποιηθούν οι στρατηγικές Top-down και
Bottom-up.
Ι1(Ρ 1) Ι1 (Ρ 2)

Ι2(Ρ 1) Ρ1

Ρ2
Ι3(Ρ 1)

Ρ3
Ρ5

Ι1 (Ρ3)
Ο1 (Ρ5)
Ρ4
Ο1 (Ρ4)

Ο2 (Ρ4)

Σχήμα 9.10: Αλληλεπιδράσεις διαδικασιών πραγματικού χρόνου

Ο έλεγχος thread είναι μια στρατηγική ελέγχου που ακολουθεί ξεχωριστό έλεγχο
διαδικασιών. Η επεξεργασία κάθε εξωτερικού γεγονότος προκαλεί την εκτέλεση
κάποιου/-ων νήματος/-ων (thread) εντολών μέσα στις διάφορες διαδικασίες του
συστήματος. Το «thread testing» αφορά αναγνώριση και εκτέλεση κάθε πιθανού

143
 Επαλήθευση και Επικύρωση

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

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

Ι1 (Ρ3) Ο1 (Ρ4)
Ρ3 Ρ2 Ρ4

Σχήμα 9.11: Έλεγχος απλού thread

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

Ι2 (Ρ 1) Ο 1 (Ρ5)
Ρ1 Ρ2 Ρ5

Ι3 (Ρ 1)

Σχήμα 9.12: Έλεχγος thread πολλών εισόδων

Ι1 (Ρ 1) Ι1 (Ρ 2)

Ι2 (Ρ 1) Ο 1 (Ρ5)
Ρ1 Ρ2 Ρ5

Ι3 (Ρ 1)

Ο 2 (Ρ 4)
Ρ4

Σχήμα 9.13: Πολλαπλός thread έλεγχος

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

9.3.4. Stress έλεγχος

Μερικές κατηγορίες συστημάτων είναι σχεδιασμένες στο να χειρίζονται ένα

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

144
 Επαλήθευση και Επικύρωση

λειτουργικό σύστημα μπορεί να σχεδιαστεί ώστε να διαχειρίζεται έως 200 ξεχωριστά

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

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

 Ελέγχει την συμπεριφορά αποτυχίας του συστήματος. Μέσα από ένα μη

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

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

Ο stress έλεγχος είναι κατάλληλος για κατανεμημένα συστήματα βασισμένα σε ένα

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

145
 Επαλήθευση και Επικύρωση

ΚΥΡΙΑ ΣΗΜΕΙΑ

 Η επαλήθευση και η επικύρωση δεν είναι το ίδιο πράγμα. Η επαλήθευση έχει

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

 Ο έλεγχος έχει μια διπλή λειτουργικότητα: χρησιμοποιείται για να αποδείξει την

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

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

 Η διαδικασία ελέγχου περιλαμβάνει έλεγχο μονάδας, έλεγχο module, έλεγχο

υποσυστήματος, έλεγχο ολοκλήρωσης και έλεγχο αποδοχής.

 Ο έλεγχος θα έπρεπε να σχεδιάζεται σαν τμήμα της διαδικασίας σχεδιασμού του

έργου. Επαρκή μέσα πρέπει να είναι διαθέσιμα για έλεγχο.

 Οι στρατηγικές ελέγχου που μπορούν να υιοθετηθούν περιλαμβάνουν τον top-

down έλεγχο,τον bottom-up έλεγχο, τον thread και τον stress έλεγχο.

ΒΙΒΛΙΟΓΡΑΦΙΑ

Myers, G.J. (1979). The art of software testing, John Wiley & Sons.
IEEE Software, 6 (3), May 1989.
Comm. ACM, 31 (6), June 1988.

146