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

∆ιαχείριση και Ποιότητα Λογισµικού

ΣηµείωσηΤο ΕΑΠ είναι υπεύθυνο για την επιµέλεια έκδοσης και την ανάπτυξη των κειµένων σύµφωνα µε τη Μεθο-δολογία της εξ Αποστάσεως Εκπαίδευσης. Για την επιστηµονική αρτιότητα και πληρότητα των συγγραµ-µάτων την αποκλειστική ευθύνη φέρουν οι συγγραφείς, κριτικοί αναγνώστες και ακαδηµαϊκοί υπεύθυνοιπου ανέλαβαν το έργο αυτό.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 1

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 2

ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟΣχολή Θετικών Επιστηµών και Τεχνολογίας

Πρόγραµµα Σπουδών

ΠΛHPOΦOPIKH

Θεµατική Ενότητα

EI∆IKA ΘEMATA TEXNOΛOΓIAΣ ΛOΓIΣMIKOY

Τόµος Γ'

∆ιαχείριση και Ποιότητα ΛογισµικούΜΙΧΑΛΗΣ ΞΕΝΟΣ

Λέκτορας Σχολής Θετικών Eπιστηµών & TεχνολογίαςEλληνικό Aνοικτό Πανεπιστήµιο

ΠATPA 2003

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 3

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

Σχολή Θετικών Επιστηµών και Τεχνολογίας

Πρόγραµµα Σπουδών

ΠΛHPOΦOPIKH

Θεµατική Ενότητα

EI∆IKA ΘEMATA TEXNOΛOΓIAΣ ΛOΓIΣMIKOY

Τόµος Γ'

∆IAXEIPIΣH KAI ΠOIOTHTA ΛΟΓΙΣΜΙΚΟΥ

Συγγραφή

MIXAΛHΣ ΞENOΣ

Λέκτορας Σχολής Θετικών Eπιστηµών & Tεχνολογίας

Eλληνικό Aνοικτό Πανεπιστήµιο

Κριτική Ανάγνωση

ΝΙΚΟΛΑΟΣ ΑΒΟΥΡΗΣ

Aναπληρωτής Kαθηγητής Tµήµατος Hλεκτρολόγων Mηχανικών & Tεχνολογίας

Πανεπιστηµίου Πατρών

Ακαδηµαϊκός Υπεύθυνος για την επιστηµονική επιµέλεια του τόµου

ΠΑΝΑΓΙΩΤΗΣ ΠΙΝΤΕΛΑΣ

Kαθηγητής Tµήµατος Mαθηµατικών

Πανεπιστηµίου Πατρών

Επιµέλεια στη µέθοδο της εκπαίδευσης από απόσταση

IΩANNHΣ KOYTΣONIKOΣ

Γλωσσική Επιµέλεια

KΩNΣTANTINOΣ KΛAMΠANIΣTHΣ

Τεχνική Επιµέλεια

EΣΠI EK∆OTIKH E.Π.E.

Καλλιτεχνική Επιµέλεια – Σελιδοποίηση

TYPORAMA

Συντονισµός ανάπτυξης εκπαιδευτικού υλικού και γενική επιµέλεια των εκδόσεων

ΟΜΑ∆Α ΕΚΤΕΛΕΣΗΣ ΕΡΓΟΥ ΕΑΠ / 1997 – 2003

ISBN: 960–538–405–1

Kωδικός Έκδοσης: ΠΛH 42/3

Copyright 2002 για την Ελλάδα και όλο τον κόσµο

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

Οδός Παπαφλέσσα & Υψηλάντη, 262 22 Πάτρα – Τηλ: 2610 314094, 314206 Φαξ: 2610 317244

Σύµφωνα µε το Ν. 2121/1993, απαγορεύεται η συνολική ή αποσπασµατική αναδηµοσίευση του βιβλίου αυτού

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

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 4

¶ÂÚÈÂ¯fiÌÂÓ·

Πρόλογος.................................................................................................................................................................................. 9

K ∂ º ∞ § ∞ π √ 1EÈÛ·ÁˆÁ‹ ÛÙË ¢È·¯Â›ÚÈÛË §ÔÁÈÛÌÈÎÔ‡

Σκοπός, Προσδοκώµενα αποτελέσµατα, Έννοιες κλειδιά, Eισαγωγικές παρατηρήσεις .................................................................................................................................... 13

1.1 ∆ιαχείριση ανάπτυξης λογισµικού ................................................................................................ 16

1.1.1 Bασικές έννοιες ............................................................................................................................... 16

1.1.2 Iδιαιτερότητες στην ανάπτυξη λογισµικού .............................................................. 17

1.1.3 H κρίση του λογισµικού ως πρόβληµα διαχείρισης ......................................... 19

1.2 ∆ιαδικασίες διαχείρισης έργων ........................................................................................................ 21

1.2.1 Aνάλυση διαδικασιών ................................................................................................................ 21

1.2.2 Tεχνικές διαχείρισης ................................................................................................................... 28

1.3 Oι άνθρωποι ...................................................................................................................................................... 38

1.3.1 Mέλος της διοίκησης ................................................................................................................... 38

1.3.2 Yπεύθυνος έργου ή έργων ...................................................................................................... 39

1.3.3 Hγέτης οµάδας .................................................................................................................................. 40

1.3.4 Mηχανικός ανάπτυξης ................................................................................................................ 40

1.3.5 Προγραµµατιστής .......................................................................................................................... 41

1.3.6 Tεχνικοί και υπόλοιπο προσωπικό .................................................................................. 41

1.3.7 Πελάτες ................................................................................................................................................... 42

1.4 Eργασία σε οµάδες ...................................................................................................................................... 43

1.4.1 Tρόποι οργάνωσης οµάδων ................................................................................................... 44

1.4.2 Πλεονεκτήµατα εργασίας σε οµάδες ............................................................................ 44

1.4.3 Oργανόγραµµα ανάπτυξης λογισµικού ....................................................................... 45

Σύνοψη κεφαλαίου και συµβουλές µελέτης .............................................................................................. 47

Βιβλιογραφία και προτάσεις για περαιτέρω µελέτη ........................................................................... 48

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 5

6 ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ∫ ∞ π ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

K ∂ º ∞ § ∞ π √ 2EÎÙ›ÌËÛË Î·È ·Ó¿Ï˘ÛË ÎÈÓ‰‡ÓÔ˘


2.1 Eκτίµηση παραγόντων όπως οι ανάγκες σε ανθρώπνο δυναµικό,το κόστος και ο χρόνος ............................................................................................................................ 54

2.1.1 Eισαγωγή στην εκτίµηση παραγόντων όπως οι ανάγκες σε ανθρώπινο δυναµικό, το κόστος και ο χρόνος ...................................................... 54

2.1.2 Παράγοντες που επιδρούν στην εκτίµηση ................................................................ 57

2.1.3 Mέθοδοι εκτίµησης ....................................................................................................................... 58

2.2 Tεχνικές εκτίµησης και εµπειρικά µοντέλα .......................................................................... 60

2.2.1 Tεχνικές εκτίµησης ....................................................................................................................... 60

2.2.2 Eµπειρικά µοντέλα ........................................................................................................................ 67

2.3 Aνάλυση κινδύνου ...................................................................................................................................... 71



K ∂ º ∞ § ∞ π √ 3EÈÛ·ÁˆÁ‹ ÛÙËÓ ¶ÔÈfiÙËÙ·


3.1 Oρισµοί και ιστορική αναδροµή ..................................................................................................... 80

3.1.1 Ποιότητα και µετρήσεις ............................................................................................................ 80

3.1.2 Bασικές έννοιες ............................................................................................................................... 82

3.1.3 Iστορική αναδροµή στην ποιότητα και στις µετρήσεις ................................. 84

3.2 Ποιότητα στην παραγωγή υλικών αγαθών ............................................................................. 85

3.2.1 ∆ιαχείριση ολικής ποιότητας ............................................................................................... 86

3.2.2 Oι πρώτες απόψεις για την ποιότητα ............................................................................ 87

3.2.3 Στατιστικός έλεγχος ποιότητας .......................................................................................... 88

3.3 Iδιαιτερότητες στην ποιότητα λογισµικού .............................................................................. 90


•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 6


K ∂ º ∞ § ∞ π √ 4¶ÔÈfiÙËÙ· ÏÔÁÈÛÌÈÎÔ‡


4.1 Ποιοτικά χαρακτηριστικά λογισµικού ....................................................................................... 99

4.1.1 Παράγοντες ποιότητας ............................................................................................................. 99

4.1.2 Tο µοντέλο FCM ....................................................................................................................... 101

4.1.3 To µοντέλο του Boehm ........................................................................................................ 103

4.1.4 To πρότυπο ISO 9126 ............................................................................................................ 104

4.2 Σύστηµα ποιότητας λογισµικού .................................................................................................... 108

4.2.1 Eφαρµογή του συστήµατος ποιότητας ................................................................... 109

4.2.2 Xρήστες του συστήµατος ποιότητας ........................................................................ 113

4.2.3 Oφέλη από το σύστηµα ποιότητας ............................................................................. 117

Σύνοψη κεφαλαίου και συµβουλές µελέτης ........................................................................................... 120

Βιβλιογραφία και προτάσεις για περαιτέρω µελέτη ....................................................................... 121

K ∂ º ∞ § ∞ π √ 5MÂÙÚ‹ÛÂÈ˜ Î·È MÂÙÚÈÎ¤˜ ¶ÔÈfiÙËÙ·˜ §ÔÁÈÛÌÈÎÔ‡

Σκοπός, Προσδοκώµενα αποτελέσµατα, Έννοιες κλειδιά, Eισαγωγικές παρατηρήσεις ................................................................................................................................ 123

5.1 Mετρήσεις και µετρικές ....................................................................................................................... 125

5.2 Eσωτερικές µετρήσεις και µετρικές λογισµικού ............................................................ 129

5.2.1 Kυκλωµατική πολυπλοκότητα ......................................................................................... 135

5.3 Eξωτερικές µετρήσεις και µετρικές λογισµικού ............................................................ 139

5.4 Συσχέτιση εσωτερικών και εξωτερικών µετρικών λογισµικού ......................... 142



7¶ E P I E X O M E N A

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 7

K ∂ º ∞ § ∞ π √ 6¶ÚfiÙ˘· ¶ÔÈfiÙËÙ·˜ §ÔÁÈÛÌÈÎÔ‡

Σκοπός, Προσδοκώµενα αποτελέσµατα, Έννοιες κλειδιά, Eισαγωγικές παρατηρήσεις ................................................................................................................................ 147

6.1 Tα διεθνή πρότυπα ISO ....................................................................................................................... 149

6.1.1 To πρότυπο ISO 9001 και η οδηγία ISO 9000–3 .......................................... 151

6.2 To πρότυπο αξιολόγησης CMM ................................................................................................... 156

6.2.1 Oρισµός και εξέλιξη του CMM .................................................................................... 157

6.2.2 CMM και ISO 9001: Oµοιότητες και διαφορές ............................................. 158

6.2.3 Eπίπεδα ωριµότητας στο CMM ................................................................................... 160



Eπίλογος ............................................................................................................................................................................. 167

Aπαντήσεις Aσκήσεων Aυτοαξιολόγησης ............................................................................................... 169

Γενική βιβλιογραφία ................................................................................................................................................ 182

Αλφαβητικό ευρετήριο όρων (ελληνικά – αγγλικά) ........................................................................ 187

Αλφαβητικό ευρετήριο όρων (αγγλικά – ελληνικά) ........................................................................ 193

Γλωσσάρι .......................................................................................................................................................................... 199

8 ™ ∆∞∆ π ™ ∆ π ∫ ∂ ™ ∫ ∞ π O π ∫ √ ¡ √ ª ∂ ∆ ƒ π ∫ ∂ ™ M ∂ £ √ ¢ √ π

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 8

¶ÚfiÏÔÁÔ˜

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

σηµαντικά θέµατα που σχετίζονται µε το λογισµικό. Τη διαχείριση της ανάπτυξης

λογισµικού και την ποιότητα λογισµικού. Το βιβλίο βασίζεται στη µέθοδο της Εκπαί-

δευσης από απόσταση (δηλαδή είναι αναλυτικό, εµπλουτισµένο µε πολλές ασκήσεις

επανάληψης και δραστηριότητες), αλλά είναι και βιβλίο που απευθύνεται σε έµπει-

ρους φοιτητές (δηλαδή σας εισάγει σε αρκετά θέµατα και σας ενθαρρύνει να εµβα-

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

την εµπειρία συγγραφής άλλων δύο βιβλίων για το Ελληνικό Ανοικτό Πανεπιστήµιο,

αλλά κυρίως είχα την εµπειρία του πρώτου χρόνου διδασκαλίας σε συµφοιτητές σας

και εσάς. Αυτή η εµπειρία και οι συζητήσεις µαζί τους µε βοήθησαν να καταλάβω

ακόµα καλύτερα τι θα θέλατε από ένα βιβλίο του Ελληνικού Ανοικτού Πανεπιστηµί-

ου και να προσπαθήσω να το εφαρµόσω στο βιβλίο που κρατάτε στα χέρια σας.

Πριν προχωρήσουµε στην ύλη που καλύπτει το βιβλίο, καλό είναι να σας δώσω µερι-

κές συµβουλές για τη µελέτη σας, τις οποίες, αν θέλετε, µπορείτε να ακολουθήσετε.

Το βιβλίο έχει πολλές ασκήσεις. Αυτές τις ασκήσεις πρέπει να τις χρησιµοποιείτε ως

εργαλεία ελέγχου (για το αν µάθατε καλά) και επανάληψης. Προσέξτε όµως! ∆εν

έχει νόηµα να διαβάσετε µία ενότητα και αµέσως µετά να απαντήσετε στην άσκη-

ση που ακολουθεί. Αντίθετα, διαβάστε τη µία µέρα κάποιες ενότητες και την επό-

µενη (πριν αρχίσετε τη µελέτη σας) δοκιµάστε να λύσετε τις ασκήσεις που αναφέ-

ρονται σε αυτές. Εάν τις λύσετε σωστά, τότε προχωρήστε στην επόµενη ενότητα,

αλλιώς καλύτερα να ξαναδιαβάσετε την προηγούµενη ενότητα και να επαναλάβετε

τις ασκήσεις µέχρι να τις λύνετε σωστά.

Το βιβλίο έχει και δύο τύπους δραστηριοτήτων. Ο πρώτος τύπος είναι οι δραστη-

ριότητες στις οποίες η απάντηση δίνεται µέσα στο βιβλίο. Νοµίζω πως ότι καλύτε-

ρο για τη µελέτη σας είναι να λύνετε αυτές τις δραστηριότητες µόνοι σας (και πριν,

φυσικά, διαβάσετε την απάντηση). Αυτός είναι και ο σκοπός των δραστηριοτήτων.

∆εν θα το βρείτε εύκολο και σε πολλές θα κάνετε λάθη, αλλά µέσα από αυτά τα λάθη

θα µάθετε πολύ καλύτερα από το να διαβάσετε απλώς την απάντηση. Ο άλλος τύπος

δραστηριοτήτων είναι αυτές που δεν λύνονται µέσα στο βιβλίο. Αυτές είναι οι δρα-

στηριότητες για περαιτέρω µελέτη και σας καλούν να ανατρέξετε στη βιβλιογραφία

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

βρείτε κάποια βιβλία) να µην µπορέσετε να τις υλοποιήσετε όλες, αλλά αξίζει να

προσπαθήσετε να ολοκληρώσετε όσο περισσότερες µπορείτε. Συζητήστε τις λύσεις

µε τους Συµβούλους – Καθηγητές σας!

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 9

1 0 ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ∫ ∞ π ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

Ας µιλήσουµε τώρα για την ύλη του βιβλίου. Το βιβλίο οργανώνεται σε 6 κεφάλαια.

Στο 1ο κεφάλαιο, σας εισάγουµε στις βασικές αρχές της διαχείρισης της ανάπτυξης

λογισµικού, παρουζιάσουµε τις βασικές δραστηριότητες που σχετίζονται µε τη δια-

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

τεχόντων στην ανάπτυξη λογισµικού και τρόπους οργάνωσης της ανάπτυξης (εργα-

σίας σε οµάδες, οργάνωση, κτλ).

Στο 2ο κεφάλαιο, γίνεται παρουσίαση των εννοιών της εκτίµησης και της ανάλυσης

κινδύνου. Παρουσιάζονται τεχνικές εκτίµησης και εµπειρικά µοντέλα εκτίµησης µε

σκοπό τη γνώση της εφαρµογής των βασικότερων από αυτές σε έργα λογισµικού.

Επίσης, συζητείται ο τρόπος εντοπισµού και κατηγοριοποίησης των περιπτώσεων

κινδύνου για κάποιο έργο.

Στο 3ο κεφάλαιο, γίνεται η εισαγωγή στις βασικές έννοιες και τους ορισµούς της

ποιότητας γενικά, η σύντοµη περιγραφή των βασικών αρχών της ποιότητας στη βιο-

µηχανική παραγωγή και η εισαγωγή στο στατιστικό έλεγχο της ποιότητας. Επίσης,

η επεξήγηση των ιδιαιτεροτήτων στην ποιότητα λογισµικού, σε σχέση µε την ποιό-

τητα στην παραγωγή υλικών αγαθών.

Στο 4ο κεφάλαιο, αναλύεται η έννοια της ποιότητας λογισµικού σε ποιοτικά χαρα-

κτηριστικά και περιγράφονται τα πιο γνωστά µοντέλα ποιότητας και τα επιµέρους

χαρακτηριστικά κάθε ενός από αυτά. Επίσης, παρουσιάζεται συνοπτικά το σύστηµα

ποιότητας λογισµικού και η χρήση και συνεισφορά του στην ανάπτυξη λογισµικού.

Στο 5ο κεφάλαιο, γίνεται µία εισαγωγή στις µετρήσεις που διεξάγονται στα πλαίσια

ενός συστήµατος ποιότητας λογισµικού µε χρήση µετρικών και η παρουσίαση επι-

λεγµένων µετρικών και τρόπων µέτρησης.

Τέλος, στο 6ο κεφάλαιο, παρουσιάζονται τα πρότυπα που σχετίζονται µε την ανά-

πτυξη του λογισµικού και ειδικότερα τα πρότυπα της σειράς ISO και το πιο εξειδι-

κευµένο στο λογισµικό Capability Maturity Model (CMM).

Στο τέλος κάθε κεφαλαίου υπάρχει η βιβλιογραφία του κεφαλαίου και σχολιασµένα

βιβλία. Τα σχολιασµένα βιβλία είναι βιβλία που µπορείτε να χρησιµοποιήσετε για

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

µερικές σελίδες, µπορείτε, αν θέλετε να εµβαθύνετε, να βρείτε πολυσέλιδα βιβλία

εξειδικευµένα στο θέµα. Θέληση να υπάρχει και η περαιτέρω µελέτη θα αποβεί πολύ-

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

βρείτε είµαι βέβαιος!)

Έχοντας την τύχη να δω ένα βιβλίο µου ήδη να διδάσκεται στο Ελληνικό Ανοικτό

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 10

Πανεπιστήµιο, ξέρω ότι είναι αδύνατο το βιβλίο να µην έχει µερικά λάθη, παρόλο

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

δείτε αυτά τα λάθη µε κατανόηση και –το σηµαντικότερο– να τα επισηµάνετε στο

Σύµβουλο – Καθηγητή σας ώστε να τα διορθώσουµε στην επόµενη έκδοση.

Τελειώνοντας, θέλω να ευχαριστήσω όλους όσοι συνετέλεσαν ώστε να φτάσει το

βιβλίο αυτό στα χέρια σας. Πρώτα από όλα τον Ακαδηµαϊκό Υπεύθυνο Καθηγητή

Παναγιώτη Πιντέλα και τον κριτικό αναγνώστη Αναπληρωτή Καθηγητή Νίκο Αβού-

ρη, που έλεγξαν την επιστηµονική ορθότητα των πρωτοτύπων και µε τις πολύτιµες

παρατηρήσεις τους συνετέλεσαν στη µείωση (ελπίζω και εξάλειψη) των λαθών από

την τελική έκδοση. Επίσης, την Οµάδα Εκτέλεσης Έργου του ΕΑΠ που έλεγξε το

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

Θέλω, επίσης, να ευχαριστήσω τους προπτυχιακούς φοιτητές και µεταπτυχιακούς

φοιτητές µε τους οποίους κατά καιρούς συνεργάστηκα και µε βοήθησαν στη συλ-

λογή του πρωτότυπου υλικού. Ευχαριστώ λοιπόν τους (αλφαβητικά): Γιώτα Ευαγ-

γελιστή, Κωσταντινιά Ζηκούλη, Βασιλική Λάζαρη, Κώστα Λεώνη, Ελένη Μακο-

πούλου, ∆ηµήτρη Σταυρινούδη, Αντωνία Στεφανή και Βασίλη Συρίµπεη. Τέλος, θα

ήθελα να απευθύνω ένα πολύ µεγάλο ευχαριστώ και σε όλους τους συντελεστές του

βιβλίου αυτού που δεν γνωρίζω ακόµα (τεχνικό επιµελητή, γραφίστα, καλλιτεχνικό

επιµελητή, υπεύθυνο σελιδοποίησης, κτλ).

Μιχάλης Ξένος

Λέκτορας

Ελληνικού Ανοικτού Πανεπιστηµίου

1 1¶ ƒ √ § √ ° √ ™

Υ.Γ. Η συγγραφή αυτού του βιβλίου ήταν µεγάλη ευχαρίστηση (ίσως γιατί αγαπάω

πολύ το αντικείµενο)! Ελπίζω να ευχαριστηθείτε κι εσείς τη µελέτη σας!

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 11

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 12

∂ÈÛ·ÁˆÁ‹ ÛÙË ¢È·¯Â›ÚÈÛË §ÔÁÈÛÌÈÎÔ‡

™ÎÔfi˜

Σκοπός του κεφαλαίου 1 είναι να εισάγουµε στις βασικές αρχές της διαχείρισης της

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

νται µε τη διαχείριση καθώς και τεχνικές διαχείρισης και να µιλήσουµε για ρόλους

των συµµετεχόντων στην ανάπτυξη λογισµικού και τρόπους οργάνωσης της ανάπτυ-

ξης (εργασίας σε οµάδες, οργάνωση, κτλ).

¶ÚÔÛ‰ÔÎÒÌÂÓ· ·ÔÙÂÏ¤ÛÌ·Ù·

Όταν θα έχετε ολοκληρώσει τη µελέτη αυτού του κεφαλαίου θα µπορείτε να:

• εξηγήσετε τις βασικές έννοιες και ορισµούς της διαχείρισης λογισµικού,

• εξηγήσετε τις ιδιαιτερότητες στην παραγωγή λογισµικού,

• αναφέρετε τουλάχιστον πέντε λόγους γιατί αποτυγχάνουν έργα ανάπτυξης λογι-

σµικού,

• ορίσετε τα τρία σηµεία στα οποία πρέπει να επικεντρώνει η διαχείριση της ανά-

πτυξης έργων λογισµικού,

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

της ανάπτυξης λογισµικού,

• αναφέρετε και περιγράψετε τις δραστηριότητες που εκτελεί ο υπεύθυνος έργου σε

όλη τη διάρκεια της ανάπτυξης λογισµικού,

• περιγράψετε τι είναι η διαδικασία της ανάθεσης έργου σε ανθρώπινο δυναµικό,

• σχεδιάσετε το διάγραµµα δραστηριοτήτων έργου για ένα συγκεκριµένο και σαφώς

ορισµένο παράδειγµα έργου λογισµικού,

• σχεδιάσετε το διάγραµµα αξιολόγησης έργου για ένα συγκεκριµένο και σαφώς ορι-

σµένο παράδειγµα έργου λογισµικού και να εντοπίσετε τα ορόσηµα και τα κρίσι-

µα µονοπάτια του έργου,

• σχεδιάσετε το χρονοδιάγραµµα έργου και το διάγραµµα ανάθεσης έργου σε ανθρώ-

πινο δυναµικό για ένα συγκεκριµένο και σαφώς ορισµένο παράδειγµα έργου λογι-

σµικού,

• αναφέρετε τους συµµετέχοντες και να περιγράψετε τα ζητούµενα προσόντα και τους

ρόλους τους στην ανάπτυξη λογισµικού,

• σχεδιάσετε το οργανόγραµµα διαχείρισης έργου για ένα συγκεκριµένο και σαφώς

1∫ ∂ º ∞ § ∞ π √

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 13

• ∆ιαχείριση (Management)

• Υπεύθυνος διαχείρισης (Manager)

• Έργο λογισµικού (Software project)

• Υπεύθυνος διαχείρισης έργου λογι-

σµικού (Software project manager)

• ∆ιοίκηση (Administration)

• Προσαρµοσµένο λογισµικό (Custom

software)

• Προγραµµατισµός έργου (Planning)

• Προσπάθεια (Effort)

• Πρόοδος (Progress)

• Έκθεση προόδου (Progress report)

• Tεκµηρίωση (Documentation)

• ∆ίκτυο δραστηριοτήτων (Activity

network)

• ∆ιάγραµµα αξιολόγησης έργου (PERT

Chart)

• Κρίσιµο µονοπάτι (Critical Path)

• Xρονοδιάγραµµα (Gantt chart)

• ∆ιάγραµµα ανάθεσης έργου σε

ανθρώπινο δυναµικό (Staff allocation

chart)

• Προσωπικό (Personnel)

• Ανώτερος υπεύθυνος έργων (Senior

projects manager)

• Προγραµµατιστής (Programmer)

• Ανώτερος προγραµµατιστής (Senior

Programmer)

• Πελάτης (Customer)

• Μη εγωιστικός προγραµµατισµός

(Egoless programming)

• Οργανόγραµµα διαχείρισης έργου

(Project management structure)

∂ÈÛ·ÁˆÁÈÎ¤˜ ·Ú·ÙËÚ‹ÛÂÈ˜

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

διαδικασία µε την οποία επιφορτίζεται ο υπεύθυνος έργου. Στην ενότητα 1.1, θα

παρουσιάσουµε τις βασικές έννοιες και ορισµούς και θα συζητήσουµε για τις ιδιαι-

1 4 K E º A § A I O 1 : ∂ π ™ ∞ ° ø ° ∏ ™ ∆ ∏ ¢ π ∞ Ã ∂ π ƒ π ™ ∏ § √ ° π ™ ª π ∫ √ À

ορισµένο παράδειγµα έργου λογισµικού στο οποίο γνωρίζετε τους συµµετέχοντες

και τους ρόλους τους,

• περιγράψετε τους τρόπους οργάνωσης των οµάδων εργασίας στην ανάπτυξη λογι-

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

τρόπου οργάνωσης,

• αναλύσετε τα πλεονεκτήµατα της εργασίας σε οµάδες.

ŒÓÓÔÈÂ˜ ÎÏÂÈ‰È¿

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 14

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

λεγόµενη κρίση του λογισµικού. Στην ενότητα 1.2 θα αναλύσουµε τις βασικές δρα-

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

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

Θα δούµε επίσης ένα παράδειγµα υπό µορφή δραστηριότητας που θα κληθείτε να υλο-

ποιήσετε πριν διαβάσετε τη δική µας λύση. Στην ενότητα 1.3 θα µιλήσουµε για τους

συµµετέχοντες στην ανάπτυξη λογισµικού το ρόλο τους και συνοπτικά για τα προσό-

ντα που θα πρέπει να έχει ο καθένας από αυτούς. Τέλος, στην ενότητα 1.4 συζητάµε

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

τες κάθε έργου, για τα πλεονεκτήµατα της εργασίας σε οµάδες και για το οργανό-

γραµµα διαχείρισης του έργου.

Για τα περισσότερα σηµεία που καλύπτουµε στο κεφάλαιο αυτό σας παραθέτουµε σχο-

λιασµένη βιβλιογραφία για περαιτέρω µελέτη στο τέλος του κεφαλαίου, όπου µπο-

ρείτε να βρείτε οδηγίες για το τι να διαβάσετε, ώστε να εµπλουτίσετε τη µελέτη σας,

αντλώντας γνώσεις από πολλαπλές πηγές.

1 5∂ π ™ ∞ ° ø ° π ∫ ∂ ™ ¶ ∞ ƒ∞∆ ∏ ƒ ∏ ™ ∂ π ™

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 15


1.1 ¢È·¯Â›ÚÈÛË ·Ó¿Ù˘ÍË˜ ÏÔÁÈÛÌÈÎÔ‡

Στην ενότητα αυτή θα δοθούν αρκετοί βασικοί όροι και έννοιες που θα χρησιµοποι-

ηθούν στο βιβλίο. Οι όροι που παρουσιάζονται για πρώτη φορά δίνονται τόσο στα

Ελληνικά όσο και στα Αγγλικά (σε παρενθέσεις). Αυτό γίνεται ώστε να σας δοθεί η

δυνατότητα να εξοικειωθείτε και µε την αγγλική ορολογία, µια και αρκετή από τη

βιβλιογραφία που παρατίθεται στο τέλος του κεφαλαίου είναι στα αγγλικά.

Στο πρώτο µέρος της ενότητας, µε τίτλο βασικές έννοιες, θα συζητήσουµε για κάποι-

ους ορισµούς που θα χρησιµοποιηθούν σε όλη την έκταση του βιβλίου. Στο δεύτερο

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

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

κών αγαθών και, τέλος, στο τρίτο και τελευταίο µέρος της ενότητας θα συζητήσουµε

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

1.1.1 µ·ÛÈÎ¤˜ ¤ÓÓÔÈÂ˜

Όπως θα προσέξατε ο τίτλος της ενότητας είναι «∆ιαχείριση Ανάπτυξης Λογισµικού».

Με τον όρο «διαχείριση» αποδίδουµε τον αγγλικό όρο «management». Σήµερα έχει

πάντως επικρατήσει να αποδίδεται ο όρος «manager» ως «υπεύθυνος διαχείρισης»

και έτσι θα τον αναφέρουµε στη συνέχεια του βιβλίου. Αν αναζητήσουµε στο «Λεξι-

κό της Νέας Ελληνικής Γλώσσας» του Γ. Μπαµπινιώτη τη σηµασία της λέξης δια-

χείριση, θα βρούµε τον ορισµό που δίνεται δίπλα.

Σαν ορισµός µπορεί να µοιάζει απλός, αλλά στην πραγµατικότητα η διαχείριση ενός

έργου είναι µία πολύ δύσκολη δραστηριότητα στην οποία ο υπεύθυνος διαχείρισης

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

και τεχνολογικούς και οικονοµικούς. Τους παράγοντες αυτούς θα συζητήσουµε στην

ενότητα 1.2 του κεφαλαίου 1.

Ας επανέλθουµε όµως στον τίτλο της ενότητας που µιλά για «ανάπτυξη λογισµικού».

Όπως θα συζητήσουµε στην ενότητα 1.1.2 που ακολουθεί, το λογισµικό δεν κατα-

σκευάζεται µε τρόπο αντίστοιχο µε τα περισσότερα υλικά αγαθά. Με τον όρο «ανα-

πτύσσεται» αποδίδουµε τον αντίστοιχο αγγλικό όρο «engineered». Με την εµπειρία

που έχετε ως τώρα και µε τα µαθήµατα που έχετε διδαχθεί, γνωρίζετε καλά τι σηµαί-

νει τεχνολογία λογισµικού (software engineering) και γιατί διαφέρει από την παρα-

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

πλαίσια των µαθηµάτων που έχετε παρακολουθήσει. Σε αυτό το βιβλίο θα µιλήσου-

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

Σε µία επιχείρηση ή οργανισµό που αναπτύσσει λογισµικό είναι πολύ πιθανό να ανα-

∆ιαχείριση

είναι το σύνολοτων ενεργειών που

κάνει κανείς, γιανα τακτοποιήσει,να επιλύσει ή να

προωθήσει θέµατατης αρµοδιότητάςτου, ο τρόπος µε

τον οποίο τα χειρίζεται

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 16

πτύσσονται παράλληλα αρκετά έργα λογισµικού (software projects). Για κάθε ένα

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

κάποιος υπεύθυνος διαχείρισης έργου λογισµικού (software project manager). Ο

υπεύθυνος διαχείρισης έργου λογισµικού θα αναφέρεται, στο υπόλοιπο του βιβλί-

ου, καθαρά για λόγους συντοµίας και υπεύθυνος έργου.

Ο ορισµός δίπλα είναι πολύ συνοπτικός, αφού για τις ευθύνες, αρµοδιότητες και

εξουσίες του υπεύθυνου έργου θα µιλήσουµε αναλυτικά στην ενότητα 1.3 του κεφα-

λαίου 1. Όπως θα δούµε, ο ίδιος άνθρωπος µπορεί να είναι υπεύθυνος για περισσό-

τερα από ένα έργα.

Ένας ακόµα λόγος που επιλέξαµε τον όρο «υπεύθυνος διαχείρισης έργου λογισµικού»

για τον άνθρωπο που θα έχει την ευθύνη ενός ή περισσοτέρων έργων λογισµικού

είναι για να τονίσουµε τη διαφορά µεταξύ του ρόλου του υπεύθυνου έργου και του

ρόλου του υπεύθυνου για τη διοίκηση της επιχείρησης ή του οργανισµού. Η διοίκη-

ση της επιχείρησης που αναπτύσσει λογισµικό µπορεί να είναι το διοικητικό συµ-

βούλιο ή η συνέλευση των µετόχων (ανάλογα µε το είδος της επιχείρησης ή του

οργανισµού) και όπως θα συζητήσουµε στην ενότητα 1.3 έχει διαφορετικές αρµο-

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

υπόλοιπο του βιβλίου, θα χρησιµοποιούµε τον όρο διοίκηση (administration) για τη

διοίκηση της επιχείρησης ή του οργανισµού χωρίς να εισερχόµαστε σε λεπτοµέρει-

ες για τη µορφή της επιχείρησης και πώς διοικείται.

Πριν προχωρήσουµε στην επόµενη ενότητα, να διευκρινίσουµε ότι όσα θα αναφέ-

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

όπου οι ρόλοι και οι αρµοδιότητες καθενός είναι σαφέστατα καθορισµένες. Αυτό

όµως δεν σηµαίνει ότι όσα διαπραγµατευόµαστε δεν ισχύουν στις µικρές επιχειρή-

σεις που αναπτύσσουν λογισµικό. Στην Ελλάδα υπάρχουν πολλές επιχειρήσεις µε

δύο έως πέντε άτοµα προσωπικό που αναπτύσσουν λογισµικό. Σε τέτοιες περιπτώ-

σεις οι ρόλοι µοιράζονται και κάποιος µπορεί να είναι ταυτόχρονα συνεταίρος, υπεύ-

θυνος έργου και προγραµµατιστής. Τότε οι ανάγκες για επικοινωνία και συντονισµό

είναι µικρότερες, αλλά οι ανάγκες για οργάνωση της διαδικασίας ανάπτυξης είναι

κοινές µε τις µεγάλες επιχειρήσεις και οι τεχνικές που θα καλύψουµε ισχύουν και

πρέπει να εφαρµόζονται.

1.1.2 π‰È·ÈÙÂÚfiÙËÙÂ˜ ÛÙËÓ ·Ó¿Ù˘ÍË ÏÔÁÈÛÌÈÎÔ‡

Με την εµπειρία που έχετε αποκτήσει ήδη από µαθήµατα όπως οι «Αρχές Τεχνολο-

γίας Λογισµικού», γνωρίζετε ότι το λογισµικό ως προϊόν έχει αρκετές ιδιαιτερότη-

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

1 71 . 1 ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ∞ ¡ ∞ ¶ ∆ À • ∏ ™ § √ ° π ™ ª π ∫ √ À

Υπεύθυνος

έργου είναι αυτός

που έχει την

ευθύνη για την

πορεία του έργου,

δηλαδή την τεχνι-

κή, οικονοµική

και διαχειριστική

ευθύνη για το

έργο.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 17


Για την πρώτη διαφορά µιλήσαµε ήδη στην προηγούµενη ενότητα. Το λογισµικό,

όπως γνωρίζετε πολύ καλά, σχεδιάζεται και αναπτύσσεται και δεν κατασκευάζεται

µε τρόπο αντίστοιχο της παραγωγής υλικών αγαθών. Βασικές αρχές της παραγωγής

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

επεξεργασία πρώτων υλών για τη δηµιουργία τµηµάτων του προϊόντος, η σύνθεση

έτοιµων τµηµάτων για τη δηµιουργία του τελικού προϊόντος, η δηµιουργία ενός πρω-

τοτύπου και η έµφαση στην πιστή αναπαραγωγή αντιγράφων µε ελάχιστες αποκλί-

σεις από το πρωτότυπο. Αυτές οι αρχές δεν σχετίζονται άµεσα µε την παραγωγή λογι-

σµικού. Βέβαια ο αντικειµενοστραφής προγραµµατισµός (object – oriented

programming) και ακόµα περισσότερο ο προγραµµατισµός που είναι βασισµένος σε

ψηφίδες (component based programming) έχουν συντελέσει αρκετά στο να θεωρούµε

ότι το λογισµικό αναπτύσσεται µε σύνθεση τµηµάτων, αλλά όχι ακόµα στους ρυθ-

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

Επειδή η τεχνολογία των ηλεκτρονικών υπολογιστών –και κατά συνέπεια και του

λογισµικού– εξελίσσεται µε ταχύτατους ρυθµούς, για αρκετά έργα ανάπτυξης λογι-

σµικού δεν έχουµε καθόλου ιστορικά δεδοµένα, ή τα ιστορικά δεδοµένα δεν είναι

αξιοποιήσιµα. Ιστορικά δεδοµένα αποκαλούµε δεδοµένα από παρόµοια έργα που

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

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

µπορούν να χρησιµοποιηθούν (έστω κι αν προέρχονται από αντίστοιχα έργα) γιατί

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

Η διαδικασία ανάπτυξης λογισµικού δεν είναι τόσο διαφανής όσο είναι η διαδικα-

σία κατασκευής σε αντίστοιχα κατασκευαστικά έργα ή έργα παραγωγής υλικών αγα-

θών, αλλά δεν είναι (ή δεν θα έπρεπε να είναι) αδιαφανής για τον υπεύθυνο του

έργου. Φανταστείτε ένα κατασκευαστικό έργο (π.χ. την κατασκευή ενός σπιτιού) και

πόσο εύκολα ακόµα και κάποιος που δεν έχει γνώση της διαδικασίας ανάπτυξης µπο-

ρεί να παρακολουθεί την εξέλιξη της κατασκευής και δείτε την αντιστοιχία του µε

ένα έργο ανάπτυξης λογισµικού. Στην πραγµατικότητα ένας από τους στόχους της

διαχείρισης της ανάπτυξης λογισµικού είναι η διαφάνεια στην ανάπτυξη. Η διαφά-

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

άλλων, µε την ωριµότητα της επιχείρησης.

Σε έρευνα του Curtis [Cur88] αναφέρεται ότι η πλειοψηφία των έµπειρων διαχειρι-

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

από τον οποίο εξαρτάται η επιτυχία του έργου. Σε αντίθεση µε την παραγωγή υλι-

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

πτυξη λογισµικού, όπου τα εργαλεία και οι τεχνικές εξελίσσονται ραγδαία, η σηµα-

Το λογισµικό αναπτύσσεται δεν κατασκευάζεται.

Για πολλά έργαανάπτυξης

λογισµικού δενυπάρχουν ιστορικά

δεδοµένα.

Η διαδικασία ανάπτυξης

λογισµικού είναισχετικά

αδιαφανής.

Στην ανάπτυξηλογισµικού οι

άνθρωποι είναισηµαντικόςπαράγοντας

της διαδικασίας.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 18

σία των ανθρώπων (µε τις ιδιαιτερότητες που αυτό συνεπάγεται) είναι κυρίαρχη. Επί-

σης, στην ανάπτυξη λογισµικού ένας µεγάλος αριθµός έργων είναι προσαρµοσµένο

λογισµικό (custom software), δηλαδή λογισµικό το οποίο αναπτύσσεται για συγκε-

κριµένο πελάτη ο οποίος εντάσσεται στη διαδικασία ανάπτυξης, γεγονός που εµπλέ-

κει έναν ακόµα ανθρώπινο παράγοντα.

1 91 . 1 ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ∞ ¡ ∞ ¶ ∆ À • ∏ ™ § √ ° π ™ ª π ∫ √ À

ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏfiÁËÛË˜ 1.1

Ακολουθούν µερικές προτάσεις. Ποιες από αυτές είναι σωστές και ποιες λάθος;

∆είτε στο τέλος του βιβλίου τις σωστές απαντήσεις, αλλά και αιτιολόγηση για κάθε

απάντηση.

Σωστό Λάθος

i) Το λογισµικό δεν κατασκευάζεται ούτε αναπτύσσεται,

αλλά διαχειρίζεται.

ii) Ο υπεύθυνος έργου είναι αυτός που έχει την ευθύνη

για την πορεία του έργου.

iii) Ο υπεύθυνος διαχείρισης ενός έργου λογισµικού είναι

πάντα µέλος της διοίκησης του οργανισµού.

iv) Στα έργα ανάπτυξης λογισµικού δεν υπάρχουν ποτέ

ιστορικά δεδοµένα.

v) Η διαχείριση των έργων λογισµικού γίνεται µε αδιαφανείς

διαδικασίες.

1.1.3 ∏ ÎÚ›ÛË ÙÔ˘ ÏÔÁÈÛÌÈÎÔ‡ ˆ˜ Úfi‚ÏËÌ· ‰È·¯Â›ÚÈÛË˜

Σίγουρα έχετε ακούσει για τη λεγόµενη κρίση του λογισµικού. Η κρίση αυτή προ-

κύπτει από το µεγάλο αριθµό έργων λογισµικού που δεν ολοκληρώθηκαν µέσα στα

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

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

στίας του πελάτη, ή δεν σχεδιάστηκαν σωστά µε αποτέλεσµα να µην µπορούν (τµή-

µατα ή στο σύνολό τους) να ξαναχρησιµοποιηθούν.

Τα προβλήµατα αυτά, συνδυαζόµενα µε τις συνεχώς αυξανόµενες απαιτήσεις για

λογισµικό (που ζητείται συνήθως να παραδοθεί άµεσα για να καλύψει αυτές τις ανά-

γκες) έχουν οδηγήσει µεγάλο µέρος του ανθρώπινου δυναµικού να απασχολείται µε

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 19


τη λεγόµενη συντήρηση (maintenance) –που γνωρίζετε ως φάση της ανάπτυξης λογι-

σµικού– και που είναι η φάση κατά την οποία διορθώνουµε, αλλάζουµε ή βελτιώ-

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

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

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

φορές στο βωµό της πυροσβεστικής αντιµετώπισης προβληµάτων παραβιάζονται δοκι-

µασµένες αρχές, µε αποτέλεσµα να επιβεβαιώνουν τη σηµασία αυτών των αρχών για

µία φορά ακόµα. Για παράδειγµα, ενώ ο Brooks [Bro97] τονίζει ότι «προσθέτοντας

ανθρώπους σε ένα έργο που έχει καθυστερήσει θα το καθυστερήσουµε περισσότερο»,

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

Η κρίση του λογισµικού

τις περισσότερεςφορές οφείλεται

σε λάθη διαχείρισης.

¢Ú·ÛÙËÚÈfiÙËÙ· 1.1

Μιλήσαµε για την κρίση του λογισµικού και αναφέραµε ότι πολλά έργα ανάπτυ-

ξης λογισµικού αποτυγχάνουν στην τήρηση του αρχικού τους χρονοδιαγράµµατος.

Χωρίς να ξεπεράσετε τις 300 λέξεις προσπαθήστε –χρησιµοποιώντας την εµπειρία

που έχετε αποκτήσει από τις σπουδές σας– να καταγράψετε και να τεκµηριώσετε

λόγους για τους οποίους συµβαίνει αυτό. Αφού (και µόνο αφού) ολοκληρώσετε τη

δραστηριότητα διαβάστε τι σας προτείνουµε εµείς ως απάντηση παρακάτω. Προ-

σοχή, µελετήστε την απάντηση σαν να είναι διδακτέα ύλη. Ο λόγος που τοποθε-

τούµε τις απαντήσεις (ή υποδείξεις) των δραστηριοτήτων µέσα στο κείµενο είναι

ότι συµπληρώνουν τη διδακτέα ύλη.

Απάντηση

Στο βιβλίο του «The mythical man–month» o Brooks για το ίδιο θέµα παρουσιάζει

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

τήρηση του αρχικού τους χρονοδιαγράµµατος:

i) Οι τεχνικές εκτίµησης είναι ανεπαρκείς µε αποτέλεσµα οι αρχικές εκτιµήσεις να

είναι συνήθως υπερβολικά αισιόδοξες.

ii) Συνήθως συγχέεται η προσπάθεια (effort) µε την πρόοδο (progress) και γίνονται

αριθµητικές πράξεις µε ανθρωποµήνες που συχνά οδηγούν σε σοβαρά λάθη στην

εκτίµηση. (Η λογική ότι ένα τµήµα του έργου που έγινε από 5 ανθρώπους σε 6

µήνες θα µπορέσει να γίνει από 10 ανθρώπους σε 3 µήνες είναι τελείως λάθος,

γιατί θεωρεί ότι οι µήνες και οι άνθρωποι είναι απλές αριθµητικές µονάδες. Αν

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

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 20

µήνας έχει 20 εργάσιµες ηµέρες: τότε µπορούµε να υπολογίσουµε ότι 600 άνθρω-

ποι θα ανέπτυσσαν το ίδιο τµήµα του έργου σε 1 ηµέρα!

iii) Επειδή δεν υπάρχει βεβαιότητα στις εκτιµήσεις, συχνά οι υπεύθυνοι των έργων

δεν έχουν την απαιτούµενη επιµονή στις απαιτήσεις τους.

iv) Η διαδικασία ανάπτυξης δεν είναι εύκολα εποπτευόµενη από τους υπευθύνους.

Αντίθετα συχνά την αντιµετωπίζουν σαν µία τελείως σκοτεινή (αδιαφανή) δια-

δικασία στην οποία περιµένουν να δουν µόνο το τελικό αποτέλεσµα.

v) Τέλος όταν βγούµε εκτός χρονοδιαγράµµατος, συχνά προστίθεται νέο προσωπικό.

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

αν συνεχίσουµε να ρίχνουµε κι άλλο λάδι, σύντοµα θα έρθει η καταστροφή.

1.2 ¢È·‰ÈÎ·Û›Â˜ ‰È·¯Â›ÚÈÛË˜ ¤ÚÁˆÓ

Έχοντας ολοκληρώσει την ενότητα 1.1, έχετε αποκτήσει γνώσεις για βασικούς ορι-

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

λογισµικού. Σε αυτή την ενότητα θα συζητήσουµε τη διαδικασία (process) διαχείρισης

έργων λογισµικού. Θα µιλήσουµε δηλαδή για τις δραστηριότητες που πρέπει να έχει ο

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

Ο Pressman [Pre97] αναφέρει ότι η διαχείριση έργων λογισµικού πρέπει να επικε-

ντρώνει το ενδιαφέρον της σε τρία «P»: People, Problem και Process, που µετα-

φράζονται «Άνθρωποι», «Πρόβληµα» και «∆ιαδικασία». Για τους ανθρώπους θα

µιλήσουµε στην ενότητα 1.3, ενώ το πρόβληµα σχετίζεται µε τις συχνές επαφές µε

τον πελάτη για τον ακριβή καθορισµό των αναγκών του, ώστε να µην καταλήξουµε

να δηµιουργήσουµε λογισµικό που να µην ικανοποιεί τις ανάγκες του πελάτη. Για

την ανάλυση του προβλήµατος θα αναφερθούµε και στο πρώτο τµήµα της ενότητας

1.2.1. Τέλος για τη διαδικασία θα µιλήσουµε σε αυτή την ενότητα.

Η ενότητα χωρίζεται σε δύο τµήµατα, στο πρώτο τµήµα παρουσιάζουµε τις δρα-

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

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

προσεκτικά την απάντηση στη δραστηριότητα 1.3 µε τη µελέτη περίπτωσης (case

study) που θα σας βοηθήσει να κατανοήσετε τη διαδικασία.

1.2.1 ∞Ó¿Ï˘ÛË ‰È·‰ÈÎ·ÛÈÒÓ

Οι βασικές διαδικασίες που αφορούν τη διαχείριση έργων είναι:

• η συγγραφή της αρχικής πρότασης,

2 11 . 2 ¢ π ∞ ¢ π ∫ ∞ ™ π ∂ ™ ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ™ ∂ ƒ ° ø ¡

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 21


• ο προγραµµατισµός του έργου (µε όσα αυτός περικλείει),

• η ανάθεση έργου σε ανθρώπινο δυναµικό,

• η επίβλεψη του έργου και

• η τεκµηρίωση – εκπροσώπηση.

Από αυτές, οι δύο πρώτες γίνονται στα πρώτα στάδια της ανάπτυξης, ενώ οι δύο

τελευταίες είναι συνεχείς διαδικασίες που ο διαχειριστής έργων λογισµικού εκτελεί

σε όλη τη διάρκεια της ανάπτυξης του λογισµικού. Η ανάθεση έργου σε ανθρώπινο

δυναµικό µπορεί είτε να γίνει στα πρώτα στάδια είτε να γίνεται σε συγκεκριµένα

χρονικά σηµεία του έργου, αν και ο καθορισµός των αναγκών θα έχει γίνει στα

πρώτα στάδια.

Συγγραφή αρχικής πρότασης

Τις περισσότερες φορές πριν την εκκίνηση ενός έργου έχει προηγηθεί µία αντίστοι-

χη αρχική πρόταση. Η πρόταση αυτή µπορεί να είναι προς τον πελάτη, ή γενικά προς

κάποιον φορέα χρηµατοδότησης του έργου, ακόµα και προς το διοικητικό συµβού-

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

αρχική ιδέα και µέχρι να ωριµάσει και να ξεκινήσει ένα έργο απαιτούνται πολλές

συναντήσεις µε τον πελάτη, συγγραφή πολλών ενηµερωτικών και τεχνικών κειµέ-

νων, παρουσιάσεις του έργου κτλ. Την εργασία αυτή αναλαµβάνει ο υπεύθυνος έργου

συνεπικουρούµενος από κάποιον ή κάποιους τεχνικούς.

Στην εύλογη ερώτηση «πώς ο υπεύθυνος έργου θα έχει πάντα ιδέες για νέα έργα;»,

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

συνεργασία του µε το προσωπικό που επιβλέπει στα έργα του. Ο καλός υπεύθυνος

έργων θα πρέπει να εµπνέει τους συνεργάτες του ώστε να έχουν ιδέες και προτάσεις

για το αντικείµενό τους και αυτός θα πρέπει µε την εµπειρία του να εντοπίζει αυτές

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

που είχε την αρχική ιδέα (δηλαδή να αναφέρει πάντα την ιδέα ως ιδέα του «Τάδε»).

Ο καλός υπεύθυνος έργων γνωρίζει ότι είναι επίτευγµα και προσόν του να µπορεί

να εντοπίζει και να προωθεί τις καλές ιδέες των υφιστάµενών του και ότι δεν είναι

µειωτικό για αυτόν να είχε κάποιος άλλος µία καλή ιδέα.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 22

Προγραµµατισµός έργου

Η αρχική φάση του προγραµµατισµού (planning) του έργου, την οποία και έχετε διδα-

χθεί στα πλαίσια της τεχνολογίας λογισµικού, εµπεριέχει αρκετές δραστηριότητες

διαχείρισης έργου. Στη φάση αυτή καθορίζονται οι βασικές προδιαγραφές του λογι-

σµικού, γίνεται η κοστολόγηση του έργου, η τιµολόγηση του έργου (εάν είναι έργο

που αναπτύσσεται για συγκεκριµένο πελάτη), η εκτίµηση των µεγεθών του έργου, η

µελέτη του εφικτού, η ανάλυση του ρίσκου, η αρχική τµηµατοποίηση και ο χρονοπρο-

γραµµατισµός του έργου.

Την κοστολόγηση του έργου, την εκτίµηση και την ανάλυση του ρίσκου θα τις συζη-

τήσουµε χωριστά στο κεφάλαιο 2, ώστε να έχουµε την άνεση να τις παρουσιάσουµε πιο

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

(χωρίς να µπαίνουµε σε θέµατα σχεδίασης που ήδη έχετε διδαχθεί) και ο χρονοπρο-

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

Κατά την αρχική τµηµατοποίηση του έργου ο υπεύθυνος έργου αναλαµβάνει να

χωρίσει το έργο σε τµήµατα ώστε να υπολογίσει τις αλληλεξαρτήσεις ανάµεσα στα

τµήµατα και να εκτιµήσει το απαιτούµενο ανθρώπινο δυναµικό. Χρονοπρογραµµα-

τισµός είναι η διαδικασία κατά την οποία γίνεται εκτίµηση του χρόνου που θα πάρει

κάθε τµήµα του έργου. Στο τµήµα 1.2.2 της ενότητας αυτής θα µιλήσουµε για τεχνι-

κές που βοηθούν στην αρχική τµηµατοποίηση και χρονοπρογραµµατισµό του έργου.

2 31 . 2 ¢ π ∞ ¢ π ∫ ∞ ™ π ∂ ™ ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ™ ∂ ƒ ° ø ¡


Σε µία επιχείρηση ο Περικλής είναι υπεύθυνος για ένα έργο ανάπτυξης λογισµι-

κού. Μία νεοδιοριζόµενη προγραµµατίστρια, η Ασπασία έχει µία πολύ καλή ιδέα

ότι ένα τµήµα του έργου που η ίδια ανέπτυξε θα µπορούσε να έχει εµπορική αξία

και να πωλείται αυτόνοµα σε αρκετούς πελάτες, µε κάποια πρόσθετη ανάπτυξη

(νέο έργο). Τι από τα παρακάτω θα ήταν το σωστότερο να κάνει ο Περικλής;

i) Να ετοιµάσει µία πρόταση για το νέο έργο και να την παρουσιάσει ως δική του;

ii) Να ζητήσει από την Ασπασία να ετοιµάσει µία πρόταση για το νέο έργο και

να της προτείνει να την παρουσιάσει αυτή, αφού αυτή είχε και την αρχική ιδέα;

iii) Να συνεργαστεί µε την Ασπασία ώστε να ετοιµάσει αυτός µία πρόταση για

νέο έργο, έχοντας την βοήθεια της Ασπασίας για τα τεχνικά θέµατα και να την

παρουσιάσει µαζί µε την Ασπασία, αναφέροντας ότι είναι ιδέα της Ασπασίας;

iv) Να βγάλει την Ασπασία για δείπνο.

Τα ορόσηµα

πήραν το αγγλικόόνοµά τους«milestones» απότα πέτρινα κολω-νάκια που ήταντοποθετηµέναπαλαιότερα στηνάκρη των δρόµωνκαι έδειχναν σεποιο µίλι βρίσκεταιο οδηγός. Σκοπόςενός ορόσηµουείναι να κάνειπερίπου ότι και τοσυγκεκριµένοκολωνάκι, νακαθορίζει δηλαδήένα σηµαντικόσηµείο του έργουπου σχετίζεται µετην ολοκλήρωσηενός µετρήσιµουστόχου.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 23


Βασικό στοιχείο του χρονοπρογραµµατισµού είναι ο καθορισµός των βασικών ορό-

σηµων (milestones) του έργου. Ο καθορισµός των ορόσηµων είναι σηµαντική και

δύσκολη εργασία που θα βοηθήσει στην επίβλεψη του έργου. Ο Metzer [Met73]

περιγράφει τη σηµασία των ορόσηµων και ορίζει ότι ένα ορόσηµο θα πρέπει να είναι

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

ένα µετρήσιµο ορόσηµο, αλλά η ολοκλήρωση του 50% του κώδικα δεν είναι καλή

επιλογή για ορόσηµο. Πώς θα καταλάβουµε ότι είµαστε στο 50% και όχι στο 45%;

Η επίτευξη ενός ορόσηµου πρέπει να οδηγεί σε τεκµηρίωση µε τη µορφή έκθεσης

προόδου (progress report). Εάν λοιπόν σε ένα έργο τοποθετηθούν πολλά ορόσηµα

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

γραφή αναφορών προόδου. Ο αριθµός των οροσήµων πρέπει να είναι µικρός και να

τοποθετούνται στα σηµαντικά σηµεία του έργου.

Η έκθεση προόδου

(progress report)είναι ένα τεχνικό κεί-

µενο το οποίο συγγρά-φεται (συνήθως απότον υπεύθυνο έργου)

µε την επίτευξηκάποιου ορόσηµου.

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

του έργου µε αφορµήτην επίτευξη

του ορόσηµου.


Στο προηγούµενο τµήµα του βιβλίου µιλήσαµε για την έκθεση προόδου (progress

report). Αφού διαβάσετε τον ορισµό της έκθεσης προόδου στο γλωσσάριο, προ-

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

απαντήσετε) τις δικές µας υποδείξεις που ακολουθούν.

Απάντηση

Υπάρχουν πολλοί δυνατοί τρόποι να γράψει κανείς µία έκθεση προόδου. Έτσι –όπως

θα κάνουµε και σε κάθε δραστηριότητα που δεν έχει µονοσήµαντη λύση– θα σας

δώσουµε υποδείξεις για το τι θα έπρεπε να εντάξετε σε αυτή. Μπράβο σας αν τα

είχατε προβλέψει όλα. Σε αντίθετη περίπτωση, ξαναγράψτε τον πίνακα περιεχοµέ-

νων, έχοντας διαβάσει τις οδηγίες µας.

i) Ανάλυση του χρονοδιαγράµµατος του έργου, δηλαδή καταγραφή του πότε (χρο-

νικά) είχαµε προγραµµατίσει να «πιάσουµε» το συγκεκριµένο ορόσηµο και πότε

πραγµατικά φτάσαµε σε αυτό.

ii) Αιτιολόγηση των αποκλίσεων, δηλαδή επεξήγηση γιατί υπήρξε απόκλιση από

το αρχικό χρονοδιάγραµµα και που (σε ποιους παράγοντες) οφείλεται αυτή.

Προσοχή, αυτή η ανάλυση θα γίνει ακόµα κι αν έχουµε κερδίσει χρόνο, ώστε

να υπάρχει καταγεγραµµένη γνώση γιατί καταφέραµε να ξεπεράσουµε τις αρχι-

κές προσδοκίες.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 24

iii) Ανάλυση των παραδοτέων. Συνήθως ένα ορόσηµο αντιστοιχεί σε παράδοση (ή

ολοκλήρωση) κάποιου σηµαντικού τµήµατος του έργου. Η ολοκλήρωση αυτού

του τµήµατος συνεπάγεται κάποια παραδοτέα, που θα πρέπει να αναγράφονται

και να αναλύονται και στην έκθεση προόδου.

iv) Γενική παρουσίαση της πορείας του έργου και των συνεπειών απόκλισης από

το συγκεκριµένο ορόσηµο. Συνήθως σε κάθε έργο η µη επίτευξη ενός ορόση-

µου στο αρχικά καθορισµένο χρονικό πλαίσιο σηµαίνει ότι και άλλα ορόσηµα

πιθανότατα θα καθυστερήσουν αν δεν γίνουν κάποιες ενέργειες. Η έκθεση προ-

όδου πρέπει να τα επισηµαίνει.

v) Απαιτούµενες ενέργειες (σε περίπτωση προβλήµατος φυσικά) που πρέπει να

γίνουν ώστε να εξαλειφθούν (ή να ελαχιστοποιηθούν) οι συνέπειες από την µη

επίτευξη αυτού του ορόσηµου.

Ανάθεση έργου σε ανθρώπινο δυναµικό

Η ανάθεση έργου σε ανθρώπινο δυναµικό σχετίζεται µε την εκτίµηση που θα συζη-

τήσουµε αναλυτικά στο κεφάλαιο 2. Στα πρώτα στάδια του έργου, ο υπεύθυνος θα

πρέπει να εντοπίσει τις ανάγκες του έργου σε προσωπικό γενικά, αλλά και να ανα-

θέσει συγκεκριµένα τµήµατά του σε κάποιους από τους υφισταµένους του. Προφα-

νώς τµήµατα του έργου που προβλέπεται να αρχίσουν πολύ µετά από την έναρξή

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

θα πρέπει να έχει µεριµνήσει για τη διαθεσιµότητα του προσωπικού. Επειδή η δια-

θεσιµότητα του προσωπικού είναι σηµαντικός παράγοντας για την επιτυχία του

έργου, η ανάθεση έργου σε ανθρώπινο δυναµικό σχετίζεται µε την αρχική τµηµα-

τοποίηση του έργου, όπου θα πρέπει να εξεταστεί ο φόρτος εργασίας που επιφέρει

η παράλληλη εκτέλεση κάποιων τµηµάτων του έργου. Για όλα αυτά όµως θα µιλή-

σουµε περισσότερο στην ενότητα 1.2.2.

Επίβλεψη έργου

Η επίβλεψη του έργου (project monitoring) είναι διαδικασία που εκτελείται σε όλη

τη διάρκεια του έργου. Ο υπεύθυνος του έργου πρέπει να παρακολουθεί όλες τις δια-

δικασίες του έργου (την πορεία και την πρόοδο όλων των τµηµάτων του έργου) και

να συγκρίνει το πραγµατικό µε το αρχικό χρονοδιάγραµµα, το πραγµατικό κόστος

µε την αρχική εκτίµηση και την πραγµατική προσπάθεια υλοποίησης µε την αρχική

εκτίµηση. Οι περισσότερες επιχειρήσεις ή οργανισµοί που παράγουν λογισµικό χρη-

σιµοποιούν συγκεκριµένες τεχνικές (θα µιλήσουµε για µερικές στην ενότητα 1.2.2)

και τα αντίστοιχα εργαλεία και µηχανισµούς, αλλά τις περισσότερες φορές ένας ανώ-

2 51 . 2 ¢ π ∞ ¢ π ∫ ∞ ™ π ∂ ™ ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ™ ∂ ƒ ° ø ¡

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 25


τερος υπεύθυνος έργου µπορεί να µάθει πολύ περισσότερα από µία κατ’ ιδίαν συνά-

ντηση µε το προσωπικό που έχει αναλάβει κάθε τµήµα του έργου. Βέβαια οι συγκε-

κριµένες συναντήσεις συνήθως θα είναι ενταγµένες στη διαδικασία παρακολούθη-

σης και στο µηχανισµό της επιχείρησης.

Στο βιβλίο τους [Kra95] οι Kraul και Streeter, αναλύουν τους διάφορους τρόπους

επικοινωνίας ανάµεσα στα µέλη της οµάδας ανάπτυξης έργου και τον υπεύθυνο του

έργου. Οι τρόποι που προτείνουν µπορούν να συνδυαστούν σε δύο βασικούς τύπους

επικοινωνίας:

• Τυπική επικοινωνία. Περιλαµβάνει την καθορισµένη (τόσο χρονικά, όσο και δια-

δικαστικά) ανταλλαγή αναφορών όπως τεκµηρίωση, παραδοτέα (κώδικας), ανα-

φορές προόδου (ατοµικής και τµήµατος που έχει αναλάβει κάποιος), αναφορές

λαθών ή προβληµάτων, προτάσεις αλλαγών (στο έργο ή στη διαδικασία παρα-

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

τρόπος που γίνεται µπορεί να είναι µε απλό ηλεκτρονικό ταχυδροµείο, ή µε τη

χρήση του ενδοδικτύου (intranet) της επιχείρησης, ή και µε απλή ανταλλαγή

τυπωµένων αναφορών, αν και οι ηλεκτρονικές µέθοδοι έχουν συνήθως καλύτε-

ρα αποτελέσµατα.

• Άτυπη επικοινωνία. Περιλαµβάνει τη διαπροσωπική επικοινωνία του υπεύθυνου

έργου µε κάθε µέλος της οµάδας υλοποίησης, αλλά και τις συναντήσεις οµάδων

για ενηµέρωση και συλλογική επίλυση προβληµάτων, ακόµα και τη δηµιουργία

ενός διευρυµένου κύκλου συναντήσεων στις οποίες θα συµµετέχει και προσωπι-

κό έξω από τα πλαίσια του έργου το οποίο θα κληθεί για να βοηθήσει µε την

εµπειρία του και τις γνώσεις του.

Η τυπική και η άτυπη επικοινωνία είναι το ίδιο σηµαντικοί και συµπληρωµατικοί

µηχανισµοί επικοινωνίας µεταξύ των µελών µίας οµάδας. Οι περισσότερο τυπικές

προσεγγίσεις συνήθως φέρνουν καλύτερα αποτελέσµατα σε επιχειρήσεις ή οργανι-

σµούς µε καλή διοικητική συγκρότηση και υψηλό επίπεδο ωριµότητας (θα συζητή-

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

σουµε για ποιότητα λογισµικού).

Τελειώνοντας πρέπει να τονίσουµε, ότι παρόλο που η επίβλεψη του έργου είναι

σηµαντικότατη δραστηριότητα του υπεύθυνου έργου, αυτός δεν πρέπει να δίνει την

εντύπωση στους υφισταµένους του ότι είναι επιβλέπων, αλλά να δείχνει και να είναι

δάσκαλος για αυτούς, να επισηµαίνει τα λάθη τους, αλλά και να τους κατευθύνει

προς το σωστό δρόµο και να τους διδάσκει µε την εµπειρία του.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 26

Τεκµηρίωση και εκπροσώπηση

Στα πλαίσια αυτής της ενότητας µιλήσαµε πολλές φορές για αναφορές που είναι

ενταγµένες στα πλαίσια των διαδικασιών ανάπτυξης λογισµικού. Όλες αυτές οι ανα-

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

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

πελάτη συνοψίζονται µε τον όρο τεκµηρίωση (documentation). ∆υστυχώς πολλές

φορές η σηµασία της τεκµηρίωσης υποβαθµίζεται επειδή το βασικό παραδοτέο ενός

έργου λογισµικού για πολλούς θεωρείται –κακώς– ότι είναι µόνο το λογισµικό. Για

την αξία της τεκµηρίωσης θα αναφερθούµε συχνά στα πλαίσια αυτού του βιβλίου.

Η τεκµηρίωση αν και θα είναι αρµοδιότητα πολλών από τα µέλη της οµάδας ανά-

πτυξης έργου, θα είναι τελική ευθύνη του υπεύθυνου έργου.

Τέλος, η εκπροσώπηση στα πλαίσια ενός έργου είναι και αυτή ενταγµένη στις διαδι-

κασίες ανάπτυξης έργων λογισµικού. Ο υπεύθυνος έργου θα πρέπει να µπορεί να

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

οργανισµού και να παρουσιάζει την πορεία του έργου, τα προβλήµατα, καθώς και

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

2 71 . 2 ¢ π ∞ ¢ π ∫ ∞ ™ π ∂ ™ ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ™ ∂ ƒ ° ø ¡

Tεκµηρίωση

(documentation)ονοµάζεται κάθεείδος κειµένουπου παράγεταιστα πλαίσια ενόςέργου λογισµικού.




i) Η αρχική τµηµατοποίηση του έργου είναι βασική

διαδικασία σχεδίασης.

ii) Χρονοπρογραµµατισµός είναι η διαδικασία κατά την οποία

γίνεται εκτίµηση του χρόνου που θα χρειαστεί κάθε τµήµα

του έργου.

iii) Ορόσηµα ορίζονται τα σηµεία στα οποία θα πρέπει να γραφεί

µία έκθεση προόδου.

iv) Η επίβλεψη έργου γίνεται από τον υπεύθυνο έργου.

v) Το ενδοδίκτυο προσφέρεται για χρήση σε τυπική επικοινωνία

του υπευθύνου έργου µε την οµάδα ανάπτυξης έργου.

vi) Η τεκµηρίωση του έργου δεν είναι τόσο σηµαντική για έργα

ανάπτυξης λογισµικού, λόγω του κυρίαρχου ρόλου

του λογισµικού.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 27


1.2.2 ∆Â¯ÓÈÎ¤˜ ‰È·¯Â›ÚÈÛË˜

Στην ενότητα 1.2.1 µιλήσαµε για τις διαδικασίες του προγραµµατισµού έργου, της ανά-

θεσης έργου σε ανθρώπινο δυναµικό και της επίβλεψης έργου, χωρίς να παρουσιά-

σουµε τις τεχνικές µε τη βοήθεια των οποίων γίνονται όσα περιγράψαµε. Σε αυτή την

ενότητα θα µιλήσουµε για τις πιο διαδεδοµένες από αυτές τις τεχνικές, δηλαδή το

δίκτυο δραστηριοτήτων έργου, το διάγραµµα αξιολόγησης έργου, το χρονοδιάγραµ-

µα και το διάγραµµα ανάθεσης έργου σε ανθρώπινο δυναµικό. Στο τέλος της ενότη-

τας θα παρουσιάσουµε ένα πλήρες παράδειγµα ως απάντηση της δραστηριότητας 1.5.

∆ίκτυο δραστηριοτήτων έργου

Το δίκτυο δραστηριοτήτων έργου θα το βρείτε στην αγγλική βιβλιογραφία τόσο ως

activity network, όσο και ως task network. Στόχος του είναι να δείξει τις σχέσεις και

εξαρτήσεις ανάµεσα στις διάφορες δραστηριότητες του έργου. Οι δραστηριότητες

αυτές για µεγάλα έργα συχνά ονοµάζονται και τυπικά υποέργα. Στο σχήµα 1.1 µπο-

ρείτε να δείτε ένα παράδειγµα ενός δικτύου δραστηριοτήτων έργου στο οποίο ανα-

λύεται ένα έργο σε 8 τυπικά υποέργα (στο σχήµα συµβολίζονται ως ΤΥ1 … ΤΥ8).

Η σχεδίαση του δικτύου δραστηριοτήτων βοηθά στην καλύτερη αντίληψη των

συσχετίσεων ανάµεσα στα διάφορα τµήµατα στα οποία διασπάται ένα έργο.

To δίκτυο

δραστηριοτήτων

έργου είναι µίαγραφική

αναπαράστασητων διαφόρων


(activities ήtasks) που συνθέ-

τουν ένα έργο.

™¯‹Ì· 1.1

Παράδειγµα

δικτύου δραστη-

ριοτήτων έργου

Aρχή Tέλος

TY 1

TY 2

TY 3

TY 4

TY 5

TY 6

TY 7

TY 8

Στο σχήµα 1.1 µπορούµε να δούµε ότι µε την έναρξη του έργου αρχίζουν παράλλη-

λα δύο τµήµατα του έργου, τα ΤΥ 1 και ΤΥ 2. Για να µπορέσει να αρχίσει το τµήµα

ΤΥ 3 πρέπει να έχουν ολοκληρωθεί και τα δύο προαπαιτούµενα τµήµατα (ΤΥ 1 και

ΤΥ 2). Μόνο µετά από την ολοκλήρωση του τµήµατος ΤΥ 3 θα µπορέσουν να ξεκι-

νήσουν τα ΤΥ 4, ΤΥ 5 και ΤΥ 6, κ.ο.κ. Προσέξτε ότι στο συγκεκριµένο σχήµα µπο-

ρούµε να δούµε µόνο ποιο τµήµα είναι προαπαιτούµενο κάποιου άλλου, αλλά όχι

πληροφορίες όπως ο χρόνος που θα χρειαστεί (κατ’ εκτίµηση) για την υλοποίηση

ενός τµήµατος, ή πληροφορίες για τµήµατα που αν καθυστερήσουν θα καθυστερή-

σει και ολόκληρο το έργο. Αυτές οι πληροφορίες υπάρχουν στο διάγραµµα αξιολό-

γησης έργου το οποίο θα συζητήσουµε ακολούθως και που ουσιαστικά είναι ένα

δίκτυο δραστηριοτήτων έργου µε περισσότερες πληροφορίες.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 28

∆ιάγραµµα αξιολόγησης έργου (διάγραµµα PERT)

Το διάγραµµα αξιολόγησης έργου θα το βρείτε στην αγγλική βιβλιογραφία ως PERT

Chart, όπου PERT προκύπτει από το Program Evaluation and Review Technique. To

PERT Chart είναι ένα δίκτυο δραστηριοτήτων στο οποίο έχουν προστεθεί ορόσηµα

και πληροφορίες για τη διάρκεια κάθε τµήµατος (έναρξη, λήξη, κανονική διάρκεια,

κτλ.). Υπάρχουν διάφορες µορφές που χρησιµοποιούνται για να αναπαρασταθεί ένας

κόµβος σε ένα PERT Chart. Στις πιο απλές µορφές ένα τµήµα έχει τον κωδικό του

και την εκτίµηση για διάρκεια, έναρξη και λήξη, ενώ στις πιο εµπλουτισµένες µορ-

φές, κάθε τµήµα συνοδεύεται από εκτιµήσεις διάρκειας τόσο κανονικές, όσο αισιό-

δοξες και απαισιόδοξες. Στο σχήµα 1.2 παρουσιάζεται ένας κόµβος από ένα είδος

PERT Chart.

Στο σχήµα 1.2, στην πάνω αριστερή γωνία υπάρχει ο αριθµός αναφοράς του κόµβου

(1073 για το παράδειγµα). Οι άλλες τρεις στήλες στο πάνω µέρος είναι εκτίµηση για

τη διάρκεια του έργου σε µήνες. Η µεσαία από τις τρεις στήλες (3 µήνες για το παρά-

δειγµα) αντιστοιχεί στην κανονική εκτίµηση, η πρώτη αντιστοιχεί στην αισιόδοξη

εκτίµηση (2,5 µήνες για το παράδειγµα) και η τελευταία στην απαισιόδοξη εκτίµη-

ση (5 µήνες για το παράδειγµα). Για να είναι πιο φανερή η κανονική ηµεροµηνία έχει

χρωµατιστεί. Στη µέση του κόµβου αναγράφεται η περιγραφή του τµήµατος στο

οποίο αντιστοιχεί ο κόµβος και στο κάτω µέρος η εκτίµηση για την έναρξη (στα αρι-

στερά) και την ολοκλήρωση (στα δεξιά) του τµήµατος. Σε πολλά παραδείγµατα

2 91 . 2 ¢ π ∞ ¢ π ∫ ∞ ™ π ∂ ™ ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ™ ∂ ƒ ° ø ¡

™¯‹Ì· 1.2

Κόµβος

PERT Chart

Aισιόδοξηεκτίµησηδίαρκειας

Kωδικόςκόµβου

Kανονικήεκτίµησηδίαρκειας Aπαισιόδοξη

εκτίµησηδίαρκειας

Περιγραφή

Eκτίµηση γιαηµεροµηνία

λήξης

Hµεροµηνίαέναρξης

1073

TY 7Σχεδίαση Bάσης ∆εδοµένων

15–01–2001 15–04–2001

2,5 µ 3 µ 5 µ

To διάγραµµα

αξιολόγησης

έργου (ProgramEvaluation andReview Techniqueή συνοπτικά PERTChart) είναι µίαγραφική αναπαρά-σταση των διαφό-ρων δραστηριοτή-

των (activities ήtasks) που συνθέ-τουν ένα έργο,εµπλουτισµένη µεπληροφορίες όπωςεκτιµήσεις διάρκει-ας και ορόσηµα.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 29


PERT Chart µπορούν να υπάρχουν πολλές πιθανές ηµεροµηνίες έναρξης (που εξαρ-

τώνται από τις εκτιµήσεις των προαπαιτούµενων τµηµάτων) και πολλές πιθανές ηµε-

ροµηνίες λήξης (που εξαρτώνται τόσο από την ηµεροµηνία έναρξης όσο και από τη

διάρκεια του τµήµατος).

™¯‹Ì· 1.3


PERT Chart

1 5 εβ 6 εβ 8 εβ

TY 1

08–01–07 16–02–07

4 2 εβ 3 εβ 5 εβ

TY 4

09–04–07 27–05–07

2 3 εβ 4 εβ 6 εβ

TY 2

19–02–07 16–03–07

3 6 εβ 7 εβ 9 εβ

TY 3

19–02–07 06–04–07

Στο σχήµα 1.3 παρουσιάζεται ένα έργο που έχει χωριστεί σε 4 τµήµατα. Η ηµερο-

µηνία έναρξης του έργου είναι η 8η Ιανουαρίου 2007 και ως ηµεροµηνία ολοκλή-

ρωσης του έργου έχει προγραµµατιστεί η 27η Απριλίου 2007 (είναι δηλαδή ένα έργο

µε συνολική διάρκεια 16 εβδοµάδες). Αυτές οι ηµεροµηνίες υπολογίζονται µε βάση

την κανονική εκτίµηση για τη διάρκεια του κάθε τµήµατος. Παρατηρήστε ότι έχει

υπολογιστεί κάθε εβδοµάδα να τελειώνει Παρασκευή (π.χ. 16/2/2007)[1] και η επό-

µενη να αρχίζει ∆ευτέρα (π.χ. 19/2/2007). Μετά την ολοκλήρωση των τµηµάτων ΤΥ

2 και ΤΥ 3 υπάρχει ορόσηµο (συµβολίζεται µε ρόµβο). Παρατηρήστε ότι το ΤΥ 4 που

έχει ως προαπαιτούµενα τα ΤΥ 2 και ΤΥ 3 δεν θα αρχίσει µόλις τελειώσει το ΤΥ 2

(που τελειώνει αν όλα πάνε κανονικά νωρίτερα), αλλά µόλις τελειώσουν και τα δύο.

Προσέξτε ότι τα τµήµατα ΤΥ 1, ΤΥ 3 και ΤΥ 4 συνδέονται µε έντονη γραµµή. Αυτό

συµβαίνει γιατί συγκροτούν ένα κρίσιµο µονοπάτι (critical path). Το κρίσιµο µονο-

πάτι ξεκινά από την αρχή του έργου και τελειώνει µε την ολοκλήρωση του έργου,

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

να υπάρχουν πολλά κρίσιµα µονοπάτια ή όλα τα τµήµατα του έργου να είναι ένα

κρίσιµο µονοπάτι. Προσέξτε ότι αν για παράδειγµα καθυστερήσει το ΤΥ 3, τότε θα

καθυστερήσει και η έναρξη του ΤΥ 4 και κατά συνέπεια και όλο το έργο. Το ίδιο θα

συµβεί αν καθυστερήσει το ΤΥ 1.

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

κάθε τµήµα του έργου. Η απάντηση είναι ότι δεν υπάρχει κάποιος «µαγικός» αριθ-

µός που να καθορίζει την ιδανική διάρκεια τµήµατος. Είναι πολύ λογικό τα τµήµα-

Κρίσιµο µονο-

πάτι (criticalpath) είναι µια

αλληλουχία δρα-στηριοτήτων από

τις οποίες ανκαθυστερήσει

κάποια από αυτέςαυτό θα έχει ως

συνέπεια την καθυ-στέρηση όλου του

έργου.

1 Θα ήταν επίσης σωστό (αν και λιγότερο διαδεδοµένο) να τελειώνει Κυριακή (δηλαδή να είναι18/2/07 για το ΤΥ 1) αλλά το αφήσαµε Παρασκευή σεβόµενοι τις ηµέρες αργίας.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 30

τα ενός έργου συνολικής διαρκείας 5 ετών να έχουν µεγαλύτερη διάρκεια από τα

τµήµατα ενός έργου διάρκειας 6 µηνών, αλλά ούτε αυτό είναι απόλυτος κανόνας. Η

εµπειρία έχει δείξει ότι συνήθως τµήµατα έργων που έχουν διάρκεια 6 έως 14 εβδο-

µάδες (δηλαδή 1,5 µήνα µέχρι 3,5 µήνες) είναι πιο εύκολο να διαχειριστούν και να

επιβλέπονται. Πολύ µικρά τµήµατα συνήθως δεν έχουν την απαιτούµενη αυτονοµία

(άρα κακώς ορίστηκαν ως αυτόνοµα τµήµατα), ενώ πολύ µεγάλα τµήµατα συνήθως

θα υποχρεωθούµε να τα χωρίσουµε σε µικρότερα.

3 11 . 2 ¢ π ∞ ¢ π ∫ ∞ ™ π ∂ ™ ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ™ ∂ ƒ ° ø ¡


Όπως παρουσιάζεται το διάγραµµα αξιολόγησης έργου (PERT Chart) στο σχήµα

1.3, γιατί δεν θα µπορούσε να είναι κρίσιµο µονοπάτι και η αλληλουχία των τµη-

µάτων ΤΥ 1, ΤΥ 2, ΤΥ 4; Αιτιολογήστε την απάντησή σας. Αφού απαντήσετε δείτε

και τη δικιά µας απάντηση που ακολουθεί.

Απάντηση

Η αλληλουχία των τµηµάτων ΤΥ 1, ΤΥ 2, ΤΥ 4 ξεκινά από τη αρχή του έργου και

τελειώνει µε το τέλος του έργου όπως κάθε κρίσιµο µονοπάτι. Όµως αν και τα ΤΥ 1

και ΤΥ 4 δεν µπορούν να καθυστερήσουν χωρίς να καθυστερήσει και το έργο ως

συνέπεια αυτής της καθυστέρησης, αντίθετα το ΤΥ 2 µπορεί να καθυστερήσει χωρίς

απαραίτητα αυτό να έχει ως συνέπεια την καθυστέρηση του έργου. ∆είτε στο σχήµα

1.3, ότι το ΤΥ 2 έχει περιθώριο να τελειώσει ακόµα και 3 εβδοµάδες µετά το προ-

γραµµατισµένο χωρίς να επιβραδύνει το έργο, αφού το ΤΥ 4 που έπεται δεν θα ξεκι-

νήσει πριν την ολοκλήρωση του ΤΥ 3. Για αυτό το λόγο, τα ΤΥ 1 και ΤΥ 4 συµµετέ-

χουν στο κρίσιµο µονοπάτι ΤΥ 1 – ΤΥ 3 – ΤΥ 4 και όχι µαζί µε το ΤΥ 2.

Χρονοδιάγραµµα (διάγραµµα Gantt)

Το χρονοδιάγραµµα θα το βρείτε στην αγγλική βιβλιογραφία είτε ως bar chart, είτε

ως timeline chart, είτε ως Gantt chart. Σκοπός του Gantt chart είναι να δείξει, µε

χρήση οπτικών µέσων, το χρόνο που εκτιµάται ότι θα χρειαστεί κάθε τµήµα του

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

επίβλεψης του έργου για παρακολούθηση της προόδου κάθε έργου και του ποσο-

στού ολοκλήρωσης κάθε τµήµατος του έργου.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 31


Στο σχήµα 1.4 παρουσιάζεται ένα παράδειγµα Gantt chart που αντιστοιχεί στο PERT

Chart του σχήµατος 1.3. Στο πάνω µέρος του χρονοδιαγράµµατος υπάρχει µία κλί-

µακα που συνήθως είναι µήνες (ή τρίµηνα) για µεγάλα έργα και εβδοµάδες για µικρά

έργα. Κάθε τµήµα του έργου παρουσιάζεται µε µία οριζόντια µπάρα. Το ποσοστό

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

µατος. Στο σχήµα 1.4 βλέπουµε ότι το ΤΥ 1 έχει ολοκληρωθεί, ενώ τα ΤΥ 2 και ΤΥ

3 είναι σε εξέλιξη και το ΤΥ 4 δεν έχει ξεκινήσει. Το Gantt chart µπορεί να χρησι-

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

θα δούµε στο επόµενο τµήµα της ενότητας.

™¯‹Ì· 1.4


Gantt chart

Mήνες Iανουάριος ’07 Φεβρουάριος ’07 Mάρτιος ’07 Aπρίλιος ’07

Eβδοµάδες

TY 1

TY 2

TY 3

TY 4

8 15 22 29 5 12 19 26 5 12 19 26 2 9 16 23


Αν ο υπεύθυνος έργου έχει µπροστά του το Gantt chart όπως παρουσιάζεται στο

σχήµα 1.4 στις 20/2/2007 τι σηµαίνει αυτό; Το έργο είναι µέσα στους στόχους του

όσο αφορά την ολοκλήρωση εργασιών σε σχέση µε το χρόνο; Πώς είναι η κατά-

σταση σε σχέση µε τις αρχικές εκτιµήσεις; Αφού απαντήσετε διαβάστε και τη δικιά

µας απάντηση που ακολουθεί.

Απάντηση

Όπως παρουσιάζεται στο Gantt chart (δείτε που είναι η γραµµή στις 19/2/2007 και

πόσο την έχουµε ξεπεράσει) το έργο πάει καλύτερα από τις αρχικές εκτιµήσεις. Έχει

ήδη ολοκληρωθεί το ΤΥ 1 και το ποσοστό ολοκλήρωσης των ΤΥ 2 και ΤΥ 3 είναι µεγα-

λύτερο του προγραµµατισµένου για την τρέχουσα χρονική στιγµή. Όµως ενώ η ολο-

κλήρωση του ΤΥ 1 είναι αδιαµφισβήτητο γεγονός η πρόοδος των ΤΥ 2 και ΤΥ 3 δεν θα

έπρεπε να είναι λόγος εφησυχασµού για έναν καλό υπεύθυνο έργου. Πολλές φορές τα

ποσοστά ολοκλήρωσης υπερεκτιµούνται και παρουσιάζονται υπερβολικά αισιόδοξες

εκθέσεις προόδου µε αποτέλεσµα η µόνη ουσιαστική ένδειξη να είναι η πραγµατική

ολοκλήρωση του έργου. Υπάρχει για αυτό και ο λεγόµενος κανόνας του 90–90 [Zah94]

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 32

που σαρκάζει το γεγονός λέγοντας ότι: «το πρώτο 90% του έργου απαιτεί το 90% του

χρόνου, ενώ το υπόλοιπο 10% απαιτεί πάλι το 90% του χρόνου!». Πάντως το γεγονός

ότι αυτό δεν συνέβη στο ΤΥ 1 (το οποίο και έχει ολοκληρωθεί) σηµαίνει ότι πιθανό-

τατα οι εκτιµήσεις είναι σωστές και ότι το έργο πηγαίνει πραγµατικά καλά.

∆ιάγραµµα ανάθεσης έργου σε ανθρώπινο δυναµικό

Το διάγραµµα ανάθεσης έργου σε ανθρώπινο δυναµικό (staff allocation chart) σχετί-

ζει το χρονοδιάγραµµα του έργου µε το προσωπικό που έχει την ευθύνη της υλο-

ποίησης κάθε τµήµατος.

3 31 . 2 ¢ π ∞ ¢ π ∫ ∞ ™ π ∂ ™ ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ™ ∂ ƒ ° ø ¡

™¯‹Ì· 1.5


διαγράµµατος

ανάθεσης έργου

σε ανθρώπινο

δυναµικό

Mήνες Iανουάριος ’07 Φεβρουάριος ’07 Mάρτιος ’07 Aπρίλιος ’07

Eβδοµάδες

Aσπασία

Xρήστος

8 15 22 29 5 12 19 26 5 12 19 26 2 9 16 23

TY 1 30%

TY 1 100%

TY 2 50%

TY 3 100%

TY 4 100%

Στο σχήµα 1.5 παρουσιάζεται ένα παράδειγµα διαγράµµατος ανάθεσης έργου σε

ανθρώπινο δυναµικό, όπου παρατηρούµε ότι για το έργο θα εργαστούν δύο υπάλ-

ληλοι: η Ασπασία και ο Χρήστος. Η Ασπασία θα εργαστεί στο ΤΥ 1, απασχολούµε-

νη σε ποσοστό 30% του χρόνου της (δηλαδή από 8/1/2007 έως 16/2/2007 θα είναι

διαθέσιµη να εργαστεί και κάπου αλλού σε ποσοστό 70% του χρόνου της) και στο

ΤΥ 2 σε ποσοστό 50% του χρόνου της. Ο Χρήστος θα εργαστεί αποκλειστικά (σε

ποσοστό 100%) στο έργο στα TY 1, TY 3 και ΤΥ 4. Με το παραπάνω σχήµα προκύ-

πτουν πληροφορίες για την απαιτούµενη προσπάθεια υλοποίησης, όπως για παρά-

δειγµα ότι για το ΤΥ 1 θα χρειαστούµε συνολικά 7,8 ανθρωποεβδοµάδες (6 x 100%

= 6 του Χρήστου και 6 x 30% = 1,8 της Ασπασίας). Επίσης προκύπτουν πληροφο-

ρίες για τη διαθεσιµότητα του προσωπικού, για παράδειγµα ότι ο Χρήστος θα είναι

«δεσµευµένος» µε το έργο από 8/1/2007 έως 26/4/2007, ή για υπερφόρτωση του προ-

σωπικού (για παράδειγµα αν ο Χρήστος δούλευε και κατά 50% στο ΤΥ 2 τότε στο

ίδιο χρονικό διάστηµα θα έπρεπε να δουλεύει κατά 150% αφού τα ΤΥ 2 και ΤΥ 3

είναι παράλληλα).

Η δραστηριότητα 1.5 που ακολουθεί αφορά τα θέµατα που αναπτύξαµε στην ενό-

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 33


τητα 1.2.2 και θα ήταν καλό πριν προχωρήσετε µε την εκπόνησή της να έχετε κάνει

µία καλή επανάληψη στην αντίστοιχη ύλη.


Ο Περικλής έχει αναλάβει υπεύθυνος ενός νέου έργου µε κωδικό όνοµα «Αρχείο»

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

συστατικά του τη Βάση ∆εδοµένων και το λογισµικό διεπαφής µε τον πελάτη. Μέσα

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

ο έλεγχος και η εγκατάσταση του τελικού συστήµατος στον πελάτη. Μπορείτε να

θεωρήσετε ότι το έργο αποτελείται από τις παρακάτω φάσεις (τυπικά υποέργα):

ΤΥ1 Ανάλυση αναγκών πελάτη

ΤΥ2 Σχεδίαση Βάσης ∆εδοµένων

ΤΥ3 Σχεδίαση Λογισµικού και διεπαφής

ΤΥ4 Ανάπτυξη Βάσης ∆εδοµένων

ΤΥ5 Ανάπτυξη Λογισµικού και διεπαφής

ΤΥ6 Ολοκλήρωση συστήµατος και Έλεγχος

ΤΥ7 Εγκατάσταση στον πελάτη και αποδοχή

Το έργο θα έχει διάρκεια ένα χρόνο (ας υποθέσουµε ότι ξεκινά 1/1/2007) και στη

διάθεση του Περικλή θα είναι ο Γιώργος (ένας έµπειρος αναλυτής συστηµάτων),

η Ασπασία (µία προγραµµατίστρια µε µεγάλη εµπειρία σε πολλά έργα και εξειδί-

κευση σε θέµατα σχεδίασης και ανάπτυξης Βάσεων ∆εδοµένων), η Έλενα (προ-

γραµµατίστρια µε ειδίκευση στην ανάπτυξη διεπαφών χρήστη λογισµικού), ο Σπύ-

ρος (προγραµµατιστής µε εµπειρία και σε έλεγχο συστηµάτων) και η Στέλλα (έµπει-

ρη στον έλεγχο και εγκατάσταση συστηµάτων). Η αρχική εκτίµηση της διοίκησης

σε συνεργασία µε τον Περικλή είναι ότι το έργο θα χρειαστεί λιγότερο από 15

ανθρωποµήνες, που σηµαίνει ότι δεν θα εργαστούν όλοι οι παραπάνω για 12 µήνες

στο 100% του χρόνου τους.

Καλείστε αξιοποιώντας και την εµπειρία που έχετε από τις σπουδές σας έως τώρα,

να βοηθήσετε τον Περικλή και να σχεδιάσετε το δίκτυο δραστηριοτήτων έργου, το

διάγραµµα αξιολόγησης έργου, το χρονοδιάγραµµα έργου και το διάγραµµα ανά-

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

ανθρωποµήνες του έργου και πόσο θα εργαστεί κάθε ένας από το διαθέσιµο προ-

σωπικό. Μη συµπεριλάβετε στους παραπάνω τον Περικλή. Η λύση δεν είναι µονο-

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 34

Απάντηση

Ο Περικλής σχεδίασε το δίκτυο δραστηριοτήτων έργου που φαίνεται στο σχήµα 1.6.

Για λόγους απλότητας στην συνέχεια της απάντησης θα χρησιµοποιούµε τις συντο-

µογραφίες αντί για το πλήρες όνοµα.

3 51 . 2 ¢ π ∞ ¢ π ∫ ∞ ™ π ∂ ™ ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ™ ∂ ƒ ° ø ¡

σήµαντη, άρα η δική σας λύση δεν πρέπει αναγκαστικά να είναι ίδια µε την προ-

τεινόµενη, αλλά ούτε και είναι λογικό να έχει σηµαντικές διαφορές. Αφού γράψε-

τε τη δική σας λύση µελετήστε τη λύση που έδωσε ο Περικλής που ακολουθεί.

™¯‹Ì· 1.7

PERT Chart έργου

«Αρχείο»

™¯‹Ì· 1.6

∆ίκτυο


έργου «Αρχείο»

TY 2

TY 3

TY 4

TY 5

Aρχή TέλοςTY 1 TY 6 TY 7

1 1 µ 1,5 µ 2 µ

TY 1

01–01–07 15–02–07

2 1 µ 1,5 µ 2 µ

TY 2

15–02–07 31–03–07

3 2 µ 2,5 µ 3,5 µ

TY 3

15–02–07 30–04–07

4 2 µ 13 µ 5 µ

TY 4

01–04–07 30–06–07

5 2 µ 3 µ 5 µ

TY 5

01–05–07 31–07–07

6 1 µ 2 µ 3 µ

TY 6

01–09–07 31–10–07

6 1 µ 2 µ 3 µ

TY 7

01–11–07 31–12–07

01–09–07

Με βάση την εµπειρία του ο Περικλής έκανε τις εκτιµήσεις για τη διάρκεια κάθε

τµήµατος που παρουσιάζονται στο σχήµα 1.7. Προσέξτε ότι άφησε αρκετό χρόνο

για τον έλεγχο του συστήµατος και για την εγκατάσταση στον πελάτη, ώστε να εντο-

πιστούν και να διορθωθούν λάθη καθώς και για να ικανοποιηθούν αλλαγές που θα

ζητήσει ο πελάτης µετά την εγκατάσταση του συστήµατος και µέχρι την τελική απο-

δοχή. Επίσης όρισε ως ορόσηµο το σηµείο που το σύστηµα θα έχει ολοκληρωθεί και

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 35


θα είναι έτοιµο προς τον τελικό έλεγχο συστήµατος. Προσέξτε επίσης το κενό που

άφησε το µήνα Αύγουστο (για πιθανές διακοπές στο προσωπικό ή για κάλυψη χαµέ-

νου χρόνου).

Με βάση το PERT Chart του σχήµατος 1.7 το χρονοδιάγραµµα του έργου προκύπτει

εύκολα και παρουσιάζεται στο σχήµα 1.8. (Αν και µικρό έργο δίνουµε την κλίµακα

σε µήνες για να µην «γεµίσει» πολύ το σχήµα.)

™¯‹Ì· 1.8

Χρονοδιάγραµµα

έργου «Αρχείο»

Mήνες

TY1

TY2

TY3

TY4

TY5

TY6

TY7

1 2 3 4 5 6 7 8 9 10 11 12

Τέλος, µε βάση τη διαθεσιµότητα του προσωπικού, τους αρχικούς περιορισµούς σε

χρόνο και τα προσόντα κάθε ενός από τους διαθέσιµους συνεργάτες, ο Περικλής

ετοίµασε το διάγραµµα ανάθεσης έργου σε ανθρώπινο δυναµικό που παρουσιάζεται

στοσχήµα 1.9. Παρατηρήστε ότι προσπάθησε να αξιοποιήσει τη µεγάλη εµπειρία

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

και στην ολοκλήρωση και εγκατάσταση του συστήµατος.

Το σύνολο των ανθρωποµηνών για κάθε τµήµα, για το σύνολο του έργου, αλλά και η

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

τµήµατος, το προσωπικό που συµµετέχει και το ποσοστό συµµετοχής. Έχουµε λοιπόν:

ΤΥ1: 1,5 × 50% για το Γιώργο και 1,5 × 20% για την Ασπασία, σύνολο 1,05 ανθρω-

ποµήνες.

ΤΥ2: 1,5 × 100% για την Ασπασία, σύνολο 1,5 ανθρωποµήνες.

ΤΥ3: 2,5 × 100% για την Έλενα, σύνολο 2,5 ανθρωποµήνες.

ΤΥ4: 3 × 50% για την Ασπασία, σύνολο 1,5 ανθρωποµήνες.

ΤΥ5: 3 × 100% για την Έλενα και 3 × 50% για το Σπύρο, σύνολο 4,5 ανθρωποµήνες.

ΤΥ6: 2 × 50% για το Σπύρο και 2 × 50% για τη Στέλλα, σύνολο 2 ανθρωποµήνες.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 36

ΤΥ7: 2 × 20% για την Ασπασία και 2 × 50% για τη Στέλλα, σύνολο 1,4 ανθρωποµήνες.

Προσθέτοντας τα παραπάνω προκύπτει ότι το σύνολο του έργου είναι 14,45 ανθρω-

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

γισµούς βρίσκουµε τους παρακάτω ανθρωποµήνες: (Γιώργος: 0,75. Ασπασία: 3,7.

Έλενα: 5,5. Σπύρος: 2,5. Στέλλα: 2).

3 71 . 2 ¢ π ∞ ¢ π ∫ ∞ ™ π ∂ ™ ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ™ ∂ ƒ ° ø ¡

Mήνες

Γιώργος

1 2 3 4 5 6 7 8 9 10 11 12

TY 1 50%

Aσπασία

TY 1

Έλενα

Σπύρος

TY 3

20%

100%

TY 2 100%

TY 5 50%

TY 6 50%

Στέλλα TY 6 50%

TY 7 50%

TY 4 50%

TY 5 100%

TY 4 50%

™¯‹Ì· 1.9

∆ιάγραµµα

ανάθεσης έργου σε

ανθρώπινο

δυναµικό για το

έργο «Αρχείο»

Όπως είπαµε η λύση δεν είναι µονοσήµαντη και σας έλειπαν πολλά στοιχεία για να

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

δώσει λύση αντίστοιχη µε αυτή που παρατίθεται παραπάνω. Στόχος της δραστηριό-

τητας ήταν να δούµε ένα παράδειγµα όλων των τεχνικών και όχι να παρουσιάσου-

µε τη λύση του συγκεκριµένου προβλήµατος.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 37


1.3 √È ¿ÓıÚˆÔÈ

Στην ενότητα 1.1.2 αναφέραµε ότι οι άνθρωποι είναι σηµαντικός παράγοντας της

διαδικασίας ανάπτυξης λογισµικού. Για τη σηµασία των ανθρώπων στη διαδικασία

ανάπτυξης λογισµικού µιλήσαµε και στην ενότητα 1.2. Σε αυτή την ενότητα θα ανα-

λύσουµε τους ρόλους κάθε εργαζόµενου σε µία επιχείρηση ή οργανισµό που ανα-

πτύσσει λογισµικό. Θα µιλήσουµε, δηλαδή για το προσωπικό. Οι άνθρωποι που εργά-

ζονται σε µία επιχείρηση ή οργανισµό συνήθως αναφέρονται και ως προσωπικό

(personnel). Μερικές φορές στην αγγλική βιβλιογραφία θα βρείτε τον όρο staff

(θυµηθείτε το staff allocation chart για το οποίο µιλήσαµε στην ενότητα 1.2.2).

Στην ενότητα αυτή θα µιλήσουµε για όσους συµµετέχουν στην ανάπτυξη λογισµι-

κού. Αυτοί είναι το προσωπικό της επιχείρησης ή οργανισµού, αλλά και ο πελάτης.

∆εν θα επεκταθούµε σε τεχνικές λεπτοµέρειες για το τι κάνει καθένας από το προ-

σωπικό, αφού αυτό είναι αντικείµενο της Τεχνολογίας Λογισµικού που έχετε ήδη

διδαχθεί. Επειδή συχνά στα επόµενα κεφάλαια του βιβλίου θα αναφερθούµε στους

συµµετέχοντες στην ανάπτυξη λογισµικού καλό θα ήταν να µελετήσετε προσεκτικά

αυτό το κεφάλαιο πριν προχωρήσετε και γενικά να το συµπεριλάβετε στις επαναλή-

ψεις σας. Εκτός από τους ρόλους που αναφέρουµε σε αυτή την ενότητα υπάρχουν

πολλές ειδικότητες (εξειδικεύσεις των ρόλων) που δεν τις περιγράφουµε. Αφού ολο-

κληρώσετε αυτή την ενότητα και πριν προχωρήσετε στην ενότητα 1.4 δείτε τη δρα-

στηριότητα για περαιτέρω µελέτη 1.1 και προσπαθήστε να υλοποιήσετε ό,τι ζητάει.

1.3.1 ª¤ÏÔ˜ ÙË˜ ‰ÈÔ›ÎËÛË˜

Είπαµε στην ενότητα 1.1.1 ότι θα διαχωρίσουµε το ρόλο του υπεύθυνου έργου από

αυτόν της διοίκησης της επιχείρησης ή του οργανισµού. Σε όλη τη διάρκεια του

βιβλίου θα αναφερόµαστε συχνά απρόσωπα στη διοίκηση του οργανισµού (θα µιλή-

σουµε για παράδειγµα για τη «δέσµευση της διοίκησης στο πρόγραµµα ποιότητας»).

∆εν πρέπει να ξεχνάµε ότι και η διοίκηση γίνεται από ανθρώπους και η άποψη της

διοίκησης εκπροσωπείται από κάποιον άνθρωπο που συνήθως είναι ο Γενικός ∆ιευ-

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

για τη διαχείριση έργων λογισµικού και όχι για κανόνες διοίκησης επιχειρήσεων,

οπότε δεν θα δώσουµε βάρος στους ρόλους, αρµοδιότητες και σκοπούς της διοίκη-

σης. Σκόπιµα στο βιβλίο δεν θα µιλάµε συνήθως σε τρίτο ενικό πρόσωπο για τον

εκπρόσωπο της διοίκησης, αλλά απρόσωπα για τη διοίκηση. Πάντως και για το µέλος

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

είναι ένας άνθρωπος που έχει την ευθύνη να διοικεί ανθρώπους µε ό,τι προβλήµατα

και ιδιαιτερότητες αυτό συνεπάγεται.

Προσωπικό

(personnel) µίαςεπιχείρησης ή

οργανισµού είναιτο σύνολο

των ανθρώπωνπου εργάζονται

σε αυτή.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 38

Η διοίκηση της επιχείρησης ή του οργανισµού έχει ως µέριµνα την επιβίωση της επι-

χείρησης και το κέρδος. Θέλει τα έργα ανάπτυξης λογισµικού να αναπτύσσονται

µέσα στα χρονοδιαγράµµατα (ώστε να συµβάλουν στην καλή εικόνα της επιχείρη-

σης), να κοστίζουν λιγότερο από τα έσοδα που θα αποφέρουν (ώστε να αφήνουν κέρ-

δος) και να δίνουν προοπτική για νέα έργα (είτε µε µεταπώληση τµηµάτων ή και

ολόκληρων έργων, είτε µε ιδέες για νέα έργα). Μια καλή διοίκηση θα πρέπει να

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

ση των συνθηκών ανάπτυξης και των διαδικασιών καθώς και για την ικανοποίηση

του προσωπικού. Στο κεφάλαιο 3 θα µιλήσουµε περισσότερο για τη διοίκηση στα

πλαίσια της «διαχείρισης της ποιότητας», οπότε ας µην επεκταθούµε άλλο σε αυτό

το κεφάλαιο.

1.3.2 ÀÂ‡ı˘ÓÔ˜ ¤ÚÁÔ˘ ‹ ¤ÚÁˆÓ

Μιλήσαµε λίγο για τον υπεύθυνο διαχείρισης έργου λογισµικού ή υπεύθυνο έργου

στην ενότητα 1.1.1. Ουσιαστικά τα δύο πρώτα κεφάλαια του βιβλίου αυτού είναι

αφιερωµένα στον υπεύθυνο έργου, αφού όσα είπαµε στην ενότητα 1.2, αλλά και όλο

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

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

πρότασης και συνεχίζεται µε τον προγραµµατισµό του έργου (στον προγραµµατι-

σµό περιλαµβάνονται η εκτίµηση και ανάλυση ρίσκου που θα αναλύσουµε στο κεφά-

λαιο 2, καθώς και η αρχική τµηµατοποίηση, η ανάθεση έργου σε ανθρώπινο δυνα-

µικό και ο χρονοπρογραµµατισµός που συζητήσαµε στην ενότητα 1.2). Η ευθύνη

του υπεύθυνου έργου είναι ο καθηµερινός έλεγχος του έργου, η επίβλεψη του έργου

και η εκπροσώπηση και τεκµηρίωση που επίσης συζητήσαµε.

Για να µπορεί να επιτυγχάνει όλα τα παραπάνω ο υπεύθυνος έργου πρέπει να είναι

άνθρωπος µε ικανότητες οργανωτικές, αλλά και ηγετικές. Πρέπει να µπορεί να

εµπνέει και να εµψυχώνει τους υφισταµένους του, αλλά και να κατανοεί το προ-

βλήµατα και τις δυσκολίες τους. Για αυτό το λόγο οι καλύτεροι υπεύθυνοι έργων

είναι αυτοί που έχουν εµπλακεί στα διάφορα στάδια της ανάπτυξης και έχουν απο-

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

1.3.4. Επίσης, ο υπεύθυνος έργου πρέπει να µπορεί να επιλύει συστηµατικά προ-

βλήµατα, να αξιοποιεί την εµπειρία του από προηγούµενα έργα και να διαθέτει ευε-

λιξία ώστε να µπορεί να αλλάζει κατεύθυνση προλαβαίνοντας δύσκολες καταστά-

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

στους υφισταµένους του την πρωτοβουλία και να επιτρέπει (και να ενθαρρύνει µε

τις ενέργειές του) την ανάληψη από τους υφισταµένους του πρωτοβουλιών (πάντα

3 91 . 3 √ π ∞ ¡ £ ƒ ø ¶ √ π

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 39


µε µικρό ή ελεγχόµενο ρίσκο). Τέλος πρέπει να µπορεί να «χτίζει» να µεριµνά για

το «δέσιµο» και να επιβλέπει οµάδες εργασίας (για τις οποίες θα µιλήσουµε στην

ενότητα 1.4 που ακολουθεί) που θα αναλαµβάνουν τµήµατα του έργου. Είναι σαφές

ότι τα παραπάνω διδάσκονται, αλλά κυρίως µαθαίνονται στην πράξη και πολλές

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

κάθε ανθρώπου πόσο επιτυχηµένος υπεύθυνος έργου θα γίνει.

Συχνά στη βιβλιογραφία θα βρείτε και τον όρο υπεύθυνοι έργων ή ανώτεροι υπεύθυ-

νοι έργων, που στην αγγλική βιβλιογραφία αποδίδεται ως senior project managers. Οι

ανώτεροι υπεύθυνοι έργων (όπως θα τους αποκαλούµε) έχουν συνήθως διατελέσει για

κάποια χρόνια υπεύθυνοι έργου και έχουν αποδείξει τις ικανότητές τους στην πράξη

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

κάθε επιχείρηση ή οργανισµό και οι απόψεις τους επηρεάζουν σε µεγάλο βαθµό την

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

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

1.3.3 ∏Á¤ÙË˜ ÔÌ¿‰·˜

Συχνά ο ρόλος του ηγέτη (leader) κάποιων ανθρώπων δεν ανήκει αποκλειστικά στον

υπεύθυνο έργου. Ο Edgemon αναφέρει ότι «…πολύ συχνά µέλη του προσωπικού θα

αποκτήσουν τυχαία το ρόλο του ηγέτη για κάποια οµάδα ανθρώπων…». Ακριβώς

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

η ανάγκη κάποιοι άνθρωποι να ηγηθούν κάποιων άλλων στα πλαίσια της οµάδας.

Αυτούς θα τους αποκαλούµε ηγέτες οµάδας, αφού έχουν αναγκαστικά ηγετικό (δια-

χειριστικό ρόλο), χωρίς όµως να έχουν τον τίτλο (και τις ευθύνες) του υπεύθυνου

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

είναι συνήθως φυσική συνέπεια και στην περίπτωση που αποδείξουν τις διαχειρι-

στικές τους ικανότητες φυσική εξέλιξη θα είναι και η µετάβασή τους στο ρόλο του

υπευθύνου έργου.

1.3.4 ªË¯·ÓÈÎfi˜ ·Ó¿Ù˘ÍË˜

Με τον όρο µηχανικός ανάπτυξης (software engineer) θα αποκαλούµε όλους όσοι

έχουν ενεργό ρόλο σε διάφορα στάδια της ανάπτυξης λογισµικού και που ο ρόλος

αυτός απαιτεί γνώσεις τεχνολογίας λογισµικού και δεν περιορίζεται µόνο στον προ-

γραµµατισµό συγκεκριµένων και καθορισµένων τµηµάτων. Χρησιµοποιούµε τον

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

Μηχανικού (ως απόφοιτος συγκεκριµένων σχολών). Ως µηχανικούς ανάπτυξης θεω-

ρούµε τον αναλυτή (analyst), το σχεδιαστή (designer) και το µηχανικό ελέγχου (test

Yπεύθυνοι

έργων ή ανώτεροι

υπεύθυνοι έργων

(senior projectmanagers) είναι

µέλη του προσωπι-κού µιας επιχείρη-σης ή οργανισµούπου έχουν ανέβει

σε ανώτερο διοικη-τικό επίπεδο απόαυτό του υπεύθυ-

νου έργου καιέχουν αναλάβει την

ευθύνη πολλώνέργων.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 40

engineer), ρόλους που γνωρίζετε από την Τεχνολογία Λογισµικού.

Ο αναλυτής είναι υπεύθυνος για την επαφή µε τον πελάτη και τον καθορισµό των

αρχικών προδιαγραφών, ο σχεδιαστής για τον καθορισµό της αρχιτεκτονικής του

συστήµατος, την τµηµατοποίηση του συστήµατος και τις ενδοσυσχετίσεις ανάµεσα

στα τµήµατα και ο µηχανικός ελέγχου έχει την ευθύνη του τελικού ελέγχου ως λευκό

κουτί, δηλαδή τον έλεγχο των δοµών και λειτουργιών του προγράµµατος (Περισ-

σότερα για το θέµα του ελέγχου ως λευκό κουτί δείτε στο βιβλίο του ΕΑΠ «Τεχνο-

λογία Λογισµικού Ι», στην ενότητα 6.3.2.) Όλα αυτά τα µέλη του προσωπικού είναι

µέλη µε σπουδές στην ανάπτυξη λογισµικού (συνήθως έχουν και τον τίτλο του

«µηχανικού λογισµικού») και µε την εµπειρία τους στην ανάπτυξη θα πρέπει να είναι

σε θέση να εξελιχθούν σε ηγέτες οµάδων, αλλά και να συνεισφέρουν µε ιδέες και

προτάσεις τόσο για νέα έργα όσο και για τη βελτίωση και εξέλιξη της διαδικασίας

ανάπτυξης.

1.3.5 ¶ÚÔÁÚ·ÌÌ·ÙÈÛÙ‹˜

Όπως βλέπετε και στον ορισµό ο προγραµµατιστής (programmer) είναι αυτός που θα

αναλάβει τη βασική εργασία της ανάπτυξης λογισµικού, δηλαδή τη συγγραφή του

κώδικα. Τη δραστηριότητα αυτή θα την ακούσετε ως προγραµµατισµό

(programming), συγγραφή κώδικα (code authoring), κωδικοποίηση (coding), κτλ αν

και έχει επικρατήσει η λέξη προγραµµατισµός. Πολλοί προγραµµατιστές που έχουν

σπουδές στην ανάπτυξη λογισµικού και γνώσεις πολλών γλωσσών προγραµµατι-

σµού συνήθως καλούνται ανώτεροι προγραµµατιστές (senior programmers) και πέρα

από τον προγραµµατισµό έχουν ως ρόλο και την καθοδήγηση των νέων προγραµ-

µατιστών στις διαδικασίες και µεθόδους ανάπτυξης. Συχνά άνθρωποι που έχουν

σπουδάσει ως µηχανικοί λογισµικού ξεκινούν την εργασία τους σε κάποια επιχεί-

ρηση ή οργανισµό ως ανώτεροι προγραµµατιστές και σύντοµα εξελίσσονται στο

ρόλο του µηχανικού ανάπτυξης.

1.3.6 ∆Â¯ÓÈÎÔ› Î·È ˘fiÏÔÈÔ ÚÔÛˆÈÎfi

Υπόλοιπο προσωπικό µιας επιχείρησης ή οργανισµού είναι τεχνικό προσωπικό που

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

τεχνικές εγκαταστάσεις, συσκευασίες, υποστήριξη, κτλ. (Περισσότερα για το θέµα

του ελέγχου ως µαύρο κουτί δείτε στο βιβλίο του ΕΑΠ «Τεχνολογία Λογισµικού Ι»,

στην ενότητα 6.3.2.) Επίσης µία επιχείρηση ή οργανισµός έχει διοικητικό προσωπι-

κό, τµήµα προσωπικού µε τους ανθρώπους που είναι υπεύθυνοι για τη µισθοδοσία

και τη στελέχωση της επιχείρησης, τµήµα πωλήσεων και προώθησης προϊόντων

4 11 . 3 √ π ∞ ¡ £ ƒ ø ¶ √ π

Ο προγραµµατι-

στής (programmer)είναι αυτός που γνω-ρίζει µία γλώσσαπρογραµµατισµού καιτου δίνονται προδια-γραφές ώστε να υλο-ποιήσει ένα τµήµαλογισµικού σε αυτήτη γλώσσα.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 41


(marketing), γραµµατειακό προσωπικό, κτλ. Όλοι αυτοί οι άνθρωποι είναι µέλη του

προσωπικού µιας επιχείρησης και συχνά έχουν εξίσου σηµαντική συµβολή στην επι-

τυχία (ή αποτυχία) ενός έργου λογισµικού όσο και αυτοί που είναι επιφορτισµένοι

µε αυτές καθαυτές τις διαδικασίες ανάπτυξης.

1.3.7 ¶ÂÏ¿ÙÂ˜

Ο πελάτης (customer), που συχνά αναφέρεται και ως χρήστης (user) του λογισµικού,

δεν είναι µέλος του προσωπικού της επιχείρησης ή οργανισµού. Είναι όµως αναπό-

σπαστο µέλος της διαδικασίας ανάπτυξης λογισµικού και του προγράµµατος ποιότη-

τας για το οποίο θα µιλήσουµε σε επόµενα κεφάλαια του βιβλίου. Όπως θα διδαχθείτε

σε αυτό το βιβλίο, ένα από τα σηµαντικότερα λάθη της ανάπτυξης λογισµικού είναι

να εξαιρέσει τον πελάτη από τη διαδικασία ανάπτυξης και το πρόγραµµα ποιότητας.

Υπάρχουν πολλοί διαφορετικοί ρόλοι του πελάτη όπως: α) ο πελάτης – χρήστης, που

θα αγοράσει λογισµικό γενικής χρήσης που έχει ετοιµασθεί βασισµένο σε γενικές

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

που έχει κατασκευαστεί εξειδικευµένα για τις δικές του ανάγκες, γ) ο πελάτης – ορι-

στής, που ορίζει τις προδιαγραφές λειτουργικότητας του λογισµικού και δ) ο πελά-

της – χρηµατοδότης, που επενδύει στην ανάπτυξη του λογισµικού. Πολλές φορές

όλους αυτούς τους εµπλεκόµενους στην ανάπτυξη λογισµικού θα τους αποκαλούµε

πελάτες, εκτός αν οι συνθήκες µας επιβάλλουν να το διαχωρίσουµε.

Ας δούµε το εξής παράδειγµα: Έστω ότι το Ελληνικό Ανοικτό Πανεπιστήµιο θέλει να

αναπτύξει ένα κόµβο ενηµέρωσης των ενδιαφεροµένων στο διαδίκτυο. Απευθύνεται

στο Υπουργείο Εθνικής Παιδείας και Θρησκευµάτων (πιθανότατα υποβάλλοντας πρό-

ταση για χρηµατοδότηση) και αφού πάρει την έγκριση αναθέτει (µετά από διαγωνι-

σµό) σε µια εταιρία την ανάπτυξη. Η εταιρία αυτή θα έχει ως πελάτη – χρηµατοδότη

το Υπουργείο, ως πελάτη – οριστή το Ελληνικό Ανοικτό Πανεπιστήµιο, ενώ πελάτες

– χρήστες θα είναι όλοι οι ενδιαφερόµενοι που θα επισκέπτονται τον κόµβο.

¢Ú·ÛÙËÚÈfiÙËÙ· ÁÈ· ÂÚ·ÈÙ¤Úˆ ÌÂÏ¤ÙË 1.1

Εκτός από τις κατηγορίες που αναφέραµε στην ενότητα 1.3 υπάρχουν και πολλές

άλλες κατηγορίες εµπλεκοµένων στην ανάπτυξη λογισµικού που πηγάζουν από τις

πιο σύνθετες ανάγκες των επιχειρήσεων που παράγουν λογισµικό. Αν αναζητήσε-

τε τις αγγελίες που ζητούν προσωπικό δεν θα δείτε «ζητείται προγραµµατιστής»,

αλλά κάτι σαν «ζητείται στέλεχος εταιρίας πληροφορικής µε γνώσεις Java και εµπει-

ρία σε πρωτόκολλα TCP – IP». Στην πραγµατικότητα και η δεύτερη αγγελία ζητά-

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 42

1.4 ∂ÚÁ·Û›· ÛÂ ÔÌ¿‰Â˜

Στην προηγούµενη ενότητα µιλήσαµε αρκετά για την εργασία σε οµάδες και για τον

ηγέτη της οµάδας. Σε αυτή την ενότητα θα µιλήσουµε για τους τρόπους που µπο-

ρούν να οργανωθούν οι οµάδες που µετέχουν στην ανάπτυξη λογισµικού και για τα

πλεονεκτήµατα της οµαδικής εργασίας στην ανάπτυξη λογισµικού και θα παρου-

σιάσουµε το οργανόγραµµα ανάπτυξης.

4 31 . 4 ∂ ƒ °∞ ™ π ∞ ™ ∂ √ ª ∞ ¢ ∂ ™

ει προγραµµατιστή µε εξειδικευµένες γνώσεις για να καλύψει τις ανάγκες κάποι-

ου συγκεκριµένου έργου. Το ζητούµενο αυτής της δραστηριότητας είναι να ανα-

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

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

5 διαφορετικές ειδικότητες και να τις αντιστοιχίσετε µε τις ειδικότητες όπως παρου-

σιάζονται σε αυτή την ενότητα. Καταγράψτε επίσης ποιες από αυτές αντιστοιχούν

σε ειδικότητες που αναφέραµε και ποιες είναι κάτι εντελώς νέο.




i) Προσωπικό µίας επιχείρησης είναι όλοι όσοι συµµετέχουν

στην ανάπτυξη λογισµικού.

ii) Ο ανώτερος υπεύθυνος έργων συµµετέχει και στη διοίκηση

του οργανισµού ή της επιχείρησης.

iii)Η δηµιουργία οµάδων στα πλαίσια ενός έργου δηµιουργεί

την ανάγκη κάποιοι άνθρωποι να ηγηθούν αυτών

των οµάδων, ώστε να είναι πιο εύκολο το έργο

του υπεύθυνου έργου.

iv) Ο προγραµµατιστής αναλαµβάνει και την σχεδίαση


v) Ο πελάτης, αν και δεν ανήκει στο προσωπικό

της επιχείρησης, πρέπει να εντάσσεται στη διαδικασία

ανάπτυξης λογισµικού.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 43


1.4.1 ∆ÚfiÔÈ ÔÚÁ¿ÓˆÛË˜ ÔÌ¿‰ˆÓ

Ο Mantei [Man81] αναφέρει ότι η σύνθεση και ο τρόπος οργάνωσης των οµάδων

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

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

τείται και µία σειρά από άλλους –λιγότερο σηµαντικούς– παράγοντες που επηρεά-

ζουν τον τρόπο που θα πρέπει να οργανωθεί µία οµάδα ανάπτυξης. Προτείνει τρεις

τρόπους οργάνωσης µίας οµάδας ανάλογα µε τους παράγοντες του έργου: δηµο-

κρατικά οργανωµένη, αποκεντρωµένα διοικούµενη και κεντρικά διοικούµενη.

Στις δηµοκρατικά οργανωµένες οµάδες δεν υπάρχει ηγέτης οµάδας, αν και για κάποιο

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

σει σε κάποιον άλλο το ρόλο του ηγέτη για το επόµενο πρόβληµα που µε τη σειρά

του θα τον αφήσει σε κάποιον άλλο. Έτσι όλα τα µέλη της οµάδας θα έχουν την

ευκαιρία να την ηγηθούν κατά διαστήµατα. Όλα τα προβλήµατα θα συζητούνται από

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

Στις αποκεντρωµένα διοικούµενες οµάδες υπάρχει κάποιος µόνιµος ηγέτης, αλλά τα

προβλήµατα πάλι συζητούνται από κοινού και η επικοινωνία ανάµεσα στα µέλη της

οµάδας είναι οριζόντια.

Στις κεντρικά διοικούµενες οµάδες υπάρχει µόνιµος ηγέτης και υπάρχουν επιµέρους

καθορισµένες εξουσίες. Η διοίκηση και η επικοινωνία γίνεται κάθετα (δηλαδή ο ηγέ-

της επικοινωνεί µε τους άµεσα υφισταµένους του, αυτοί µε τους επόµενους στην

ιεραρχία, κτλ.

Η επιλογή του τρόπου οργάνωσης εξαρτάται από το είδος του προβλήµατος. Τα

µεγάλα προβλήµατα συνήθως απαιτούν κεντρικά διοικούµενες οµάδες, ενώ τα µικρά

δηµοκρατικά διοικούµενες, τα προβλήµατα που χρειάζονται πολύ χρόνο συνήθως

επιλύονται καλύτερα από δηµοκρατικά διοικούµενες οµάδες (αφού είναι η καλύτε-

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

µαζί) και τα προβλήµατα που διασπώνται εύκολα σε τµήµατα είναι καλύτερα να επι-

λύονται από κεντρικά διοικούµενες οµάδες. Φυσικά ο υπεύθυνος έργου πρέπει να

εκτιµήσει όλους τους παράγοντες του έργου και τις ιδιαιτερότητες του προσωπικού

πριν αποφασίσει για τον τρόπο οργάνωσης της οµάδας.

1.4.2 ¶ÏÂÔÓÂÎÙ‹Ì·Ù· ÂÚÁ·Û›·˜ ÛÂ ÔÌ¿‰Â˜

Η εργασία σε οµάδες πρώτα από όλα βοηθά στην διευκόλυνση των θεµάτων επι-

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

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

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 44

οµάδας κοντά το ένα µε το άλλο, αναπτύσσοντας µία κοινή φιλοσοφία ανάπτυξης,

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

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

–κυρίως– βοηθά σε αυτό που ο Sommerville [Som89] ονοµάζει «µη εγωιστικός προ-

γραµµατισµός (egoless programming)», δηλαδή ο προγραµµατιστής να µη θεωρεί

τον κώδικά του ως ιδιοκτησία του (δηµιουργία του), αλλά ως ιδιοκτησία (δηµιουρ-

γία) της οµάδας στην οποία έχει ενταχθεί.

1.4.3 √ÚÁ·ÓfiÁÚ·ÌÌ· ·Ó¿Ù˘ÍË˜ ÏÔÁÈÛÌÈÎÔ‡

Οι περισσότεροι από εσάς έχετε διδαχθεί ή τουλάχιστον γνωρίζετε το οργανόγραµ-

µα ως το µέσο µε το οποίο παρουσιάζονται µε σχηµατικό τρόπο οι σχέσεις και οι

εξαρτήσεις (προϊστάµενοι – υφιστάµενοι) των µελών µίας επιχείρησης. Για µεγάλα

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

χείρισης έργου (project management structure) που παρουσιάζει τις οµάδες ανάπτυ-

ξης και τους ρόλους καθενός που συµµετέχει στην ανάπτυξη λογισµικού. Έτσι ο

υπεύθυνος έργου έχει καλύτερη αντίληψη για τους συµµετέχοντες στην ανάπτυξη

λογισµικού και τις ευθύνες που έχει αναλάβει ο καθένας από αυτούς. Στο σχήµα 1.10

παρουσιάζεται ένα παράδειγµα οργανογράµµατος ενός µικρού έργου. (Το έργο που

παρουσιάζεται στο σχήµα 1.10 είναι πολύ µικρό για να γίνει σε πραγµατικές συν-

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

βάλουµε ένα τεράστιο ρεαλιστικό οργανόγραµµα).

4 51 . 4 ∂ ƒ °∞ ™ π ∞ ™ ∂ √ ª ∞ ¢ ∂ ™

Το οργανόγραµ-

µα διαχείρισηςέργου (projectmanagementstructure) παρου-σιάζει σχηµατικά τη διοικητική δοµήτου έργου.

™¯‹Ì· 1.10


οργανογράµµατος

έργου

Περικλής

Yπεύθυνος Έργου

Aσπασία

Oµάδα UI

Στέλιος

Προγρ/της

Mάριος

Προγρ/της

Kώστας

Προγρ/της

Bασίλης

Προγρ/της

Σοφία

Προγ/τρια

Xρήστος

Oµάδα B∆

XαράΓραµµατεία

έργου

Άννα

ΣχεδιάστριαER

BασίληςΈµπειροςΠρογρ/της

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 45


Στο σχήµα 1.10 βλέπουµε ότι ο Περικλής είναι υπεύθυνος ενός έργου µε γραµµα-

τεία έργου τη Χαρά. Στο έργο υπάρχουν δύο οµάδες που λειτουργούν ως κεντρικά

διοικούµενες. Στη µία οµάδα ηγέτης είναι η Ασπασία και στην άλλη ο Χρήστος. Βλέ-

πουµε επίσης τα υπόλοιπα µέλη που εργάζονται στην ανάπτυξη του έργου ποιον

έχουν άµεσα προϊστάµενο ο καθένας.




i) Οι οµάδες ανάπτυξης λογισµικού πρέπει να οργανώνονται

δηµοκρατικά.

ii) Για προβλήµατα που απαιτούν επικοινωνία ανάµεσα σε όλα

τα µέλη της οµάδας είναι καλύτερη η δηµοκρατική

οργάνωση των οµάδων.

iii)Οι κεντρικά διοικούµενες οµάδες αποδίδουν καλύτερα

για έργα που έχουν µικρή διάρκεια.

iv) Ο µη εγωιστικός προγραµµατισµός υποβοηθείται

στα πλαίσια µιας οµάδας.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 46

™‡ÓÔ„Ë ÎÂÊ·Ï·›Ô˘ Î·È Û˘Ì‚Ô˘Ï¤˜ ÌÂÏ¤ÙË˜

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

και στο επόµενο κεφάλαιο µε την εκτίµηση και την ανάλυση ρίσκου, αλλά µέχρι τώρα

µιλήσαµε για τις περισσότερες διαδικασίες που αφορούν τη διαχείριση έργων λογι-

σµικού. Πρέπει να γνωρίζετε τις βασικές έννοιες και ορισµούς που σχετίζονται µε τη

διαχείριση έργων λογισµικού και τις ιδιαιτερότητες του λογισµικού και τα προβλήµα-

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

∆ώσαµε ιδιαίτερη έµφαση στις βασικές δραστηριότητες που σχετίζονται µε τη δια-

χείριση έργων λογισµικού και παρουσιάσαµε µερικές από τις πιο διαδεδοµένες τεχνι-

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

αυτές τις τεχνικές σε κάποιο παράδειγµα έργου λογισµικού και να λύνετε εργασίες

αντίστοιχες µε τη δραστηριότητα 1.5.

Τέλος µιλήσαµε για τους συµµετέχοντες στην ανάπτυξη λογισµικού το ρόλο τους και

συνοπτικά για τα προσόντα που θα πρέπει να έχει ο καθένας από αυτούς, για οµάδες

εργασίας και οργανόγραµµα διαχείρισης έργου. Εάν δυσκολευτήκατε στην ενότητα

1.3 του βιβλίου θα πρέπει να κάνετε µία καλή επανάληψη σε θέµατα Τεχνολογίας

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

που ακολουθεί. Γενικά η συµβουλή µας είναι να ανατρέχετε και σε βιβλιογραφικές

πηγές πέρα από το βιβλίο αυτό, ώστε να εµπλουτίζετε τις γνώσεις σας, αλλά και να

διαβάζετε µε εναλλακτικό τρόπο την ύλη που καλύψαµε. Ακολουθεί βιβλιογραφία µε

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

να επικεντρώσετε την προσοχή σας.

4 7™ À ¡ √ æ ∏ ∫ ∂ º ∞ § ∞ π √ À ∫ ∞ π ™ À ª µ √ À § ∂ ™ ª ∂ § ∂ ∆ ∏ ™

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 47


µÈ‚ÏÈÔÁÚ·Ê›· Î·È ÚÔÙ¿ÛÂÈ˜ ÁÈ· ÂÚ·ÈÙ¤Úˆ ÌÂÏ¤ÙË

Ακολουθεί η βιβλιογραφία του κεφαλαίου 1. Τα επιλεγµένα βιβλία που σχολιάζο-

νται είναι αυτά που σας προτείνονται για περαιτέρω µελέτη στα θέµατα που καλύ-

ψαµε στο κεφάλαιο 1. Τα βιβλία αυτά συνοδεύονται από σχόλια για το πού να επι-

κεντρώσετε τη µελέτη σας σχετικά µε τα θέµατα του κεφαλαίου 1, αλλά και πληρο-

φορίες για τη µελέτη σας.

[Bro97] Frederick P. Brooks, «The Mythical Man–Month. Essays on Software

Engineering», Anniversary edition, Addison–Wesley, (1995).

Το βιβλίο αυτό είναι από τα παλαιότερα βιβλία για διαχείριση παραγωγής λογισµι-

κού. Η πρώτη έκδοση ήταν το 1975, ενώ αυτή που σας προτείνω είναι η επανέκδοση

του 1997. Υλικό για περαιτέρω µελέτη σχετικά µε το κεφάλαιο 1 θα βρείτε σίγουρα

στα κεφάλαια 1–4 του βιβλίου του Brooks. Πάντως και παρά τα σχετικά δύσκολα

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

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

χωρίς να κουράζει. Θεωρώ ότι δύσκολα θα βρείτε σύγχρονο βιβλίο που να µιλά για

διαχείριση λογισµικού και να µην χρησιµοποιεί στοιχεία από το βιβλίο του Brooks.

[Cur88] B. Curtis et al, «A Field Study of the Software Design Process for Large

Systems», IEEE Transactions of Software Engineering, vol. 31, no. 11, pp.

1268–1287, (1988).

[Edg95] J. Edgemon, «Right Stuff: How to recognize it when selecting a Project

Manager», Application Development Trends, vol. 2, no. 5, (1995).

[Inc95] Darrel Ince, «Software Quality Assurance: A Student Introduction»,

McGraw–Hill, (1995).

Το βιβλίο αυτό αφορά την ποιότητα λογισµικού για την οποία θα συζητήσουµε σε

επόµενα κεφάλαια, αλλά στο κεφάλαιο 1.3 που µιλά για τους χρήστες ενός συστή-

µατος ποιότητας θα βρείτε ευκαιρία να κάνετε µία καλή επανάληψη στους ρόλους

των συµµετεχόντων στην ανάπτυξη λογισµικού.

[Kra95] R. Kraul και L. Streeter, «Coordination in Software Development», CASM,

vol. 38, no. 3, (1995).

[Man81] M. Mantei, «The Effect of Programming Team Structures on Programming

Tasks», CACM, vol. 24, no. 3, (1981).

[Met73] P. W. Metzger, «Managing a Programming Project», Engelwood Cliffs,

Prentice–Hall, (1973).

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 48

[Pre97] Roger S. Pressman, «Software Engineering: A Practitioner’s Approach»,

Forth edition, European Adaptation, McGraw–Hill, (1997).

Σίγουρα ένα βιβλίο που θα το έχετε ξανακούσει αρκετές φορές ειδικά σε θέµατα

τεχνολογίας λογισµικού. Στο κεφάλαιο 3 µιλά για βασικές αρχές διαχείρισης και στο

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

περισσότερο από όσα αναπτύξαµε σε αυτό το κεφάλαιο να µην το παραλείψει από

τη µελέτη του.

[Sho93] Martin L. Shooman, «Software Engineering: Design, Reliability and

Management», McGraw–Hill, (1993).

Είναι ένα επίσης πολύ καλό βιβλίο για περαιτέρω µελέτη. Τα θέµατα που σας προ-

τείνω να µελετήσετε περαιτέρω βρίσκονται στο τµήµα 6.5 που µιλάει γενικά για

θέµατα διαχείρισης και για τεχνικές διαχείρισης. Θα βρείτε ενδιαφέρουσα µία εναλ-

λακτική παρουσίαση των ρόλων στην ανάπτυξη λογισµικού, αφού τους παρουσιά-

ζει µε µία στρατιωτική άποψη, αφού µιλάει για Στρατηγό, για Βοηθό Πιλότο, κτλ.

Νοµίζω πως αξίζει να διαβάσετε το συγκεκριµένο τµήµα, µια και είναι πολύ διαφο-

ρετική προσέγγιση από αυτή που επιλέξαµε για την ενότητα 1.3.

[Ves00] Βασίλειος Βεσκούκης, «Τεχνολογία Λογισµικού Ι: Αρχές Τεχνολογίας Λογι-

σµικού», Ελληνικό Ανοικτό Πανεπιστήµιο, ΠΛΗ20/1, (2000).

Είναι το βιβλίο του 1ου έτους του ΕΑΠ που µιλά για τις βασικές αρχές της Τεχνο-

λογίας Λογισµικού και που θα πρέπει να το συµβουλευτείτε για να κάνετε µία επα-

νάληψη στα θέµατα τις Τεχνολογίας Λογισµικού που πιθανόν δεν θυµόσαστε.

[Som89] Ian Sommerville, «Software Engineering», Third edition, Addison–Wesley,

(1989).

Επίσης ένα βιβλίο που θα το έχετε και αυτό ξανακούσει αρκετές φορές ειδικά σε

θέµατα τεχνολογίας λογισµικού. Στο κεφάλαιο 24 µιλά για βασικές αρχές διαχείρι-

σης και στο κεφάλαιο 25 για τεχνικές διαχείρισης. Νοµίζω πως είναι αρκετά απλό

και κατανοητό βιβλίο πάντα για όποιον θέλει να µελετήσει περαιτέρω.

[Xen94] Μιχάλης Ξένος και ∆ηµήτρης Χριστοδουλάκης, «Τεχνολογία Λογισµικού:

Αρχές και Μεθοδολογίες», Εκδόσεις Πανεπιστηµίου Πατρών, (1994).

Το βιβλίο αυτό διατίθεται στην Κεντρική Βιβλιοθήκη του Πανεπιστηµίου Πατρών

και στη βιβλιοθήκη του Τµήµατος Μηχανικών Ηλεκτρονικών Υπολογιστών και Πλη-

ροφορικής, αλλά όχι στο εµπόριο. Είναι το βασικό βιβλίο για το µάθηµα «Τεχνολο-

γία Λογισµικού» στο Τµήµα Μηχανικών Ηλεκτρονικών Υπολογιστών και Πληρο-

φορικής του Πανεπιστηµίου Πατρών από το 1994 έως σήµερα. Θα το πρότεινα µόνο

4 9µ π µ § π √ ° ƒ∞ º π ∞ ∫ ∞ π ¶ ƒ √ ∆∞ ™ ∂ π ™ ° π ∞ ¶ ∂ ƒ∞ π ∆ ∂ ƒ ø ª ∂ § ∂ ∆ ∏

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 49


σε κάποιον που δεν µπορεί να διαβάσει αγγλικά βιβλία για να διαβάσει για την κρίση

του λογισµικού και για µύθους και πραγµατικότητα της διαχείρισης έργων λογισµι-

κού που αναφέρονται στο κεφάλαιο 1.

[Zah94] R. Zahniser, «Timeboxing for Top Team Performance», Software

Development, vo. 3, (1994).

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 50

∂ÎÙ›ÌËÛË Î·È ∞Ó¿Ï˘ÛË ∫ÈÓ‰‡ÓÔ˘

™ÎÔfi˜

Σκοπός του κεφαλαίου 2 είναι η παρουσίαση των εννοιών της εκτίµησης παραγόντων

όπως οι ανάγκες σε ανθρώπινο δυναµικό, το κόστος και ο χρόνος και της ανάλυσης

κινδύνου. Παρουσιάζονται τεχνικές εκτίµησης και εµπειρικά µοντέλα εκτίµησης

(κόστους, χρόνου) µε σκοπό την εφαρµογή τους σε έργα λογισµικού. Επίσης, συζη-

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

κάποιο έργο.



• ορίσετε τι είναι εκτίµηση και ποιοι είναι οι παράγοντες που είναι αναγκαίο να εκτι-

µηθούν,

• περιγράψετε την έννοια της ακρίβειας στην εκτίµηση κόστους ή χρόνου και τις

συνέπειες πιθανών λαθών,

• αναφέρετε τους παράγοντες που επιδρούν στην ακρίβεια της εκτίµησης κόστους ή

χρόνου,

• περιγράψετε τις µεθόδους (στρατηγικές) που µπορούν να ακολουθηθούν αναφο-

ρικά µε την εκτίµηση παραγόντων όπως οι ανάγκες σε ανθρώπινο δυναµικό, το

κόστος και ο χρόνος,

• αναφέρετε τις πιο διαδεδοµένες τεχνικές εκτίµησης παραγόντων όπως οι ανάγκες

σε ανθρώπινο δυναµικό, το κόστος και ο χρόνος,

• περιγράψετε τους παράγοντες που επιδρούν στην ακρίβεια της εκτίµησης παραγό-

ντων όπως οι ανάγκες σε ανθρώπινο δυναµικό, το κόστος και ο χρόνος,

• εξηγήσετε τον τρόπο µε τον οποίο γίνεται η εκτίµηση που βασίζεται σε γραµµές

κώδικα και η εκτίµηση που βασίζεται σε λειτουργικά σηµεία,

• αναφέρετε τους τύπους του εµπειρικού µοντέλου COCOMO και τις κατηγορίες στις

οποίες κατατάσσει τα έργα λογισµικού,

• περιγράψετε τον τρόπο εκτίµησης που βασίζεται στο εµπειρικό µοντέλο COCOMO,

• περιγράψετε την έννοια του κινδύνου και να αναφέρετε τους παράγοντες που σχε-

2∫ ∂ º ∞ § ∞ π √

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 51

• Εκτίµηση (Estimation)

• Χρόνος ανάπτυξης (Development

time)

• Κόστος έργου (Cost)

• Τεχνικές τµηµατοποίησης

(Decomposition techniques)

• Εµπειρικά µοντέλα (Empirical

models)

• Εκτίµηση από κάτω προς τα πάνω

(Bottom – up estimation)

• Εκτίµηση που βασίζεται στο τελικό

κόστος (Pricing to win)

• Μέγεθος έργου (size)

• Γραµµή κώδικα (Line of Code ή

LOC)

• Εκτίµηση που βασίζεται σε γραµµές

κώδικα (LOC based estimation)

• Λειτουργικό σηµείο (Function point)

• Εκτίµηση που βασίζεται σε λειτουργι-

κά σηµεία (Function point based

estimation)

• Τοµείς πληροφορίας (Information

domain values)

• Παράγοντες ρύθµισης πολυπλοκότη-

τας (Complexity adjustment factors)

• Οργανική κατηγορία έργων (Organic

mode projects)

• Ηµι – προσαρτηµένη κατηγορία

έργων (Semi – detached mode

projects)

• Ενσωµατωµένη κατηγορία έργων

(Embedded mode projects)

• Ανάλυση κινδύνου (Risk analysis)

• Πίνακας αξιολόγησης συνεπειών

(Impact assessment table)

5 2 K E º A § A I O 2 : ∂ ∫ ∆ π ª ∏ ™ ∏ ∫ ∞ π ∞ ¡ ∞ § À ™ ∏ ∫ π ¡ ¢ À ¡ √ À

τίζονται µε τον κίνδυνο για κάποιο έργο,

• συντάξετε ερωτήσεις που θα σας βοηθήσουν στον εντοπισµό περιπτώσεων κινδύ-

νου για ένα έργο,

• κατηγοριοποιήσετε περιπτώσεις κινδύνου ανάλογα µε την κρισιµότητα κάθε περί-

πτωσης για την επιχείρηση.



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

σιάσαµε τις δραστηριότητες που αναλαµβάνει ο υπεύθυνος έργου. Ανάµεσα σε αυτές

αναφέρθηκαν η εκτίµηση και η ανάλυση κινδύνου οι οποίες αναλύονται σε αυτό το

κεφάλαιο. Ειδικότερα, στην ενότητα 2.1, παρουσιάζεται η έννοια της εκτίµησης παρα-

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 52

γόντων όπως το κόστος ή ο χρόνος στο λογισµικό. Στην ενότητα 2.2 παρουσιάζονται

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

COCOMO. Τέλος στην ενότητα 2.3 παρουσιάζεται –πολύ συνοπτικά– η έννοια του

κινδύνου που εµπεριέχει ένα έργο λογισµικού και συζητούνται οι τρόποι ανάλυσης (και

κατηγοριοποίησης) αυτού του κινδύνου από τον υπεύθυνο έργου.

Για τα περισσότερα από τα σηµεία που καλύπτουµε στο κεφάλαιο αυτό σας παραθέ-

τουµε σχολιασµένη βιβλιογραφία για περαιτέρω µελέτη στο τέλος του κεφαλαίου, όπου

µπορείτε να βρείτε οδηγίες για το τι να διαβάσετε, ώστε να εµπλουτίσετε τη µελέτη

σας, αντλώντας γνώσεις από πολλαπλές πηγές.

5 3∂ π ™ ∞ ° ø ° π ∫ ∂ ™ ¶ ∞ ƒ∞∆ ∏ ƒ ∏ ™ ∂ π ™

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 53

5 4 K E º A § A I O 2 : ∂ ∫ ∆ π ª ∏ ™ ∏ ∫ ∞ π ∞ ¡ ∞ § À ™ ∏ ∫ π ¡ ¢ À ¡ √ À

2.1 ∂ÎÙ›ÌËÛË ·Ú·ÁfiÓÙˆÓ fiˆ˜ ÔÈ ·Ó¿ÁÎÂ˜ ÛÂ ·ÓıÚÒÈÓÔ ‰˘Ó·ÌÈÎfi,ÙÔ ÎfiÛÙÔ˜ Î·È Ô ¯ÚfiÓÔ˜

Στην ενότητα αυτή θα µιλήσουµε για την εκτίµηση στο λογισµικό. Στο πρώτο τµήµα

της ενότητας, µε τίτλο εισαγωγή στην εκτίµηση, παρουσιάζονται οι βασικοί όροι που

σχετίζονται µε την εκτίµηση και οι στόχοι της εκτίµησης στο λογισµικό. Στο δεύτε-

ρο τµήµα της ενότητας, µε τίτλο παράγοντες που επιδρούν στην εκτίµηση, παρου-

σιάζονται οι παράγοντες που σχετίζονται µε την ακρίβεια της εκτίµησης, οι οποίοι

µπορούν να επηρεάσουν τη διαδικασία της εκτίµησης. Τέλος, στο τρίτο τµήµα της

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

την εκτίµηση και οι επιλογές του υπευθύνου έργου σχετικά µε τον τρόπο µε τον

οποίο µπορεί να προσεγγίσει το θέµα της εκτίµησης.

2.1.1 ∂ÈÛ·ÁˆÁ‹ ÛÙËÓ ÂÎÙ›ÌËÛË ·Ú·ÁfiÓÙˆÓ fiˆ˜ ÔÈ ·Ó¿ÁÎÂ˜ ÛÂ·ÓıÚÒÈÓÔ ‰˘Ó·ÌÈÎfi, ÙÔ ÎfiÛÙÔ˜ Î·È Ô ¯ÚfiÓÔ˜

Η εκτίµηση στο λογισµικό είναι στις περισσότερες περιπτώσεις η πρώτη προτεραι-

ότητα του υπεύθυνου έργου πριν ακόµα αρχίσει η υλοποίηση του έργου. Ο Αριστο-

τέλης από το 330 π.Χ. έλεγε: «Είναι σηµάδι ενός δοµηµένου µυαλού, να µένει ικανο-

ποιηµένο από το βαθµό της ακρίβειας που του δίνει η φύση ενός θέµατος και όχι να

ψάχνει την ακρίβεια εκεί όπου υπάρχει κάτι περίπου αληθινό», δίνοντας την πραγ-

µατική ερµηνεία στην έννοια «εκτίµηση».

Η εκτίµηση των δυνατοτήτων της οµάδας ανάπτυξης (ή της επιχείρησης γενικότε-

ρα), του κόστους και του απαιτούµενου χρόνου απαιτεί εµπειρία, πρόσβαση σε αξιό-

πιστα και ακριβή ιστορικά δεδοµένα και βέβαια την ικανότητα να εξάγει κανείς

ποσοτικά δεδοµένα, όταν αυτό που έχει στη διάθεσή του είναι οι ποιοτικές αναλύ-

σεις. Αυτό εξάλλου πρέπει να είναι βασικό προσόν του υπεύθυνου έργου. Είναι προ-

φανές λοιπόν πως η διαδικασία της εκτίµησης εµπεριέχει σε κάποιο βαθµό και ρίσκο,

το οποίο οδηγεί στην αβεβαιότητα. Η εκτίµηση κάποιων παραγόντων είναι πολύ

σηµαντική διαδικασία στην ανάπτυξη λογισµικού και αποτελεί τη βάση πάνω στην

οποία προγραµµατίζεται ένα έργο, αφού αυτό έχει να κάνει µε ανθρώπινη προσπά-

θεια και κόστος. Οι παράγοντες που συνήθως αποτελούν αντικείµενο εκτίµησης σε

ένα έργο είναι:

• Οι ανάγκες σε ανθρώπινο δυναµικό, έτσι ώστε να εκτιµηθεί η προσπάθεια (effort).

• Ο χρόνος που θα χρειαστεί για την ανάπτυξη του έργου.

• Το κόστος του έργου.

Συνήθως, στα πλαίσια της εκτίµησης υπολογίζονται πρώτα οι ανάγκες σε ανθρώπι-

Εκτίµηση παρα-γόντων όπως οι

ανάγκες σε ανθρώ-πινο δυναµικό, τοκόστος και ο χρό-νος είναι η ικανό-

τητα πρόβλεψης τηςεξέλιξης µιας κατά-στασης πριν ακόµα

αυτή δροµολογηθεί.Για τη γνώση αυτήχρησιµοποιούνταιτεχνικές που βασί-ζονται σε δεδοµένα

από αντίστοιχεςπροηγούµενεςκαταστάσεις.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 54

νο δυναµικό και ο χρόνος και αυτό (προσθέτοντας και κόστη εξοπλισµού και λει-

τουργίας) οδηγεί στην κοστολόγηση του έργου και κατά συνέπεια στην τιµολόγησή

του. ∆είτε τη δραστηριότητα 2.1 για αποσαφήνιση της διαφοράς κοστολόγησης και

τιµολόγησης.

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

νο δυναµικό, το κόστος και ο χρόνος αποτελούσε δευτερεύουσα διαδικασία. Ακόµα

και µια πολύ µεγάλη απόκλιση από το τελικό αποτέλεσµα, της τάξης του 200%, είχε

σχετικά µικρές συνέπειες στην επιχείρηση. Σήµερα, λόγω του µεγάλου ανταγωνι-

σµού στις επιχειρήσεις λογισµικού, τέτοιες αποκλίσεις δεν είναι ανεκτές, µε δεδο-

µένο ότι υπάρχει σηµαντικός αριθµός συστηµατοποιηµένων τεχνικών που χρησιµο-

ποιούνται για να επιτευχθεί όσο το δυνατό µεγαλύτερη ακρίβεια στην εκτίµηση. Μία

µεγάλη απόκλιση στην εκτίµηση παραγόντων όπως οι ανάγκες σε ανθρώπινο δυνα-

µικό, το κόστος και ο χρόνος υλοποίηση κάποιου έργου θα µπορούσε να έχει κατα-

στροφικές συνέπειες για κάποια επιχείρηση. Σαν παράδειγµα τέτοιων συνεπειών

δείτε τη δραστηριότητα 2.1 που ακολουθεί.

5 52 . 1 ∂ ∫ ∆ π ª ∏ ™ ∏ ¶ ∞ ƒ∞ ° √ ¡ ∆ ø ¡ √ ¶ ø ™ √ π ∞ ¡ ∞ ° ∫ ∂ ™ ™ ∂ ∞ ¡ £ ƒ ø ¶ π ¡ √ ¢ À ¡ ∞ ª π ∫ √ , ∆ √ ∫ √ ™ ∆ √ ™ ∫ ∞ π √ Ã ƒ √ ¡ √ ™


Ο Χρήστος είναι βασικός µέτοχος σε µία µικρή εταιρία ανάπτυξης λογισµικού.

Αποφασίζει να υποβάλει προσφορά σε ένα διαγωνισµό που προκηρύσσει µια µεγά-

λη επιχείρηση που ζητά την ανάπτυξη ενός τµήµατος λογισµικού. Η επιχείρηση

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

εταιρία που θα έχει τη καλύτερη πρόταση τόσο ως προς το κόστος, όσο και ως προς

την ταχύτητα ανάπτυξης του έργου. Αναφέρει µάλιστα ότι για κάθε 10 ηµέρες

καθυστέρησης από την αρχική προσφορά, θα υπάρχει ρήτρα ύψους 3.000 Euro.

Ο Χρήστος, που στο συγκεκριµένο έργο θα έχει και το ρόλο του υπεύθυνου έργου,

αναλαµβάνει τη συγγραφή και την υποβολή της σχετικής προσφοράς. Έπειτα από

αρκετές ηµέρες εργασίας και βασισµένος στην προσωπική του εµπειρία, ο Χρή-

στος εκτιµά ότι το έργο θα χρειαστεί 8 µήνες και η κοστολόγηση του έργου στην

εταιρία είναι 69.100 Euro. Για να έχει µία σχετική άνεση χρόνου (προβλέποντας

και ένα πιθανό µικρό λάθος στην εκτίµηση) και για να υπάρχει και το σχετικό κέρ-

δος (στην περίπτωση αυτή ο Χρήστος επιδιώκει κέρδος περίπου 28%), υποβάλλει

πρόταση για 10 µήνες µε τιµολόγηση 88.200 (Αφήνει µικρά περιθώρια κέρδους

για να είναι η πρότασή του ανταγωνιστική).

Ας υποθέσουµε ότι τελικά η εταιρία του Χρήστου πήρε το έργο. Τι θα συµβεί αν

ο Χρήστος έχει πέσει έξω στην εκτίµησή του κατά κάποιο ποσοστό (όλα τα λάθη

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 55

5 6 K E º A § A I O 2 : ∂ ∫ ∆ π ª ∏ ™ ∏ ∫ ∞ π ∞ ¡ ∞ § À ™ ∏ ∫ π ¡ ¢ À ¡ √ À

Απάντηση

Ο Χρήστος από αυτό το έργο επιδίωκε κέρδος 19.100 Euro. Αναλύοντας κάθε µία

από τις ζητούµενες περιπτώσεις υπολογίζουµε:

Ο χρόνος που είχε εκτιµήσει ο Χρήστος ήταν 8 µήνες. Άρα 40% λάθος σηµαίνει ότι

χρειάστηκαν επιπλέον 3,2 µήνες, δηλαδή 3 µήνες και 6 ηµέρες ανεβάζοντας το χρόνο

ανάπτυξης σε 11 µήνες και 6 ηµέρες. Με δεδοµένο τους 10 µήνες της αρχικής πρό-

τασης και τη ρήτρα ύψους 3.000 Euro για κάθε 10 ηµέρες καθυστέρησης αυτό σηµαί-

νει 12.000 Euro ρήτρα. Αντίστοιχα 100% λάθος στο χρόνο σηµαίνει καθυστέρηση

8 µήνες, δηλαδή ρήτρες 72.000 Euro (υπολογίζεται µε τον ίδιο τρόπο).

Σχετικά µε το κόστος, 40% λάθος σηµαίνει ότι το έργο κόστισε 96.740 Euro (αντί

69.100 Euro που είχε εκτιµηθεί) και 100% λάθος σηµαίνει κόστος 138.200 Euro.

Συνοψίζοντας τα παραπάνω έχουµε:

α) Εκτιµώµενο κέρδος: +19.100 Euro.

Πραγµατικό κέρδος: +7.100 Euro.

β) Εκτιµώµενο κέρδος: +19.100 Euro.

Πραγµατικό κέρδος: –8.540 Euro.

γ) Εκτιµώµενο κέρδος: +19.100 Euro.


δ) Εκτιµώµενο κέρδος: +19.100 Euro.


Παρατηρήστε ότι µόνο στην περίπτωση α) η εταιρία του Χρήστου έβγαλε κάποιο

µικρό κέρδος, ενώ στις περιπτώσεις β), γ) και δ) είχε ζηµιά από το έργο λόγω της

κακής εκτίµησης. Μάλιστα η ζηµιά στην περίπτωση δ) πιθανότατα θα ήταν κατα-

στροφική για µία µικρή εταιρία.

θεωρήστε ότι είναι προς το χειρότερο και όχι προς το καλύτερο):

α) 40% στο χρόνο που εκτίµησε.

β) 40% στο κόστος που εκτίµησε.

γ) 40% στο χρόνο και 40% στο κόστος που εκτίµησε.

δ) 100% στο χρόνο και 100% στο κόστος που εκτίµησε.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 56

2.1.2 ¶·Ú¿ÁÔÓÙÂ˜ Ô˘ ÂÈ‰ÚÔ‡Ó ÛÙËÓ ÂÎÙ›ÌËÛË

Στην προηγούµενη ενότητα είδαµε (στα πλαίσια της δραστηριότητας 2.1) πόσο

σηµαντική είναι η ακρίβεια στην εκτίµηση παραγόντων όπως οι ανάγκες σε ανθρώ-

πινο δυναµικό, το κόστος και ο χρόνος. Από τι όµως επηρεάζεται η εκτίµηση αυτών

των παραγόντων; Ποιοι είναι οι παράγοντες που επιδρούν στην ακρίβεια των εκτι-

µήσεων; Αυτές τις ερωτήσεις θα απαντήσουµε σε αυτό το τµήµα. Πριν συνεχίσου-

µε, πρέπει να τονιστεί ότι η εκτίµηση στο λογισµικό δεν θα είναι ποτέ µια επιστήµη

µε την αυστηρή έννοια του όρου. Οι τεχνολογικές, ψυχολογικές, περιβαλλοντολο-

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

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

χουν συγκεκριµένοι παράγοντες του έργου που πρόκειται να αναπτυχθεί οι οποίοι

έχουν κάποια επίδραση –άλλοτε σηµαντική και άλλοτε µικρότερη– στην εκτίµηση

του κόστους, της ανθρώπινης προσπάθειας και του απαιτούµενου χρόνου.

Ένας από τους πιο σηµαντικούς παράγοντες είναι το µέγεθος του έργου που θα υλο-

ποιηθεί. Υπάρχουν διάφορες τεχνικές υπολογισµού του µεγέθους του έργου και αρκε-

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

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

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

τεχνικές διάσπασης του προβλήµατος να µην είναι ικανές να απλοποιήσουν αρκετά

τα επιµέρους κοµµάτια του έργου και να οδηγήσουν σε ακριβείς εκτιµήσεις.

Η πολυπλοκότητα του έργου επίσης είναι ένας σηµαντικός, αν και σχετικά υποκει-

µενικός, παράγοντας που επηρεάζει την ακρίβεια της εκτίµησης. Ανάλογα µε την

εµπειρία που υπάρχει από προηγούµενες προσπάθειες, ένα έργο µπορεί να είναι

δύσκολο και πολύπλοκο, αν η οµάδα των ανθρώπων που το έχουν αναλάβει δεν είχε

ασχοληθεί µε κάτι παρόµοιο στο παρελθόν, ή ευκολότερο αν έχουν γνώση και εµπει-

ρία στο σχετικό αντικείµενο.

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

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

στην εκτίµηση, αφού τέτοια δεδοµένα αποτελούν ένα πολύτιµο µέτρο σύγκρισης και

συντελούν στην αποφυγή λαθών. Τα µεγέθη που εξάγονται από τις µετρήσεις των

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

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

συγκλίνουν µε αυτές του παλαιού. Τα µοντέλα εκτίµησης κόστους για τα οποία θα

µιλήσουµε σε επόµενα τµήµατα της ενότητας βασίζουν τα αποτελέσµατά τους στα

ιστορικά δεδοµένα µειώνοντας έτσι το συνολικό κίνδυνο της εκτίµησης.


•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 57

5 8 K E º A § A I O 2 : ∂ ∫ ∆ π ª ∏ ™ ∏ ∫ ∞ π ∞ ¡ ∞ § À ™ ∏ ∫ π ¡ ¢ À ¡ √ À

Τέλος, ένας εξίσου σηµαντικός παράγοντας που καθορίζει την ακρίβεια της εκτίµη-

σης είναι η λεπτοµέρεια στον καθορισµό των απαιτήσεων του πελάτη και η στα-

θερότητα αυτών των απαιτήσεων. Αυτό σηµαίνει πως ο υπεύθυνος του έργου και

η οµάδα που θα κάνουν τις εκτιµήσεις θα πρέπει να έχουν πλήρη και λεπτοµερή περι-

γραφή του συστήµατος, των λειτουργιών που θα επιτελεί και των επιµέρους στοι-

χείων του έργου που θα αναπτυχθεί.


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

της εκτίµησης:

• Ικανότητα του προσωπικού ανάπτυξης

• Μέγεθος του έργου

• Πολυπλοκότητα του έργου

• Βάσεις δεδοµένων

• Ιστορικά δεδοµένα

• Λεπτοµερείς απαιτήσεις έργου

• Σταθερές απαιτήσεις έργου

• Σχεδιασµός έργου

2.1.3 ª¤ıÔ‰ÔÈ ÂÎÙ›ÌËÛË˜

Στόχος των µεθόδων εκτίµησης παραγόντων όπως οι ανάγκες σε ανθρώπινο δυνα-

µικό, το κόστος και ο χρόνος είναι να µετατρέψουν την εκτίµηση κόστους, χρόνου

και προσπάθειας στο λογισµικό από κάτι που µοιάζει µια εµπειρική διαδικασία σε

µια σειρά από καθορισµένα βήµατα, τα οποία –σε συνδυασµό και µε αξιόπιστα ιστο-

ρικά δεδοµένα– να οδηγούν σε ακριβείς εκτιµήσεις των παραπάνω µεγεθών. Για να

εξασφαλιστεί αυτή η ακρίβεια, σύµφωνα µε τον Pressman [Pre97] µπορούµε να: α)

καθυστερήσουµε την εκτίµηση τόσο ώστε να έχει προχωρήσει αρκετά το έργο και να

έχει αποκτηθεί αρκετή γνώση για αυτό, β) βασίσουµε τις εκτιµήσεις µας σε παρό-

µοια έργα που έχουν ήδη τελειώσει, γ) χρησιµοποιήσουµε σχετικά απλές τεχνικές

τµηµατοποίησης, ώστε να διασπάσουµε το πρόβληµα και δ) χρησιµοποιήσουµε ένα

ή περισσότερα εµπειρικά µοντέλα για εκτίµηση κόστους και προσπάθειας.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 58

Η καθυστέρηση της εκτίµησης είναι η λύση που έχει τα καλύτερα αποτελέσµατα

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

ποίηση του έργου ή έστω στα πρώτα στάδια αυτού. Η καλύτερη εκτίµηση (µε 100%

ακρίβεια) θα επιτευχθεί αν περιµένουµε να τελειώσει το έργο, αλλά αυτή η «εκτί-

µηση» θα έχει µηδενική αξία. Ωστόσο, επειδή σε µερικά έργα δεν υπάρχουν καθό-

λου στοιχεία στα οποία µπορεί να βασιστεί η εκτίµηση, είναι αναγκαίο η εκτίµηση

να γίνει αφού το έργο ξεκινήσει και προκύψουν κάποια δεδοµένα.

Το να βασιστεί η εκτίµηση σε παρόµοια έργα που έχουν ήδη ολοκληρωθεί µπορεί

να λειτουργήσει καλά, αν το συγκεκριµένο έργο το οποίο θέλουµε να εκτιµήσουµε

έχει αρκετές οµοιότητες µε τα «παρόµοια έργα» µε τα οποία το συσχετίζουµε, συµπε-

ριλαµβανοµένων όλων των παραγόντων που αναφέρθηκαν στην ενότητα 2.1.2. Συνή-

θως, στην πράξη αυτό δεν συµβαίνει. Αυτό που συµβαίνει είναι να έχουµε ιστορικά

δεδοµένα από άλλα έργα που έχουν ολοκληρωθεί, αλλά οι συνθήκες να είναι αρκε-

τά διαφορετικές ώστε αυτά να µην µπορούν να θεωρηθούν «παρόµοια έργα».

Οι τεχνικές τµηµατοποίησης βασίζονται στη λογική του «διαίρει και βασίλευε»,

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

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

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

µεγαλύτερη ακρίβεια στην εκτίµηση.

Τα εµπειρικά µοντέλα µπορούν να χρησιµοποιηθούν επικουρικά στις τεχνικές τµη-

µατοποίησης και να δώσουν πολύτιµες πληροφορίες σχετικά µε τα µεγέθη που εξε-

τάζονται. Η χρήση των εµπειρικών µοντέλων βασίζεται στην αξιοποίηση ιστορικών

δεδοµένων από ποσότητες ανεξάρτητες από αυτές που στοχεύουµε να εκτιµήσουµε.

Πάντως τέτοιου είδους εκτίµηση είναι τόσο καλή όσο και τα ιστορικά δεδοµένα που

χρησιµοποιούνται για να οδηγηθούµε σε αυτή την εκτίµηση. Αν δεν υπάρχουν κατάλ-

ληλα ιστορικά δεδοµένα, η εκτίµηση στέκεται σε πολύ αβέβαιες βάσεις.

Στην επόµενη ενότητα, θα µιλήσουµε περισσότερο για τεχνικές τµηµατοποίησης και

εµπειρικά µοντέλα εκτίµησης. Σε αυτό το σηµείο, πρέπει να διευκρινίσουµε, όσον

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

ταξιδιών της οµάδας που ασχολείται µε αυτό, καθώς και κόστος της προσπάθειας

αυτών των ανθρώπων (η οποία µετράται σε ανθρωποµήνες). Το τελευταίο είναι και

αυτό στο οποίο αναφερόµαστε εµείς εδώ, χωρίς αυτό να σηµαίνει πως τα υπόλοιπα

είναι αµελητέα. Απλά συνήθως είναι πιο εύκολο να εκτιµηθούν.


•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 59

6 0 K E º A § A I O 2 : ∂ ∫ ∆ π ª ∏ ™ ∏ ∫ ∞ π ∞ ¡ ∞ § À ™ ∏ ∫ π ¡ ¢ À ¡ √ À

2.2 ∆Â¯ÓÈÎ¤˜ ÂÎÙ›ÌËÛË˜ Î·È ÂÌÂÈÚÈÎ¿ ÌÔÓÙ¤Ï·

Στην ενότητα αυτή θα µιλήσουµε συνοπτικά για µερικές από τις πιο γνωστές τεχνι-

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

λο COCOMO που είναι από τα πιο διαδεδοµένα.

2.2.1 ∆Â¯ÓÈÎ¤˜ ÂÎÙ›ÌËÛË˜

Έχουν υπάρξει διάφορες προσεγγίσεις του προβλήµατος της εκτίµησης παραγόντων

όπως οι ανάγκες σε ανθρώπινο δυναµικό, το κόστος και ο χρόνος ενός έργου. Ο

υπεύθυνος έργου αρχίζει µε τη µελέτη και την κατανόηση των απαιτήσεων και των

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

βλήµατος της εκτίµησης. Υπάρχουν αρκετές τεχνικές εκτίµησης που έχουν προτα-

θεί από το 1981 [Boe81] µε πιο σηµαντικές τις εξής: εκτίµηση από κάτω προς τα

πάνω (bottom – up estimation) και εκτίµηση που βασίζεται στο τελικό κόστος

(pricing to win). Κάθε µια από τις τεχνικές που έχουν προταθεί έχει τα πλεονεκτή-

µατα και τα µειονεκτήµατά της. Το σηµαντικότερο είναι πως καµία τεχνική δεν µπο-

ρεί να δώσει ικανοποιητικά αποτελέσµατα από µόνη της. Σε µεγάλου µεγέθους έργα

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

βεια της κάθε εκτίµησης σε συνάρτηση µε τις υπόλοιπες.


Συµπληρώστε τις παρακάτω προτάσεις επιλέγοντας µία από τις προτεινόµενες

λέξεις που ακολουθούν:

α) Η καθυστέρηση της εκτίµησης είναι συνήθως η λύση που έχει τα

…………………… αποτελέσµατα, αλλά δεν είναι ……………….

(καλύτερα, χειρότερα) (οικονοµική, πρακτική, βέλτιστη)

β) Το να βασιστεί η εκτίµηση σε παρόµοια έργα που έχουν ήδη ολοκληρωθεί, µπο-

ρεί να λειτουργήσει καλά, αν το συγκεκριµένο έργο το οποίο θέλουµε να εκτι-

µήσουµε είναι ………………… µε εκείνο το οποίο συσχετίζουµε.

(διαφορετικό, παρόµοιο, ισοδύναµο, παράλληλο)

γ) Τα εµπειρικά µοντέλα µπορούν να χρησιµοποιηθούν ………………… στις

τεχνικές τµηµατοποίησης και να δώσουν ………………… πληροφορίες σχετι-

κά µε τα µεγέθη που εξετάζονται.

(ανεξάρτητα, παράλληλα, επικουρικά) (αµφιλεγόµενες, πολύτιµες)

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 60

Βασικό στοιχείο για την εκτίµηση παραγόντων, όπως οι ανάγκες σε ανθρώπινο δυνα-

µικό, το κόστος και ο χρόνος είναι κυρίως η πρόβλεψη για το µέγεθος (size) του

έργου έτσι ώστε µε βάση αυτό το µέγεθος να προκύψουν (συνήθως µετά από απλές

αριθµητικές πράξεις) τα υπόλοιπα µεγέθη (κόστος και χρόνος). Για άµεση προσέγ-

γιση, χρησιµοποιούµε εκτίµηση που βασίζεται σε γραµµές κώδικα (LOC based

estimation), ενώ για µια έµµεση προσέγγιση, αλλά αρκετές φορές µε καλύτερα απο-

τελέσµατα, επιλέγουµε την εκτίµηση που βασίζεται σε λειτουργικά σηµεία

(function point based estimation). Στις τεχνικές αυτές, που η εκτίµηση βασίζεται

στην αρχική εκτίµηση του µεγέθους του έργου (είτε σε LOC, είτε σε FPs), η ακρί-

βεια της εκτίµησης σχετίζεται µε τα παρακάτω:

• Το βαθµό επιτυχίας της εκτίµησης του µεγέθους,

• την ικανότητα να µεταφραστεί αυτή η εκτίµηση του µεγέθους σε ανθρώπινη προ-

σπάθεια, χρόνο και χρήµατα,

• το βαθµό στον οποίο ο αρχικός προγραµµατισµός του έργου αντανακλά τις ικα-

νότητες της οµάδας και

• τη σταθερότητα των απαιτήσεων και το περιβάλλον που υποστηρίζει την προ-

σπάθεια ανάπτυξης του έργου.

Εκτίµηση από κάτω προς τα πάνω

Η εκτίµηση από κάτω προς τα πάνω είναι µία τεχνική εκτίµησης που βασίζεται στη

λογική διάσπασης του έργου σε µικρότερα τµήµατα. Είναι δηλαδή µία τεχνική τµη-

µατοποίησης (η πιο διαδεδοµένη από αυτές τις τεχνικές) που αναφέραµε στην ενό-

τητα 2.1.3. Στη εκτίµηση από κάτω προς τα πάνω, το έργο διασπάται σε κοµµάτια

και µετριέται το κόστος καθενός από αυτά. Τελικά, από το σύνολο των επιµέρους

τµηµάτων εκτιµάται το συνολικό κόστος. Αυτή η τεχνική έχει στατιστικό πλεονέ-

κτηµα σε σχέση µε τις υπόλοιπες τεχνικές µόνο αν οι ξεχωριστές µετρήσεις είναι

ανεξάρτητες και απαλλαγµένες από προκατάληψη. Αυτό δεν είναι κάτι αυτονόητο

και δεν είναι εύκολο να εξασφαλιστεί σε ένα περιβάλλον µε πολλούς εργαζόµενους

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

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

κοµµάτι µε υψηλότερο κόστος, αυτό σίγουρα επηρεάζει τον πρώτο, ο οποίος συζη-

τώντας γι αυτό θα σκεφτεί να αυξήσει το κόστος του δικού του τµήµατος. Αυτό θα

είχε ως συνέπεια να µειώνεται η αντικειµενικότητα των µετρήσεων.

Έστω m διαφορετικοί προγραµµατιστές που εκτιµούν ανεξάρτητα κάθε τµήµα

(module) ενός έργου, κόστους ci και κάθε εκτίµηση έχει µια απόκλιση σi2. Τότε, το

6 12 . 2 ∆ ∂ Ã ¡ π ∫ ∂ ™ ∂ ∫ ∆ π ª ∏ ™ ∏ ™ ∫ ∞ π ∂ ª ¶ ∂ π ƒ π ∫ ∞ ª √ ¡ ∆ ∂ § ∞

Μέγεθος (size)στη γλώσσα τουλογισµικού,εννοούµε τηµετρήσιµη ποσό-τητα –που συνή-θως µετριέται σεγραµµές κώδι-κα– του εξαγόµε-νου προϊόντος.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 61

6 2 K E º A § A I O 2 : ∂ ∫ ∆ π ª ∏ ™ ∏ ∫ ∞ π ∞ ¡ ∞ § À ™ ∏ ∫ π ¡ ¢ À ¡ √ À

συνολικό εκτιµώµενο κόστος cp του έργου θα είναι:

cp = c1 + c2 +…+ cm (2.1)

Η συνολική απόκλιση σp είναι:

σp2 = σ1

2 + σ22 +…+σm

2 (2.2)

Αν κάνουµε την υπόθεση ότι έχουµε πετύχει να διασπάσουµε το έργο σε τµήµατα

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

cp = m c µε (c1 = c2 = … = cm = c) (2.3)

σp = m1/2 σ µε (σ1 = σ2 = … = σm = σ) (2.4)

Παρατηρούµε ότι για σταθερό σ, η ακρίβεια της µέτρησης αυξάνει όσο αυξάνει ο

αριθµός των modules που εξετάζονται. Αυτό δείχνει τη σηµασία της διάσπασης του

προβλήµατος και της λεπτοµερούς ανάλυσης κάθε επιµέρους κοµµατιού.

Εκτίµηση που βασίζεται στο τελικό κόστος

Η τεχνική της εκτίµησης που βασίζεται στο τελικό κόστος µπορεί να φαίνεται ψυχρή

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

ρες επιχειρήσεις και ειδικότερα στις µικρές επιχειρήσεις. Σε αυτή την τεχνική, ο βασι-

κός παράγοντας είναι το κόστος και όχι οι απαιτήσεις του έργου. Το κόστος θεωρεί-

ται σταθερά και κατά συνέπεια οι απαιτήσεις του έργου είναι δυνατό να µεταβλη-

θούν έτσι ώστε να µην ξεπεραστεί ένα καθορισµένο τελικό κόστος. Με αυτή την

τεχνική ο υπεύθυνος έργου ξεκινά µε σκοπό όχι να εκτιµήσει πόσο θα κοστίσει

κάποιο έργο, αλλά τι µπορεί να υλοποιηθεί µε δεδοµένο ότι δεν µπορεί να ξεπερα-

στεί το καθορισµένο τελικό κόστος.

Εκτίµηση που βασίζεται σε γραµµές κώδικα

Οι γραµµές κώδικα (Lines Of Code), που από αυτό το σηµείο και µετά θα αναφέ-

ρονται ως LOC, χρησιµοποιούνται είτε ως µεταβλητή εκτίµησης που µετρά το µέγε-

θος, είτε ως έµµεση εκτίµηση παραγωγικότητας αξιοποιώντας τα διαθέσιµα ιστορι-

κά δεδοµένα. Ο υπεύθυνος του έργου, σε συνεργασία µε µία οµάδα έµπειρων προ-

γραµµατιστών και βασισµένος στην αρχική ανάλυση απαιτήσεων, διασπά το πρό-

βληµα σε βασικές λειτουργίες, επιλέγει τις τεχνικές ανάπτυξης που θα χρησιµοποι-

ηθούν και έτσι υπολογίζει τις γραµµές κώδικα (LOC) για κάθε λειτουργία. Έπειτα,

αξιοποιώντας ιστορικά δεδοµένα, επιλέγεται η βασική µετρική παραγωγικότητας

που συνήθως είναι η: γραµµές κώδικα / ανθρωποµήνες (LOC / pm) και εξάγονται

οι εκτιµήσεις.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 62

Γενικά είναι σκόπιµο το έργο να χωρίζεται σε κοµµάτια ανάλογα µε το µέγεθος της

οµάδας, το είδος κάθε λειτουργίας ή την πολυπλοκότητά της. Έτσι, σε κάθε τµήµα του

έργου εφαρµόζεται η παραπάνω µέθοδος ανεξάρτητα. Στην περίπτωση των γραµµών

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

λεπτοµέρειας. Όσα περισσότερα είναι τα επιµέρους έργα, τόσο πιο ακριβής θα είναι

και η εκτίµηση, όπως είδαµε και στην τεχνική της εκτίµησης από κάτω προς τα πάνω.

Χρησιµοποιώντας τα ιστορικά δεδοµένα (ή αν αυτά δεν είναι διαθέσιµα, την εµπει-

ρία και τη διαίσθησή του) ο υπεύθυνος έργου εκτιµά 3 σηµεία. Αυτή είναι η λεγό-

µενη εκτίµηση της αναµενόµενης τιµής. Γίνεται δηλαδή εκτίµηση της πιο απαισιό-

δοξης, της πιο πιθανής και της πιο αισιόδοξης τιµής του µεγέθους όπως στη σχέση

(2.5), όπου το EV είναι η αναµενόµενη τιµή (Expected Value) που µετράται σε γραµ-

µές κώδικα και τα sopt, sm και spess, είναι η µέση τιµή αντίστοιχα της αισιόδοξης της

πιθανής και της απαισιόδοξης εκτίµησης. Αυτή η εξίσωση δίνει µεγαλύτερο βάρος

στην πιθανή λύση και ακολουθεί µια βήτα – κατανοµή:

EV = (sopt + 4 sm + spess) / 6 (2.5)

Με αυτή την τεχνική υπάρχει µικρή πιθανότητα να ξεφύγουµε από την απαισιόδο-

ξη και την αισιόδοξη εκτίµηση αφού υπάρχει και η δυνατότητα υπολογισµού της

απόκλισης. Έτσι και αλλιώς, η εµπειρία, η διαίσθηση και η κοινή λογική είναι εκεί-

να τα στοιχεία που θα κάνουν πιο ασφαλείς τις εκτιµήσεις. Όσοι υποστηρίζουν αυτή

την τεχνική, πιστεύουν πως η µέτρηση των γραµµών κώδικα µπορεί να χρησιµο-

ποιηθεί σε όλα τα έργα ανάπτυξης λογισµικού, είναι εύκολα υλοποιήσιµη και υπάρ-

χουν πολλά ιστορικά δεδοµένα πάνω σε αυτό το θέµα. Από την άλλη πλευρά, οι

µετρήσεις των γραµµών κώδικα φαίνονται να εξαρτώνται από τη χρησιµοποιούµε-

νη γλώσσα προγραµµατισµού, δεν µπορούν να διαχειριστούν εύκολα τις σύγχρονες

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

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

ανάλυση και ο σχεδιασµός του έργου.

6 32 . 2 ∆ ∂ Ã ¡ π ∫ ∂ ™ ∂ ∫ ∆ π ª ∏ ™ ∏ ™ ∫ ∞ π ∂ ª ¶ ∂ π ƒ π ∫ ∞ ª √ ¡ ∆ ∂ § ∞


Ο Χρήστος πρέπει να εκτιµήσει το κόστος ενός έργου. Αυτή τη φορά θα βασίσει

την εκτίµηση σε γραµµές κώδικα για τις οποίες έχει και εµπειρία και ιστορικά δεδο-

µένα. Από τα ιστορικά δεδοµένα γνωρίζει ότι έχει µία µέση τιµή 1.250 LOC/pm

και ότι το κόστος του ανθρωποµήνα είναι 4.500 Euro. Ο Χρήστος σε συνεργασία

µε άλλους δύο έµπειρους προγραµµατιστές έχουν διασπάσει το έργο σε 5 τµήµα-

τα και για κάθε ένα έχουν υπολογίσει (βασισµένοι στην εµπειρία τους και στα ιστο-

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 63

6 4 K E º A § A I O 2 : ∂ ∫ ∆ π ª ∏ ™ ∏ ∫ ∞ π ∞ ¡ ∞ § À ™ ∏ ∫ π ¡ ¢ À ¡ √ À

Απάντηση

Μπορούµε να υπολογίσουµε την εκτίµηση της αναµενόµενης τιµής είτε στα σύνο-

λα των προβλέψεων είτε για κάθε τµήµα. Και οι δύο περιπτώσεις θα οδηγήσουν στο

ίδιο αποτέλεσµα. Μια επιχείρηση βέβαια θα την υπολόγιζε ξεχωριστά για κάθε

τµήµα, ώστε να µπορεί να ελέγχει την εκτίµηση τµηµατικά. Εµείς, για λόγους ευκο-

λίας, θα την υπολογίσουµε συνολικά.

Από τον πίνακα έχουµε (για όλο το έργο):

sopt = 8.050 LOC

sm = 10.400 LOC

spess = 13.700 LOC

Εφαρµόζοντας στις παραπάνω τιµές τη σχέση EV = (sopt + 4 sm + spess) / 6 προκύπτει

ότι EV = 10.558 LOC. Χρησιµοποιώντας τα ιστορικά δεδοµένα (1.250 γραµµές

κώδικα ανά ανθρωποµήνα) αυτό αντιστοιχεί σε 8,45 ανθρωποµήνες και χρησιµο-

ποιώντας το κόστος του ανθρωποµήνα οδηγεί σε µία εκτίµηση κόστους

8,45 × 4.500 Euro = 38.025 Euro που είναι και η εκτίµηση του κόστους.

Βέβαια σε αυτό το κόστος ο Χρήστος θα προσθέσει εκτιµήσεις για έξοδα ταξιδιών,

αγοράς εξοπλισµού και αναλωσίµων (αν υπάρχει ανάγκη για το έργο) και θα προ-

σθέσει και το κέρδος της εταιρίας του για να καταλήξει στην τελική τιµολόγηση

(δηλαδή στο ποσό που θα χρεώσει ή θα ζητήσει από τον πελάτη).

ρικά δεδοµένα) µία αισιόδοξη, µία κανονική και µία απαισιόδοξη εκτίµηση που

δίνονται στον παρακάτω πίνακα (όλες οι τιµές είναι σε LOC):

Τµήµατα Αισιόδοξη Κανονική Απαισιόδοξη

1ο τµήµα 2200 2650 3500

2ο τµήµα 750 1100 1500

3ο τµήµα 1800 2350 3000

4ο τµήµα 800 1200 1700

5ο τµήµα 2500 3100 4000

Υπολογίστε το τελικό κόστος του έργου που θα εκτιµήσει ο Χρήστος βασιζόµενοι

στην εκτίµηση της αναµενόµενης τιµής.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 64

Εκτίµηση που βασίζεται σε λειτουργικά σηµεία

Η εκτίµηση που βασίζεται σε λειτουργικά σηµεία ξεκινά πάλι µε τον προσδιορισµό

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

Το έργο δεν χωρίζεται σε τµήµατα, αλλά σε τοµείς πληροφορίας (information

domain values). Αυτοί οι τοµείς πληροφορίας ορίζονται [Alb79] ως:

• στοιχεία εισόδου (inputs)

• στοιχεία εξόδου (outputs)

• αρχεία (files)

• αναζητήσεις (inquiries)

• εξωτερικές διεπαφές (external interfaces)

Με αυτή την τεχνική µετριέται η λειτουργικότητα κάθε εφαρµογής, η οποία βέβαια

δεν είναι κάτι που υπολογίζεται άµεσα. Γι αυτό χρησιµοποιούνται έµµεσες µετρή-

σεις µεγεθών τα οποία καλούνται λειτουργικά σηµεία (function points), τα οποία

από αυτό το σηµείο και µετά θα αναφέρονται ως FP. Ένα FP µετριέται µε τη χρήση

µιας εµπειρικής σχέσης η οποία βασίζεται σε µετρήσιµα µεγέθη τοµέων πληροφο-

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

ρύθµισης πολυπλοκότητας (complexity adjustment factors) βασίζονται στις απα-

ντήσεις που δίνονται σε 14 διαφορετικά ερωτήµατα που έχουν σχέση µε τη λει-

τουργικότητα κάθε εφαρµογής (όπως για παράδειγµα τη δυνατότητα αποθήκευσης

και επαναφοράς δεδοµένων, το υπάρχον λειτουργικό περιβάλλον, την ικανότητα του

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

περιβάλλοντα κτλ). Οι 14 αυτοί παράγοντες παίρνουν τιµές από το 1 µέχρι το 5 ανά-

λογα µε το βαθµό που επηρεάζουν την εκτίµηση.

Η τελική τιµή των FP υπολογίζεται από τη σχέση (2.6), όπου οι σταθερές έχουν προ-

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

ροφορίας και το ΣFi είναι το άθροισµα όλων των τιµών των παραγόντων ρύθµισης

πολυπλοκότητας.

FPest = C × [0.65 + 0.01 × ΣFi] (2.6)

Για την εκτίµηση που βασίζεται σε λειτουργικά σηµεία θα µπορέσετε να βρείτε πολλά

στη σχολιασµένη βιβλιογραφία που υπάρχει στο τέλος του βιβλίου. Εκεί θα βρείτε τους

14 παράγοντες ρύθµισης πολυπλοκότητας, πληροφορίες για το πώς υπολογίζονται και

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

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

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

6 52 . 2 ∆ ∂ Ã ¡ π ∫ ∂ ™ ∂ ∫ ∆ π ª ∏ ™ ∏ ™ ∫ ∞ π ∂ ª ¶ ∂ π ƒ π ∫ ∞ ª √ ¡ ∆ ∂ § ∞

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 65

6 6 K E º A § A I O 2 : ∂ ∫ ∆ π ª ∏ ™ ∏ ∫ ∞ π ∞ ¡ ∞ § À ™ ∏ ∫ π ¡ ¢ À ¡ √ À

Απάντηση

Από την εξίσωση (2.6) ο Χρήστος υπολογίζει FPest = 56 × (0,65 + 0,01 × 52) = 65,5

FPs. Σύµφωνα µε τα ιστορικά δεδοµένα (7 FP/pm) αυτό αντιστοιχεί σε 9,36 ανθρω-

ποµήνες, ενώ χρησιµοποιώντας το κόστος του ανθρωποµήνα οδηγείται σε µία εκτί-

µηση κόστους 9,36 × 4.500 Euro = 42.120 Euro.

Συγκρίνοντας τα αποτελέσµατα από τις δυο µεθόδους (δείτε και τη δραστηριότητα

2.2), παρατηρούµε µια µικρή απόκλιση στη µέτρηση της προσπάθειας. Τέτοιες απο-

κλίσεις µπορούν να οφείλονται σε ασυµβατότητες των ιστορικών δεδοµένων, είτε

σε λάθη στη χρήση των γραµµών κώδικα ή των λειτουργικών σηµείων. Αυτός είναι

και ο λόγος που συνήθως χρησιµοποιούνται περισσότερες από µία τεχνικές εκτίµη-

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

εάν προκύπτουν µεγάλες διαφορές στα εξαγόµενα αποτελέσµατα, τότε δεν έχει γίνει

κατανοητός ο στόχος του έργου ή τα δεδοµένα που χρησιµοποιήθηκαν για την µέτρη-

ση της παραγωγικότητας δεν ισχύουν πια για τα συγκεκριµένα έργα. Σε αυτή την

περίπτωση, ο Χρήστος ως υπεύθυνος του έργου θα πρέπει να επαναπροσδιορίσει το

πρόβληµα και να συµβιβάσει τα αντίθετα αποτελέσµατα.


Ο Χρήστος αυτή τη φορά θα βασίσει την εκτίµησή του για το ίδιο έργο σε λειτουρ-

γικά σηµεία. Από τα ιστορικά δεδοµένα γνωρίζει ότι έχει µία µέση τιµή 7 FP/pm και

ότι το κόστος του ανθρωποµήνα είναι 4.500 Euro. Ο Χρήστος σε συνεργασία µε

άλλους δύο έµπειρους προγραµµατιστές έχει υπολογίσει (βασισµένος στην εµπειρία

του και στα ιστορικά δεδοµένα) τα παρακάτω FP για κάθε τοµέα πληροφορίας:

Τµήµατα FP

στοιχεία εισόδου 11

στοιχεία εξόδου 14

αρχεία 20

αναζητήσεις 7

εξωτερικές διεπαφές 4

Count C 56

Υπολογίστε το τελικό κόστος του έργου όπως θα το εκτιµήσει ο Χρήστος, θεω-

ρώντας ότι το άθροισµα των τιµών από 0 έως 5 για τους 14 παράγοντες ρύθµισης

πολυπλοκότητας που µέτρησε ο Χρήστος είναι ίσο µε 52.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 66

2.2.2 ∂ÌÂÈÚÈÎ¿ ÌÔÓÙ¤Ï·

Τα εµπειρικά µοντέλα βασίζονται κυρίως σε ιστορικά δεδοµένα και οδηγούν σε µία

σχέση της µορφής (2.7), όπου το d είναι ένα από τα µεγέθη που υπολογίζονται (συνή-

θως προσπάθεια, κόστος, διάρκεια έργου κτλ.) και το ui είναι µια σειρά από επιλεγµέ-

6 72 . 2 ∆ ∂ Ã ¡ π ∫ ∂ ™ ∂ ∫ ∆ π ª ∏ ™ ∏ ™ ∫ ∞ π ∂ ª ¶ ∂ π ƒ π ∫ ∞ ª √ ¡ ∆ ∂ § ∞



∆είτε στο τέλος του βιβλίου τις σωστές απαντήσεις, καθώς και την αιτιολόγηση

για κάθε απάντηση.


i) Σε µεγάλου µεγέθους έργα είναι απαραίτητη η χρήση

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

οι ανάγκες σε ανθρώπινο δυναµικό, το κόστος και

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

εκτίµησης σε συνάρτηση µε την άλλη.

ii) Στις τεχνικές που η εκτίµηση βασίζεται στο µέγεθος,

η ακρίβεια της εκτίµησης σχετίζεται µε την ικανότητα

να µεταφραστεί αυτή η εκτίµηση του µεγέθους

σε ανθρώπινη προσπάθεια, χρόνο και χρήµατα.

iii)Η εκτίµηση από κάτω προς τα πάνω είναι µία τεχνική

εκτίµησης που βασίζεται στη λογική ότι πρώτα κάνουν

εκτίµηση οι κατώτεροι προγραµµατιστές, µετά

οι έµπειροι και τελευταίος ο υπεύθυνος έργου.

iv) Η τεχνική της εκτίµησης που βασίζεται στο τελικό

κόστος είναι η λιγότερο διαδεδοµένη στις µικρές

επιχειρήσεις.

v) Οι γραµµές κώδικα µπορούν να χρησιµοποιούνται

ως έµµεση εκτίµηση παραγωγικότητας αξιοποιώντας

τα διαθέσιµα ιστορικά δεδοµένα.

vi) H εκτίµηση που βασίζεται σε γραµµές κώδικα και

η εκτίµηση που βασίζεται σε λειτουργικά σηµεία είναι

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

«τεχνικές τµηµατοποίησης».

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 67

6 8 K E º A § A I O 2 : ∂ ∫ ∆ π ª ∏ ™ ∏ ∫ ∞ π ∞ ¡ ∞ § À ™ ∏ ∫ π ¡ ¢ À ¡ √ À

νες ανεξάρτητες παραµέτρους (όπως είναι οι γραµµές κώδικα ή τα λειτουργικά σηµεία):

d = f (ui ) (2.7)

Ένα από τα πιο διαδεδοµένα µοντέλα είναι το COCOMO (το όνοµα προκύπτει από

τα αρχικά του Constructive Cost Model) και προτάθηκε από τον Boehm [Boe81].

Υπάρχουν τρεις τύποι του µοντέλου: βασικό (basic), ενδιάµεσο (intermediate) και

προηγµένο (advanced). Τα έργα λογισµικού στα οποία εφαρµόζονται αυτοί οι τύποι

χωρίζονται, σύµφωνα µε τον Boehm σε τρεις κατηγορίες, µε βάση το βαθµό εµπει-

ρίας, τις γνώσεις, τους περιορισµούς και τις απαιτήσεις της εφαρµογής: οργανική

κατηγορία (organic mode), ηµι – προσαρτηµένη κατηγορία (semi – detached mode)

και ενσωµατωµένη κατηγορία (embedded mode). Στην οργανική κατηγορία έργων,

µικρές οµάδες µε ικανοποιητική εµπειρία και γνώση, εργάζονται σε µικρά και µε

χαµηλές απαιτήσεις έργα λογισµικού. Στην ηµι – προσαρτηµένη κατηγορία έργων,

εργάζονται άτοµα µε διαφορετική εµπειρία και περιορισµένη γνώση για το σύστη-

µα και τέλος, στην ενσωµατωµένη κατηγορία έργων, οι απαιτήσεις των έργων είναι

αυστηρές και οι περιορισµοί που θέτονται από το σύστηµα καθορίζουν σε µεγάλο

βαθµό το ρυθµό της διαδικασίας (για παράδειγµα ένα σύστηµα ελέγχου για πυρηνι-

κό εργοστάσιο παραγωγής ηλεκτρικής ενέργειας).

Το βασικό µοντέλο

Το βασικό µοντέλο COCOMO εκτιµά την απαιτούµενη προσπάθεια υλοποίησης και

το κόστος ανάλογα µε το µέγεθος του προγράµµατος, το οποίο µετράται σε χιλιάδες

γραµµές κώδικα (KLOC). Στο βασικό µοντέλο, για κάθε τύπο λογισµικού, η προ-

σπάθεια δίνεται από την εξίσωση (2.8), όπου τα α και β είναι σταθερές που εξαρτώ-

νται από τον τύπο του έργου και δίνονται στον πίνακα που ακολουθεί και το ΚLOC

είναι οι υπολογισµένες γραµµές κώδικα που µετρώνται σε χιλιάδες (Κ = 103 ΚLOC

= 1000 LOC). Το Ε εκτιµάται σε ανθρωποµήνες.

E = α (KLOC) β (2.8)

Κατηγορία έργου α β

Οργανική 2,4 1,05

ηµι – προσαρτηµένη 3,0 1,12

Ενσωµατωµένη 3,6 1,20

Η προσπάθεια Ε, όπως φαίνεται και από την εξίσωση (2.8) είναι µια εκθετική συνάρ-

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

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 68

έργο (διάρκεια έργου) δίνεται στην εξίσωση (2.9), ενώ ο αναγκαίος αριθµός ατόµων

για να υλοποιηθεί το έργο στην εξίσωση (2.10), όπου ο χρόνος D µετράται σε µήνες

και το Ν δίνει τον αριθµό των ατόµων που απαιτούνται για την ολοκλήρωση του

έργου. Η σταθερά γ παίρνει τις παρακάτω τιµές για τους τρεις τύπους έργων λογι-

σµικού (οργανική γ = 0,38, ηµι – προσαρτηµένη γ = 0,35 και ενσωµατωµένη γ = 0,32).

D = 2,5E γ (2.9)

(2.10)

Εδώ είναι σηµαντικό να τονισθεί ότι η σχέση προσπάθειας και χρόνου δεν είναι

γραµµική (όπως φαίνεται και από την εξίσωση 2.9) και ότι µια µείωση του αριθµού

των εργαζόµενων δεν θα επιφέρει απαραίτητα µια ανάλογη αύξηση του χρόνου εκτέ-

λεσης. Αυτό σηµαίνει πως η έγκαιρη ολοκλήρωση δεν εξαρτάται µόνο από τον αριθ-

µό των ανθρώπων που απασχολούνται αλλά από την ολική προσπάθεια, η οποία

εξαρτάται άµεσα από την παραγωγικότητα των παραπάνω ανθρώπων αλλά και από

πολλούς ακόµα σηµαντικούς παράγοντες. Άλλωστε, όπως προκύπτει από την πρα-

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

της διάρκειας του έργου στις περιπτώσεις όπου τα αποθέµατα του ανθρώπινου δυνα-

µικού είναι περιορισµένα και οι ηµεροµηνίες παράδοσης του έργου είναι ρευστές.

Το ενδιάµεσο µοντέλο

Το ενδιάµεσο µοντέλο COCOMO συνυπολογίζει και άλλους επιπλέον παράγοντες οι

οποίοι σχετίζονται άµεσα µε το προϊόν, την παραγωγή, το ανθρώπινο δυναµικό και

το υλικό που χρησιµοποιείται. Οι παράγοντες αυτοί είναι δυνατό να δρουν αθροιστι-

κά, επηρεάζοντας δυναµικά το κόστος και το χρόνο που έχει αρχικά ορισθεί. Με βάση

αυτούς τους παράγοντες, η προσπάθεια Ε για το ενδιάµεσο µοντέλο δίνεται από την

εξίσωση (2.11), όπου το EAF (Effort Adjustment Factor) είναι ο παράγοντας ρύθµι-

σης της προσπάθειας και κυµαίνεται –από ιστορικά δεδοµένα– µεταξύ των τυπικών

τιµών 0,9 και 1,4 δηλαδή µεταβάλει την τιµή του Ε κατά 90% έως 140%.

Ε = ai KLOC βi × EAF (2.11)

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

για τα αi και βi.

Το πλήρες µοντέλο και γενικές πληροφορίες για το COCOMO

Το Πλήρες µοντέλο συγκεντρώνει τα χαρακτηριστικά των δυο προηγούµενων υπο-

λογίζοντας και την επίδραση των παραπάνω παραγόντων σε κάθε βήµα της διαδι-

NE

D=

6 92 . 2 ∆ ∂ Ã ¡ π ∫ ∂ ™ ∂ ∫ ∆ π ª ∏ ™ ∏ ™ ∫ ∞ π ∂ ª ¶ ∂ π ƒ π ∫ ∞ ª √ ¡ ∆ ∂ § ∞

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 69

7 0 K E º A § A I O 2 : ∂ ∫ ∆ π ª ∏ ™ ∏ ∫ ∞ π ∞ ¡ ∞ § À ™ ∏ ∫ π ¡ ¢ À ¡ √ À

κασίας ανάπτυξης. Υπολογίζει ολοκληρωµένα και σφαιρικά αυτούς τους παράγο-

ντες που επηρεάζουν την προσπάθεια, µειώνοντας έτσι την πιθανότητα λάθους. ∆εν

θα επεκταθούµε άλλο στο πλήρες µοντέλο, αφού όποιος επιθυµεί µπορεί να το µελε-

τήσει στην προτεινόµενη βιβλιογραφία.

Γενικά, και τα τρία µοντέλα COCOMO µπορούν να προσαρµοστούν σε συγκεκρι-

µένες εφαρµογές, θέτοντας κάθε φορά τις σταθερές και τους εκθέτες ανάλογα µε τον

τύπο του έργου που αναπτύσσεται και αντλώντας στοιχεία από ιστορικά δεδοµένα.

Μια γρήγορη εξέταση κάποιων εµπειρικών µοντέλων εκτίµησης µας οδηγεί στο

συµπέρασµα πως τα δεδοµένα θα πρέπει να υπολογίζονται σύµφωνα µε τις ανάγκες

του κάθε έργου, εξετάζοντας τις τρέχουσες συνθήκες. Το µειονέκτηµα των µοντέ-

λων COCOMO είναι το γεγονός ότι τα προϊόντα λογισµικού αποτελούνται συνήθως

από διαφορετικούς τύπους τµηµάτων, κάθε ένα από τα οποία έχει ειδικές ανάγκες

και διάφορες από τα υπόλοιπα, και έτσι πρέπει να αντιµετωπίζονται.

Πάντως, όπως αναφέρει ο Pressman [Pre97], τα µοντέλα αυτά είναι επιτυχή, αν µπο-

ρούν να εκτιµούν το κόστος µε απόκλιση έως 20%, και τη διάρκεια του έργου µε

απόκλιση έως 70% της πραγµατικής. Το ποσοστό αυτό µπορεί να µην είναι το ιδα-

νικό, αλλά συνήθως αποτελεί µία πολύ καλή βοήθεια για οικονοµική ανάλυση και

κυρίως για λήψη αποφάσεων.


Αντιστοιχίστε τις φράσεις της δεξιάς στήλης µε την κατάλληλη κατηγορία έργων

σύµφωνα µε την κατάταξη των έργων κατά το COCOMO, ανάλογα µε την κατη-

γορία στην οποία αναφέρονται. Προσοχή, κάθε φράση δεξιά αντιστοιχεί σε µόνο

µία κατηγορία έργων στα αριστερά.

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

άτοµα µε γνώση για το σύστηµα

χαµηλές απαιτήσεις έργων

ηµι – προσαρτηµένη κατηγορία αυστηρές απαιτήσεις έργων

άτοµα µε ικανοποιητική εµπειρία

µικρές οµάδες ανάπτυξης

ενσωµατωµένη κατηγορία άτοµα µε περιορισµένη γνώση για

το σύστηµα

µικρά έργα

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 70

2.3 ∞Ó¿Ï˘ÛË ÎÈÓ‰‡ÓÔ˘

Ο Hambling [Ham96] µιλώντας για την «παθολογία ενός αποτυχηµένου έργου λογι-

σµικού», αναφέρει ότι ένα τέτοιο έργο περνάει από µία αρχική κατάσταση αισιοδο-

ξίας (όπου γίνονται και τα περισσότερα λάθη) σε µία φάση ρεαλισµού (όπου οι

πραγµατικές συνθήκες αρχίζουν να αποκαλύπτονται), µετά σε µία κατάσταση απαι-

σιοδοξίας (όπου τα προβλήµατα που δεν είχαν προβλεφθεί αρχικά αρχίζουν να

κάνουν αδύνατη την τήρηση των αρχικών σχεδίων) και µετά σε µία κατάσταση απο-

γοήτευσης (όπου πια είναι βέβαιο ότι οι αρχικές εκτιµήσεις ήταν τελείως λανθα-

σµένες και ότι το έργο θα αποτύχει). Ένα καλό γιατρικό –αλλά όχι πανάκεια– για να

µην προκύψουν απρόβλεπτα προβλήµατα στην εξέλιξη του έργου, είναι η ανάλυση

κινδύνου. Αν και δύσκολα κανείς θα βρει κάποιον κατάλληλο ορισµό του κινδύνου,

το σίγουρο είναι ότι ο κίνδυνος εµπεριέχει [Hig95] αβεβαιότητα και απώλεια. Εάν

κάτι είναι απόλυτα βέβαιο ότι θα συµβεί, ή δεν έχει αρνητικές συνέπειες τότε δεν

αποτελεί κίνδυνο. Κατά συνέπεια, η ανάλυση του κινδύνου είναι η µελέτη (συνή-

θως από τον υπεύθυνο του έργου) όλων εκείνων των καταστάσεων που αν συµβούν

(χωρίς να είναι βέβαιο ότι θα συµβούν) θα έχουν αρνητικές συνέπειες για το έργο.

Στα πρώτα στάδια του προγραµµατισµού του έργου, ο υπεύθυνος του έργου πρέπει

να εντοπίσει πού βρίσκεται ο κίνδυνος στο έργο (προβλέποντας καταστάσεις που θα

είχαν αρνητικές συνέπειες). Ακόµα πιο σηµαντικό όµως είναι να προβλέψει και τους

τρόπους για την αντιµετώπιση αυτών των καταστάσεων εάν συµβούν. Η ανάλυση

κινδύνου βοηθά τον υπεύθυνο του έργου να προγραµµατίσει τα οικονοµικά του

έργου και τα εναλλακτικά σενάρια που µπορεί να υλοποιήσει σε περίπτωση που κάτι

δεν πάει καλά. Υπάρχουν πολλά θέµατα που σχετίζονται µε την ύπαρξη κινδύνου

στα πλαίσια ενός έργου. Ενδεικτικά αναφέρουµε:

• Το µέγεθος του έργου. Είναι γεγονός ότι όσο αυξάνεται το µέγεθος ενός έργου

τόσο αυξάνεται και ο κίνδυνος.

• Η εξάρτηση από τον ανθρώπινο παράγοντα. Αν το έργο στηρίζεται αποκλειστικά

σε έναν άνθρωπο (ή µια µικρή οµάδα ανθρώπων) και αυτός φύγει από την επιχεί-

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

• Οι εξελίξεις στην αγορά. Το έργο µπορεί να θεωρηθεί απαρχαιωµένο όταν θα

ολοκληρωθεί.

• Η τεχνολογία. Το έργο µπορεί να χρησιµοποιεί πρωτοποριακές αλλά ταυτόχρο-

να ανώριµες τεχνολογίες, ή τεχνολογίες που η επιχείρηση δεν είναι σε θέση να

διαχειριστεί.

• Το ποσοστό κατά το οποία τα προγράµµατα και οι προϋπολογισµοί που καθορί-

7 12 . 3 ∞ ¡ ∞ § À ™ ∏ ∫ π ¡ ¢ À ¡ √ À

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

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 71

7 2 K E º A § A I O 2 : ∂ ∫ ∆ π ª ∏ ™ ∏ ∫ ∞ π ∞ ¡ ∞ § À ™ ∏ ∫ π ¡ ¢ À ¡ √ À

ζονται ανταποκρίνονται στην πραγµατικότητα.

• Οι υπεργολαβίες. Η µη τήρηση προθεσµιών από εξωτερικούς προµηθευτές.

• Ο πελάτης. Ο βαθµός στον οποίο ο πελάτης είναι εξοικειωµένος µε την τεχνολογία

µπορεί να αποτελέσει αρνητικό παράγοντα στην εξέλιξη και πρόοδο του έργου.

• Το περιβάλλον υλοποίησης. Η ύπαρξη, η διαθεσιµότητα και η ποιότητα του εξο-

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

• Τα λάθη στον αρχικό σχεδιασµό των τµηµάτων ή του περιβάλλοντος αλληλεπί-

δρασης του λογισµικού, που είναι κι ένα από τα σηµαντικότερα σηµεία!

Ο Boehm [Boe89] προτείνει στους υπεύθυνους έργου, αφού θέσουν µία σειρά από

ερωτήµατα για να εντοπίσουν περιπτώσεις όπως αυτές που αναφέραµε παραπάνω,

να δηµιουργήσουν ένα πίνακα όπου κάθε πιθανός κίνδυνος να τοποθετείται σε µία

κατηγορία, ανάλογα µε τις συνέπειες που θα είχε για την επιχείρηση. Ο πίνακας

αυτός ονοµάζεται πίνακας αξιολόγησης συνεπειών (impact assessment table) και

οι κατηγορίες είναι:

1. καταστροφικό (catastrophic)

2. κρίσιµο (critical)

3. µέτριο (marginal)

4. αµελητέο (negligible)

Στην πρώτη κατηγορία καταγράφονται περιπτώσεις κινδύνου που θα οδηγούσαν την

επιχείρηση σε καταστροφή ή σηµαντικές απώλειες, ενώ στην τελευταία αυτές που

δεν θα είχαν σηµαντικές αρνητικές συνέπειες για την επιχείρηση. Από τον πίνακα

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

ο υπεύθυνος του έργου θα αποφασίσει αν πρέπει να προχωρήσει το έργο και τι ενέρ-

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

θυνος του έργου µπορεί να πάρει την απόφαση να µην ξεκινήσει κάποιο έργο ώστε

να µην εµπλακεί η επιχείρηση σε περιπέτειες. Εδώ µπορεί να κάνει δύο είδη λάθους:

α) Να αποφασίσει να µην ξεκινήσει ένα έργο που στην πραγµατικότητα έχει µικρό

κίνδυνο για την επιχείρηση (µε συνέπεια η επιχείρηση να χάσει µία ευκαιρία),

β) να επιτρέψει να ξεκινήσει ένα έργο που έχει µεγάλο κίνδυνο µε καταστροφικές

συνέπειες (µε συνέπεια να θέσει την επιχείρηση σε κίνδυνο).

Είναι σαφές ότι λάθος του δεύτερου είδους µπορεί να είναι άµεσα καταστροφικό,

αλλά και συνεχόµενα λάθη του πρώτου είδους πιθανότατα θα οδηγήσουν την επι-

χείρηση σε συρρίκνωση, αφού ο αδικαιολόγητος δισταγµός δεν συγχωρείται σε µία

ανταγωνιστική αγορά.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 72

7 32 . 3 ∞ ¡ ∞ § À ™ ∏ ∫ π ¡ ¢ À ¡ √ À


Ο Χρήστος αναλαµβάνει να εκτιµήσει τον κίνδυνο για ένα νέο έργο το οποίο η

εταιρία του εξετάζει την προοπτική να αναλάβει. Εξετάζοντας µόνο τον κίνδυνο

σχετικά µε τον πελάτη, σκεφτείτε τι ερωτήσεις θα έθετε ο Χρήστος για να µπορέ-

σει να εκτιµήσει τον κίνδυνο σε σχέση µε τον πελάτη. Γράψτε σε χαρτί τουλάχι-

στον 5 ερωτήσεις (σε τέτοια µορφή που αν η απάντηση είναι «ναι» αυτό να σηµαί-

νει αυξηµένο κίνδυνο) και προτείνετε πιθανές λύσεις αν υπάρχει κίνδυνος.

Απάντηση

Οι ερωτήσεις που ετοίµασε ο Χρήστος και που σχετίζονται µε τον πελάτη είναι οι

παρακάτω (στην παρένθεση τι σκέφτηκε σε περίπτωση θετικής απάντησης):

1. Είναι η πρώτη φορά που συνεργαζόµαστε µε το συγκεκριµένο πελάτη; (Αν ναι,

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

να αντλήσουµε πληροφορίες;)

2. Οι προδιαγραφές του έργου µας δόθηκαν από τον πελάτη προφορικά; (Αν ναι, τότε

έχει τις ικανότητες –και κυρίως τη διάθεση– να καταγράψει τις απαιτήσεις του;)

3. Ο πελάτης έχει ασαφή εικόνα για το τι θέλει να γίνει στο έργο; (Αν ναι, έχουµε

συνεργάτες στην εταιρία που να γνωρίζουν το αντικείµενό του για να τον βοη-

θήσουν στον καθορισµό των απαιτήσεων, ώστε να µην ανακαλύπτει απαιτήσεις

µετά την έναρξη της υλοποίησης;)

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

έτσι ώστε να καταγράψουµε µαζί και µε δοµηµένο τρόπο τις προδιαγραφές του

έργου; (Εάν ναι, µπορεί να διαθέσει χρόνο και προσωπικό;)

5. Ο πελάτης έχει άγνοια από τεχνικά θέµατα σχετικά µε το αντικείµενο; (Εάν ναι, έχει

τη θέληση και το χρόνο να εκπαιδευτεί σύντοµα για τις δυνατότητες που µπορεί να

του παρέχει η τεχνολογία πριν προχωρήσουµε στις προδιαγραφές του έργου;)

Θα µπορούσαν να τεθούν κι άλλες ερωτήσεις, ή ερωτήσεις που θέτουν τα ίδια ερω-

τήµατα µε διαφορετικό τρόπο. Ο κίνδυνος που θέλει να εντοπίσει ο Χρήστος µε

αυτές τις ερωτήσεις είναι µήπως ο πελάτης δεν έχει ξεκάθαρη γνώµη για το έργο

(είτε γιατί δεν έχει τεχνικές γνώσεις, είτε γιατί δεν αφιέρωσε χρόνο σε αυτό) µε συνέ-

πεια οι αρχικές απαιτήσεις του να ανατραπούν αργότερα. Επίσης τον ανησυχεί η δια-

θεσιµότητα του πελάτη να συνεργαστεί (να επενδύσει σε χρόνο) για τον αυστηρό

καθορισµό του έργου.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 73

7 4 K E º A § A I O 2 : ∂ ∫ ∆ π ª ∏ ™ ∏ ∫ ∞ π ∞ ¡ ∞ § À ™ ∏ ∫ π ¡ ¢ À ¡ √ À


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

ανθρώπινο δυναµικό, το κόστος και ο χρόνος και την ανάλυση κινδύνου. ∆ώσαµε

παραδείγµατα τεχνικών εκτίµησης και µιλήσαµε για το εµπειρικό µοντέλο COCOMO.

Πρέπει πια να γνωρίζετε τις βασικές έννοιες και τους ορισµούς που σχετίζονται µε

την εκτίµηση παραγόντων όπως οι ανάγκες σε ανθρώπινο δυναµικό, το κόστος και

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

τις τεχνικές που περιγράψαµε σε κάποιο παράδειγµα έργου λογισµικού, µε την προ-

ϋπόθεση ότι έχετε τα αντίστοιχα ιστορικά δεδοµένα.

Σε αρκετά σηµεία του κεφαλαίου δεν επεκταθήκαµε σε λεπτοµερή παρουσίαση κάποι-

ων τεχνικών, αφήνοντάς σας να τις µελετήσετε από µόνοι σας. Σε αυτό το σηµείο θα

σας βοηθήσει η βιβλιογραφία που ακολουθεί. Γενικά, η συµβουλή µας είναι να ανα-

τρέχετε και σε βιβλιογραφικές πηγές πέρα από το βιβλίο αυτό, ώστε να εµπλουτίζετε

τις γνώσεις σας, αλλά και να διαβάζετε µε εναλλακτικό τρόπο την ύλη που καλύψα-

µε. Ακολουθεί βιβλιογραφία µε προτεινόµενα βιβλία για περαιτέρω µελέτη και υπο-

δείξεις για το πού να επικεντρώσετε την προσοχή σας.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 74





κεντρώσετε τη µελέτη σας σχετικά µε τα θέµατα του κεφαλαίου 2 και γενικές πλη-

ροφορίες για τη µελέτη σας.

[Alb83] A. J. Albrecht and J. E. Gaffney, «Software Function, Source Lines of Code

and Development Effort Prediction: A Software Science Validation», IEEE

Transactions on Software Engineering, (1983).

[Boe81] B. Boehm, «Software Engineering Economics», Prentice–Hall, (1981).

[Boe89] B. Boehm, «Software Risk Management», IEEE Computer Society Press,

(1989).

[Con86] S. D. Conte et al., «Software Engineering Metrics and Models», Benjamin

Cummings, (1986).

Είναι, ίσως, το πιο εξειδικευµένο βιβλίο για Τεχνολογία Λογισµικού µε έµφαση στην

εκτίµηση και µετρικές εκτίµησης. Εάν κάποιος θέλει να επεκταθεί στο θέµα της εκτί-

µησης σίγουρα πρέπει να το συµπεριλάβει στη µελέτη του. Στα κεφάλαια 5 και 6

υπάρχει εκτενέστατη κάλυψη του θέµατος της εκτίµησης, των µετρικών εκτίµησης

και των εµπειρικών µοντέλων µε ιδιαίτερη έµφαση στο COCOMO.

[Ham96] Brian Hambling, «Managing Software Quality», McGraw–Hill, (1996).

Αν και το βιβλίο είναι κυρίως για το πρότυπο ISO 9001, θα το πρότεινα και για τη

µελέτη της ανάλυσης κινδύνου (κεφάλαιο 3) γιατί είναι αρκετά απλά γραµµένο και

δεν απαιτεί εξειδικευµένες γνώσεις για να γίνει κατανοητό.

[Hig95] R. P. Higuera, «Team Risk Management», CrossTalk, U.S. Dept. of Defence,

(1995).



Το βιβλίο αυτό σας το προτείναµε και στο προηγούµενο κεφάλαιο. Στο κεφάλαιο 5

θα βρείτε στοιχεία για την εκτίµηση παραγόντων όπως οι ανάγκες σε ανθρώπινο

δυναµικό, το κόστος και ο χρόνος και στο κεφάλαιο 6 για την ανάλυση κινδύνου. Θα

το πρότεινα ανεπιφύλακτα σε όποιον θέλει να επεκταθεί περισσότερο σε όσα ανα-

πτύξαµε σε αυτό το κεφάλαιο και ιδιαίτερα στη µελέτη της εκτίµησης που βασίζε-

ται σε λειτουργικά σηµεία στην οποία αφιερώνει αρκετές σελίδες.


•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 75

7 6 K E º A § A I O 2 : ∂ ∫ ∆ π ª ∏ ™ ∏ ∫ ∞ π ∞ ¡ ∞ § À ™ ∏ ∫ π ¡ ¢ À ¡ √ À

[Som89] Ian Sommerville, «Software Engineering», Third edition, Addison – Wesley,

(1989).

Και αυτό είναι ένα βιβλίο που σας το προτείναµε και στο κεφάλαιο 1. Στο κεφάλαιο

26 θα βρείτε στοιχεία για εκτίµηση και για το εµπειρικό µοντέλο COCOMO.



Το βιβλίο αυτό διατίθεται στην Κεντρική Βιβλιοθήκη του Πανεπιστηµίου Πατρών

και στη βιβλιοθήκη του Τµήµατος Μηχανικών Ηλεκτρονικών Υπολογιστών και Πλη-

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

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

όπως οι ανάγκες σε ανθρώπινο δυναµικό, το κόστος και ο χρόνος.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 76

∂ÈÛ·ÁˆÁ‹ ÛÙËÓ ¶ÔÈfiÙËÙ·

™ÎÔfi˜

Σκοπός του κεφαλαίου 3 είναι η εισαγωγή στις βασικές έννοιες και τους ορισµούς

της ποιότητας γενικά, η σύντοµη περιγραφή των βασικών αρχών της ποιότητας στη

βιοµηχανική παραγωγή και η εισαγωγή στο στατιστικό έλεγχο της ποιότητας. Επί-

σης, η επεξήγηση των ιδιαιτεροτήτων στην ποιότητα λογισµικού σε σχέση µε την

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

–πιο εξειδικευµένο– κεφάλαιο που είναι αφιερωµένο αποκλειστικά στην ποιότητα

λογισµικού.



• περιγράψετε τους βασικούς ορισµούς της ποιότητας και της µέτρησης και να εξη-

γήσετε την κοινή συνισταµένη όλων των διαφορετικών ορισµών,

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

• περιγράψετε τους τοµείς ενός οργανισµού που ασχολούνται µε την ποιότητα και

να αναφέρετε τις αρµοδιότητες και ευθύνες κάθε τοµέα,

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

υλικών αγαθών,

• ορίσετε τη διαχείριση ολικής ποιότητας και τις απόψεις των πρωτοπόρων της ποι-

ότητας για την ποιότητα,

• εξηγήσετε τι είναι ο στατιστικός έλεγχος ποιότητας,

• περιγράψετε τα διαγράµµατα ελέγχου και να τα σχεδιάσετε για γνωστές δειγµατο-

ληπτικές µετρήσεις,

• αναφέρετε τις διαφορές της ποιότητας λογισµικού µε την ποιότητα στην παραγω-

γή υλικών αγαθών,

• περιγράψετε ποιες από τις τεχνικές που εφαρµόζονται στην παραγωγή υλικών αγα-

θών µπορούν να εφαρµοστούν στην ανάπτυξη λογισµικού και ποιες όχι και να εξη-

γήσετε τους λόγους για τους οποίους συµβαίνει αυτό.

3∫ ∂ º ∞ § ∞ π √

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 77

7 8 K E º A § A I O 3 : ∂ π ™ ∞ ° ø ° ∏ ™ ∆ ∏ ¡ ¶ √ π √ ∆ ∏ ∆∞

• Ποιότητα (Quality)

• Ποιότητα λογισµικού (Software

quality)

• Μέτρηση (Measurement)

• ∆ιασφάλιση ποιότητας (Quality

assurance)

• Ποιοτικός έλεγχος (Quality control)

• Επισκόπηση (Inspection)

• Εσωτερικός περιοδικός έλεγχος

(Audit)

• Επίβλεψη (Surveillance)

• Εγχειρίδιο ποιότητας (Quality

manual)

• Λειτουργικό εγχειρίδιο (Operating

manual)

• ∆ιαδικασίες ποιότητας (Quality

procedures)

• Πρόγραµµα ποιότητας (Quality

program)

• Σύστηµα ποιότητας (Quality system)

• ∆ιαχείριση ποιότητας (Quality

management)

• Τεχνολογία ποιότητας (Quality

engineering)

• Επισκόπηση ποιότητας (Quality

inspection)

• ∆ιαχείριση Ολικής ποιότητας (Total

quality management)

• Στατιστικός έλεγχος ποιότητας

(Statistical quality control)

• ∆ειγµατοληψία (Sampling)

• Έλεγχος απόκλισης (Deviation

control)

• ∆ιαγράµµατα ελέγχου (Control

charts)



Στο κεφάλαιο αυτό θα µιλήσουµε για την ποιότητα (quality) γενικά. Η ποιότητα

λογισµικού (software quality), που είναι και το αντικείµενο της µελέτης σας, δανεί-

ζεται στοιχεία από την ποιότητα στην παραγωγή υλικών αγαθών, αλλά έχει και ιδι-

αιτερότητες και διαφορές από αυτή, τις οποίες θα παρουσιάσουµε σε αυτό το κεφά-

λαιο. Ειδικότερα, στην ενότητα 3.1 µε τίτλο ορισµοί και ιστορική αναδροµή, παρου-

σιάζουµε βασικούς ορισµούς της ποιότητας και µία σύντοµη –και ελπίζουµε συνάµα

ευχάριστη– ιστορική αναδροµή στην ποιότητα. Στην ενότητα 3.2, µε τίτλο ποιότητα

στην παραγωγή υλικών αγαθών, παρουσιάζουµε τις βασικές αρχές της ποιότητας στη

βιοµηχανική παραγωγή, παραθέτουµε τις απόψεις των πρωτοπόρων στα θέµατα της

ποιότητας Juran, Deming και Crosby και εισάγουµε την έννοια του στατιστικού ελέγ-

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 78

χου της ποιότητας. Τέλος, στην ενότητα 3.3 µε τίτλο ιδιαιτερότητες στην ποιότητα

λογισµικού, συζητούµε γιατί το λογισµικό είναι τόσο διαφορετικό από την παραγωγή

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

µεθόδων που συζητήσαµε για την παραγωγή υλικών αγαθών.


λιασµένη βιβλιογραφία για περαιτέρω µελέτη στο τέλος του κεφαλαίου, όπου µπο-

ρείτε να βρείτε οδηγίες για το τι να διαβάσετε ώστε να εµπλουτίσετε τη µελέτη σας,

αντλώντας γνώσεις από πολλαπλές πηγές.

7 9∂ π ™ ∞ ° ø ° π ∫ ∂ ™ ¶ ∞ ƒ∞∆ ∏ ƒ ∏ ™ ∂ π ™

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 79

8 0 K E º A § A I O 3 : ∂ π ™ ∞ ° ø ° ∏ ™ ∆ ∏ ¡ ¶ √ π √ ∆ ∏ ∆∞

3.1 √ÚÈÛÌÔ› Î·È ÈÛÙÔÚÈÎ‹ ·Ó·‰ÚÔÌ‹

Στην ενότητα αυτή εισάγουµε την έννοια της ποιότητας και παραθέτουµε µερικούς

από τους πιο γνωστούς ορισµούς της ποιότητας. Επίσης, περιγράφουµε τις βασικές

έννοιες που σχετίζονται µε την ποιότητα και µε τις οποίες θα ασχοληθούµε στα επό-

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

τα από την αρχαιότητα µέχρι σήµερα.

3.1.1 ¶ÔÈfiÙËÙ· Î·È ÌÂÙÚ‹ÛÂÈ˜

Η έννοια της ποιότητας ξεκινάει από τα αρχαία χρόνια µε τον Αριστοτέλη (330 π.Χ.),

που πρώτος διακρίνει το «ποιόν» και τα χαρακτηριστικά του και συνεχίζεται αργό-

τερα µε τους σχολαστικούς φιλοσόφους. Με τη γενική σηµασία του όρου, ποιότητα

είναι κάθε ιδιότητα είτε αυτή ανήκει στην ουσία ενός πράγµατος είτε αποδίδεται επι-

πρόσθετα σε αυτή. Ο επίσηµος ορισµός της ποιότητας δίνεται στο πρότυπο ISO 8402

(για τα πρότυπα που σχετίζονται µε την ποιότητα θα µιλήσουµε στο κεφάλαιο 6).

Αυτός ο ορισµός έχει υιοθετηθεί και από τον Ελληνικό Οργανισµό Τυποποίησης

(ΕΛ.Ο.Τ.). Προσέξτε ότι ο ορισµός µιλά τόσο για εκφρασµένες όσο και για συνε-

παγόµενες ανάγκες. Θα µιλήσουµε για αυτές αναλυτικά στη συνέχεια.

Το αντικείµενο της ποιότητας λογισµικού (το οποίο είναι και το αντικείµενο της

µελέτης σας) είναι ένα αντικείµενο που βασίζεται τόσο στην από κοινού εφαρµογή

των τεχνικών διασφάλισης της ποιότητας των υλικών αγαθών (τεχνικών που ανα-

πτύχθηκαν αρκετά χρόνια πριν από την εµφάνιση της παραγωγής λογισµικού), όσο

και στην εφαρµογή τεχνικών της τεχνολογίας λογισµικού (επιστηµονικού κλάδου

που αναπτύχθηκε κατά τα πρώτα χρόνια της γενικευµένης ανάπτυξης λογισµικού).

Πέρα από τους ορισµούς, η σηµερινή αντίληψη για την ποιότητα –όχι και πολύ δια-

φορετική από την αρχική της– είναι ότι χαρακτηρίζει τη φύση, την εσωτερική υπό-

σταση των πραγµάτων. Έτσι, όταν λέµε για παράδειγµα ότι το τραπέζι δεν είναι

καλής ποιότητας, εννοούµε ότι τα χαρακτηριστικά του (χρώµα, ξύλο, σχέδιο, κ.λπ.)

δεν είναι καλά και αυτό το διαπιστώνουµε µε την εµπειρία µας (µε την όραση ή την

αφή). Τόσο από τους ορισµούς, όσο και από την αντίληψή µας για την ποιότητα προ-

κύπτουν δύο βασικές ιδιότητες της ποιότητας. Πρώτον, ότι η ποιότητα νοείται σε

σχέση µε τα χαρακτηριστικά της και συντίθεται από αυτά, οπότε για να συµπερά-

νουµε το είδος της ποιότητας ενός αντικειµένου πρέπει να εξετάσουµε τα χαρακτη-

ριστικά του εκείνα που τη συνθέτουν. ∆εύτερον, ότι η εξέταση των ποιοτικών αυτών

χαρακτηριστικών, που είναι δυνατόν να γίνει και µε την εµπειρία µας, οδηγεί στην

απόδοση κάποιου χαρακτηρισµού σε αυτά (σκληρό – µαλακό, λείο – ανώµαλο, ψηλό

– κοντό, κ.λπ.) ή και κάποιου αριθµού. Έτσι, από το χαρακτηρισµό των επιµέρους

Ποιότητα

είναι το σύνολοτων χαρακτηρι-

στικών µιαςοντότητας πουτης αποδίδουν

την ικανότητα ναικανοποιεί

εκφρασµένες καισυνεπαγόµενες

ανάγκες. ISO8402, (1985)

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 80

στοιχείων που απαρτίζουν την ποιότητα, καταλαβαίνουµε το είδος της. Η απόδοση

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

Η διασφάλιση ποιότητας είναι συνυφασµένη µε την έννοια των µετρήσεων

(measurements). Ο DeMarco τονίζει πως «είναι αδύνατο να ελέγξεις ότι δεν µπορείς

να µετρήσεις» [Dma82]. Πόσο µάλλον αδύνατο είναι να στοχεύεις να διασφαλίσεις

την ποιότητα κάποιας οντότητας που δεν µπορείς να µετρήσεις. Αντικείµενο των

µετρήσεων δεν είναι η µέτρηση των οντοτήτων, αλλά η µέτρηση των ιδιοτήτων οντο-

τήτων. Για παράδειγµα, δεν µετράµε έναν άνθρωπο αλλά ιδιότητές του που τον χαρα-

κτηρίζουν, όπως το ύψος του ή το βάρος του. Με τις µετρήσεις (και ειδικότερα µε

τις µετρήσεις στο λογισµικό) θα ασχοληθούµε στο επόµενο κεφάλαιο.

8 13 . 1 √ ƒ π ™ ª √ π ∫ ∞ π π ™ ∆ √ ƒ π ∫ ∏ ∞ ¡ ∞ ¢ ƒ √ ª ∏

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


Αν ανατρέξετε στην προτεινόµενη βιβλιογραφία, ή σε πηγές στο διαδίκτυο θα βρεί-

τε πολλούς ορισµούς της ποιότητας. Βρείτε τουλάχιστον τέσσερις τέτοιους ορι-

σµούς και καταγράψτε τους. Έπειτα αφού τους µελετήσετε συγκρίνετέ τους και

δείτε πού συµβαδίζουν (ποια είναι τα κοινά τους στοιχεία). Μετά δείτε και την

ενδεικτική απάντηση που ακολουθεί.

Απάντηση

Οι πιο γνωστοί από τους ορισµούς ποιότητας παρουσιάζονται εδώ µε χρονολογική

σειρά. Ένας από τους πρώτους ορισµούς της ποιότητας υπάρχει στο παλαιό πρότυ-

πο Α3 του τότε ASQC (American Society for Quality Control) [Ame78] και τώρα

ASQ[1] (American Society for Quality) και ορίζει: «Ποιότητα είναι η συλλογή των

χαρακτηριστικών και των ιδιοτήτων του προϊόντος που σχετίζονται µε τη δυνατό-

τητά του να εκπληρώνει τις ζητούµενες ανάγκες των πελατών».

Ένας από τους πρωτοπόρους στα θέµατα της ποιότητας ο Phillip Crosby [Cro79]

ορίζει την ποιότητα πολύ πιο απλά: «Ποιότητα είναι η συµµόρφωση µε τις απαιτή-

σεις των χρηστών».

Παρόµοιος είναι και ο ορισµός του Joseph Juran [Jur80] που είναι ένας επίσης από

τους πρωτοπόρους της ποιότητας: «Ποιότητα είναι καταλληλότητα προς χρήση».

[1] Έγινε (American Society for Quality) αφού κόπηκε το «Control» από τον τίτλο, ακολουθώ-ντας τη γενικότερη πρακτική που θέλει την έννοια της ποιότητας να εµπεριέχει τόσο τον έλεγ-χο, όσο και τη διασφάλιση.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 81

8 2 K E º A § A I O 3 : ∂ π ™ ∞ ° ø ° ∏ ™ ∆ ∏ ¡ ¶ √ π √ ∆ ∏ ∆∞

Υπάρχουν αντίστοιχοι ορισµοί από άλλους πολυγραφότατους συγγραφείς, όπως του

Feigenbaum [Fei83] που λέει ότι: «Ποιότητα είναι η συλλογή των χαρακτηριστι-

κών σχεδιασµού, κατασκευής και συντήρησης, δια µέσω των οποίων το προϊόν κατά

τη χρήση του θα εκπληρώσει τις προσδοκίες των πελατών», ή του Aubrey [Aub85]:

«Ποιότητα είναι η συµµόρφωση µε τυποποιηµένες προδιαγραφές που περιγράφουν

τα βασικά χαρακτηριστικά του προϊόντος και έχουν βασιστεί στις ανάγκες και προσ-

δοκίες των πελατών».

Αν και οι ορισµοί της ποιότητας είναι πολλοί, το κοινό στοιχείο τους είναι πως θεω-

ρούν ότι η ποιότητα του προϊόντος είναι άµεσα συνυφασµένη µε τις ανάγκες των

πελατών (χρηστών για το λογισµικό) και την ικανοποίηση αυτών των αναγκών.

3.1.2 µ·ÛÈÎ¤˜ ¤ÓÓÔÈÂ˜

Παλαιότερα –στη βιβλιογραφία για την ποιότητα– όταν ήθελαν να µιλήσουν για

αυτή, υπήρχε η γενικότερη τάση χρήσης των επιµέρους στόχων της ποιότητας, παρό-

λο που αυτοί εµπεριέχονται στην έννοια «ποιότητα». Έτσι, µιλούσαµε για διασφά-

λιση ποιότητας (quality assurance) και για ποιοτικό έλεγχο (quality control). Τώρα

µιλάµε µόνο για ποιότητα και αυτό σηµαίνει αυτόµατα πως οι παραπάνω έννοιες

εµπεριέχονται, ότι δηλαδή σε ένα πρόγραµµα ποιότητας έχουµε ως στόχο να δια-

σφαλίσουµε και να ελέγξουµε την ποιότητα του προϊόντος που

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

πώς θεωρείται ότι θα έπρεπε να είναι, και η διασφάλιση ποιότητας εξασφαλίζει ότι

η ποιότητα είναι πράγµατι έτσι όπως το ζητούµενο.

Στην προσπάθειά µας να διασφαλίσουµε την ποιότητα σε κάποιο προϊόν, χρησιµο-

ποιούµε επισκοπήσεις (inspections), εσωτερικούς περιοδικούς έλεγχους (audits)

και επίβλεψη (surveillance). Η επισκόπηση, αν χρησιµοποιηθεί κατάλληλα, µπορεί

να παρέχει ένα µεγάλο σύνολο από πληροφορίες που αφορούν στην απόδοση µιας

διαδικασίας. Αυτή η µορφή ελέγχου ποιότητας πρέπει να χρησιµοποιείται ως εργα-

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

σφαλίσει ένα ποιοτικό προϊόν. Ο εσωτερικός περιοδικός έλεγχος πρέπει να είναι καλά

ορισµένος και πρέπει να δίνει απαντήσεις σε βασικά ερωτήµατα όπως, για παρά-

δειγµα, αν ο οργανισµός διαθέτει εγχειρίδιο ποιότητας (quality manual), λειτουρ-

γικό εγχειρίδιο (operating manual), ή διαδικασίες ποιότητας (quality procedures),

καθώς και αν υπάρχει και ακολουθείται κάποιο πρόγραµµα ποιότητας (quality

program) και αν αυτό είναι αποτελεσµατικό, δηλαδή, αν είναι τα αποτελέσµατά του

σταθερά και θετικά. Τέλος, η επίβλεψη χρησιµοποιείται για να απαντά σε ερωτήµα-

τα όπως αν ακολουθείται η διαδικασία εκτέλεσης όπως σχεδιάστηκε και αν το προϊ-

∆ιασφάλιση ποι-

ότητας είναι η δια-δικασία που εµπε-

ριέχει τη διαχείρισητης ποιότητας, δηλα-

δή την πράξη πουεξασφαλίζει ή υπο-

δεικνύει ότι έναπρόγραµµα παραγω-

γής είναι συµβατόκαι λειτουργικά

αποδοτικό.

Έλεγχος

ποιότητας είναιένας κανόνας δρά-σης κατά τον οποίο

χρησιµοποιούµεστρατηγικές, όπως

οι επισκοπήσεις καιο στατιστικός έλεγ-

χος απόδοσης για ναδιασφαλίσουµε ότιτο προϊόν που θα

παραχθεί θα είναιποιοτικά αποδεκτό.

Επισκόπηση

είναι η υψηλή οριο-θέτηση και η λεπτο-µερής εξέταση ενός

προϊόντος, ή µιαςδιαδικασίας.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 82

όν διαθέτει µια αποδεκτή ποιότητα.

Σε µία µεγάλη επιχείρηση ή βιοµηχανία που έχει εγκαθιδρύσει ένα πρόγραµµα ποι-

ότητας (quality program) –πολλές φορές θα το δείτε και µε τον ισοδύναµο όρο

σύστηµα ποιότητας (quality system)– οι τοµείς που ασχολούνται µε την ποιότητα

του τελικού προϊόντος είναι αρκετοί και τα άτοµα που έχουν ως στόχο τη διασφάλι-

ση ενός υψηλού ποιοτικού επιπέδου πρέπει να διαθέτουν την κατάλληλη εκπαίδευ-

ση, γνώσεις και υπευθυνότητα. Τυπικά, οι ευθύνες για τη διασφάλιση ποιότητας

στους τοµείς ενός οργανισµού είναι χωρισµένες σε τρεις βασικές κατηγορίες:

α) Τη διαχείριση ποιότητας (quality management), που έχει σχέση µε την άσκηση

της ανώτατης διαχείρισης και την ανατροφοδότηση της παραγωγής µε ακρίβεια

και εγκυρότητα.

β) Την τεχνολογία ποιότητας (quality engineering), που έχει σχέση µε την ανάλυ-

ση των προβληµάτων που σχετίζονται µε την ποιότητα, την επίλυσή τους, την

εκπαίδευση του προσωπικού και την εγκαθίδρυση προγραµµάτων που βελτιώ-

νουν την ποιότητα.

γ) Την επισκόπηση ποιότητας (quality inspection), που έχει ως βασικούς ρόλους

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

για να αναγνωρίσει τη ρίζα των προβληµάτων στην ποιότητα των προϊόντων και

να καταλήξει σε ένα διορθωτικό µοντέλο.

8 33 . 1 √ ƒ π ™ ª √ π ∫ ∞ π π ™ ∆ √ ƒ π ∫ ∏ ∞ ¡ ∞ ¢ ƒ √ ª ∏

Εσωτερικός

περιοδικός έλεγχος

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

Επίβλεψη είναιµια χαλαρή διαδι-κασία επισκόπησηςπου χρησιµοποιείµερικές τεχνικέςαπό τον περιοδικόέλεγχο και µερικές από τηνεπισκόπηση.

Το Πρόγραµµα

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



∆είτε στο τέλος του βιβλίου τις σωστές απαντήσεις και την αιτιολόγηση για κάθε

απάντηση.


i) Οι επισκοπήσεις και ο στατιστικός έλεγχος απόδοσης είναι

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

ii) Η επισκόπηση είναι η βασική µέθοδος που θα

µας εξασφαλίσει ένα ποιοτικό προϊόν.

iii)Ο απώτερος (τελικός) στόχος του εσωτερικού περιοδικού

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

iv) Οι όροι πρόγραµµα ποιότητας και σύστηµα ποιότητας συχνά

χρησιµοποιούνται µε την ίδια σηµασία.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 83

8 4 K E º A § A I O 3 : ∂ π ™ ∞ ° ø ° ∏ ™ ∆ ∏ ¡ ¶ √ π √ ∆ ∏ ∆∞

3.1.3 πÛÙÔÚÈÎ‹ ·Ó·‰ÚÔÌ‹ ÛÙËÓ ÔÈfiÙËÙ· Î·È ÛÙÈ˜ ÌÂÙÚ‹ÛÂÈ˜

Σε όλες τις οργανωµένες κοινωνίες κάθε εποχής, από την αρχαιότητα µέχρι σήµερα,

όπου υπάρχει υψηλή πολιτισµική στάθµη, αυτή συνοδεύεται πάντα από µία ανα-

πτυγµένη τεχνολογία. Και –το πιο σηµαντικό– η τελευταία λειτουργεί στη βάση ενός

µηχανισµού ελέγχου της ποιότητας και προστασίας του καταναλωτή. Χαρακτηρι-

στικά παραδείγµατα µπορεί κανείς να συναντήσει στην αρχαία Βαβυλώνα, όπου ανά-

µεσα στους νόµους του Hammourabi υπάρχει και ο αρχαιότερος κανονισµός σχετι-

κά µε την οικοδοµή. Σύµφωνα µε αυτόν, αν ένας οικοδόµος κτίσει µία κατοικία για

κάποιον, αλλά δεν πραγµατοποιήσει την εργασία του σύµφωνα µε τους ισχύοντες

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

τότε ο οικοδόµος αυτός οφείλει να τον ενισχύσει µε δικά του έξοδα [Bar96].

Η αντιµετώπιση του προβλήµατος της ποιότητας, ο καθορισµός προτύπων και η

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

τη σηµερινή εποχή. Στην αρχαία Αίγυπτο είχαν τεθεί οι βασικές αρχές της ποιότη-

τας και υπήρχε τυποποίηση των µετρήσεων βασισµένη στο µήκος του βραχίονα του

Φαραώ. Με βάση αυτό το µήκος κατασκευαζόταν ένα «µοναδιαίο ραβδί». Κάθε

κατασκευαστής έπρεπε να έχει ένα αντίστοιχο ραβδί που έπρεπε να το συγκρίνει µε

το µοναδιαίο κάθε γεµάτο φεγγάρι. Η τήρηση των κανόνων ποιότητας (συµµόρφω-

ση µε το µοναδιαίο ραβδί) ήταν αρκετά σηµαντικό θέµα, αφού σε περίπτωση δια-

φοράς µήκους ο κατασκευαστής αντιµετώπιζε τη θανατική ποινή [Arn95].

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

πιστοποίησης των παραγόµενων και προσφερόµενων προϊόντων στον τόπο παρα-

γωγής αλλά και στην αγορά. Οι αρχαίοι Έλληνες εφάρµοζαν πρότυπα µε πολύ

αυστηρές προδιαγραφές που κάλυπταν όλο το φάσµα των τότε παραγόµενων προϊ-

όντων, όπως τα µέταλλα και τα κράµατά τους, τα γεωργικά προϊόντα, τα τρόφιµα

και τα ποτά, αλλά και τις ίδιες τις κατασκευές, χαρακτηριστικό παράδειγµα των οποί-

ων αποτελεί ο Παρθενώνας, του οποίου ακόµα και σήµερα, µετά από διάστηµα περί-

που 2500 χρόνων από την κατασκευή του (κτίστηκε το διάστηµα 447 – 438 π.Χ. και

διακοσµήθηκε µεταξύ 438 και 432 π.Χ.), όλοι θαυµάζουµε τη συµµετρία και τη

µετρική τελειότητα, αποτέλεσµα της προσήλωσης και της συνέπειας στην τήρηση

v) Η τεχνολογία ποιότητας έχει ως βασικό ρόλο τη συλλογή

δεδοµένων για να αναγνωρίσει τη ρίζα των προβληµάτων

στην ποιότητα των προϊόντων και να καταλήξει σε ένα

διορθωτικό µοντέλο.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 84

των προδιαγραφών ποιότητας που βασίστηκαν σε µετρήσεις από τους αρχιτέκτονες

Ικτίνο και Καλλικράτη. Ακόµα, στην Αθηναϊκή Πολιτεία ορίζονταν µε κλήρο δέκα

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

λαν να µεριµνούν ώστε οι πωλητές να τα χρησιµοποιούν σωστά.

Αλλά και στην αρχαία Ρώµη, η ποιότητα ήταν θέµα ζωής και θανάτου. Μόλις ολο-

κληρωνόταν η κατασκευή µιας γέφυρας και έπρεπε να αφαιρεθούν τα υποστηρίγ-

µατα, ο αρχιµηχανικός στεκόταν κάτω από τη γέφυρα έτσι ώστε σε περίπτωση που

αυτή καταρρεύσει να σκοτωθεί. ∆εν είναι παράξενο λοιπόν ότι αρκετές ρωµαϊκές

γέφυρες όχι µόνο διατηρούνται αλλά χρησιµοποιούνται ακόµα και σήµερα.

8 53 . 2 ¶ √ π √ ∆ ∏ ∆∞ ™ ∆ ∏ ¡ ¶ ∞ ƒ∞ ° ø ° ∏ À § π ∫ ø ¡ ∞ °∞ £ ø ¡


Από τις πηγές που σας προτείνουµε (βλέπε βιβλιογραφία στο τέλος του κεφαλαί-

ου), αλλά και από δικές σας πηγές, ή και από αναζητήσεις σας στο διαδίκτυο συλ-

λέξτε επιπλέον πληροφορίες για το πώς αντιµετωπιζόταν η ποιότητα σε διάφορες

περιόδους της ιστορίας. Με βάση αυτό το υλικό ετοιµάστε µία αναφορά (από 500

έως 2000 λέξεις) που να παρουσιάζει τα ευρήµατά σας. Την αναφορά αυτή µπο-

ρείτε να τη συζητήσετε µε τον Καθηγητή – Σύµβουλό σας.

3.2 ¶ÔÈfiÙËÙ· ÛÙËÓ ¶·Ú·ÁˆÁ‹ ÀÏÈÎÒÓ ∞Á·ıÒÓ

Η διασφάλιση ποιότητας και η χρήση µετρήσεων έδωσε µεγάλη ώθηση στη βιοµη-

χανία τις τελευταίες δεκαετίες. Για τη µαζική παραγωγή ενός υλικού αγαθού τίθενται

λεπτοµερείς και µετρήσιµοι ποιοτικοί στόχοι και τα προϊόντα ελέγχονται ως προς την

εκπλήρωση αυτών των στόχων. Σήµερα, είναι αδιανόητη η µαζική παραγωγή ενός

υλικού αγαθού χωρίς η διαδικασία παραγωγής να υποστηρίζεται από πρόγραµµα ποι-

ότητας και χωρίς να υπάρχει µέθοδος µέτρησης των ιδιοτήτων του, οι οποίες επιθυ-

µούµε να βρίσκονται µέσα στα όρια που καθορίζονται από το πρόγραµµα ποιότητας.

Για παράδειγµα, για τη µαζική παραγωγή µιας βίδας καθορίζονται λεπτοµερώς ιδιό-

τητες της βίδας όπως διαστάσεις, αντοχή σε πίεση, κτλ. καθώς και οι µέγιστες επι-

τρεπόµενες αποκλίσεις από αυτά τα όρια για να είναι το προϊόν αποδεκτό.

Οι βασικές λειτουργίες του προγράµµατος ποιότητας στη µαζική παραγωγή υλικών

αγαθών είναι:

• ο καθορισµός των χαρακτηριστικών που θα µετρηθούν και των επιθυµητών

ορίων,

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 85

8 6 K E º A § A I O 3 : ∂ π ™ ∞ ° ø ° ∏ ™ ∆ ∏ ¡ ¶ √ π √ ∆ ∏ ∆∞

• ο καθορισµός των διαδικασιών µέτρησης,

• ο εντοπισµός και η απόρριψη των προϊόντων που δεν πληρούν τις ποιοτικές προ-

διαγραφές και

• η βελτίωση της διαδικασίας παραγωγής, ώστε να ελαχιστοποιηθεί ο αριθµός των

προϊόντων που απορρίπτονται.

Στη βιοµηχανική παραγωγή υλικών αγαθών χρησιµοποιούνται τεχνικές δειγµατο-

ληψίας και στατιστικές µέθοδοι –όπως για παράδειγµα τα διαγράµµατα ελέγχου

(control charts)– ώστε να εντοπίζονται γρήγορα τα προβλήµατα στη διαδικασία

παραγωγής που µπορούν να οδηγήσουν σε παραγωγή ποσοτήτων (παρτίδων) προϊ-

όντων χαµηλής ποιότητας, µε βασικό στόχο τον έλεγχο της απόκλισης από τις αρχι-

κές ποιοτικές προδιαγραφές. Η διαδικασία παραγωγής βασίζεται: α) στη δηµιουρ-

γία ενός µοντέλου το οποίο πληροί τις ποιοτικές προδιαγραφές και β) στη µαζική

παραγωγή προϊόντων που είναι παρόµοια (µέσα στα όρια που καθορίζουν οι ποιοτι-

κές προδιαγραφές) µε το πρωτότυπο.

Οι τεχνικές ποιοτικού ελέγχου που χρησιµοποιούνται στην παραγωγή υλικών αγα-

θών δίνουν µεγάλη έµφαση στο λεγόµενο «µη καταστροφικό έλεγχο», δηλαδή στο να

βρεθούν τρόποι να ελεγχθεί η ποιότητα του προϊόντος χωρίς να χρειαστεί να προ-

βούµε σε καταστροφή του δείγµατος που εξετάζουµε.

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

ποιότητας, τις απόψεις µερικών από τους πρώτους επιστήµονες που µελέτησαν και

έγραψαν για την ποιότητα και για το στατιστικό έλεγχο ποιότητας, θέλοντας να σας

δώσουµε το στίγµα για το πώς αντιµετωπίζεται η ποιότητα στη βιοµηχανική παραγω-

γή αγαθών. Σκοπός µας είναι µέσα από αυτή την παρουσίαση να αναδειχθούν και οι

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

3.2.1 ¢È·¯Â›ÚÈÛË ÔÏÈÎ‹˜ ÔÈfiÙËÙ·˜

Η διαχείριση ολικής ποιότητας (total quality management) έχει γνωρίσει ευρεία

αποδοχή στην παραγωγή υλικών αγαθών. Ο ορισµός του ISO 8402 που αναγράφε-

ται δίπλα θεωρεί ως «οργανισµό» κάθε εταιρία, νοµικό πρόσωπο, επιχείρηση ή ίδρυ-

µα που έχει τη δική του λειτουργική ή διοικητική δοµή. Η διαχείριση ολικής ποιό-

τητας, ως τρόπος διοίκησης, µπορεί να απεικονιστεί µε το βρόγχο του σχήµατος 3.1.

∆ιαχείριση

ολικής ποιότητας

είναι τρόπος διοί-κησης ενός οργανι-

σµού που εστιάζειστην ποιότητα, οοποίος βασίζεται

στη συµµετοχήόλων των µελώντου και στοχεύει

στη µακροπρόθε-σµη επιτυχία µέσωτης ικανοποίησης

του πελάτη και στηνπαροχή οφελών σε

όλα τα µέλη τουοργανισµού καιστην κοινωνία.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 86

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

αρχή σαφέστατα προσδιορισµένα, οι διαδικασίες να ακολουθούνται προκειµένου να

διασφαλίζεται η ικανοποίηση των προδιαγραφών, ενώ τα αποτελέσµατα να παρα-

κολουθούνται µε στόχο να ελέγχεται η συµµόρφωση µε τις προδιαγραφές. Πρόκει-

ται, λοιπόν, για ένα δυναµικό σύστηµα το οποίο πρέπει να έχει ταχύτατη αντίδραση

σε αλλαγές, νέες ιδέες και σε προβλήµατα που προκύπτουν, πάντα µε ελεγχόµενο

τρόπο και στα πλαίσια µιας ξεκάθαρης µεθοδολογίας. ∆εν θα επεκταθούµε άλλο στη

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

Ανοικτού Πανεπιστηµίου αφιερωµένο σε αυτή.

8 73 . 2 ¶ √ π √ ∆ ∏ ∆∞ ™ ∆ ∏ ¡ ¶ ∞ ƒ∞ ° ø ° ∏ À § π ∫ ø ¡ ∞ °∞ £ ø ¡

™¯‹Ì· 3.1

Βρόγχος

ποιότητας

Σχεδίασε

Έλεγξε

∆ράσε Πράξε


Από το βιβλίο του Ελληνικού Ανοικτού Πανεπιστηµίου «∆ιασφάλιση Ποιότητας:

Ολική Ποιότητα» (βλέπε βιβλιογραφία του κεφαλαίου) αλλά και από όποιες άλλες

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

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

χωρίς να ξεπεράσετε τις 1500 λέξεις.

3.2.2 √È ÚÒÙÂ˜ ·fi„ÂÈ˜ ÁÈ· ÙËÓ ÔÈfiÙËÙ·

Από τα τέλη της δεκαετίας του 1970 οι απόψεις ορισµένων από τους πρώτους επι-

στήµονες που µελέτησαν και έγραψαν για την ποιότητα, όπως ο Juran, ο Deming και

ο Crosby, ήταν αυτές που πυροδότησαν την επανάσταση στην παραγωγή υλικών

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

δες επιχειρήσεις.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 87

8 8 K E º A § A I O 3 : ∂ π ™ ∞ ° ø ° ∏ ™ ∆ ∏ ¡ ¶ √ π √ ∆ ∏ ∆∞

Ο Joseph Juran βάσιζε τη φιλοσοφία ποιότητας στον πελάτη και στο τρίπτυχο: Σχε-

διασµός για την ποιότητα, Βελτίωση της ποιότητας και Έλεγχος ποιότητας. Το τρί-

πτυχο αυτό είναι γνωστό και ως η τριλογία της ποιότητας. Ο Juran δίδαξε κυρίως

στην Ιαπωνία και από εκεί οι αρχές του διαδόθηκαν παγκοσµίως.

Ο Edward Deming δίδαξε κι αυτός στην Ιαπωνία και έχει γίνει διάσηµος για τα 14

σηµεία (14 οδηγίες για επιτυχία στην ποιότητα), τον κύκλο του Deming (που διδά-

σκει τον τρόπο λειτουργίας µιας επιχείρησης) και τις θανατηφόρες ασθένειες (που

περιγράφουν τι δεν πρέπει να κάνει µία επιχείρηση αν θέλει να πετύχει το πρόγραµµα

ποιότητάς της).

O Phillip Crosby, που δίδαξε στην Αµερική, βασίζει τη φιλοσοφία του στο ρητό

«κανένα ελάττωµα» (zero defects), τονίζοντας ότι η επιχείρηση θα πρέπει να ετοι-

µάζει το προϊόν σωστά από την πρώτη φορά.


Είτε από τις πρωτότυπες πηγές (τα βιβλία και των τριών πρωτοπόρων υπάρχουν

στη βιβλιογραφία), είτε από το βιβλίο του Ελληνικού Ανοικτού Πανεπιστηµίου

«∆ιασφάλιση Ποιότητας: Ολική Ποιότητα» (βλέπε βιβλιογραφία του κεφαλαίου),

ετοιµάστε µία αναφορά που θα συνοψίζει τις απόψεις κάθε ενός από τους τρεις

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

φορά αυτή µπορείτε να τη συζητήσετε µε τον Καθηγητή – Σύµβουλό σας.

3.2.3 ™Ù·ÙÈÛÙÈÎfi˜ ¤ÏÂÁ¯Ô˜ ÔÈfiÙËÙ·˜

Ανεξάρτητα από τη φιλοσοφία διαχείρισης ποιότητας, ο στατιστικός έλεγχος ποι-

ότητας (statistical quality control) των παραγόµενων προϊόντων είναι η βασική µέθο-

δος για τον έλεγχο της ποιότητας στην παραγωγή υλικών αγαθών. Οι βασικές αρχές

του στατιστικού ελέγχου ποιότητας είναι η δειγµατοληψία (sampling) και ο έλεγ-

χος της απόκλισης (deviation control). Ο έλεγχος δεν γίνεται σε ολόκληρη την παρ-

τίδα των προϊόντων, αλλά σε ένα µικρό δείγµα. Ο έλεγχος µπορεί να είναι κατα-

στροφικός (δηλαδή το δείγµα καταστρέφεται ως συνέπεια του ελέγχου) ή µη κατα-

στροφικός (το δείγµα µένει ανέπαφο και µπορεί να προωθηθεί στον πελάτη. Στην

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

περισσότερων µεθόδων µη – καταστροφικού ελέγχου. Κατά τη διάρκεια του ελέγ-

χου αυτού εξετάζεται αν το δείγµα των προϊόντων αποκλίνει ή όχι από τις αρχικές

προδιαγραφές (λαµβάνοντας υπόψη κάποια όρια ανοχής).

∆ειγµατοληψία

είναι η περιοδικήεπιλογή ενός

µικρού αριθµούπροϊόντων από µία

παρτίδα προϊό-ντων, µε σκοπό να

ελεγχθεί αν πλη-ρούν τις αρχικές

προδιαγραφές.

Έλεγχος

απόκλισης

ονοµάζεται η διαδι-κασία µε την οποίαελέγχουµε εάν έναπροϊόν ικανοποιεί

τις αρχικές προδιαγραφές,

λαµβάνοντας υπόψηκάποια αποδεκτάόρια απόκλισης.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 88

Τα αποτελέσµατα του στατιστικού ελέγχου αναλύονται µε τη χρήση πληθώρας τεχνι-

κών [Mon91] µε πιο διαδεδοµένη τα διαγράµµατα ελέγχου (control charts). Ένα

παράδειγµα διαγράµµατος ελέγχου παρουσιάζεται στο σχήµα 3.2. Στον οριζόντιο

άξονα παρουσιάζονται περιοδικές δειγµατοληψίες και στον κατακόρυφο άξονα η

µέση τιµή του µετρούµενου χαρακτηριστικού του δείγµατος. Οι δύο οριζόντιες γραµ-

µές πάνω και κάτω απεικονίζουν το ανώτερο και το κατώτερο αποδεκτό όριο, ενώ

αυτή στη µέση την επιθυµητή µέση τιµή. Οι κουκίδες είναι η µέση τιµή του δείγµα-

τος και οι διαδοχικές χρονικά δειγµατοληψίες έχουν συνδεθεί µε µία γραµµή µετα-

ξύ τους για να είναι καλύτερα παρουσιάσιµα τα αποτελέσµατα. Ο υπεύθυνος παρα-

γωγής, εξετάζοντας τα αποτελέσµατα του διαγράµµατος ελέγχου, εντοπίζει αν η δια-

δικασία εξελίσσεται κανονικά ή παρουσιάζει πρόβληµα (όπως λέµε είναι «εκτός

ελέγχου») και αποφασίζει αν θα διακόψει την παραγωγή (για επιδιόρθωση των µηχα-

νηµάτων ή της µεθόδου παραγωγής) ή όχι.

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

στην ποιότητα λογισµικού (µε διαφορετικό όµως τρόπο προσέγγισης), όπως θα συζη-

τήσουµε στο επόµενο κεφάλαιο.

8 93 . 2 ¶ √ π √ ∆ ∏ ∆∞ ™ ∆ ∏ ¡ ¶ ∞ ƒ∞ ° ø ° ∏ À § π ∫ ø ¡ ∞ °∞ £ ø ¡


Η Μαρία είναι υπεύθυνη ποιότητας σε µία βιοµηχανία που παράγει µεταλλικά

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

τοληψία επιλέγοντας 10 φύλλα από κάθε παρτίδα 1.000 φύλλων κάθε 1 ώρα παρα-

™¯‹Ì· 3.2

∆ιάγραµµα

ελέγχου

Άνω όριο

Kάτω όριο

Mέση τιµή

∆είγµατα ανά χρονική περίοδο

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 89

9 0 K E º A § A I O 3 : ∂ π ™ ∞ ° ø ° ∏ ™ ∆ ∏ ¡ ¶ √ π √ ∆ ∏ ∆∞

Απάντηση

Το γράφηµα ελέγχου παρουσιάζεται στο σχήµα 3.3. Η διαδικασία θα µπορούσε να

θεωρηθεί εντός ελέγχου (αφού όλα τα σηµεία είναι µέσα στα όρια), αλλά οι 9 συνε-

χόµενες τιµές πάνω από τη µέση τιµή στην πραγµατικότητα την θέτουν εκτός ελέγ-

χου και η Μαρία θα σταµατήσει την παραγωγή για να εντοπίσει τι φταίει. ∆εν θα

επεκταθούµε στο πότε µία διαδικασία είναι εντός ή εκτός ελέγχου (το αφήνουµε ως

συµπληρωµατική µελέτη) αλλά αυτό το παράδειγµα δείχνει ότι η ικανοποίηση των

ορίων δεν είναι η µόνη προϋπόθεση διαδικασίας που εξελίσσεται οµαλά.

γωγής. Ελέγχει το πάχος κάθε φύλλου µε επιθυµητή τιµή τα 2 εκατοστά και απο-

δεκτή απόκλιση 0,1 εκατοστό. Οι τιµές που έχει πάρει µετά από 13 συνεχόµενες

δειγµατοληψίες είναι οι παρακάτω: 2,02 – 2,01 – 1,93 – 1,92 – 2,05 – 2,02 – 2,04

– 2,01 – 2,07 – 2,06 – 2,09 – 2,08 – 2,09.

Να σχεδιάσετε το γράφηµα ελέγχου για τη διαδικασία και να µας πείτε την άποψή

σας αν η διαδικασία είναι εντός ή εκτός ελέγχου.

™¯‹Ì· 3.3

∆ιάγραµµα ελέγχου

δραστηριότητας 3.1

Άνω όριο

Kάτω όριο

Mέση τιµή

∆είγµατα ανά χρονική περίοδο

2,10

2,00

1,90

3.3 π‰È·ÈÙÂÚfiÙËÙÂ˜ ÛÙËÓ ÔÈfiÙËÙ· ÏÔÁÈÛÌÈÎÔ‡

Παρόλο που οι βασικές αρχές της ποιότητας λογισµικού είναι ίδιες µε εκείνες της

ποιότητας κάθε άλλου προϊόντος, υπάρχουν βασικές διαφορές στον τρόπο προσέγ-

γισης της ποιότητας στο λογισµικό από την ποιότητα όπως εφαρµόζεται στη µαζική

παραγωγή υλικών προϊόντων. Σε αντίθεση µε τη µαζική παραγωγή όπου παράγονται

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 90

ποσότητες ίδιων (φαινοµενικά) προϊόντων, το λογισµικό παράγεται µία φορά. Έτσι,

µε εξαίρεση τις διαδικασίες συσκευασίας και συνοδευτικού υλικού (εγχειρίδια, οδη-

γίες εγκατάστασης, µέσο αποθήκευσης, κτλ), αυτό καθεαυτό το λογισµικό παράγε-

ται µόνο µία φορά και αναπαράγεται σε αντίτυπα που είναι ακριβή αντίγραφα του

πρωτοτύπου.

Αυτό σηµαίνει ότι, αν και οι στόχοι του προγράµµατος ποιότητας είναι ίδιοι (δηλα-

δή η διασφάλιση της ποιότητας του τελικού προϊόντος), η εφαρµογή τους διαφέρει.

∆εν είναι το ζητούµενο ο εντοπισµός και η απόρριψη των προϊόντων που αποκλί-

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

πρωτότυπου του προϊόντος. Με πρώτη µατιά, κάτι τέτοιο µοιάζει πιο εύκολο από το

αντίστοιχο πρόβληµα της µαζικής παραγωγής, αφού διασφαλίζοντας την ποιότητα

ενός πρωτοτύπου αυτόµατα διασφαλίζεται η ποιότητα για όλα τα υπόλοιπα αντί-

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

ροδοτείται σε όλα τα αντίγραφα.

Το βασικό πρόβληµα της διασφάλισης ποιότητας λογισµικού είναι η έλλειψη µετρή-

σιµων στόχων και διαδικασιών µέτρησης. Μπορεί να είναι εύκολο να ζητάµε µια

βίδα να έχει διάµετρο κεφαλής 7 χιλιοστά µε απόκλιση ±1%, αλλά πώς µπορούµε

να ζητάµε το λογισµικό να έχει «υψηλή συντηρησιµότητα», ή «να είναι επεκτάσι-

µο», ή «να έχει υψηλή αξιοπιστία». Είναι επίσης εφικτό να µετρήσουµε τις βίδες και

να απορρίψουµε αυτές που έχουν διάµετρο κεφαλής έξω από τα επιθυµητά όρια,

αλλά δεν είναι εξίσου εφικτό να πραγµατοποιήσουµε κάτι ανάλογο για το λογισµι-

κό. Όπως αναφέρει ο Gustafsson [Sqm93]: «Όταν ένας εργάτης που δουλεύει σε µια

γραµµή µαζικής παραγωγής κάνει ένα λάθος, τότε πετάει το εξάρτηµα που έφτιαχνε.

Αν το κάνει συχνά, σε λίγο ένας επιστάτης θα θέλει να µάθει γιατί η στοίβα µε τα πετα-

µένα εξαρτήµατα είναι τόσο µεγάλη. Αυτό το κάνουµε συνέχεια µε το λογισµικό, αλλά

κανένας δεν µπορεί να δει τη στοίβα µε τα πεταµένα εξαρτήµατα.» Άλλο πρόβληµα

της διασφάλισης ποιότητας λογισµικού είναι ότι η πλειονότητα του λογισµικού έχει

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

(κάτι που είναι συνηθισµένο στην παραγωγή υλικών αγαθών).

Τέλος, µια άλλη ιδιαιτερότητα της διασφάλισης ποιότητας λογισµικού είναι ότι συνή-

θως δεν υπάρχει ιστορικό παρελθόν σηµαντικής διάρκειας στο οποίο να µπορούµε

να ανατρέξουµε και να αναζητήσουµε ενδείξεις παραγωγικότητας, έτσι ώστε να µπο-

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

τύπων. Ακόµα και επιχειρήσεις που λειτουργούν πολλά χρόνια και έχουν ιστορικά

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

ραγδαίων εξελίξεων στις τεχνολογίες λογισµικού), ώστε αυτά τα αρχεία να µην είναι

9 13 . 3 π ¢ π ∞ π ∆ ∂ ƒ √ ∆ ∏ ∆ ∂ ™ ™ ∆ ∏ ¡ ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 91

9 2 K E º A § A I O 3 : ∂ π ™ ∞ ° ø ° ∏ ™ ∆ ∏ ¡ ¶ √ π √ ∆ ∏ ∆∞

απόλυτα αξιοποιήσιµα. Επίσης, το γεγονός ότι το λογισµικό είναι σχετικά νέο προϊ-

όν κάνει πολύ δύσκολη τη σωστή επικοινωνία ανάµεσα στον πελάτη και στο δηµι-

ουργό του λογισµικού. Πολύ συχνά οι πελάτες δε µένουν ικανοποιηµένοι από το

αποτέλεσµα, διότι θεωρούν ότι οι απαιτήσεις τους δεν έγιναν αντιληπτές σωστά από

τους δηµιουργούς.

Πέρα από τα µειονεκτήµατα όµως, βασικό πλεονέκτηµα της διασφάλισης ποιότητας

λογισµικού είναι ότι όλοι οι έλεγχοι (ανεξάρτητα από το βαθµό δυσκολίας τους) µπο-

ρούν να πραγµατοποιηθούν χωρίς να χρειάζεται να καταστραφεί το προϊόν (λογι-

σµικό). Ο εντοπισµός τεχνικών µη καταστροφικού ελέγχου, που είναι µεγάλο πρό-

βληµα στην παραγωγή υλικών αγαθών, δεν έχει νόηµα για το λογισµικό.




απάντηση.


i) Οι τεχνικές ποιοτικού ελέγχου που χρησιµοποιούνται

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

στο λεγόµενο «µη καταστροφικό έλεγχο», δηλαδή στο

να βρεθούν τρόποι να ελεγχθεί η ποιότητα του προϊόντος

χωρίς να χρειαστεί να προβούµε σε καταστροφή

του δείγµατος που εξετάζουµε.

ii) Η διαχείριση ολικής ποιότητας είναι τρόπος διοίκησης και

όχι τεχνική παραγωγής.

iii) Η βασική αρχή της φιλοσοφίας του Joseph Juran είναι

το ρητό «κανένα ελάττωµα».

iv) Οι βασικές αρχές του στατιστικού ελέγχου ποιότητας

είναι η δειγµατοληψία και ο έλεγχος της απόκλισης.

v) Τα αποτελέσµατα του στατιστικού ελέγχου αναλύονται

µόνο µε τη χρήση των διαγραµµάτων ελέγχου.

vi) Στην ποιότητα λογισµικού ζητούµενο είναι ο εντοπισµός

και η απόρριψη των προϊόντων που αποκλίνουν

από τις προδιαγραφές.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 92


Στο κεφάλαιο αυτό µιλήσαµε για τις βασικές έννοιες και τους ορισµούς της ποιότη-

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

από τη µελέτη των ιδιαιτεροτήτων στην ποιότητα λογισµικού σε σχέση µε την ποιό-

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

λαιο που είναι αφιερωµένο αποκλειστικά στην ποιότητα λογισµικού.

Σε αρκετά σηµεία του κεφαλαίου και ειδικότερα στην ενότητα 3.2 (όπου αναφερό-

µαστε σε έννοιες που υπάρχουν και σε άλλα βιβλία του Ελληνικού Ανοικτού Πανεπι-

στηµίου), δεν επεκταθήκαµε σε λεπτοµερή παρουσίαση της ποιότητας στην παραγω-

γή υλικών αγαθών, αφήνοντάς σας να τις µελετήσετε από µόνοι σας. Μην ξεχνάτε τη

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

ώστε να εµπλουτίζετε τις γνώσεις σας, αλλά και να διαβάζετε µε εναλλακτικό τρόπο

την ύλη που καλύψαµε. Ακολουθεί βιβλιογραφία µε προτεινόµενα βιβλία για περαι-

τέρω µελέτη µε σχόλια για το πού να επικεντρώσετε την προσοχή σας.

9 3™ À ¡ √ æ ∏ ∫ ∂ º ∞ § ∞ π √ À ∫ ∞ π ™ À ª µ √ À § ∂ ™ ª ∂ § ∂ ∆ ∏ ™

vii) Ένα βασικό πρόβληµα της διασφάλισης ποιότητας

λογισµικού είναι η έλλειψη µετρήσιµων στόχων και

διαδικασιών µέτρησης.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 93

9 4 K E º A § A I O 3 : ∂ π ™ ∞ ° ø ° ∏ ™ ∆ ∏ ¡ ¶ √ π √ ∆ ∏ ∆∞



νται είναι αυτά που σας προτείνονται για περαιτέρω µελέτη πάνω στα θέµατα που

καλύψαµε στο κεφάλαιο 3. Τα βιβλία αυτά συνοδεύονται από σχόλια για το πού να

επικεντρώσετε τη µελέτη σας σχετικά µε τα θέµατα του κεφαλαίου 3 αλλά και γενι-

κές πληροφορίες για τη µελέτη σας.

[Ame78] American Society for Quality Control, «Standard A3», (1978).

[Arn95] K. Arnold and M. Holler, «Quality Assurance. Methods and Technologies»,

McGraw – Hill, New York, (1995).

Είναι ένα βιβλίο που µιλά κυρίως για ποιότητα στην παραγωγή υλικών αγαθών, όµως

στο πρώτο κεφάλαιο θα βρείτε µία πολύ καλή ιστορική αναδροµή που αξίζει να δια-

βάσετε.

[Aub85] C. Aubrey, «Quality Management in Financial Service», Wheaton IL,

Hitchcock Publishing, (1985).

[Bar96] Γ. Βαρουφάκης, «Αρχαία Ελλάδα & Ποιότητα. Η ιστορία και ο έλεγχος των

υλικών που σηµάδεψαν τον ελληνικό πολιτισµό», Εκδόσεις Αίολος, (1996).

Το βιβλίο αναφέρεται στην ποιότητα στην Αρχαία Ελλάδα και κυρίως στα µέταλλα

και κράµατα, στα νοµίσµατα, στα γεωργικά και αλιευτικά προϊόντα και στην παρα-

γωγή του κρασιού.

[Cro79] Philip Crosby, «Quality is Free», New York, McGraw – Hill, (1979).

[Cro96] Philip Crosby, «Quality is Still Free», New York, McGraw – Hill, (1996).

Είναι ένα από τα βιβλία που σηµάδεψαν την εποχή του στην 1η έκδοση και ακόµα

και 25 χρόνια µετά την πρώτη έκδοσή του (εµπλουτισµένο φυσικά και µε σύγχρονο

υλικό) αποτελεί ένα εύκολο, ευχάριστο και ταυτόχρονα διδακτικό ανάγνωσµα.

[Dem88] Edwards Deming, «Out of the Crisis», Massachusetts Institute of

Technology, Cambridge University Press, (1988).

[Dma82] Tomas DeMarco, «Controlling Software Projects», Prentice Hall, New –

York, (1982).

[Fei83] V. A. Feigenbaum, «Total Quality Control», 3rd ed. New York, McGraw –

Hill, (1983).

[Jur80] Joseph Juran and F. Gryna, «Quality Planning and Analysis», 2nd ed. New

York, McGraw – Hill, (1980).

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 94

Κάποτε κυκλοφορούσε ένα ανέκδοτο που έλεγε ότι «για να γίνει κανείς «ειδικός»

στην ποιότητα χρειάζονται 2 εβδοµάδες, αφού τόσο θέλει κανείς να διαβάσει το βιβλίο

του Juran!». Εκείνη την περίοδο –δυστυχώς– κυκλοφορούσαν και πολλοί «ειδικοί»

για την ποιότητα που µε την άγνοιά τους έκαναν κακό σε πολλές επιχειρήσεις. Μην

το διαβάσετε ελπίζοντας ότι θα γίνετε ειδικοί στην ποιότητα σε δύο εβδοµάδες, αλλά

γιατί είναι πραγµατικά ένα από τα καλύτερα βιβλία που µπορεί να διαβάσει κανείς

για ποιότητα.

[Mon91] D. C. Montgomery, «Introduction to Statistical Quality Control», second

edition, John Wiley & Sons, (1991).

Σε περισσότερες από 700 σελίδες µε δεκάδες παραδείγµατα θα µπορέσετε να µελε-

τήσετε αναλυτικά και αποκλειστικά για το Στατιστικό έλεγχο ποιότητας, για τον

οποίο µιλήσαµε στην ενότητα 3.2.3. Προϋποθέτει καλή γνώση βασικών µαθηµατι-

κών, αν και αρχίζει από απλές έννοιες.

[Sqm93] Software Quality Management, «A Review of the Managing Software

Quality in the 90’s», Conference by Elliott Marley, Issue 18, Spring, pp. 24 – 28,

(1993).

[Ste00] Σ. Στεφανάτος, «∆ιασφάλιση Ποιότητας: Ολική Ποιότητα», Ελληνικό Ανοι-

κτό Πανεπιστήµιο, ∆ΙΠ51/3, (2000).

Είναι το βιβλίο του Ελληνικού Ανοικτού Πανεπιστηµίου για τη διαχείριση ολικής

ποιότητας. Σχεδόν όλο το βιβλίο (κεφάλαια 1 έως και 7) περιγράφει αυτό που εµείς

απλά αναφέραµε στην ενότητα 3.2.1. Στο κεφάλαιο 8, µπορείτε να διαβάσετε περισ-

σότερα για τις απόψεις των πρωτοπόρων της ποιότητας. Γενικά, αν θέλετε να επε-

κταθείτε στα θέµατα που καλύψαµε στις ενότητες 3.2.1 και 3.2.2 νοµίζω πως πρέπει

οπωσδήποτε να το ζητήσετε από τη βιβλιοθήκη.

[Xen96] Μιχάλης Ξένος, «Μεθοδολογία ελέγχου και εξασφάλισης της ποιότητας λογισµι-

κού βασισµένη στις µετρικές προϊόντος και στα εξωτερικά ποιοτικά χαρακτηριστικά

του λογισµικού», ∆ιδακτορική ∆ιατριβή, Πανεπιστήµιο Πατρών, (1996).

Αν και από το 2ο κεφάλαιο η διατριβή εξειδικεύεται, στο 1ο εισαγωγικό κεφάλαιο

θα βρείτε µια περίληψη όλων των θεµάτων που καλύψαµε εδώ και που θα καλύ-

ψουµε στο επόµενο κεφάλαιο.


•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 95

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 96

¶ÔÈfiÙËÙ· §ÔÁÈÛÌÈÎÔ‡

™ÎÔfi˜

Σκοπός του κεφαλαίου 4 είναι η ανάλυση της έννοιας της ποιότητας λογισµικού, µε

την περιγραφή των πιο γνωστών µοντέλων ποιότητας και την ανάλυσή της σε επιµέ-

ρους χαρακτηριστικά. Επίσης, παρουσιάζεται συνοπτικά το σύστηµα ποιότητας λογι-

σµικού και η χρήση και συνεισφορά του στην ανάπτυξη λογισµικού.


Όταν θα έχετε ολοκληρώσει τη µελέτη αυτού του κεφαλαίου, θα µπορείτε να:

• αναφέρετε τα πιο γνωστά µοντέλα ποιότητας λογισµικού,

• ορίσετε την έννοια των παραγόντων ποιότητας, αλλά και να αναφέρετε και ορίσε-

τε τους βασικότερους παράγοντες ποιότητας λογισµικού,

• αναφέρετε τους παράγοντες ποιότητας τους µοντέλου FCM και του µοντέλου του

Boehm,

• αναφέρετε και να ορίσετε τους παράγοντες ποιότητας του προτύπου ISO 9126 και

να περιγράψετε τα χαρακτηριστικά που συνθέτουν κάθε παράγοντα,

• περιγράψετε τι περιέχει ένα σύστηµα ποιότητας στο λογισµικό και να ορίσετε τις

έννοιες του προτύπου, της οδηγίας και της διαδικασίας,

• εξηγήσετε τις διαφορές ανάµεσα στο εγχειρίδιο ποιότητας και στο πλάνο ποιότη-

τας και να περιγράψετε πώς εντάσσονται και τα δύο στο σύστηµα ποιότητας µίας

επιχείρησης,

• προσδιορίσετε τι θα µπορούσε να περιέχει ένα πρότυπο ή µια διαδικασία ποιότη-

τας για µια συγκεκριµένη φάση ανάπτυξης (τα χαρακτηριστικά της οποίας γνωρί-

ζετε σε βάθος),

• αναφέρετε τι προσφέρει το σύστηµα ποιότητας σε κάθε χρήστη του και συνολικά

στην επιχείρηση.


4∫ ∂ º ∞ § ∞ π √

• Ποιότητα λογισµικού (Software

quality)

• Λειτουργικότητα (Functionality)

• Ευχρηστία (Usability)

• Συντηρησιµότητα (Maintainability)

• Ελεγξιµότητα (Testability)

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 97

9 8 K E º A § A I O 4 : ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À


Στο προηγούµενο κεφάλαιο µιλήσαµε για την ποιότητα στην παραγωγή υλικών αγα-

θών και τους τρόπους µε τους οποίους προσεγγίζεται η ποιότητα. Μιλήσαµε επίσης

για τις ιδιαιτερότητες της ανάπτυξης λογισµικού και γιατί αρκετοί από τους τρόπους

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

στούν στην ποιότητα λογισµικού. Σε αυτό το κεφάλαιο περιγράφουµε τις προσεγγί-

σεις στην ποιότητα λογισµικού, τα ποιοτικά χαρακτηριστικά του λογισµικού και το

σύστηµα ποιότητας στην ανάπτυξη λογισµικού.

Ειδικότερα, στην ενότητα 4.1 µε τίτλο ποιοτικά χαρακτηριστικά λογισµικού, εισάγουµε

τις έννοιες των παραγόντων ποιότητας και των ποιοτικών χαρακτηριστικών και παρου-

σιάζουµε τα πιο διαδεδοµένα µοντέλα ποιότητας λογισµικού, µε έµφαση στο πρότυπο

ISO 9126. Στην ενότητα 4.2 µε τίτλο σύστηµα ποιότητας λογισµικού, παρουσιάζουµε το

σύστηµα ποιότητας επεξηγώντας τις διαφορές ανάµεσα στο εγχειρίδιο και στο πλάνο

ποιότητας, αναλύουµε τους χρήστες του συστήµατος ποιότητας και τα οφέλη από αυτό.


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

µπορείτε να βρείτε και πληροφορίες για πρόσθετες πηγές.

• Επαναχρησιµοποιησιµότητα

(Reusability)

• Μεταφερσιµότητα (Portability)

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

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

• Παράγοντες (Factors)

• Κριτήρια (Criteria)

• Μετρικές (Metrics)

• Σύστηµα ποιότητας (Quality system)

• Πρότυπο (Standard)

• Οδηγία (Guideline)

• ∆ιαδικασία (Procedure)

• Ανεξαρτησία (Independence)

• Ανιχνευσιµότητα (Traceability)

• ∆ιασφάλιση ποιότητας διαδικασιών

(Process quality assurance)

• ∆ιασφάλιση ποιότητας πόρων

(Resource quality assurance)

• ∆ιασφάλιση ποιότητας προϊόντος

(Product quality assurance)

• Υπεύθυνος ποιότητας (Quality

manager)

• Εγχειρίδιο ποιότητας (Quality

manual)

• Πλάνο ποιότητας έργου (Project

Quality plan)

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 98

4.1 ¶ÔÈÔÙÈÎ¿ ¯·Ú·ÎÙËÚÈÛÙÈÎ¿ ÏÔÁÈÛÌÈÎÔ‡

Ακριβώς επειδή η έννοια της ποιότητας λογισµικού είναι αρκετά αφηρηµένη και δεν

επιτρέπει τον καθορισµό µετρήσιµων στόχων, προέκυψε η ανάγκη επιµερισµού της

ποιότητας σε χαρακτηριστικά τα οποία θα συνθέτουν αυτή την αφηρηµένη έννοια

«ποιότητα». Αυτά τα χαρακτηριστικά ονοµάζονται παράγοντες ποιότητας (quality

factors). Η διαδικασία διάσπασης της ποιότητας σε παράγοντες ποιότητας και του

εντοπισµού των ποιοτικών χαρακτηριστικών των οποίων η διασφάλιση είναι σηµα-

ντική για το εκάστοτε έργο (µε στόχο τη διενέργεια µετρήσεων για τον έλεγχο αυτών

των χαρακτηριστικών), είναι σήµερα βασική διαδικασία κάθε προγράµµατος ποιό-

τητας λογισµικού. Το σκεπτικό αυτό παρουσιάστηκε περίπου την ίδια χρονική περίο-

δο –τέλη της δεκαετίας του ’80– τόσο από τον McCall [Mcc77] όσο και τον Boehm

[Boe78]. Βασισµένο σε αυτά τα δύο µοντέλα –αρκετά χρόνια µετά– δηµιουργήθη-

κε τo πρότυπο ISO 9126, το αποτέλεσµα µιας διεθνούς προσπάθειας να αναπτυχθεί

ένα πρότυπο για τη µέτρηση της ποιότητας λογισµικού [Iso91].

Στην ενότητα 4.1.1 παρουσιάζουµε τους βασικούς παράγοντες ποιότητας λογισµι-

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

ντων θα σας βοηθήσει στην κατανόηση του µοντέλου του McCall (γνωστό και ως

FCM) που παρουσιάζεται συνοπτικά στην ενότητα 4.1.2 και του Boehm που ακο-

λουθεί στην ενότητα 4.1.3. Τέλος, το πρότυπο ISO 9126 παρουσιάζεται στην ενό-

τητα 4.1.4 µαζί µε τα χαρακτηριστικά που συνθέτουν κάθε έναν από τους παράγο-

ντες ποιότητάς του.

4.1.1 ¶·Ú¿ÁÔÓÙÂ˜ ÔÈfiÙËÙ·˜

Υπάρχουν πολλές προσεγγίσεις στην έννοια της ποιότητας. Ο Garvin [Gar84] ορί-

ζει την ποιότητα ως µια πολύπλοκη και πολυπρόσωπη έννοια που µπορεί να περι-

γραφεί µε πέντε διαφορετικές θεωρήσεις:

• Εµπειρική θεώρηση (transcendental view): Θεωρεί ότι η ποιότητα είναι κάτι που

µπορεί να αναγνωριστεί εµπειρικά, αλλά όχι να οριστεί ούτε να επιτευχθεί πλήρως.

• Θεώρηση από την πλευρά του χρήστη (user view): Αντιµετωπίζει την ποιότητα

ως καταλληλότητα για χρήση.

• Κατασκευαστική θεώρηση (manufacturing view): Αντιµετωπίζει την ποιότητα ως

ικανοποίηση των κατασκευαστικών προδιαγραφών του χρήστη.

• Θεώρηση προϊόντος (product view): Θεωρεί ότι η ποιότητα ταυτίζεται µε τα ενδο-

γενή (εσωτερικά) χαρακτηριστικά του προϊόντος.

9 94 . 1 ¶ √ π √ ∆ π ∫ ∞ Ã ∞ ƒ∞ ∫ ∆ ∏ ƒ π ™ ∆ π ∫ ∞ § √ ° π ™ ª π ∫ √ À

Παράγοντες

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

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 99

1 0 0 K E º A § A I O 4 : ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

• Θεώρηση βάσει της αξίας (value – based view): Θεωρεί ότι η ποιότητα εξαρτά-

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

Ανάλογα µε τη θεώρηση της ποιότητας, προκύπτουν και αντίστοιχοι παράγοντες ποι-

ότητας που συνεισφέρουν σε αυτό που αφηρηµένα καλούµε «ποιότητα του προϊό-

ντος». Αυτοί οι παράγοντες µπορεί να διαφέρουν για την επιχείρηση που αναπτύσ-

σει το λογισµικό (θεώρηση του κατασκευαστή) σε σχέση µε αυτούς που ενδιαφέ-

ρουν τους τελικούς χρήστες. Ακόµα, µπορεί να βασίζονται σε πολιτισµικές ή κοι-

νωνικές αντιλήψεις για την ποιότητα.

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

(functionality) και η ευχρηστία (usability). Ακριβώς επειδή στον ορισµό της λει-

τουργικότητας µιλάµε και για «συνεπαγόµενες ανάγκες», είναι σαφές ότι ο παράγο-

ντας αυτός σχετίζεται και µε τις κοινωνικές αντιλήψεις για την ποιότητα. Επίσης, για

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

λογισµικό, η χρήση του να είναι εύκολη και κατανοητή από αυτούς.

Αναφορικά µε την οµάδα υλοποίησης, το ενδιαφέρον εντοπίζεται σε παράγοντες ποι-

ότητας όπως η συντηρησιµότητα (maintainability), η ελεγξιµότητα (testability), η

επαναχρησιµοποιησιµότητα (reusability) και η µεταφερσιµότητα (portability). Η

οµάδα ανάπτυξης ενδιαφέρεται να µπορεί εύκολα να υλοποιεί αλλαγές στο λογι-

σµικό. Για να µπορεί η οµάδα ανάπτυξης να υλοποιεί αλλαγές, χρειάζεται να µπο-

ρεί να ελέγχει το λογισµικό για λάθη και παραλείψεις, αλλά και να µπορεί να επα-

ναχρησιµοποιεί τµήµατα του λογισµικού που αναπτύχθηκε για ένα έργο σε κάποιο

άλλο έργο. Τέλος, η οµάδα ανάπτυξης επιθυµεί να µπορεί να µεταφέρει το λογισµι-

κό που αναπτύχθηκε για ένα έργο εύκολα σε διαφορετικές πλατφόρµες υλικού ή λει-

τουργικών συστηµάτων.

Για την κοινωνία, όπως εύκολα µπορούµε να παρατηρήσουµε, δε νοείται το λογι-

σµικό να µην είναι αξιόπιστο και αποτελεσµατικό. Αυτοί οι παράγοντες ποιότητας,

δηλαδή η αξιοπιστία (reliability) και η αποδοτικότητα (efficiency) είναι και αυτοί

που συνήθως υπονοούνται στις προδιαγραφές των µικρών έργων. Φυσικά σε εξει-

δικευµένα έργα όπου η αξιοπιστία ή η αποδοτικότητα είναι καθοριστικοί παράγο-

ντες, τότε αυτοί παύουν να αφορούν κοινωνικές αντιλήψεις και µεταφέρονται στις

απαιτήσεις του χρήστη. Για παράδειγµα σε µία εφαρµογή πραγµατικού χρόνου, η

αξιοπιστία και η αποδοτικότητα θα αντιµετωπιστούν τελείως διαφορετικά από µία

εφαρµογή αυτοµατισµού γραφείου.

Λειτουργικότητα

είναι ένα σύνολοχαρακτηριστικώνπου είναι φορείς

ενός συνόλου λει-τουργιών και των

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

νες ανάγκες.

Ευχρηστία ενόςσυστήµατος είναι η

ικανότητά του ναλειτουργεί αποτελε-σµατικά και αποδο-

τικά ενώ παρέχειυποκειµενική ικα-

νοποίηση στουςχρήστες του. Πρό-

τυπο ISO 9241.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 100

4.1.2 ∆Ô ÌÔÓÙ¤ÏÔ FCM

Ο McCall [Mcc77] προτείνει την τµηµατοποίηση της ποιότητας σε παράγοντες

(factors) ποιότητας. Επειδή τόσο η ίδια η ποιότητα, όσο και οι ποιοτικοί παράγοντες

είναι εξαιρετικά αφηρηµένες έννοιες, ο McCall πρότεινε επίσης την τµηµατοποίηση

των παραγόντων σε κριτήρια (criteria) που βρίσκονται σε χαµηλότερο επίπεδο αφαί-

ρεσης και τα οποία µπορούν να µετρηθούν άµεσα µε µετρικές (metrics). Αν και για

τις µετρικές θα µιλήσουµε στο επόµενο κεφάλαιο, στο σηµείο αυτό πρέπει να ανα-

φερθεί ότι ο McCall είχε προτείνει οι µετρήσεις για κάθε κριτήριο να προκύπτουν από

απαντήσεις σε ερωτήσεις για το κριτήριο. Από τα ονόµατα των τριών επιπέδων αφαί-

ρεσης το µοντέλο αυτό ονοµάστηκε µοντέλο FCM (Factors – Criteria – Metrics).

Όπως φαίνεται και στο σχήµα 4.1, ο McCall πρότεινε 11 παράγοντες ποιότητας, 25 κρι-

τήρια και 41 µετρικές. Οι 11 παράγοντες είναι οι: ευχρηστία (usability), ακεραιότητα

(integrity), αποδοτικότητα (efficiency), ορθότητα (correctness), αξιοπιστία (reliability),

συντηρησιµότητα (maintainability), ελεγξιµότητα (testability), ευελιξία (flexibility),

επαναχρησιµοποιησιµότητα (reusability), µεταφερσιµότητα (portability) και διαλει-

τουργικότητα (interoperability). ∆εν θα επεκταθούµε στην ανάλυση όλων των παρα-

γόντων του FCM µοντέλου, αφού οι βασικότεροι ορίστηκαν στην ενότητα 4.1.1 και για

τους υπόλοιπους θα σας παραπέµψουµε στη βιβλιογραφία στο τέλος του κεφαλαίου.

1 0 14 . 1 ¶ √ π √ ∆ π ∫ ∞ Ã ∞ ƒ∞ ∫ ∆ ∏ ƒ π ™ ∆ π ∫ ∞ § √ ° π ™ ª π ∫ √ À

Συντηρησιµότητα

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

Ελεγξιµότητα

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




α) Παράγοντες ποιότητας είναι οµάδες ………………… τα οποία συνθέτουν την

ποιότητα ενός προϊόντος, έχουν την ελάχιστη δυνατή ……………… µεταξύ

τους και είναι επαρκή για τη σύνθεση της ποιότητας.

(δεδοµένων, χαρακτηριστικών) (επικάλυψη, σχέση)

β) Η θεώρηση της ποιότητας από την πλευρά του χρήστη αντιµετωπίζει την ποιό-

τητα ως …………………… για χρήση.

(αδυναµία, συµβατότητα, καταλληλότητα, αυτοµατοποίηση)

γ) Αξιοπιστία είναι ένα σύνολο χαρακτηριστικών που είναι φορείς της δυνατότη-

τας του λογισµικού να διατηρεί το ……………… απόδοσής του σε

………………… συνθήκες και για προκαθορισµένη χρονική περίοδο.

(επίπεδο, πρότυπο, υλικό, λογισµικό) (καθορισµένες, µεταβαλλόµενες, σχετικές)

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 101

1 0 2 K E º A § A I O 4 : ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

Το µοντέλο αυτό αποτέλεσε ένα από τα πιο ολοκληρωµένα µοντέλα της εποχής του

και έγινε η βάση για το διεθνές πρότυπο ISO 9126 [Iso91]. Παρά τα προβλήµατα της

υποκειµενικότητας των ερωτήσεων, της ύπαρξης περιορισµένης κλίµακας (το µοντέ-

λο δεχόταν µόνο απαντήσεις «ΝΑΙ» και «ΟΧΙ») και της αδυναµίας συνδυασµού µετρι-

κών, το µοντέλο αυτό γνώρισε ευρεία αποδοχή και ακόµα και σήµερα, που το ISO

9126 κυριαρχεί, αρκετές επιχειρήσεις βασίζουν το σύστηµα ποιότητάς τους στην τµη-

Επαναχρησι-

µοποιησιµότητα

είναι ένα σύνολοχαρακτηριστικών

που σχετίζονται µετην απαιτούµενηπροσπάθεια για

επαναχρησιµοποίη-ση του συνόλου ή

µέρους του λογισµι-κού που έχει ανα-

πτυχθεί.

Μεταφερσιµότητα

είναι ένα σύνολοχαρακτηριστικών που

σχετίζονται µε τηδυνατότητα του λογι-σµικού να µεταφέρε-ται από ένα περιβάλ-

λον σε άλλο (αυτόπεριλαµβάνει το

υλικό, λογισµικό ήοργανωτικό

περιβάλλον).

Παράγοντες

Eυχριστία

Operability

Training

Communicattiveness

I/O Volume

I/O rate

Access control

Access audit

Storage efficiency

Execution efficiency

Traceability

Completeness

Accuracy

Error tolerance

Concistrency

Simplicity

Conciseness

Instrumentation

Expandability

Generality

Self–descriptiveness

Modularity

Machine independence

S/W system independence

Comms commonality

Data commonality

Aκεραιότητα

Aποδοτικότητα

Oρθότητα

Aξιοπιστία


Eλεγξιµότητα

Eυελιξία

Eπαναχρησιµοποι-ησιµότητα

Mεταφερσιµότητα

∆ιαλειτουργικότητα

Kριτήρια Mετρικές

Metrics

™¯‹Ì· 4.1

Μοντέλο FCM

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 102

µατοποίηση του FCM µοντέλου. Ο βασικότερος λόγος για αυτό είναι ότι είναι καλύ-

τερα προσαρµοσµένο στην οµάδα υλοποίησης και πιο αναλυτικό από το ISO 9126.

1 0 34 . 1 ¶ √ π √ ∆ π ∫ ∞ Ã ∞ ƒ∞ ∫ ∆ ∏ ƒ π ™ ∆ π ∫ ∞ § √ ° π ™ ª π ∫ √ À

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


Είτε από την προτεινόµενη βιβλιογραφία [Fen97], [Inc95], [Kit96], είτε από πηγές

στο διαδίκτυο, βρείτε πληροφορίες για το FCM µοντέλο και περιγράψτε και τους

11 παράγοντες ποιότητας (πώς ορίζεται καθένας, τι σηµαίνει πρακτικά για µία επι-

χείρηση και πώς µπορεί να αναλυθεί;).

4.1.3 ∆Ô ÌÔÓÙ¤ÏÔ ÙÔ˘ Boehm

To µοντέλο του Boehm [Boe78] ακολουθεί παρόµοια ιεραρχική δοµή µε αυτή του

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

ταρχικές χρήσεις (primary uses) και αυτές σε ενδιάµεσες κατασκευές (intermediate

constructs), ανάλογες µε τα κριτήρια ποιότητας του προηγούµενου µοντέλου, όπως

φαίνεται και στο σχήµα 4.2. Οι ενδιάµεσες κατασκευές µε τη σειρά τους διασπώνται

σε πρωτογενείς κατασκευές (primitive constructs) οι όποιες µετρώνται άµεσα µε

µετρικές (metrics).

™¯‹Ì· 4.2

Μοντέλο του Boehm

Πρωταρχικές χρήσεις Eνδιάµεσες κατασκευές Πρωτογενείς κατασκευές

Γενικήπρακτικότητα

Πρακτικότηταως είναι

Συντηρησι-µότητα

Metrics

Portability

Reliability

Efficiency

Human engineening

Testability

Understandability

Modifiability

Device independence

Completeness

Accuracy

Consistency

Device efficiency

Accessibility

Comunicativeness

Structuredness

Self descriptiveness

Conciseness

Legibility

Augmentability

Το µοντέλο του Boehm, παρόλο που ακολουθεί τη λογική της ανάλυσης της ποιό-

τητας σε ποιοτικά χαρακτηριστικά, δεν είναι τόσο δοµηµένο όσο το FCM µοντέλο.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 103

1 0 4 K E º A § A I O 4 : ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

Όµως, ήταν το πρώτο µοντέλο που εισήγαγε την πρακτική της χρήσης µετρικών λογι-

σµικού αντί για ερωτήσεις στο κατώτερο επίπεδο. Αυτή η πρακτική εφαρµόστηκε

µε σχετική επιτυχία για τη µέτρηση των ποιοτικών χαρακτηριστικών, άσχετα αν το

γενικό µοντέλο είναι το FCM, του Boehm, ή το ISO 9126.

4.1.4 ∆Ô ÚfiÙ˘Ô ISO 9126

Το πρότυπο ISO 9126 [Iso91] αποτελεί ένα µοντέλο ποιότητας λογισµικού που εξε-

λίχθηκε σε διεθνές πρότυπο από το διεθνή οργανισµό τυποποίησης ISO. Ως µοντέ-

λο ποιότητας λογισµικού διαφέρει από τα προγενέστερα µοντέλα τόσο στην ορολο-

γία, όσο και στη δοµή, καθώς είναι απόλυτα ιεραρχικό. Στο ISO 9126 κάθε χαρα-

κτηριστικό ανήκει αυστηρά σε ένα παράγοντα ποιότητας χωρίς να υπάρχουν επικα-

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

τερικό χαρακτηριστικό του προϊόντος. Με αυτή τη λογική, το ISO 9126 αντικατο-

πτρίζει περισσότερο τη θεώρηση από την πλευρά του χρήστη, σε αντίθεση µε τα δύο

προγενέστερα µοντέλα που αντικατοπτρίζουν την προσέγγιση της οµάδας ανάπτυ-

ξης. Αυτός είναι και ο βασικός λόγος που –αν και πρότυπο– αρκετές επιχειρήσεις

(οι οµάδες ανάπτυξης δηλαδή) εµµένουν ακόµα και σήµερα στο FCM µοντέλο.

Άλλοι λόγοι είναι ότι το ISO 9126 δεν ορίζει καθαρά πώς µπορούν να µετρηθούν

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

ποιοτικών χαρακτηριστικών σε επιµέρους υποχαρακτηριστικά.

Στο σχήµα 4.3 παρουσιάζεται το πρότυπο ISO 9126. Φροντίσαµε να αποδώσουµε

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

γία. Ειδικά για το ISO 9126 θα αφιερώσουµε λίγο χώρο για να επεξηγήσουµε τους

παράγοντες και τα επιµέρους χαρακτηριστικά, χωρίς να χρησιµοποιούµε τον αυστη-

ρό φορµαλισµό των πρωτότυπων ορισµών.

Η λειτουργικότητα που, όπως είπαµε, είναι η δυνατότητα του λογισµικού να παρέ-

χει όλες τις απαιτούµενες λειτουργίες, εµπεριέχει τα χαρακτηριστικά:

• Καταλληλότητα (suitability) που είναι η παροχή από το λογισµικό κατάλληλου

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

• Ακρίβεια (accuracy) που είναι η δυνατότητα του λογισµικού να παρέχει σωστά

και αποδεκτά αποτελέσµατα ή ενέργειες.

• ∆ιαλειτουργικότητα (interoperability) που είναι η δυνατότητα του λογισµικού

να αλληλεπιδρά µε ένα ή περισσότερα προεγκατεστηµένα ή προκαθορισµένα

συστήµατα.

• Ασφάλεια (security) που είναι η δυνατότητα του λογισµικού να προλαµβάνει

Αποδοτικότητα

είναι ένα σύνολοχαρακτηριστικώνπου είναι φορείς

της σχέσης που υφί-σταται ανάµεσα

στην επίδοση τουλογισµικού και το

σύνολο των πόρωνπου χρησιµοποιεί,υπό καθορισµένες

συνθήκες.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 104

αθέλητη προσπέλαση και να αντιστέκεται σε εσκεµµένες επιθέσεις που σκοπό

έχουν τη µη εξουσιοδοτηµένη πρόσβαση σε εµπιστευτικές πληροφορίες, ή τη µη

εξουσιοδοτηµένη τροποποίηση της περιεχόµενης πληροφορίας ή του προγράµ-

µατος, µε σκοπό είτε να αποκτήσει ο εισβολέας κάποιο πλεονέκτηµα είτε να παρε-

µποδίσει εξουσιοδοτηµένους χρήστες να έχουν πρόσβαση στις υπηρεσίες του

προγράµµατος.

1 0 54 . 1 ¶ √ π √ ∆ π ∫ ∞ Ã ∞ ƒ∞ ∫ ∆ ∏ ƒ π ™ ∆ π ∫ ∞ § √ ° π ™ ª π ∫ √ À


(Functionality)

Aξιοπιστία

(Reliability)

Eυχριστία

(Usability)

Aποδοτικότητα

(Efficiency)


(Maintainability)

Mεταφερσιµότητα

(Portability)

Kαταλληλότητα (Suitability)

Aκρίβεια (Accuracy)

∆ιαλειτουργοκότητα (Interoperability)

Aσφάλεια (Security)

Aναλυσιµότητα (Analyzability)

Tροποποιησηµότητα (Changeability)

Σταθερότητα (Stability)

Eλεγξιµότητα (Testability)

Προσαρµοστικότητα (Adaptability)

Eυκολία εγκατάστασης (Installability)

∆υνατότητα συνύπρξης (Conformance)

Aντικαταστασιµότητα (Replaceability)

Ωριµότητα (Maturity)

Aνεκτικότητα σε λάθη (Fault tolerance)

Aνακτησιµότητα (Recoverability)

Kατανοησηµότητα (Understandability)

Eυκολία εκµάθηση (Learnability)

Eυκολία χειρισµού (Operability)

Xρονική συµπεριφορά (Time behavior)

Aξιοποίηση πόρων (Resource behavior)

™¯‹Ì· 4.3

Το πρότυπο

ISO 9126

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 105

1 0 6 K E º A § A I O 4 : ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

Η αξιοπιστία που, όπως είπαµε, είναι η δυνατότητα του λογισµικού να λειτουργεί

µε σταθερό και συγκεκριµένο τρόπο κάτω από καθορισµένες συνθήκες, εµπεριέχει

τα χαρακτηριστικά:

• Ωριµότητα (maturity) που είναι η δυνατότητα να αποφεύγονται προβλήµατα που

είναι αποτέλεσµα λαθών στο λογισµικό.

• Ανεκτικότητα σε λάθη (fault tolerance) που είναι η υποστήριξη από το λογι-

σµικό καθορισµένου επιπέδου εφαρµογής σε περιπτώσεις λαθών στο λογισµικό

ή παραβιάσεων στο περιβάλλον διεπαφής.

• Ανακτησιµότητα (recoverability) που είναι η θεµελίωση από το λογισµικό του

επιπέδου των εφαρµογών και η αποκατάσταση των δεδοµένων που άµεσα επη-

ρεάζονται σε περίπτωση αποτυχίας.

Η ευχρηστία που, όπως είπαµε, σχετίζεται µε την ευκολία αντίληψης, εκµάθησης,

χρήσης και ικανοποίησης του χρήστη, εµπεριέχει τα χαρακτηριστικά:

• Κατανοησιµότητα (understandability) που είναι η ιδιότητα του λογισµικού να

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

γκες του και πώς µπορεί να χρησιµοποιηθεί για συγκεκριµένο έργο και συνθήκες

χρήσης.

• Ευκολία εκµάθησης (learnability) που αφορά το βαθµό ευκολίας στον οποίο ο

χρήστης µπορεί να µάθει την εφαρµογή.

• Ευκολία χειρισµού (operability) που είναι η δυνατότητα του λογισµικού να καθι-

στά το χρήστη ικανό να χειρίζεται και να ελέγχει την εφαρµογή.

Η αποδοτικότητα που, όπως είπαµε, είναι η ικανότητα του λογισµικού να αποδίδει

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

θήκες, εµπεριέχει τα χαρακτηριστικά:

• Χρονική συµπεριφορά (time behaviour) που είναι η ικανότητα του λογισµικού

να παρέχει καθορισµένο και αποδεκτό χρόνο απόκρισης και εκτέλεσης διαδικα-

σίας ή ενεργειών σε καθορισµένες συνθήκες.

• Αξιοποίηση πόρων (resource behaviour) που είναι το επίπεδο χρήσης συγκε-

κριµένων πόρων σε καθορισµένο χρόνο, όταν εκτελείται µια διαδικασία σε καθο-

ρισµένες συνθήκες.

Η συντηρησιµότητα που, όπως είπαµε, σχετίζεται µε την ευκολία του λογισµικού

να τροποποιείται, εµπεριέχει τα χαρακτηριστικά:

• Αναλυσιµότητα (analyzability) που είναι η δυνατότητα διάγνωσης του βαθµού

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 106

ανεπάρκειας, ή των βλαβών ή λαθών στο λογισµικό, ή στα τµήµατα που έχουν

τροποποιηθεί.

• Τροποποιησιµότητα (changeability) που είναι η ευκολία υλοποίησης αλλαγών

και τροποποίησης του λογισµικού.

• Σταθερότητα (stability) που είναι η δυνατότητα ελαχιστοποίησης ανεπιθύµητων

αποτελεσµάτων που οφείλονται στις τροποποιήσεις του λογισµικού.

• Ελεγξιµότητα (testability) που είναι η δυνατότητα ελέγχου της αξιοπιστίας του

λογισµικού που έχει τροποποιηθεί, ή πρόκειται να τροποποιηθεί.

Και τέλος, η µεταφερσιµότητα που, όπως είπαµε, σχετίζεται µε τη δυνατότητα του

λογισµικού να µπορεί να µεταφερθεί από ένα περιβάλλον σε άλλο.

• Προσαρµοστικότητα (adaptability) που είναι η δυνατότητα του λογισµικού να

µπορεί να τροποποιηθεί, ώστε να εκτελεστεί σε διαφορετικά λειτουργικά περι-

βάλλοντα χωρίς να απαιτεί διαφορετικές πρακτικές χρήσης.

• Ευκολία εγκατάστασης (installability) που είναι η δυνατότητα εγκατάστασης

σε κάποιο περιβάλλον.

• ∆υνατότητα συνύπαρξης (conformance) που αφορά τη δυνατότητα συνύπαρξής

του ως ανεξάρτητου λογισµικού σε περιβάλλον κοινό µε άλλες εφαρµογές.

• Αντικαταστασιµότητα (replaceability) που είναι η δυνατότητα του λογισµικού

να µπορεί να χρησιµοποιηθεί στο περιβάλλον ενός άλλου λογισµικού (αντικαθι-

στώντας κάποιο τµήµα του).

1 0 74 . 1 ¶ √ π √ ∆ π ∫ ∞ Ã ∞ ƒ∞ ∫ ∆ ∏ ƒ π ™ ∆ π ∫ ∞ § √ ° π ™ ª π ∫ √ À


∆ίνεται µία λίστα µε παράγοντες ποιότητας. Επιλέξτε ποιοι από αυτούς αποτελούν

παράγοντες ποιότητας σύµφωνα µε το FCM µοντέλο, ποιοι µε το µοντέλο του

Boehm και ποιοι µε το ISO 9126, βάζοντας ένα στην αντίστοιχη στήλη δίπλα σε

κάθε έναν. Προσέξτε ότι κάποιοι µπορεί να µην αποτελούν παράγοντες σε κανένα

µοντέλο, ενώ κάποιοι άλλοι να αποτελούν και στα τρία µοντέλα.

Παράγοντας ποιότητας FCM Boehm ISO 9126

ακεραιότητα

αξιοπιστία

αποδοτικότητα

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 107

1 0 8 K E º A § A I O 4 : ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

4.2 ™‡ÛÙËÌ· ¶ÔÈfiÙËÙ·˜ §ÔÁÈÛÌÈÎÔ‡

Σε αυτή την ενότητα θα παρουσιάσουµε το σύστηµα ποιότητας (quality system),

στο οποίο αναφερθήκαµε στο κεφάλαιο 3. Πριν την παρουσίαση πρέπει να επεξη-

γηθούν οι έννοιες του προτύπου (standard), της οδηγίας (guideline) και της διαδι-

κασίας (procedure), όπως τις χρησιµοποιούµε στα πλαίσια του συστήµατος ποιότη-

τας στην ανάπτυξη λογισµικού. Το πρότυπο παρέχει κατευθύνσεις για το πώς ένα

γεγονός θα αναπαρασταθεί στο χαρτί ή στον ηλεκτρονικό υπολογιστή. Ένα παρά-

δειγµα προτύπου που θα παρουσιάσουµε στο κεφάλαιο 6 είναι το ISO 9001. Παρά-

δειγµα οδηγίας (για την οποία επίσης θα µιλήσουµε στο 6ο κεφάλαιο είναι η οδηγία

ISO 9000 – 3 που επεξηγεί την εφαρµογή του ISO 9001 στην ανάπτυξη λογισµικού.

Το σύστηµα ποιότητας λογισµικού πρέπει να ικανοποιεί δύο βασικές αρχές: της ανε-

ξαρτησίας (independence) και της ανιχνευσιµότητας (traceability). Η έννοια της

ανεξαρτησίας σχετίζεται µε την εγκυρότητα. ∆ηλαδή, ακριβώς επειδή είναι δύσκο-

λο για έναν εργαζόµενο να εκτιµήσει την εγκυρότητα της εργασίας του, ένα σύστη-

µα ποιότητας θα πρέπει να παρέχει τρόπους αξιολόγησης εργασιών όχι από τους ίδι-

ους τους δηµιουργούς τους. Σχετικά µε την ανιχνευσιµότητα, διακρίνουµε την ορθή

ανιχνευσιµότητα (forward traceability) και την αντίστροφη ανιχνευσιµότητα

ασφάλεια

ελεγξιµότητα

διαλειτουργικότητα

επαναχρησιµοποιησιµότητα

ευελιξία

ευχρηστία

κατανοησιµότητα

λειτουργικότητα

µεταφερσιµότητα

ορθότητα

προσαρµοστικότητα

συντηρησιµότητα

ωριµότητα

Πρότυπο είναιµία τεκµηριωµένη

σύµβαση πουπεριέχει τεχνικέςπροδιαγραφές, ή

άλλα ακριβή κριτή-ρια χρησιµοποιού-

µενα ως κανόνεςκαι κατευθυντήριες

γραµµές για τηνεξασφάλιση της

τυποποίησης τωνκατάλληλων υλι-κών, προϊόντων,

διεργασιών καιυπηρεσιών για τηδιευκόλυνση της

διεθνούς ανταλλα-γής αγαθών και

υπηρεσιών και τηςανάπτυξης συνερ-

γασίας στη σφαίρατων επιστηµονι-

κών, τεχνολογικώνκαι οικονοµικών

ενεργειών.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 108

(reverse traceability). H πρώτη αναφέρεται στην ικανότητα ανίχνευσης (εντοπισµού),

ξεκινώντας από τις λειτουργικές προδιαγραφές των τµηµάτων του κώδικα που υλο-

ποιούν αυτές τις λειτουργίες, ενώ η δεύτερη το αντίστροφο (την ανίχνευση ποιες λει-

τουργίες υλοποιεί κάποιο τµήµα του κώδικα).

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

και των λειτουργιών που επιτελεί. Στην ενότητα 4.2.2 αναφερόµαστε στους χρήστες

αυτού του συστήµατος και στο τι παρέχει σε αυτούς, ενώ στην ενότητα 4.2.3 παρου-

σιάζονται τα οφέλη που αποφέρει (µεσοµακροπρόθεσµα) στην επιχείρηση ένα

σύστηµα ποιότητας.

1 0 94 . 2 ™ À ™ ∆ ∏ ª ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

Οδηγία είναιπεριγραφικό κεί-µενο που επεξηγείτην εφαρµογήενός προτύπου.

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

™¯‹Ì· 4.4

Σύστηµα

ποιότητας

λογισµικού

Πρότυπο (π.χ. ISO 9001)

Σύστηµα διασφάλισηςποιότητας

Eγχειρίδιο ποιότητας

Mετρικές καιδιαδικασίεςποιότητας

1ο Έργο 2ο Έργο N–οστό Έργο

1ο πλάνοποιότητας

2ο πλάνοποιότητας

N–οστό πλάνοποιότητας

4.2.1 ∂Ê·ÚÌÔÁ‹ ÙÔ˘ Û˘ÛÙ‹Ì·ÙÔ˜ ÔÈfiÙËÙ·˜

Ένα πλήρες σύστηµα ποιότητας έχει τρεις βασικούς στόχους: τη διασφάλιση ποιό-

τητας διαδικασιών παραγωγής, τη διασφάλιση ποιότητας πόρων και τη διασφάλιση

ποιότητας προϊόντων. Η διασφάλιση ποιότητας διαδικασιών παραγωγής (process

quality assurance) έχει ως αντικείµενο τη συνεχή βελτιστοποίηση, βάσει των προ-

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 109

1 1 0 K E º A § A I O 4 : ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

διαγραφών ποιότητας, των διαδικασιών παραγωγής του προϊόντος και γενικότερα

της λειτουργίας της επιχείρησης. Η διασφάλιση ποιότητας πόρων (resource quality

assurance) έχει ως αντικείµενο τη βελτίωση των πόρων που χρησιµοποιούνται για

την παραγωγή του προϊόντος. Ως πόροι ορίζονται η υλικοτεχνική υποδοµή της επι-

χείρησης (δηλαδή ο εξοπλισµός, τα εργαλεία, το λογισµικό ανάπτυξης, οι χώροι

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

όντος (product quality assurance) έχει ως αντικείµενο τη βελτίωση της ποιότητας

του τελικού προϊόντος. Είναι φανερό βέβαια, ότι έµµεσος στόχος και των δύο πρώ-

των κατηγοριών (διαδικασιών και πόρων) είναι τελικά η διασφάλιση της ποιότητας

του τελικού προϊόντος.

Στο σχήµα 4.4 [Xen96] απεικονίζεται η µορφή του συστήµατος ποιότητας. Το σύστη-

µα ποιότητας θα πρέπει να βασίζεται σε κάποιο πρότυπο (το οποίο συνήθως είναι

κάποιο διεθνές πρότυπο ποιότητας, αλλά µπορεί να είναι και κάποιο υβριδικό πρό-

τυπο εξειδικευµένο για χρήση στη συγκεκριµένη επιχείρηση) το οποίο παρέχει οδη-

γίες για την εφαρµογή του συστήµατος ποιότητας. Το σύστηµα ποιότητας αποτε-

λείται από δοµές, δραστηριότητες, αρµοδιότητες, διαδικασίες, πόρους, µετρικές και

εργαλεία µέτρησης, τα οποία χρησιµοποιούνται για να διασφαλίσουν ότι τα έργα

λογισµικού που αναπτύσσονται εκπληρώνουν τους ποιοτικούς παράγοντες οι οποί-

οι είναι επιθυµητοί τόσο από τον πελάτη, όσο και από την επιχείρηση. Οι συγκε-

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

ποιότητας (quality manual). Ότι συµπεριλαµβάνεται στο εγχειρίδιο ποιότητας δεν

είναι απαραίτητο ότι θα χρησιµοποιηθεί σε κάθε έργο.

Είναι κοινή αρµοδιότητα του υπεύθυνου ποιότητας (quality manager) και του υπεύ-

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

τας κάθε έργου. Το πλάνο ποιότητας έργου (project quality plan) είναι συγκεκρι-

µένο για κάθε έργο και περιγράφει αυτά τα ποιοτικά χαρακτηριστικά στην εξασφά-

λιση των οποίων επικεντρώνει το ενδιαφέρον του το συγκεκριµένο έργο, καθώς και

τις διαδικασίες και µετρικές για τη διασφάλισή τους. Όµως, εκτός από τα ειδικά ποι-

οτικά χαρακτηριστικά τα οποία ενσωµατώνονται στο πλάνο ποιότητας, θα πρέπει να

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

διασφάλιση της «ελάχιστης αποδεκτής ποιότητας», όπως αυτή καθορίζεται από το

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

ποιοτικών χαρακτηριστικών τα οποία θα πρέπει να βρίσκονται οπωσδήποτε πάνω

από καθορισµένα όρια, ανεξάρτητα από τα υπόλοιπα χαρακτηριστικά στα οποία δίνει

έµφαση το πλάνο εξασφάλισης ποιότητας του συγκεκριµένου έργου.

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

Το εγχειρίδιο

ποιότητας

συγκεντρώνει όλεςτις δοµές, τις δρα-

στηριότητες, τιςαρµοδιότητες, τιςδιαδικασίες, τουςπόρους, τις µετρι-

κές και τα εργαλείαµέτρησης που ηεπιχείρηση έχει

συµπεριλάβει στοσύστηµα ποιότητας

και που είναιδυνατόν να χρησι-µοποιηθούν για τηδιασφάλιση ή τον

έλεγχο της ποιότη-τας κάποιου έργου.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 110

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

ποιοτικά χαρακτηριστικά στα οποία δίνει έµφαση το έργο. Για παράδειγµα, στο

πλάνο ποιότητας ενός έργου, το οποίο η επιχείρηση σκοπεύει να εξελίξει µελλοντι-

κά και να εκδώσει και σε άλλες πλατφόρµες (λειτουργικών συστηµάτων ή υλικού)

θα δοθεί έµφαση στα ποιοτικά χαρακτηριστικά της «µεταφερσιµότητας» και της

«συντηρησιµότητας». Αντίθετα, στο πλάνο εξασφάλισης ποιότητας ενός έργου, το

οποίο υλοποιείται για την προσωρινή κάλυψη αναγκών του πελάτη και χωρίς να

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

ση σε ποιοτικούς παράγοντες όπως η «µεταφερσιµότητα» και η «συντηρησιµότη-

τα», µπορεί όµως να δοθεί έµφαση σε παράγοντες όπως για παράδειγµα η «ευχρη-

στία». Σε κάθε περίπτωση και τα δύο πλάνα εξασφάλισης ποιότητας θα πρέπει να

περιέχουν έναν αριθµό ποιοτικών χαρακτηριστικών, τα οποία θα απαιτείται από το

πρόγραµµα ποιότητας να ελέγχονται για κάθε έργο.

Τέλος, το εγχειρίδιο ποιότητας δεν πρέπει να µένει στάσιµο, αλλά να εξελίσσεται

µαζί µε την επιχείρηση. Αυτό συµβαίνει, είτε γιατί τα ποιοτικά κριτήρια της επιχεί-

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

σης και ελέγχου, είτε γιατί αναθεωρούνται οι µετρικές και οι µετρήσιµοι στόχοι ανά-

λογα µε τις απόψεις των πελατών. Άµεση αρµοδιότητα του τµήµατος ποιότητας (και

φυσικά του υπευθύνου ποιότητας) είναι να ελέγχει αν οι µετρήσεις για τα ποιοτικά

χαρακτηριστικά αντικατοπτρίζονται στην άποψη των πελατών για τα ίδια ποιοτικά

χαρακτηριστικά. Στην περίπτωση διαφορών πιθανότατα το σύστηµα ποιότητας χρει-

άζεται αλλαγές οι οποίες σχετίζονται είτε µε την αξιοπιστία των µετρικών, είτε µε

τις διαδικασίες µέτρησης.

Είναι σηµαντικό σε αυτό το σηµείο να αναφέρουµε ότι κυριαρχούν δυο βασικές

εσφαλµένες απόψεις σχετικές µε το σύστηµα ποιότητας στο λογισµικό, οι οποίες

πρέπει να ξεπεραστούν. Η πρώτη εσφαλµένη άποψη θεωρεί πως ένα εγχειρίδιο ποι-

ότητας είναι αρκετό για να διασφαλίσει την ποιότητα σε κάθε έργο. Το πρόβληµα

µε αυτή την άποψη έγκειται στο γεγονός ότι κανείς δεν υποχρεώνει τους υπεύθυνους

ενός έργου να τηρήσουν τους κανόνες του εγχειριδίου, είτε γιατί το τµήµα ποιότη-

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

επισηµάνσεις του αγνοούνται κάτω από την πίεση για την τήρηση των προθεσµιών

των έργων.

Η δεύτερη εσφαλµένη άποψη θεωρεί ότι για να είναι ένα λογισµικό ποιοτικό, αρκεί

να ικανοποιεί τον ορισµό της ποιότητας «κατάλληλο για τον προορισµό του». Το λογι-

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

τει και κάποια, επιπλέον, ποιοτικά χαρακτηριστικά, τα οποία µπορεί να περιγράφο-

1 1 14 . 2 ™ À ™ ∆ ∏ ª ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

Υπεύθυνος

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

Το πλάνο

ποιότητας είναισυγκεκριµένο γιακάθε έργο και είναιτο υποσύνολο τουεγχειριδίου ποιότη-τας που έχει κριθείότι εξυπηρετεί τουςστόχους ποιότηταςτου συγκεκριµένουέργου.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 111

1 1 2 K E º A § A I O 4 : ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

νται στον προσδιορισµό των απαιτήσεων, να βασίζονται σε κοινωνικές παραδοχές ή

να σχετίζονται µε τους στόχους της επιχείρησης. Ο προσδιορισµός των απαιτήσεων

περιέχει µια περιγραφή του τι µπορεί να κάνει το λογισµικό, καθώς επίσης και περιο-

ρισµούς, όπως ο χρόνος απόκρισης, που πρέπει να συµπεριληφθούν στο πλάνο ποι-

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

κούς και που δεν έχουν απασχολήσει τους πελάτες και δεν αναγράφονται στον προσ-

διορισµό των απαιτήσεων (για παράδειγµα η ικανότητα του λογισµικού να επανα-

χρησιµοποιηθεί) πρέπει και αυτοί να συµπεριληφθούν στο πλάνο ποιότητας.




απάντηση.


i) Τα πρότυπα κωδικοποιούνται µε τα αρχικά ISO

ακολουθούµενα από ένα αριθµό.

ii) Οδηγία είναι περιγραφικό κείµενο που επεξηγεί

την εφαρµογή ενός προτύπου.

iii) Η ορθή ανιχνευσιµότητα αναφέρεται στην ικανότητα

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

προδιαγραφές) των τµηµάτων του κώδικα που υλοποιούν

αυτές τις λειτουργίες, ενώ η αντίστροφη ανιχνευσιµότητα

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

υλοποιεί κάποιο τµήµα του κώδικα.

iv) Η διασφάλιση ποιότητας προϊόντος στοχεύει έµµεσα

στη διασφάλιση ποιότητας διαδικασιών και πόρων.

v) Το εγχειρίδιο ποιότητας είναι διαφορετικό για κάθε

έργο λογισµικού.

vi) Το πλάνο ποιότητας εξελίσσεται δυναµικά καθώς

εξελίσςεται και η επιχείρηση.

vii) Ένα εγχειρίδιο ποιότητας είναι αρκετό για να διασφαλίσει

την ποιότητα σε κάθε έργο.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 112

4.2.2 ÃÚ‹ÛÙÂ˜ ÙÔ˘ Û˘ÛÙ‹Ì·ÙÔ˜ ÔÈfiÙËÙ·˜

Στην ενότητα 1.3 του κεφαλαίου 1 µιλήσαµε για τους ανθρώπους που σχετίζονται

µε την ανάπτυξη λογισµικού. Σε αυτή την ενότητα παρουσιάζεται τι προσφέρει

[Inc95] το σύστηµα ποιότητας στον υπεύθυνο έργου, στους προγραµµατιστές, στους

µηχανικούς που έχουν αναλάβει τη σχεδίαση, τον έλεγχο ή τη συντήρηση του λογι-

σµικού, στον αναλυτή, καθώς και στον πελάτη.

Το σύστηµα ποιότητας πρέπει να διευκολύνει τον υπεύθυνο έργου στη διαδικασία

της εκτίµησης παραγόντων όπως οι ανάγκες σε ανθρώπινο δυναµικό, το κόστος και

ο χρόνος και ανάλυσης κινδύνου. Θα πρέπει να διαθέτει έναν κατάλογο που να ανα-

φέρει τους παράγοντες εκείνους που θα µπορούσαν να κάνουν το πρόγραµµα να απο-

τύχει ως προς τα χρονικά περιθώρια ή τον προϋπολογισµό του. Θα πρέπει, επίσης,

να καθορίζει τη διαδικασία καταγραφής των δεδοµένων του έργου µε τυποποιηµέ-

νη µορφή, έτσι ώστε τα ιστορικά δεδοµένα από προηγούµενα έργα να υπάρχουν

καταγεγραµµένα σε εύκολα επεξεργάσιµη τυποποιηµένη µορφή, ώστε ο διαχειρι-

στής ποιότητας να µπορεί να βασίζει την εκτίµησή του για µελλοντικά έργα σε αυτά

τα δεδοµένα. Ακόµα, το εγχειρίδιο ποιότητας θα πρέπει να προδιαγράφει έναν τρόπο,

ώστε να συλλέγονται και να αναλύονται στατιστικά δεδοµένα που αφορούν σε λάθη

ή ατέλειες και τη σοβαρότητά τους για το λογισµικό. Επίσης, το σύστηµα ποιότητας

θα πρέπει να προσδιορίζει έναν οµοιόµορφο τρόπο µε τον οποίο το προσωπικό θα

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

θηση του έργου. Τέλος, το σύστηµα ποιότητας πρέπει να προδιαγράφει την υποβο-

λή αναφορών σχετικά µε τους στόχους που επιτεύχθηκαν έναντι των στόχων που

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

Αναφορικά µε τον προγραµµατιστή, το σύστηµα ποιότητας πρέπει να θέτει πρότυ-

πα προγραµµατισµού που ορίζουν τον τρόπο µε τον οποίο ένα πρόγραµµα πρέπει να

αναπτυχθεί (κωδικοποιηθεί) και να παρουσιαστεί. Ένα καλό πρότυπο ποιότητας θα

πρέπει (µε την τυποποίηση που θα επιφέρει) να βοηθά τον προγραµµατιστή να δια-

βάζει πηγαίο κώδικα και να κατανοεί εύκολα τη συνεισφορά κάθε κοµµατιού του

πηγαίου κώδικα στο γενικό, µεγάλο τµήµα του λογισµικού που εξετάζεται. Ακόµα,

το εγχειρίδιο ποιότητας πρέπει να εµπεριέχει οδηγίες προς τον προγραµµατιστή για

το πώς να αποθηκεύει τα δεδοµένα ελέγχου. Τέλος, το εγχειρίδιο ποιότητας πρέπει

να παρέχει στον προγραµµατιστή ένα πρότυπο που να διασφαλίζει ότι τα ονόµατα

και οι µεταβλητές που έχει χρησιµοποιήσει συµφωνούν µε τα αρχεία που χρησιµο-

ποιήθηκαν για να αποθηκεύσουν τον πηγαίο κώδικα, το αντικείµενο του κώδικα και

τα δεδοµένα ελέγχου.

1 1 34 . 2 ™ À ™ ∆ ∏ ª ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 113

1 1 4 K E º A § A I O 4 : ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

Το σύστηµα ποιότητας πρέπει να παρέχει ένα πρότυπο που να καθορίζει τον τρόπο

περιγραφής της αρχιτεκτονικής του συστήµατος από το σχεδιαστή. Επίσης το εγχει-

ρίδιο ποιότητας πρέπει να εµπεριέχει τυποποιηµένες διαδικασίες ανάλυσης και σχε-

δίασης. Ένα καλό πρότυπο πρέπει να βοηθά το µηχανικό σχεδίασης να ελέγχει αν

το σύστηµα που έχει σχεδιάσει πραγµατικά υλοποιεί τις λειτουργίες που περιγρά-

φονται στον προσδιορισµό των απαιτήσεων. Ιδιαίτερη έµφαση πρέπει να δίνεται στο

σχεδιασµό της διεπιφάνειας χρήστη [Abo00], παρέχοντας κανόνες και οδηγίες για

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

των χρηστών του συγκεκριµένου έργου.

Το σύστηµα ποιότητας πρέπει να επιµένει σε ένα προγραµµατιστικό πρότυπο το

οποίο εξασφαλίζει ότι οι µηχανικοί που θα αναλάβουν τη συντήρηση θα µπορούν

εύκολα να ανιχνεύσουν ποια λειτουργία εκτελείται κάθε φορά από συγκεκριµένο

τµήµα κώδικα. Ακόµα, πρέπει να παρέχει διαδικασίες που βοηθούν τους µηχανικούς

συντήρησης να εντοπίζουν και να εποπτεύουν τις διάφορες εκδόσεις του συστήµα-

τος που δηµιουργούνται κατά τη διαδικασία της συντήρησης. Τέλος, το σύστηµα ποι-

ότητας πρέπει να εξασφαλίζει (παρέχοντας διαδικασίες) ότι οι µηχανικοί του τµή-

µατος ελέγχου αποθηκεύουν εξωτερικά τα δεδοµένα που έχουν προκύψει κατά τη

διάρκεια του ελέγχου, έτσι ώστε οι συντηρητές να µην χρειάζεται να δηµιουργήσουν

καινούργια δεδοµένα για επανέλεγχο.

Το σύστηµα ποιότητας πρέπει να εξασφαλίζει ότι ο προσδιορισµός των απαιτήσεων

έχει γίνει µε τέτοιο τρόπο, ώστε οι µηχανικοί που αναλαµβάνουν τον έλεγχο να µπο-

ρούν εύκολα να παράγουν δεδοµένα και διαδικασίες ελέγχου. Ακόµα, το εγχειρίδιο

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

που ακολουθούνται για την παραγωγή δεδοµένων και αποτελεσµάτων κατά τη διάρ-

κεια του ελέγχου µπορούν να αποθηκευτούν σε µια βιβλιοθήκη, ώστε να είναι επα-

ναχρησιµοποιήσιµες. Σηµαντικό είναι επίσης το εγχειρίδιο να προβλέπει διαδικα-

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

ελέγχου για την αξιολόγησή της.

Αναφορικά µε τον αναλυτή, το σύστηµα ποιότητας πρέπει να παρέχει ένα πρότυπο

για τον προσδιορισµό των απαιτήσεων, τέτοιο που να αναδεικνύει στον οργανισµό

λειτουργίες οι οποίες είναι σχετικές µε άλλες και θα µπορούσαν να χρησιµοποιη-

θούν αυτούσιες σε παρόµοιες περιπτώσεις. Επίσης, το σύστηµα ποιότητας πρέπει να

περιλαµβάνει έναν κατάλογο που θα δίνει τη δυνατότητα στον αναλυτή να εξασφα-

λίζει ότι τα χαρακτηριστικά ενός συγκεκριµένου έργου που αναπτύσσεται θα περι-

γραφούν µε επαρκή λεπτοµέρεια. Τέλος, πρέπει να παρέχει τυποποιηµένη (αλλά όχι

σε τέτοιο βαθµό που να µην αφήνει κανένα περιθώριο ελευθερίας κατά περίπτωση)

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 114

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

σε επαφή µε τον πελάτη.

Το σύστηµα ποιότητας πρέπει να παρέχει οδηγίες για το πώς θα οργανώνονται οι

συναντήσεις µεταξύ του πελάτη και του αναλυτή ή του υπεύθυνου έργου, που θα

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

τυποποιηµένο έγγραφο που να παρέχει λεπτοµερή περιγραφή του τρόπου που οι

κατασκευαστές σκοπεύουν να ελέγξουν αν ικανοποιούνται οι απαιτήσεις του πελά-

τη. Τέλος, το σύστηµα ποιότητας πρέπει να προσδιορίσει τον τύπο των αναφορών

που θα σταλθούν στον πελάτη σχετικά µε την εξέλιξη του έργου και να καθορίζει τη

συχνότητα µε την οποία θα στέλνονται.

1 1 54 . 2 ™ À ™ ∆ ∏ ª ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À


Αντιστοιχίστε τους χρήστες της αριστερής στήλης µε τις φράσεις της δεξιάς στή-

λης που περιγράφουν τι παρέχει το σύστηµα ποιότητας. Προσέξτε ότι µία φράση

της δεξιάς στήλης αντιστοιχεί σε µία µόνο κατηγορία χρηστών, ενώ σε µία κατη-

γορία χρηστών µπορούν να αντιστοιχηθούν πολλές φράσεις που περιγράφουν τι

παρέχει το σύστηµα ποιότητας

Κατηγορίες Χρηστών Τι παρέχει το σύστηµα ποιότητας

Υπεύθυνος έργου Πρότυπα που να ορίζουν τον τρόπο µε τον οποίο

ένα πρόγραµµα πρέπει να αναπτυχθεί (κωδικο-

ποιηθεί).

Αναλυτής Πρότυπο για τον προσδιορισµό των απαιτήσεων.

Τυποποιηµένες διαδικασίες ανάλυσης και σχε-

δίασης.

Προγραµµατιστής ∆ιαδικασία καταγραφής βασικών δεδοµένων

έργου.

Κανόνες και οδηγίες για την ορθή σχεδίαση της

διεπιφάνειας χρήστη που θα είναι προσαρµοσµέ-

νη στις ανάγκες και ιδιαιτερότητες των χρηστών

του συγκεκριµένου έργου.

Σχεδιαστής Τυποποίηση αναφορών δραστηριοτήτων έργου.

Τυποποιηµένη περιγραφή της διαδικασίας επα-

φής µε τον πελάτη

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 115

1 1 6 K E º A § A I O 4 : ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

Απάντηση

Η Μαρία προτείνει να υπάρχει στο πρότυπο αναλυτική περιγραφή του τρόπου ανά-

πτυξης του κώδικα η οποία περιλαµβάνει τις παρακάτω οδηγίες:

• Στην αρχή κάθε τµήµατος του προγράµµατος πρέπει να αναφέρονται σχόλια µε

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

την ηµεροµηνία τελευταίας αναθεώρησης.

• Στην αρχή κάθε τµήµατος του προγράµµατος πρέπει να αναφέρονται σχόλια µε

τις σχέσεις αυτού του τµήµατος µε άλλα.

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

το τµήµα (µε αναφορές στα αντίστοιχα κείµενα των αρχικών προδιαγραφών).

• Κάθε µεταβλητή πρέπει να συνοδεύεται από σχόλια στο σηµείο που ορίζεται και

σε κάθε σηµείο που γίνεται αλλαγή της τιµής της.

• Κάθε προγραµµατιστική δοµή πρέπει να συνοδεύεται από σχόλια για το σκοπό

που επιτελεί.

• Για κάθε γραµµή κώδικα που δεν είναι αυτονόητη η χρήση της ή δεν έχει επεξη-

γηθεί µε άλλο τρόπο πρέπει να υπάρχει και µια γραµµή επεξηγηµατικών σχολίων.

Επίσης η Μαρία προτείνει µία τυποποίηση για τα παρακάτω:

• Καθορισµός µορφής αρχικοποιήσεων (για παράδειγµα αρχικοποιήσεις µεταβλη-

τών θα γίνονται µόνο στην αρχή του κώδικα και σε τµήµα που θα ορίζεται από

σχόλια που θα το προσδιορίζουν).

• Καθορισµός ονοµατολογίας µεταβλητών, σταθερών και τµηµάτων κώδικα (για

παράδειγµα κάθε global µεταβλητή θα έχει όνοµα που να αρχίζει από «g_» και

κάθε σταθερά από «s_», ενώ όλες οι µεταβλητές θα έχουν όνοµα τουλάχιστον 6


Η Μαρία έχει αναλάβει υπεύθυνη ποιότητας σε µία επιχείρηση που τώρα ετοιµά-

ζει το εγχειρίδιο ποιότητας και προσπαθεί να αποφασίσει τι θα συµπεριλάβει σε

αυτό. Στην παρούσα φάση της εργασίας της εξετάζει τη δηµιουργία ενός προ-

γραµµατιστικού προτύπου. Εργαστείτε ως βοηθοί της Μαρίας και προτείνετέ της

τι θα µπορούσε να συµπεριλάβει σε αυτό το πρότυπο. Γράψτε την απάντησή σας

συνοπτικά χωρίς να ξεπεράσετε τις 500 λέξεις. Μετά δείτε τι προτείνουµε εµείς

στην απάντηση που ακολουθεί.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 116

χαρακτήρων και που θα περιγράφει µε κάποιο τρόπο τη χρήση τους).

Ακόµα, η Μαρία προτείνει για λόγους σαφήνειας και αναγνωσιµότητας να αποφεύ-

γονται:

• οι δοµές που δηµιουργούν ασάφειες,

• µεγάλες και δυσανάγνωστες εκφράσεις,

• περιττές αναφορές στις global µεταβλητές,

• πολλές εµφωλεύσεις τµηµάτων κώδικα.

Τέλος, η Μαρία προτείνει κάθε τµήµα κώδικα να συνοδεύεται από τα παρακάτω

εγχειρίδια:

• Εγχειρίδιο συντήρησης (που περιγράφει αναλυτικά τις λειτουργίες που επιτε-

λούνται, τις µεταβλητές που χρησιµοποιούνται, τις προγραµµατιστικές δοµές και

τις αναθέσεις τιµών και δίνει οδηγίες για το πώς µπορεί να γίνουν αλλαγές στον

κώδικα, ποια σηµεία πρέπει να προσεχθούν, µε ποια άλλα τµήµατα του κώδικα

υπάρχει σύζευξη και τι ενέργειες πρέπει να γίνουν σε αυτά).

• Εγχειρίδιο ελέγχου (που περιγράφει πώς ελέγχθηκε το συγκεκριµένο τµήµα, τι

δεδοµένα χρησιµοποιήθηκαν αναλυτικά και πώς πρέπει να ελεγχθεί σε περίπτω-

ση αλλαγών).

Ένα τέτοιο πρότυπο σε µία επιχείρηση πρέπει να είναι πολύ λεπτοµερές και να περι-

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

είναι ένα πολυσέλιδο εγχειρίδιο που είναι άµεσα διαθέσιµο και ηλεκτρονικά στους

προγραµµατιστές, ενώ συχνά διδάσκεται σε αυτούς και µε σεµινάρια εκπαίδευσης.

Στην απάντηση σας δώσαµε τις βασικές κατευθύνσεις για αυτό.

4.2.3 √Ê¤ÏË ·fi ÙÔ Û‡ÛÙËÌ· ÔÈfiÙËÙ·˜

Η εφαρµογή ενός συστήµατος ποιότητας σε µία επιχείρηση που αναπτύσσει λογι-

σµικό εξασφαλίζει σηµαντικά οφέλη για αυτή. Τα σηµαντικότερα από αυτά παρου-

σιάζονται συνοπτικά παρακάτω:

• Μείωση κόστους παραγωγής (κυρίως λόγω της ελαχιστοποίησης απωλειών από

τη µείωση της χαµένης ή επαναλαµβανόµενης εργασίας και τη µείωση λαθών).

• Μείωση δαπανηρών και χρονοβόρων φάσεων παραγωγής (µείωση του χρόνου

που δαπανάται για έλεγχο και διορθωτική συντήρηση).

• Καλύτερη οργάνωση της επιχείρησης (που επιτυγχάνεται µε την καταγραφή και

1 1 74 . 2 ™ À ™ ∆ ∏ ª ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 117

1 1 8 K E º A § A I O 4 : ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

εφαρµογή τυποποιηµένων διαδικασιών παραγωγής και τη χρήση προτύπων που

τυποποιούν τη διαδικασία ανάπτυξης).

• ∆υνατότητα παρακολούθησης (monitoring) έργων (που µεταφράζεται σε αύξηση

της παραγωγικότητας, καλύτερη αξιοποίηση πόρων, αποφυγή λανθασµένων κατευ-

θύνσεων στα έργα και σωστή αξιοποίηση των δυνατοτήτων του προσωπικού).

• Καλά και µε ακρίβεια καθορισµένες αρµοδιότητες και ευθύνες για κάθε µέλος

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

επιχείρηση.

• Ανεξαρτητοποίηση της επιχείρησης από τα άτοµα (που επιτυγχάνεται µε την τυπο-

ποίηση των διαδικασιών ανάπτυξης και τη χρήση προγραµµατιστικών προτύπων).

• ∆ηµιουργία αποθεµατικού στην επιχείρηση (καλογραµµένα και κατανοήσιµα τµή-

µατα κώδικα, σχολιασµένα και µε επαρκή τεκµηρίωση που έχουν υλοποιηθεί µε

βάση κάποιο πρότυπο και είναι άµεσα επαναχρησιµοποιήσιµα).

• Καταγραφή και τεκµηρίωση της πορείας (επιτυχία ή αποτυχία) κάθε έργου και

δηµιουργία αρχείου δεδοµένων που µπορεί να χρησιµοποιηθεί στις διαδικασίες

εκτίµησης παραγόντων όπως οι ανάγκες σε ανθρώπινο δυναµικό, το κόστος και

ο χρόνος µελλοντικών έργων.

• Καλύτερη οργάνωση των µελλοντικών στόχων της επιχείρησης που βασίζεται

στην καταγραφή των επιτυχιών, προβληµάτων και δυνατοτήτων της.

• Καλύτερη επαφή µε τον πελάτη (που βασίζεται σε καθορισµένες διαδικασίες επι-

κοινωνίας που είναι κοινοποιηµένες και στον πελάτη).




απάντηση.


i) Η ανεξαρτητοποίηση της επιχείρησης από τα άτοµα

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

προγραµµατιστών.

ii) Ένα σύστηµα ποιότητας βοηθά στην καλύτερη επαφή

µε τον πελάτη, αφού βασίζεται σε καθορισµένες

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 118

1 1 94 . 2 ™ À ™ ∆ ∏ ª ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

διαδικασίες επικοινωνίας που είναι κοινοποιηµένες

και στον πελάτη.

iii)Η δηµιουργία αποθεµατικού στην επιχείρηση σχετίζεται

µε την παραγωγή µεγάλων ποσοτήτων κώδικα.

iv) Η µείωση δαπανηρών και χρονοβόρων φάσεων παραγωγής

αναφέρεται στη µείωση των φάσεων ανάλυσης απαιτήσεων

και σχεδίαςης.

v) Ένα σύστηµα ποιότητας βοηθά στην καλύτερη οργάνωση

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

και εφαρµογή τυποποιηµένων διαδικασιών παραγωγής

και µε τη χρήση προτύπων που τυποποιούν τη διαδικασία

ανάπτυξης.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 119

1 2 0 K E º A § A I O 4 : ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À


Στο κεφάλαιο µιλήσαµε για την ποιότητα λογισµικού, εισάγοντας τις έννοιες των

παραγόντων ποιότητας και των ποιοτικών χαρακτηριστικών και παρουσιάσαµε τα

πιο διαδεδοµένα µοντέλα ποιότητας λογισµικού µε έµφαση στο πρότυπο ISO 9126.

Επίσης παρουσιάσαµε το σύστηµα ποιότητας λογισµικού, επεξηγώντας τις διαφορές

ανάµεσα στο εγχειρίδιο και στο πλάνο ποιότητας. Μιλήσαµε για διαδικασίες και πρό-

τυπα ποιότητας, αναφέραµε τις µετρικές (για τις οποίες θα µιλήσουµε στο επόµενο

κεφάλαιο) και τους χρήστες του συστήµατος ποιότητας, καθώς και τα οφέλη µιας επι-

χείρησης από την εφαρµογή ενός συστήµατος ποιότητας.

Σε αρκετά σηµεία του κεφαλαίου δεν επεκταθήκαµε σε λεπτοµερή παρουσίαση κάποι-

ων µοντέλων ή στην εφαρµογή του συστήµατος ποιότητας για κάθε φάση της παρα-

γωγής, αφήνοντάς σας να τις µελετήσετε από µόνοι σας. Σε αυτό το σηµείο πρέπει να

σας βοηθήσει και η βιβλιογραφία που ακολουθεί. Γενικά, η συµβουλή µας είναι να

ανατρέχετε και σε βιβλιογραφικές πηγές πέρα από το βιβλίο αυτό, ώστε να εµπλου-

τίζετε τις γνώσεις σας, αλλά και να µελετήσετε εναλλακτικές απόψεις για την ύλη που

καλύψαµε. Ακολουθεί βιβλιογραφία µε προτεινόµενα βιβλία για περαιτέρω µελέτη

στα οποία σας υποδεικνύουµε πού να επικεντρώσετε την προσοχή σας.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 120







[Abo00] Νικόλαος Αβούρης, «Εισαγωγή στην Επικοινωνία Ανθρώπου – Υπολογι-

στή», Εκδόσεις ∆ΙΑΥΛΟΣ, (2000).

Είναι ένα βιβλίο που ακολουθεί τη λογική της εκπαίδευσης από απόσταση (είναι

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

χρήσιµο στη µελέτη σας. Στο κεφάλαιο 1 θα διαβάσετε για την ευχρηστία (επίσηµο

ορισµό από το πρότυπο ISO 9241) και για τη διεπιφάνεια χρήστη, ενώ στο κεφάλαιο

4 θα διαβάσετε για τα διάφορα στυλ αλληλεπίδρασης στη διεπιφάνεια χρήστη ενός

συστήµατος. Τέλος, στα κεφάλαια 6 και 7 θα βρείτε οδηγίες και κανόνες για τη σχε-

δίαση τέτοιων συστηµάτων.

[Boe78] B. Boehm et al., «Characteristics of Software Quality», North Holland,

(1978).

[Fen97] N. Fenton and S. Pfleeger, «Software Metrics A Rigorous & Practical

Approach», Thomson Computer Press, (1997).

Το βιβλίο εξειδικεύεται στις µετρήσεις και µετρικές (για τις οποίες θα µιλήσουµε

στο επόµενο κεφάλαιο). Στα κεφάλαια 13, 14 και 15 παρουσιάζει πώς εντάσσονται

οι µετρήσεις στα πλαίσια ενός συστήµατος ποιότητας.

[Gar84] David Garvin, «What Does Product Quality Really Mean?», Sloan

Management Review, Fall, (1984).



Είναι ένα εύκολο στην ανάγνωση εισαγωγικό βιβλίο στην ποιότητα λογισµικού. Ο

Ince (που είναι καθηγητής στο αγγλικό Open University) έχει γράψει το βιβλίο του

ακολουθώντας κανόνες εκπαίδευσης από απόσταση, οπότε θα το βρείτε αρκετά εύκο-

λο στη µελέτη. Στα κεφάλαια 1 και 2 παρουσιάζεται το σύστηµα ποιότητας και οι

χρήστες του (για τους οποίους µιλήσαµε στην ενότητα 4.2.2). Τα κεφάλαια 3 – 10

περιγράφουν τι προσφέρει το σύστηµα ποιότητας στις διάφορες φάσεις ανάπτυξης

λογισµικού (το θέµα της ενότητας 4.2.3 του βιβλίου αυτού), ενώ αναλύονται θέµα-

τα σχετικά µε µετρικές (κεφάλαιο 11) και για πρότυπα ποιότητας (κεφάλαια 13 και

1 2 1µ π µ § π √ ° ƒ∞ º π ∞ ∫ ∞ π ¶ ƒ √ ∆∞ ™ ∂ π ™ ° π ∞ ¶ ∂ ƒ∞ π ∆ ∂ ƒ ø ª ∂ § ∂ ∆ ∏

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 121

1 2 2 K E º A § A I O 4 : ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

14). Είναι ένα βιβλίο που σας το προτείνω ανεπιφύλακτα, αν θέλετε να µελετήσετε

σε βάθος κάποια θέµατα που καλύψαµε στο κεφάλαιο 4.

[Iso91] ISO, «Information technology≠.– Evaluation of software – Quality

characteristics and guides for their use», International Standard, ISO/IEC 9126:

(1991).

[Kap95] C. Kaplan et al., «Secrets of Software Quality», McGraw Hill, (1995).

Είναι ένα βιβλίο που δίνει περισσότερο έµφαση στην πράξη από τη θεωρία. Παρου-

σιάζονται οι εµπειρίες από την εφαρµογή ενός συστήµατος ποιότητας στην IBM. Το

βιβλίο ακολουθεί τη λογική της ποιότητας κατά τα βραβεία Malcom Baldrige (είναι

βραβεία ποιότητας στην Αµερική), αλλά αυτό δεν θα σας ξενίσει και θα µπορέσετε

εύκολα να το παρακολουθήσετε. Νοµίζω ότι είναι ένα από τα καλύτερα βιβλία για

κάποιον που θέλει να δει τι συµβαίνει στην πράξη σε µία µεγάλη επιχείρηση που

αναπτύσσει λογισµικό ακολουθώντας ένα σύστηµα ποιότητας.

[Kit96] B. Kitchenham and S. Pfleeger, «Software Quality: The Elusive Target»,

IEEE Software, January, (1996).

[Mcc77] J. A. McCall et al., «Factors in Software Quality, Vols I, II, III», US Rome Air

Development Center Reports NTIS AD/A – 049 014, 015, 055, (1977).

[Xen96] Μιχάλης Ξένος, «Μεθοδολογία ελέγχου και εξασφάλισης της ποιότητας λογι-

σµικού βασισµένη στις µετρικές προϊόντος και στα εξωτερικά ποιοτικά χαρακτη-

ριστικά του λογισµικού», ∆ιδακτορική ∆ιατριβή, Πανεπιστήµιο Πατρών, (1996).

Αν και από το 2ο κεφάλαιο η διατριβή εξειδικεύεται, στο 1ο εισαγωγικό κεφάλαιο

θα βρείτε µια περίληψη όλων των θεµάτων που καλύψαµε σε αυτό και στο προη-

γούµενο κεφάλαιο.

[Yeh93] H. T. Yeh, «Software Process Quality», McGraw Hill, (1993).

Είναι ένα βιβλίο που αναφέρεται στις διαδικασίες ποιότητας λογισµικού. Στο κεφά-

λαιο 1 θα βρείτε εισαγωγικές έννοιες για την ποιότητα και τις διαδικασίες ποιότη-

τας και στα κεφάλαια 4,5 και 6 τεχνικές διασφάλισης ποιότητας διαδικασιών. Ενδια-

φέρον είναι και το τµήµα 2 του βιβλίου (κεφάλαια 7 – 9) που παρουσιάζει ένα παρά-

δειγµα πρακτικής εφαρµογής των προηγουµένων.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 122

ªÂÙÚ‹ÛÂÈ˜ Î·È ªÂÙÚÈÎ¤˜ ¶ÔÈfiÙËÙ·˜ §ÔÁÈÛÌÈÎÔ‡

™ÎÔfi˜

Σκοπός του κεφαλαίου 5 είναι η εισαγωγή στις µετρήσεις, που διεξάγονται στα πλαί-

σια ενός συστήµατος ποιότητας λογισµικού, µε τη χρήση µετρικών και η παρουσία-

ση επιλεγµένων µετρικών και τρόπων µέτρησης.



• περιγράψετε τους όρους µέτρο και µετρική και να αναλύσετε τις διαφορές τους,

• ορίσετε τα εσωτερικά και εξωτερικά χαρακτηριστικά του λογισµικού, τις εσωτερι-

κές και εξωτερικές µετρικές και την ερµηνεία της µετρικής,

• ορίσετε τις έννοιες των µετρικών διαδικασίας, πόρων και προϊόντος και να περι-

γράψετε τα ερωτήµατα στα οποία δίνουν απαντήσεις µε τη χρήση τους,

• περιγράψετε τον τρόπο εφαρµογής των εσωτερικών µετρήσεων,

• διεξάγετε µετρήσεις που να βασίζονται σε µετρικές µεγέθους και µετρικές κυκλω-

µατικής πολυπλοκότητας,

• περιγράψετε τα πλεονεκτήµατα και τα µειονεκτήµατα της χρήσης εσωτερικών

µετρήσεων και µετρικών,

• ορίζετε τις εξωτερικές µετρήσεις και να αναφέρετε τις κατηγορίες των εξωτερικών

µετρήσεων για ποιοτικά χαρακτηριστικά που αφορούν στον τελικό χρήστη,

• περιγράψετε τα πλεονεκτήµατα και τα µειονεκτήµατα της χρήσης εξωτερικών

µετρήσεων και µετρικών.


5∫ ∂ º ∞ § ∞ π √

• Μέτρηση (Measurement)

• Μετρική (Metric)

• Μέτρο (Measure)

• Εσωτερικά χαρακτηριστικά λογισµι-

κού (Internal software

characteristics)

• Εξωτερικά χαρακτηριστικά λογισµι-

κού (External software

characteristics)

• Ερµηνεία µετρικής (Metric

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 123

1 2 4 K E º A § A I O 5 : ª ∂ ∆ ƒ ∏ ™ ∂ π ™ ∫ ∞ π ª ∂ ∆ ƒ π ∫ ∂ ™ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

interpretation)

• Εσωτερικές µετρικές (Internal

metrics)

• Εξωτερικές µετρικές (External

metrics)

• Μετρικές διαδικασίας (Process

metrics)

• Μετρικές πόρων (Resource metrics)

• Μετρικές προϊόντος (Product

metrics)

• Γράφηµα ∆ιασποράς (Scatter plot)

• Κυκλωµατική πολυπλοκότητα

(Cyclomatic complexity)

• Γράφος ροής (Flow graph)

• Αναλυτικές µέθοδοι (Analytic

methods)

• Πειραµατικές µέθοδοι

(Experimental methods)

• ∆ιερευνητικές µέθοδοι (Inquiry

methods)


Στο προηγούµενο κεφάλαιο µιλήσαµε για την ποιότητα λογισµικού και αναφέραµε ότι

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

δείγµατα µετρικών και παρουσιάζουµε µετρήσεις µε χρήση επιλεγµένων µετρικών,

δίνοντας έµφαση στις εσωτερικές µετρικές και παρουσιάζοντας τις βασικές αρχές των

εξωτερικών µετρικών. Ειδικότερα, στην ενότητα 5.1 µε τίτλο µετρήσεις και µετρικές,

παρουσιάζουµε τις βασικές έννοιες που σχετίζονται µε τις µετρικές και κατηγοριο-

ποιούµε τις µετρικές σε εσωτερικές και εξωτερικές, ανάλογα µε τα χαρακτηριστικά

που µετρούν, ή σε µετρικές διαδικασιών, πόρων και προϊόντος ανάλογα µε το στόχο

του συστήµατος ποιότητας. Στην ενότητα 5.2 µε τίτλο εσωτερικές µετρήσεις και µετρι-

κές λογισµικού, δίνονται παραδείγµατα (υπό µορφή δραστηριοτήτων) από µετρήσεις

που βασίζονται στις γραµµές κώδικα και στην κυκλωµατική πολυπλοκότητα. Στην

ενότητα 5.3 µε τίτλο εξωτερικές µετρήσεις και µετρικές λογισµικού, παρουσιάζεται η

φιλοσοφία των εξωτερικών µετρήσεων και οι κατηγορίες των µεθόδων µέτρησης των

ποιοτικών χαρακτηριστικών που αφορούν στους τελικούς χρήστες και τέλος στην ενό-

τητα 5.4 συζητούµε τη συσχέτιση ανάµεσα στις εσωτερικές και εξωτερικές µετρικές


Για τα περισσότερα σηµεία που καλύπτουµε στο κεφάλαιο αυτό, σας παραθέτουµε

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

όπου µπορείτε να βρείτε και σύντοµες οδηγίες για το πού να αναζητήσετε τι και τι

µπορείτε να διαβάσετε επιπλέον.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 124

5.1 ªÂÙÚ‹ÛÂÈ˜ Î·È ÌÂÙÚÈÎ¤˜

Όπως αναφέραµε και στο 3ο κεφάλαιο, η ποιότητα λογισµικού είναι συνυφασµένη µε

την έννοια των µετρήσεων. Αναφέραµε ότι αντικείµενο των µετρήσεων δεν είναι η

µέτρηση των οντοτήτων, αλλά η µέτρηση των ιδιοτήτων των οντοτήτων. Επίσης,

δώσαµε τον ορισµό της µέτρησης (measurement). Στη βιβλιογραφία αναφέρονται οι

όροι µετρική (metric) και µέτρο (measure). Ο ορισµός της µετρικής [Fen97] δίνεται

δίπλα. Αν και πολλά βιβλία θεωρούν τους όρους ισοδύναµους, συνήθως ο όρος µετρι-

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

µήκος γραµµών κώδικα, ή η κυκλωµατική πολυπλοκότητα (που θα περιγραφεί στα

πλαίσια αυτής της ενότητας), ενώ ο όρος µέτρο χρησιµοποιείται για συσχετισµούς ιδιο-

τήτων και για την πρόβλεψη πιο πολύπλοκων χαρακτηριστικών όπως για παράδειγµα

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

ρουµε ότι: «η µετρική V(g) είναι ένα µέτρο της πολυπλοκότητας». Τιµές σε µετρικές

ανατίθενται µε τη διαδικασία της µέτρησης, ενώ συσχετισµοί µετρικών και αποτελέ-

σµατα που προκύπτουν από µετρήσεις παρέχουν πληροφορίες για κάποια µέτρα.

Η χρήση µέτρων και µετρικών, στην τεχνολογία λογισµικού, έρχεται να λύσει το

βασικό πρόβληµα του λογισµικού, που σχετίζεται µε την αδυναµία καθορισµού

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

για παράδειγµα, πως ένα πρόγραµµα θα είναι «αξιόπιστο», «φιλικό προς το χρήστη»

και «συντηρήσιµο», χωρίς να προσδιορίζουµε µε µετρήσιµες ποσότητες τι σηµαίνει

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

είναι φυσιολογική συνέπεια. Όπως ορίζει ο Gilb [Gil87]: «το µόνο ξεκάθαρο για έργα

που δεν έχουν ξεκάθαρους στόχους, είναι πως δε θα πετύχουν τους στόχους τους». Επί-

σης, αποτυγχάνουµε να εκτιµήσουµε βασικά ποσοτικά χαρακτηριστικά που σχετί-

ζονται µε το έργο, όπως για παράδειγµα το χρόνο που απαιτείται για τη µεταφορά

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

όπως είναι ο «αριθµός αποτυχιών σε δεδοµένη χρονική περίοδο». Αντίθετα, αν κανείς

δει τις διαφηµίσεις εµπορικού λογισµικού θα διαβάσει πληθώρα διαφηµιστικών σλό-

γκαν που µιλάνε για «µείωση του χρόνου συντήρησης κατά 80%», «αυξηµένη αξιο-

πιστία κατά 75%» κτλ, χωρίς την παραµικρή ένδειξη για το πώς προκύπτουν αυτοί

οι αριθµοί και βάσει ποιων µετρικών.

Οι πρώτες µετρικές λογισµικού παρουσιάστηκαν προς το τέλος της δεκαετίας του

70. Εκείνη την περίοδο δηµοσιεύθηκαν οι πρώτες εργασίες σχετικά µε τις µετρικές

λογισµικού, όπως αυτή του Halstead [Hal75] και του McCabe [Mcb76]. Οι δύο αυτές

πρωτοποριακές εργασίες στον τοµέα της εξασφάλισης ποιότητας, θεωρούνται ως το

έναυσµα για τη θεωρία των µετρήσεων και µετρικών και είναι σίγουρα οι εργασίες

1 2 55 . 1 ª ∂ ∆ ƒ ∏ ™ ∂ π ™ ∫ ∞ π ª ∂ ∆ ƒ π ∫ ∂ ™

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

Μετρική είναιµια εµπειρικήαντικειµενικήαντιστοίχησηενός αριθµού (ήσυµβόλου) σε µιαοντότητα µεστόχο να χαρα-κτηρίσει ένασυγκεκριµένοχαρακτηριστικότης οντότηταςαυτής.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 125


µε τις περισσότερες αναφορές στην επιστήµη της ποιότητας λογισµικού. Παρόλα

αυτά, καµία από τις δύο δεν παρουσίαζε τις µετρικές µε στόχο τη διασφάλιση ποιό-

τητας, αφού οι µετρικές του Halstead είχαν ως πρωταρχικό σκοπό την εκτίµηση του

µεγέθους µελλοντικών έργων και η εργασία του McCabe την ανάλυση της φάσης

ελέγχου των µονοπατιών του κώδικα. Η αξία και των δύο επιβεβαιώθηκε από τις

πρώτες συσχετίσεις [Fun76] [Fit78] των µετρήσεών τους µε στοιχεία όπως οι ανα-

φορές λαθών (defect reports). Τις δύο αυτές µετρικές ακολούθησε ένας µεγάλος αριθ-

µός µετρικών που προτάθηκαν τα επόµενα χρόνια και συνεχίζουν να προτείνονται

ακόµα και σήµερα, οι οποίες µετρούν σχεδόν τα πάντα.

Στην πλειοψηφία τους οι µετρικές που προτάθηκαν περιορίζονται στη µέτρηση µεµο-

νωµένων εσωτερικών χαρακτηριστικών (internal characteristics) του λογισµικού,

χωρίς να προτείνουν τρόπους συσχέτισης µε τα εξωτερικά χαρακτηριστικά

(external characteristics) του λογισµικού που η µέτρησή τους είναι ο σκοπός του

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

οι γραµµές κώδικα (LOC), για τις οποίες µιλήσαµε στο 2ο κεφάλαιο. Τα εσωτερικά

χαρακτηριστικά µετρούνται εύκολα, αλλά δεν προσφέρουν πληροφορίες υψηλού επι-

πέδου που σχετίζονται µε την ποιότητα του προϊόντος. Παραδείγµατα εξωτερικών

χαρακτηριστικών είναι η αξιοπιστία και η ευχρηστία. Αυτά τα χαρακτηριστικά είναι

δύσκολο έως αδύνατο να µετρηθούν άµεσα. Ακριβώς επειδή η χρήση των µετρικών

γινόταν µε στόχο τη µέτρηση των εσωτερικών χαρακτηριστικών, χωρίς να υπάρχει

σύνδεση των µετρήσεων µε τα εξωτερικά χαρακτηριστικά, αυτό είχε ως αποτέλε-

σµα, κάποιες φορές, η χρήση των µετρικών να γίνεται χωρίς σκοπό και όπως ανα-

φέρει ο Hambling [Ηam96], µε το σκεπτικό «να µετρήσουµε οτιδήποτε, µε την ελπί-

δα ότι κάποιες τουλάχιστον από τις µετρήσεις θα είναι χρήσιµες». Έλειπε δηλαδή

αυτό που ορίζουµε ως ερµηνεία µετρικής (metric interpretation), δηλαδή η χρήση

των αποτελεσµάτων της µέτρησης για την εξαγωγή συµπερασµάτων για κάποια από

τα εξωτερικά χαρακτηριστικά του λογισµικού.

Υπάρχουν διάφορες κατηγοριοποιήσεις των µετρικών. ∆ύο από τις πιο διαδεδοµέ-

νες κατηγοριοποιήσεις είναι:

α) ανάλογα µε τα χαρακτηριστικά που µετρούν, οπότε κατηγοριοποιούνται ως εσω-

τερικές και εξωτερικές µετρικές, και

β) ανάλογα µε το στόχο του συστήµατος ποιότητας µε τον οποίο σχετίζονται, (βλέπε

ενότητα 4.2.1) οπότε κατηγοριοποιούνται [Fen97] ως µετρικές διαδικασίας, µετρι-

κές πόρων και µετρικές προϊόντος.

Σύµφωνα µε την πρώτη κατηγοριοποίηση, αντίστοιχα µε τα εσωτερικά και τα εξω-

Εσωτερικά

χαρακτηριστικά

λογισµικού είναι ταχαρακτηριστικά του

λογισµικού για ταοποία υπάρχει απτή

φυσική αντίληψηκαι άµεσος τρόπος

µέτρησης.

Εξωτερικά

χαρακτηριστικά

λογισµικού είναι ταχαρακτηριστικά του

λογισµικού πουχαρακτηρίζονται

από υψηλό επίπεδοαφαίρεσης, τα

οποία συνθέτουντην ποιότητα του


Ερµηνεία

µετρικής

είναι ο καθορισµόςτου βαθµού συσχέ-τισης της µετρικήςαυτής µε κάποιο ήκάποια εξωτερικά

χαρακτηριστικά τουλογισµικού.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 126

τερικά ποιοτικά χαρακτηριστικά, ορίζουµε τις εσωτερικές µετρικές (internal

metrics) και τις εξωτερικές µετρικές (external metrics). Έτσι, οι εσωτερικές µετρι-

κές µετρούν χαρακτηριστικά όπως οι γραµµές κώδικα, το ποσοστό σχολίων στον

κώδικα, ο αριθµός των «goto» εντολών σε µία συνάρτηση, το βάθος δέντρου κλη-

ρονοµικότητας, κτλ. Οι εσωτερικές µετρικές µπορούν να υπολογιστούν εύκολα, αλλά

το ζητούµενο δεν είναι τόσο ο τρόπος µέτρησής τους, όσο η σύνδεσή τους µε τα εξω-

τερικά χαρακτηριστικά του λογισµικού τα οποία επιθυµούµε να µετρήσουµε, δηλα-

δή η ερµηνεία των εσωτερικών µετρικών.

Αντίθετα µε τις εσωτερικές µετρικές, οι εξωτερικές µετρικές δεν ικανοποιούν από-

λυτα τον ορισµό της µετρικής, αφού εµπεριέχουν –συνήθως– το στοιχείο της υπο-

κειµενικότητας. Αυτές οι µετρικές δεν µπορούν, εκ των πραγµάτων, στην πλειοψη-

φία των περιπτώσεων να βασιστούν σε µετρήσεις φυσικών ποσοτήτων (όπως στο

παράδειγµα των εσωτερικών µετρικών), αλλά βασίζονται σε έρευνες για τη γνώµη

των πελατών (συνήθως µε χρήση ερωτηµατολογίων ή συνεντεύξεων), σε παρατή-

ρηση του χρήστη και µελέτη της συµπεριφοράς του, κτλ. Αν και σύµφωνα µε τον

ορισµό της µετρικής που προηγήθηκε αυτές δεν είναι τυπικά µετρικές, σε αρκετά

βιβλία τις αναφέρουν και τις χρησιµοποιούν ως µετρικές ποιότητας (ενδεικτικά ανα-

φέρουµε τα: [Con86] [Jon91] [Kap95]). Στα πλαίσια του βιβλίου χρησιµοποιούµε

τον όρο µετρικές τόσο για τις εσωτερικές µετρικές, όσο και για τις εξωτερικές µετρι-

κές, όµως δεν πρέπει να αγνοούνται οι ιδιαιτερότητες των εξωτερικών µετρικών.

Σύµφωνα µε τη δεύτερη κατηγοριοποίηση, διακρίνουµε τις µετρικές σε µετρικές δια-

δικασίας (process metrics), µετρικές πόρων (resource metrics) και µετρικές προϊό-

ντος (product metrics). Οι µετρικές διαδικασίας µας δίνουν απαντήσεις σε ερωτήµα-

τα σχετικά µε το χρόνο που χρειάστηκε µία δραστηριότητα για να ολοκληρωθεί, πόσο

θα κοστίσει, πώς συγκρίνεται µε εναλλακτικές διαδικασίες που θα µπορούσαν να είχαν

επιλεγεί, κτλ. Ένας µικρός µόνο αριθµός των χαρακτηριστικών της διαδικασίας µπο-

ρεί να µετρηθεί άµεσα (µε χρήση εσωτερικών µετρικών). Τέτοια χαρακτηριστικά για

παράδειγµα είναι η διάρκεια µιας διαδικασίας, η προσπάθεια (σε ανθρωποµήνες) για

την ολοκλήρωσή της καθώς και ο αριθµός γεγονότων καθορισµένου τύπου που συνέ-

βησαν κατά τη διάρκειά της. Τέτοια γεγονότα µπορεί, για παράδειγµα, να είναι ο αριθ-

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

αριθµός των συναντήσεων µε τον πελάτη που απαιτήθηκαν για την ολοκλήρωση των

προδιαγραφών, ο αριθµός των αναφορών λαθών που ελήφθησαν από Ν επιλεγµένους

πελάτες κατά τη διάρκεια Μ εβδοµάδων ελέγχου βήτα (beta testing), κτλ.

Σε αντίθεση µε τα παραπάνω χαρακτηριστικά, ένας αριθµός χαρακτηριστικών της

διαδικασίας µπορεί να µετρηθεί µόνο έµµεσα (είναι λοιπόν εξωτερικά χαρακτηρι-

1 2 75 . 1 ª ∂ ∆ ƒ ∏ ™ ∂ π ™ ∫ ∞ π ª ∂ ∆ ƒ π ∫ ∂ ™

Εσωτερικές

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

Εξωτερικές

µετρικές είναι οιµετρικές αυτές πουχρησιµοποιούνταιγια τη µέτρησηχαρακτηριστικώντου λογισµικού πουχαρακτηρίζονταιαπό υψηλό επίπεδοαφαίρεσης και ταοποία σχετίζονταιάµεσα µε την ποιότητα του λογισµικού.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 127


στικά). Τέτοια χαρακτηριστικά για παράδειγµα είναι η σταθερότητα της διαδικασίας,

η δυνατότητα παρακολούθησής της από τον Υπεύθυνο έργου, κτλ. Οι µετρικές δια-

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

2 και για αυτό το λόγο δεν θα επεκταθούµε περισσότερο. Με τη χρήση µετρικών δια-

δικασιών σχετίζεται και ο στατιστικός έλεγχος ποιότητας, για τον οποίο µιλήσαµε

στην ενότητα 3.2.3. Τεχνικές στατιστικού ελέγχου στο λογισµικό [Wel00] εφαρµό-

ζουν τεχνικές αντίστοιχες µε αυτές που παρουσιάστηκαν στην ενότητα 3.2.3, προ-

κειµένου να µετρήσουν γεγονότα που σχετίζονται µε µία διαδικασία και µπορούν να

οδηγήσουν σε εκτιµήσεις για το αν αυτή η διαδικασία είναι εντός ή εκτός ελέγχου.

Τα πιο τυπικά παραδείγµατα τέτοιων γεγονότων είναι τα λάθη (defects) ανά διαδι-

κασία ανάπτυξης, τα προβλήµατα ανά εβδοµάδα, η συσχέτιση των γραµµών κώδι-

κα ανά ώρα µε τις επισκοπήσεις που χρειάστηκαν, κτλ.

Οι µετρικές πόρων µας δίνουν απαντήσεις σε ερωτήµατα σχετικά µε το προσωπικό,

τα υλικά (αναλώσιµα, εξοπλισµός γραφείου, κτλ) που χρησιµοποιήθηκαν, τα εργα-

λεία (τόσο σε επίπεδο υλικού όσο και λογισµικού) και τις µεθόδους ανάπτυξης. Οι

περισσότερες µετρικές πόρων µετρούν εσωτερικά χαρακτηριστικά τα οποία είναι

σχετικά εύκολο να µετρηθούν και για αυτό δεν θα επεκταθούµε περισσότερο σε

αυτές (για παράδειγµα είναι εύκολο να µετρηθεί χωρίς κάτι τέτοιο να απαιτεί κάποια

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

κόστος τους). Εκτός από τα εσωτερικά χαρακτηριστικά υπάρχουν και εξωτερικά

χαρακτηριστικά που σχετίζονται µε τους πόρους και είναι δύσκολο να µετρηθούν,

όπως για παράδειγµα η παραγωγικότητα του προσωπικού.

Τέλος, οι µετρικές προϊόντος σχετίζονται µε οτιδήποτε θα παραδοθεί στον πελάτη.

Έµφαση θα δώσουµε φυσικά στις µετρικές λογισµικού. Οι µετρικές λογισµικού µπο-

ρεί να είναι εσωτερικές ή εξωτερικές. Στην ενότητα 5.2 που ακολουθεί θα εµβαθύ-

νουµε στις εσωτερικές µετρήσεις και µετρικές λογισµικού, ενώ στην ενότητα 5.3 θα

αναφερθούµε στις εξωτερικές µετρήσεις και µετρικές λογισµικού.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 128

5.2 ∂ÛˆÙÂÚÈÎ¤˜ ÌÂÙÚ‹ÛÂÈ˜ Î·È ÌÂÙÚÈÎ¤˜ ÏÔÁÈÛÌÈÎÔ‡

Όπως αναφέραµε στην προηγούµενη ενότητα, οι εσωτερικές µετρικές χρησιµοποι-

ούνται για τη συλλογή δεδοµένων που σχετίζονται µε εκείνα τα χαρακτηριστικά του

λογισµικού που µπορούν να οριστούν ξεκάθαρα (χωρίς να εισέρχεται το στοιχείο της

υποκειµενικότητας) και να µετρηθούν µε ένα απλό και σαφώς καθορισµένο τρόπο.

Αυτή η µέτρηση πρέπει να οδηγεί πάντα στο ίδιο αποτέλεσµα, ανεξάρτητα µε το

ποιος εκτελεί τις µετρήσεις. Για παράδειγµα, όταν µετράµε τον αριθµό γραµµών

κώδικα πρέπει να είναι ξεκάθαρο τι αποτελεί γραµµή κώδικα και τι όχι, έτσι ώστε η

µέτρηση να είναι ανεξάρτητη από παραδοχές που µπορεί να κάνει οποιοσδήποτε

αναλαµβάνει τη µέτρηση. ∆είτε τη δραστηριότητα που ακολουθεί:

1 2 95 . 2 ∂ ™ ø ∆ ∂ ƒ π ∫ ∂ ™ ª ∂ ∆ ƒ ∏ ™ ∂ π ™ ∫ ∞ π ª ∂ ∆ ƒ π ∫ ∂ ™ § √ ° π ™ ª π ∫ √ À






i) Οι όροι µετρική και µέτρο είναι ισοδύναµοι και

χρησιµοποιούνται για την πρόβλεψη πολύπλοκων

χαρακτηριστικών, όπως για παράδειγµα το κόστος.

ii) Οι περισσότερες µετρικές που έχουν προταθεί

περιορίζονται στη µέτρηση εξωτερικών χαρακτηριστικών


iii)Μια µετρική είναι εύκολο να ερµηνευτεί, όταν υπάρχει

συσχέτιση, σε κάποιο βαθµό, αυτής της µετρικής µε κάποιο

ή κάποια εξωτερικά χαρακτηριστικά του λογισµικού.

iv) Οι εξωτερικές µετρικές δεν ικανοποιούν απόλυτα

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

v) Ο αριθµός γεγονότων καθορισµένου τύπου που συνέβησαν

κατά τη διάρκεια µίας διαδικασίας είναι δυνατό να αποτελεί

µετρική προϊόντος.

vi) Οι µετρικές προϊόντος σχετίζονται µε οτιδήποτε

παραδίδεται στον πελάτη.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 129


Απάντηση

Η Αντωνία αρχικά µέτρησε τις γραµµές του προγράµµατος και βρήκε ότι αυτές είναι

20. ∆εν απάντησε όµως LOC = 20 αµέσως. Αντίθετα διάβασε το εγχειρίδιο ποιότη-

τας της επιχείρησης για να δει πώς ορίζονται οι γραµµές κώδικα στη γλώσσα C. Εκεί


Η Αντωνία, είναι µηχανικός ποιότητας σε µία επιχείρηση και αναλαµβάνει να

µετρήσει τις γραµµές κώδικα του παρακάτω προγράµµατος σε C. (Αυτή η δουλειά

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

υποθέσουµε ότι οι µετρήσεις γίνονται «µε το χέρι»). Τι αποτέλεσµα πιστεύετε ότι

θα βγάλει;

/* Convert Fahrenheit to Celsius */

main()

/* Declarations */

int lower, upper, step;

float fahr, celsius;

lower = 0;

upper = 300;

step = 20;

fahr = lower;

while (fahr < = upper)

celsius = (5.0/9.0)*(fahr – 32.0);

printf(«%4.0f %6.1f\n», fahr, celsius);

fahr = fahr + step;

/* end of while */

/* End of Program */

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 130

βρήκε ότι, ως γραµµές κώδικα, ορίζονται οι γραµµές του προγράµµατος που προ-

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

αγκύλες µε τα αντίστοιχα τµήµατα που περικλείουν (ώστε να µην καταλαµβάνουν

γραµµή).

Ακολουθώντας τις παραπάνω οδηγίες η Αντωνία µετέτρεψε το πρόγραµµα στην

παρακάτω µορφή:

main()

int lower, upper, step;

float fahr, celsius;

lower = 0;

upper = 300;

step = 20;

fahr = lower;

while (fahr < = upper)

celsius = (5.0/9.0)*(fahr – 32.0);

printf(«%4.0f %6.1f\n», fahr, celsius);

fahr = fahr + step;

Τώρα, η απάντηση στο ερώτηµα ήταν εύκολο να δοθεί. LOC = 11.

Πιθανότατα κι εσείς καταλήξατε σε διαφορετική τιµή, πράγµα απόλυτα φυσιολογι-

κό, αφού δεν σας είχαµε αναφέρει τίποτε για τον τρόπο µέτρησης. Παρατηρήστε ότι,

ακόµα και για κάτι τόσο απλό, µπορούσαν να είχαν δοθεί πολλές πιθανές απαντή-

σεις µε µεγάλη απόκλιση µεταξύ τους (από LOC = 20 µέχρι LOC = 11). Βέβαια,

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

κάθε γλώσσα προγραµµατισµού και εργαλεία για να τις πραγµατοποιούν. ∆εν θα

χρειαζόταν, δηλαδή, η Αντωνία να µετρά «µε το χέρι» κάθε πρόγραµµα.

Οι εσωτερικές µετρήσεις, για να έχουν αξία, πρέπει να µπορούν να συσχετίζονται µε

εξωτερικά ποιοτικά χαρακτηριστικά. Αυτές οι συσχετίσεις προκύπτουν από την ανά-

λυση των µετρήσεων και την αξιοποίηση των ιστορικών δεδοµένων. Για παράδειγ-

µα, µία επιχείρηση που χρησιµοποιεί ως γλώσσα ανάπτυξης λογισµικού την Object

Pascal (χρησιµοποιώντας ως περιβάλλον ανάπτυξης το Borland Delphi), µπορεί να

1 3 15 . 2 ∂ ™ ø ∆ ∂ ƒ π ∫ ∂ ™ ª ∂ ∆ ƒ ∏ ™ ∂ π ™ ∫ ∞ π ª ∂ ∆ ƒ π ∫ ∂ ™ § √ ° π ™ ª π ∫ √ À

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 131


συσχετίσει την εσωτερική µέτρηση LOC µε τα λάθη που εντοπίζει ο πελάτης. Έτσι,

θα προέκυπτε µία ανάλυση που θα συσχέτιζε τα λάθη που εντοπίζει ο πελάτης µε τις

γραµµές κώδικα, δίνοντας µετρήσεις σε µονάδες «λάθη πελάτη ανά ΚLOC». Ανα-

λύοντας στατιστικά τα δεδοµένα για κάθε τµήµα κώδικα, η επιχείρηση θα αποκτού-

σε εξειδικευµένη γνώση για κάθε τµήµα, αλλά –το κυριότερο– δεδοµένα για το ιδα-

νικό µέγεθος (σε LOC) κάθε τµήµατος, ή για το όριο στο οποίο ένα τµήµα πρέπει να

κοπεί σε µικρότερα. Αντίστοιχες συσχετίσεις µπορούν να γίνουν µε την παραγωγι-

κότητα και τις γραµµές κώδικα, ή άλλες εσωτερικές µετρικές.

Παρόµοιες µετρήσεις µπορούν να συγκεντρωθούν για πολλές εσωτερικές µετρικές

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

να αντικατοπτρίζονται στο εγχειρίδιο ποιότητας. Οι αποφάσεις που βασίζονται σε

εσωτερικές µετρικές έχουν ως κύριο σκοπό τους την πρόληψη. Έτσι, για παράδειγ-

µα, αν µία επιχείρηση έχοντας αναλύσει δεδοµένα από µετρήσεις, αποφασίσει ότι

κάθε τµήµα δεν πρέπει να ξεπερνά τις 500 LOC (για κάποια συγκεκριµένη γλώσσα

προγραµµατισµού), αυτό δεν σηµαίνει ότι ένα τµήµα 600 LOC (για το οποίο απαι-

τείται προσπάθεια, προκειµένου να διασπαστεί σε 2 µικρότερα τµήµατα) απαραίτη-

τα θα δηµιουργήσει προβλήµατα. Όµως, επειδή η πιθανότητα να δηµιουργήσει προ-

βλήµατα είναι υψηλή, η επιχείρηση αναλαµβάνει το κόστος των αλλαγών, ελπίζο-

ντας να προλάβει τα λάθη που θα εντοπίσει ο πελάτης. Τέτοια λάθη, κοστίζουν περισ-

σότερο στην επιχείρηση (και πέρα από το υλικό κόστος υπάρχουν και έµµεσες ζηµιές

που σχετίζονται µε την εικόνα της επιχείρησης προς τον πελάτη).


Η Αντωνία έχει µετρήσει τις γραµµές κώδικα για 10 τµήµατα κώδικα (ας τα ονο-

µάσουµε, χάριν ευκολίας, Α, Β, Γ, ∆, Ε, Ζ, Η, Θ, Ι, Κ) και έχει βρει τις αντίστοιχες

τιµές (LOCΑ = 267, LOCΒ = 413, LOCΓ = 830, LOC∆ = 503, LOCΕ = 1483, LOCΖ

= 442, LOCΗ = 208, LOCΘ = 488, LOCΙ = 1045, LOCΚ = 381). Μετά την παράδο-

ση του προγράµµατος στους πελάτες, τα λάθη που εντοπίστηκαν από τους πελά-

τες για κάθε τµήµα είναι (ΛΑ = 1, ΛΒ = 1, ΛΓ = 5, Λ∆ = 3, ΛΕ = 9, ΛΖ = 2, ΛΗ = 0, ΛΘ

= 1, ΛΙ = 7, ΛΚ = 1). Η Αντωνία πρέπει να υπολογίσει το µέσο ποσοστό λαθών ανά

ΚLOC για όλο το έργο. Υπολογίστε αυτό το ποσοστό κι εσείς και µετά διαβάστε

την απάντηση που ακολουθεί. Επίσης, δείξτε µε γραφικό τρόπο πώς αυξάνει το

ποσοστό λαθών, όσο αυξάνει το µέγεθος κάθε τµήµατος.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 132

Απάντηση

Αν προσθέσουµε τις γραµµές κώδικα για όλα τα τµήµατα του έργου προκύπτει ότι:

LOCΟΛΙΚΟ = 6060

Προσθέτοντας αντίστοιχα τα λάθη προκύπτει ότι: ΛΟΛΙΚΟ = 30.

Από τις δύο τιµές συνολικά για το έργο προκύπτει ότι το µέσο ποσοστό λαθών είναι

30/6060 λάθη ανά ΚLOC που υπολογίζεται σε 4,95 λάθη/KLOC.

Παρατηρώντας τα λάθη ανά τµήµα, παρατηρούµε ότι, όσο µεγαλώνει το τµήµα µεγα-

λώνει και ο αριθµός των λαθών, αλλά αυτό είναι κάτι αναµενόµενο. Αν σε ένα τµήµα

200 γραµµών έχουµε περίπου ένα λάθος, τότε σε ένα τµήµα 400 γραµµών είναι λογι-

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

ενδιαφέρεται τόσο για τον απόλυτο αριθµό λαθών ανά τµήµα, όσο για τα λάθη ανά

ΚLOC σε κάθε τµήµα. Όλα αυτά παρουσιάζονται στον πίνακα που ακολουθεί:

Τµήµα LOC Λάθη Λάθη ανά ΚLOC

Α 267 1 3,75

Β 413 1 2,42

Γ 830 5 6,02

∆ 503 3 5,96

Ε 1483 9 6,07

Ζ 442 2 4,52

Η 208 0 0,00

Θ 488 1 2,05

Ι 1045 7 6,70

Κ 381 1 2,62

Έργο 6060 30 4,95

Παρατηρώντας τα δεδοµένα στον παραπάνω πίνακα, είναι φανερό ότι, ενώ όλα τα

τµήµατα µε µέγεθος µικρότερο των 500 LOC, έχουν λάθη ανά ΚLOC λιγότερα του

µέσου όρου, όλα τα τµήµατα µε µέγεθος µεγαλύτερο των 500 LOC, έχουν λάθη ανά

ΚLOC περισσότερα από το µέσο όρο. Στο συγκεκριµένο παράδειγµα αυτό το απο-

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

δεδοµένων, αλλά και σε πραγµατικές συνθήκες και δεδοµένα, αντίστοιχες κατα-

1 3 35 . 2 ∂ ™ ø ∆ ∂ ƒ π ∫ ∂ ™ ª ∂ ∆ ƒ ∏ ™ ∂ π ™ ∫ ∞ π ª ∂ ∆ ƒ π ∫ ∂ ™ § √ ° π ™ ª π ∫ √ À

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 133


στάσεις αποτελούν τον κανόνα και όχι την εξαίρεση. Για να δείξουµε µε γραφικό

τρόπο την αύξηση του ποσοστού των λαθών ανά ΚLOC, όσο µεγαλώνει το µέγεθος

ενός δείγµατος, χρησιµοποιούµε ένα γνωστό στατιστικό είδος γραφήµατος, τα γρα-

φήµατα διασποράς (scatter plots), όπως αυτό του σχήµατος 5.1:

™¯‹Ì· 5.1

Γράφηµα

διασποράς

0 200 400 600 800 1000 1200 1400 16000,00

1,00

2,00

3,00

4,00

5,00

6,00

7,00

8,00

Λά

θη α

νά K

LO

C

Mέγεθος σε LOC

Τα γραφήµατα διασποράς χρησιµοποιούνται πολύ συχνά από το τµήµα ποιότητας

για την αναπαράσταση συσχετίσεων ανάµεσα σε µετρήσιµες ποσότητες και συνή-

θως ανάµεσα σε εσωτερικές µετρικές και εξωτερικά ποιοτικά χαρακτηριστικά.

Πέρα από τις γραµµές κώδικα, το τµήµα ποιότητας µπορεί να επιλέξει αρκετές µετρι-

κές (στη βιβλιογραφία που σας προτείνουµε µπορείτε να διαβάσετε για δεκάδες

ακόµα), καθώς και για τους τρόπους µέτρησης και εφαρµογής τους, πώς αναλύονται

τα αποτελέσµατα και τι έχει δείξει η εµπειρία από τη χρήση τους (αυτό που ονοµά-

ζουµε ιστορικά δεδοµένα). Για να θεωρηθούν αυτές οι µετρικές χρήσιµες, πρέπει να

είναι απλές, δηλαδή τα αποτελέσµατά τους να είναι εύκολα ερµηνεύσιµα και η σχέση

τους µε τα εξωτερικά ποιοτικά χαρακτηριστικά του λογισµικού να είναι σαφής. Επί-

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

παράδειγµα, η χρήση της µετρικής στη δραστηριότητα 5.2 καθοδηγεί στην επιβολή

της µείωσης των γραµµών κώδικα κάτω από ένα καθορισµένο όριο). Ακόµα, οι µετρι-

κές πρέπει να µην επηρεάζονται από αλλαγές παραγόντων που δεν επηρεάζουν την

ποιότητα του λογισµικού (όπως για παράδειγµα την αναδιάταξη του κώδικα) και

τέλος, να είναι εύκολο να αυτοµατοποιηθούν (δηλαδή οι µετρήσεις να µην γίνονται

«µε το χέρι», αλλά αυτόµατα) αλλιώς η χρήση τους δεν µπορεί να είναι γενικευµένη.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 134

Συνοψίζοντας, µπορούµε να πούµε ότι οι εσωτερικές µετρικές είναι –συνήθως– εύκο-

λο να συγκεντρωθούν και να αναλυθούν, ότι η συλλογή δεδοµένων που βασίζονται

σε εσωτερικές µετρικές είναι πολύ οικονοµική (συγκρινόµενη και µε την αντίστοι-

χη συλλογή δεδοµένων για εξωτερικές µετρικές) και τα αποτελέσµατα που προκύ-

πτουν είναι εύκολο να αναλυθούν µε στατιστικές µεθόδους. Το κυριότερο είναι ότι

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

πολύ πριν την ολοκλήρωση και τελική παράδοση του λογισµικού. Από την άλλη, τα

αποτελέσµατά τους είναι –συνήθως– δύσκολο να ερµηνευτούν (συγκρινόµενα µε

αυτά των εξωτερικών µετρήσεων) αφού πολλές φορές δεν είναι ξεκάθαρη η σύνδε-

σή τους µε κάποιο ή κάποια εξωτερικά ποιοτικά χαρακτηριστικά. Έρευνες [Xen96]

[Xen97] έχουν αποδείξει ότι η χρήση εσωτερικών µετρικών µπορεί να εντοπίσει σχε-

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

να υποδείξει και τµήµατα κώδικα που τελικά δεν θα δηµιουργήσουν προβλήµατα.

Ακόµα κι έτσι, όµως, το όφελος από την πρώτη περίπτωση (εντοπισµός προβληµα-

τικών τµηµάτων πριν παραδοθούν) είναι πολύ σηµαντικότερο από το κόστος που

συνεπάγεται η δεύτερη περίπτωση (επιβολή αλλαγών σε «υγιή» τµήµατα). Συνεχί-

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

κυκλωµατικής πολυπλοκότητας.

5.2.1 ∫˘ÎÏˆÌ·ÙÈÎ‹ ÔÏ˘ÏÔÎfiÙËÙ·

Η µετρική της κυκλωµατικής πολυπλοκότητας (cyclomatic complexity) [Mcb76]

είναι ένα µέτρο της πολυπλοκότητας ενός τµήµατος, που βασίζεται στο γράφο ροής

(flow graph) του τµήµατος αυτού. Βασικό στοιχείο της µετρικής είναι ο εντοπισµός

εκείνων των τµηµάτων του λογισµικού, τα οποία θα είναι δύσκολο να κατανοηθούν,

να ελεγχθούν και να συντηρηθούν. Η µελέτη του τµήµατος λογισµικού, από τη σκο-

πιά αυτής της µετρικής, σχετίζεται µε τους πιθανούς δρόµους (µονοπάτια) που µπο-

ρεί να ακολουθήσει η εκτέλεση ενός τµήµατος κώδικα. Μια ένδειξη των δυνατών

επιλογών κατεύθυνσης ενός προγράµµατος παρέχει ο γράφος ροής του προγράµµα-

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

στο γράφο ροής βασίζονται οι µετρήσεις.

Ο γράφος ροής ενός προγράµµατος δείχνει σχηµατικά τους πιθανούς «δρόµους» που

µπορεί να ακολουθήσει η εκτέλεση του προγράµµατος, επιλέγοντας κάθε φορά ένα

διαφορετικό µονοπάτι από τις δυνατότητες επιλογής. Οι τέσσερις περιπτώσεις οι

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

λή διακλάδωσης, κύκλος µε έξοδο στην αρχή, κύκλος µε έξοδο στο τέλος.

Ακολουθιακές εντολές είναι ακολουθίες εντολών κατά τις οποίες δεν γίνεται επι-

1 3 55 . 2 ∂ ™ ø ∆ ∂ ƒ π ∫ ∂ ™ ª ∂ ∆ ƒ ∏ ™ ∂ π ™ ∫ ∞ π ª ∂ ∆ ƒ π ∫ ∂ ™ § √ ° π ™ ª π ∫ √ À

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 135


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

ρετικού τρόπου (µονοπατιού) εκτέλεσής τους. Εντολές διακλάδωσης (όπως η εντο-

λή «if … then … else …» στην C) είναι αυτές που καθορίζουν δύο µονοπάτια επιλο-

γής. Μετά την ολοκλήρωση των µονοπατιών και τα δύο καταλήγουν στο κοινό

σηµείο του προγράµµατος, από το οποίο αρχίζει η επόµενη εντολή. Οι εντολές

κύκλου µε έξοδο στην αρχή (χαρακτηριστικό παράδειγµα η εντολή «while … do»)

και οι εντολές κύκλου µε έξοδο στο τέλος (χαρακτηριστικό παράδειγµα η εντολή

«do … while») αφορούν τις τυπικές δοµές επανάληψης που έχετε διδαχθεί. Όλες

αυτές οι εντολές µπορούν να παρασταθούν γραφικά στο γράφο ροής του προγράµ-

µατος, όπως φαίνεται στο σχήµα 5.2.

™¯‹Ì· 5.2

Παραδείγµατα

εντολών ροήςAκολουθιακές

εντολέςEντολές

διακλάδωσηςKύκλος µε έξοδο

στην αρχήKύκλος µε έξοδο

στο τέλος

Αντίστοιχα µε τις παραπάνω περιπτώσεις, υπάρχουν πιο πολύπλοκες καταστάσεις,

οι οποίες µπορούν να δηµιουργηθούν µε τη χρήση εντολών «goto», που αν εµπε-

ριέχονται σε εντολές επανάληψης ή οδηγούν µέσα σε αυτές, περιπλέκουν σε µεγά-

λο βαθµό τη µορφή του γράφου.

Ο McCabe όρισε τη µετρική της κυκλωµατικής πολυπλοκότητας V(g) για ένα γράφο

ροής g, όπως ορίζεται στη σχέση (5.1), όπου e είναι ο αριθµός των ακµών του γρά-

φου, n ο αριθµός των κόµβων του γράφου, και p ο αριθµός των συνεκτικών συνι-

στωσών[2] του γράφου.

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

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 136

V(g) = e – n + 2p (5.1)

Η µετρική της κυκλωµατικής πολυπλοκότητας είναι από τις πιο διαδεδοµένες µετρι-

κές και έχει ενταχθεί στα προγράµµατα µετρήσεων των περισσοτέρων εταιριών.

Αρκετές εταιρίες έχουν καθορίσει στα πρότυπα ποιότητάς τους, όπως περιγράφο-

νται στα εγχειρίδια ποιότητάς τους, ότι τµήµατα κώδικα µε πολυπλοκότητα V(g)>10

δεν θα γίνονται αποδεκτά, αφού τα ιστορικά τους δεδοµένα έδειχναν υποβάθµιση

της ποιότητας για τµήµατα µε τέτοια χαρακτηριστικά (κυκλωµατική πολυπλοκότη-

τα µεγαλύτερη του 10). Βασικό πλεονέκτηµα της µετρικής είναι ότι είναι τελείως

ανεξάρτητη από τη γλώσσα προγραµµατισµού. Στη βιβλιογραφία µπορείτε να δια-

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

που έχουν προταθεί.

1 3 75 . 2 ∂ ™ ø ∆ ∂ ƒ π ∫ ∂ ™ ª ∂ ∆ ƒ ∏ ™ ∂ π ™ ∫ ∞ π ª ∂ ∆ ƒ π ∫ ∂ ™ § √ ° π ™ ª π ∫ √ À


Η Αντωνία έχει να µετρήσει (δυστυχώς πάλι «µε το χέρι») την κυκλωµατική πολυ-

πλοκότητα για το παρακάτω πρόγραµµα (το πρόγραµµα είναι πλασµατικό για τις

ανάγκες της δραστηριότητας και δεν υλοποιεί απολύτως τίποτε!). Υπολογίστε το

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

την απάντηση που ακολουθεί.

main()

if (x = = a)

do

x++;

y = y+a;

while(x< = b);

else

x = a;

y = 2*a+4*b;

while (y! = a)

y++;

x+ = a;

z = x+y^2;

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 137


Απάντηση

Ο γράφος ελέγχου g του προγράµµατος παρουσιάζεται στο σχήµα 5.3 και σχεδιάζε-

ται µε βάση το πρόγραµµα.

Από το σχήµα 5.3 προκύπτει ότι ο αριθµός ακµών e = 9, ο αριθµός κόµβων n = 7 και

οι συνεκτικές συνιστώσες p = 1. Αντικαθιστώντας στη σχέση (5.1), υπολογίζουµε

την κυκλωµατική πολυπλοκότητα V(g) = 9 ∠ 7 + 2 ⇒ V(g) = 4.

Φυσικά, σε ένα πρόγραµµα ποιότητας µίας επιχείρησης αυτοί οι υπολογισµοί θα

γίνονταν αυτόµατα και τα τµήµατα του κώδικα που ξεπερνούν τα όρια που θέτει το

πρότυπο της επιχείρησης θα εντοπίζονταν επίσης αυτόµατα.

™¯‹Ì· 5.3

Γράφος ροής δρα-

στηριότητας 5.3






i) Οι εσωτερικές µετρικές χρησιµοποιούνται για τη συλλογή

δεδοµένων που σχετίζονται µε χαρακτηριστικά

του λογισµικού τα οποία µπορούν να οριστούν ξεκάθαρα

(χωρίς να εισέρχεται το στοιχείο της υποκειµενικότητας)

και να µετρηθούν µε ένα απλό και σαφώς καθορισµένο τρόπο.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 138

5.3 ∂ÍˆÙÂÚÈÎ¤˜ ªÂÙÚ‹ÛÂÈ˜ Î·È ªÂÙÚÈÎ¤˜ §ÔÁÈÛÌÈÎÔ‡

Πριν προχωρήσουµε στις εξωτερικές µετρήσεις, πρέπει να τονιστεί ότι, αν και οι εξω-

τερικές µετρήσεις συνήθως σχετίζονται µε το χρήστη, δεν περιορίζονται µόνο στα

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

και της αξιοπιστίας. Εξωτερικές µετρήσεις µπορούν να γίνουν και για τα ποιοτικά

χαρακτηριστικά της µεταφερσιµότητας και της συντηρησιµότητας. Το τµήµα συντή-

ρησης, εξάλλου, µπορεί να θεωρηθεί ως χρήστης του κώδικα µε σκοπό την υλοποίη-

ση αλλαγών. Μετρήσεις εξωτερικές για τη συντηρησιµότητα θα µπορούσαν να είναι:

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

στό επιτυχίας της διόρθωσης, το µέσο µέγεθος του κώδικα που χρειάζεται να τροπο-

ποιηθεί για µία διόρθωση, το µέσο µέγεθος του κώδικα που χρειάστηκε να διαβαστεί

(εξεταστεί) µέχρι να εντοπιστεί το τµήµα στο οποίο υπάρχει το λάθος, κτλ.

Όπως βλέπετε, οι παραπάνω εξωτερικές µετρικές εµπεριέχουν το στοιχείο της υπο-

κειµενικότητας. Βέβαια, στα περισσότερα εγχειρίδια ποιότητας, η περιγραφή τους

γίνεται µε αυστηρούς τυπικούς περιορισµούς, έτσι ώστε να µειώνονται τα περιθώ-

ρια της υποκειµενικότητας. Εξάλλου, οι µετρήσεις που προκύπτουν από την χρήση

τους είναι άµεσα αξιοποιήσιµες για εξαγωγή συµπερασµάτων σχετικά µε τη συντη-

ρησιµότητα και δεν χρειάζεται η αναζήτηση συσχετίσεων µε εξωτερικά ποιοτικά

χαρακτηριστικά (όπως στην περίπτωση των εσωτερικών µετρικών).

1 3 95 . 3 ∂ • ø ∆ ∂ ƒ π ∫ ∂ ™ ª ∂ ∆ ƒ ∏ ™ ∂ π ™ ∫ ∞ π ª ∂ ∆ ƒ π ∫ ∂ ™ § √ ° π ™ ª π ∫ √ À

ii) Οι µετρήσεις από τις εσωτερικές µετρικές µπορούν

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

θα αντικατοπτρίζονται στο εγχειρίδιο ποιότητας.

iii)Οι γραµµές κώδικα και η κυκλωµατική πολυπλοκότητα

υπολογίζονται µόνο «µε το χέρι».

iv) Η κυκλωµατική πολυπλοκότητα είναι ένα µέτρο

της πολυπλοκότητας ενός τµήµατος, που βασίζεται

στο γράφο ροής του.


Από το κεφάλαιο 9 του βιβλίου «Software Metrics A Rigorous & Practical

Approach» που σας προτείνουµε (βλέπε βιβλιογραφία στο τέλος του κεφαλαίου),

αλλά και από αναζητήσεις σας στο διαδίκτυο, ετοιµάστε µία αναφορά για εξωτε-

ρικές µετρήσεις µεταφερσιµότητας και συντηρησιµότητας. Η αναφορά σας θα πρέ-

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 139


Οι εξωτερικές µετρήσεις για ποιοτικά χαρακτηριστικά που αφορούν τον τελικό χρή-

στη µπορούν να βασιστούν σε τρεις κατηγορίες µεθόδων [Abo00]:

α) Αναλυτικές µέθοδοι (analytic methods)

β) Πειραµατικές µέθοδοι (experimental methods)

γ) ∆ιερευνητικές µέθοδοι (inquiry methods)

Οι αναλυτικές µέθοδοι εκτελούνται στο εργαστήριο και δεν συµµετέχουν οι τελι-

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

λυση πληκτρολογήσεων (όπου χρησιµοποιείται ένα µοντέλο ανάλυσης εργασιών και

µε υπολογισµό των χρόνων που προβλέπονται για τυπικές ενέργειες του χρήστη,

εκτιµάται ο χρόνος ολοκλήρωσης ενός έργου µε τη χρήση του προγράµµατος), την

ευρετική αξιολόγηση (όπου εξωτερικοί κριτές εξετάζουν την τήρηση κανόνων µε

βάση κάποια κριτήρια σπουδαιότητας, εξειδικευµένα για κάθε εφαρµογή) και τον

έλεγχο συµβατότητας µε κανόνες σχεδιασµού και πρότυπα (όπου οι κανόνες δίδο-

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

ή όχι από το σύστηµα).

Οι πειραµατικές µέθοδοι γίνονται στο εργαστήριο αλλά –σε αντίθεση µε τις ανα-

λυτικές µεθόδους– υπάρχει συµµετοχή των τελικών χρηστών. Σε αυτές τις µεθόδους

οι χρήστες χρησιµοποιούν το πρόγραµµα µέσα σε ένα εργαστήριο, ενώ οι ειδικοί

(συνήθως αθέατα και µε χρήση εξειδικευµένου εξοπλισµού, όπως βίντεο, ή σύστη-

µα καταγραφής συµβάντων) τους παρακολουθούν και σηµειώνουν (µετρούν) τις

αντιδράσεις τους.

Τέλος, οι διερευνητικές µέθοδοι εκτελούνται εκτός εργαστηρίου και προϋποθέτουν

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

ρουµε τις συνεντεύξεις των χρηστών (όπου κάποιος αξιολογητής καταγράφει τις από-

ψεις του χρήστη) και τη συµπλήρωση ερωτηµατολογίων (όπου οι χρήστες καλού-

νται να εκφέρουν άποψη για τα ποιοτικά χαρακτηριστικά του λογισµικού).

πει να περιγράφει τον ορισµό κάθε µετρικής και να επεξηγεί τον τρόπο µέτρησης.

Προσπαθήστε να µην ξεπεράσετε τις 1000 λέξεις και συζητήστε την αναφορά σας

µε το Σύµβουλο – Καθηγητή σας.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 140

Από τις µεθόδους που αναφέραµε, η πιο διαδεδοµένη στην πράξη είναι η χρήση ερω-

τηµατολογίου. Τα πλεονεκτήµατα της µεθόδου αυτής είναι ότι µία επιχείρηση µπο-

ρεί να ζητήσει την άποψη των χρηστών για ποιοτικά χαρακτηριστικά του λογισµι-

κού µε µικρό κόστος (τα ερωτηµατολόγια µπορεί να αποστέλλονται στους χρήστες

ηλεκτρονικά, ή να βρίσκονται στον κόµβο της επιχείρησης στο διαδίκτυο και οι χρή-

στες να τα συµπληρώνουν εκεί). Μετρήσεις τέτοιου τύπου είναι απόλυτα συµβατές

µε τον ορισµό της ποιότητας (που σχετίζεται άµεσα µε την άποψη των χρηστών) και

οδηγούν σε άµεσα αναλύσιµα δεδοµένα. Τα µειονεκτήµατα αυτής της µεθόδου είναι

η υποκειµενικότητα των απαντήσεων και τα συχνά λάθη. Όσον αφορά το πρώτο µει-

ονέκτηµα, ένας καλός τρόπος αντιµετώπισής του από το σχεδιαστή του ερωτηµα-

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

απαντήσεων (µε χρήση διπλών ερωτήσεων, ερωτήσεων ασφαλείας, κτλ). Για τον

εντοπισµό των χρηστών που έχουν πολλά λάθη στις απαντήσεις τους –και κατά συνέ-

πεια δεν θα πρέπει να συµπεριληφθούν στην ανάλυση των αποτελεσµάτων– υπάρ-

χουν τεχνικές που βασίζονται σε ερωτήσεις ασφαλείας (ερωτήσεις που δεν έχουν

στόχο να µετρήσουν την άποψη του χρήστη για κάποιο ποιοτικό χαρακτηριστικό,

αλλά να ελέγξουν την εγκυρότητα των απαντήσεων του χρήστη).

Συνοψίζοντας, πρέπει να τονιστεί ότι οι εξωτερικές µετρήσεις βασίζονται στον ορισµό

της ποιότητας (ικανοποίηση των τελικών χρηστών) και µετρούν άµεσα τα επιθυµητά

εξωτερικά χαρακτηριστικά, χωρίς να χρειάζεται περαιτέρω ανάλυση, ή ερµηνεία.

Όµως, αρκετές από τις µεθόδους µέτρησης δεν είναι καθόλου οικονοµικές (ιδιαίτερα

συγκρινόµενες µε τις εσωτερικές µετρήσεις) και τα αποτελέσµατα βασίζονται συχνά

σε υποκειµενικές κρίσεις ή απόψεις. Παρά τα προβλήµατα αυτά, οι εξωτερικές µετρή-

σεις είναι πολύτιµο εργαλείο για το τµήµα ποιότητας κάθε επιχείρησης.

1 4 15 . 3 ∂ • ø ∆ ∂ ƒ π ∫ ∂ ™ ª ∂ ∆ ƒ ∏ ™ ∂ π ™ ∫ ∞ π ª ∂ ∆ ƒ π ∫ ∂ ™ § √ ° π ™ ª π ∫ √ À


Από το κεφάλαιο 8 του βιβλίου «Εισαγωγή στην Επικοινωνία Ανθρώπου – Υπο-

λογιστή» που σας προτείνουµε (βλέπε βιβλιογραφία στο τέλος του κεφαλαίου),

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

λέξεις περιγράφοντας µε λεπτοµέρεια µία αναλυτική, µία πειραµατική και µία διε-

ρευνητική µέθοδο. Για αυτή τη δραστηριότητα είναι καλό να συνεργαστείτε µε το

Σύµβουλο – Καθηγητή σας, ώστε να σας βοηθήσει στην επιλογή των µεθόδων.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 141


5.4 ™˘Û¯¤ÙÈÛË ÂÛˆÙÂÚÈÎÒÓ Î·È ÂÍˆÙÂÚÈÎÒÓ ÌÂÙÚÈÎÒÓ ÏÔÁÈÛÌÈÎÔ‡

Η εύρεση εσωτερικών µετρικών, οι οποίες ενσωµατωµένες σε µία µέθοδο εσωτερι-

κών µετρήσεων θα είχαν απόλυτη συσχέτιση µε τις εξωτερικές µετρήσεις είναι πολύ

δύσκολη. Πρακτικά, εάν υπήρχε ένα τέτοιο σύνολο µετρικών, τότε δε θα υπήρχε ανά-

γκη για εξωτερικές µετρήσεις, αφού η τήρηση των ορίων τα οποία τίθενται από αυτές

τις εσωτερικές µετρικές θα υποκαθιστούσε το πρόγραµµα ποιότητας. Για να το

θέσουµε πιο απλά: η τήρηση των ορίων στις εσωτερικές µετρικές θα συνεπαγόταν

αυτόµατα υψηλή ποιότητα του λογισµικού, οπότε δεν θα υπήρχε λόγος επιβεβαίω-

σης µε τη χρήση εξωτερικών µετρικών.

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

«ποιότητα» συντίθεται από παράγοντες µε υψηλό επίπεδο αφαίρεσης, όπως για παρά-

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

κά και που δε σχετίζονται µε χαρακτηριστικά τα οποία µετρούνται εσωτερικά βασι-

σµένα σε εσωτερικές µετρικές.

Το ζητούµενο είναι κατά πόσο µία µέθοδος εσωτερικών µετρήσεων µπορεί να προ-

βλέψει αρνητικές καταστάσεις, δηλαδή κατά πόσο οι εσωτερικές µετρήσεις µπορούν






i) Οι εξωτερικές µετρήσεις αφορούν στα ποιοτικά

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

ii) Οι εξωτερικές µετρικές είναι συνήθως απόλυτα

αντικειµενικές.

iii)Στις αναλυτικές και στις πειραµατικές µεθόδους δεν

συµµετέχουν οι τελικοί χρήστες, σε αντίθεση

µε τις διερευνητικές µεθόδους που πραγµατοποιούνται

µε συµµετοχή των τελικών χρηστών.

iv) Οι εξωτερικές µετρήσεις µε χρήση ερωτηµατολογίου είναι

οικονοµική µέθοδος, συγκρινόµενη µε τις αντίστοιχες

µεθόδους εσωτερικών µετρήσεων.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 142

να εντοπίσουν τµήµατα του λογισµικού τα οποία ενδέχεται να δηµιουργήσουν προ-

βλήµατα, τόσο κατά τις εσωτερικές στην επιχείρηση φάσεις αξιολόγησης (έλεγχο

και συντήρηση), όσο και κατά την τελική αξιολόγηση από τους χρήστες.

Η χρήση εσωτερικών µετρήσεων και µετρικών, για τις οποίες µιλήσαµε στην ενό-

τητα 5.2, είναι µία µέθοδος η οποία µπορεί να εντοπίσει τέτοια προβληµατικά τµή-

µατα του λογισµικού. Ζητούµενο είναι κατά πόσο συσχετίζονται οι εσωτερικές

µετρήσεις που γίνονται µε αυτή τη µέθοδο µε τις εξωτερικές µετρήσεις που πραγ-

µατοποιούνται µε τη µέθοδο που περιγράψαµε στην ενότητα 5.3. Αυτό το ζητούµε-

νο µπορεί να αναλυθεί στα δύο ερωτήµατα που ακολουθούν:

α) Ένα έργο το οποίο ικανοποιεί ένα πρόγραµµα ποιότητας βασισµένο σε εσωτερι-

κές µετρήσεις, θα έχει αντίστοιχη επιτυχία στις µετρήσεις της άποψης των πελα-

τών για την ποιότητά του;

β) Ένα έργο το οποίο απέτυχε να ικανοποιήσει ένα πρόγραµµα ποιότητας βασισµέ-

νο σε εσωτερικές µετρήσεις, θα γνωρίσει επίσης αποτυχία στις µετρήσεις της άπο-

ψης των πελατών για την ποιότητά του;

Η απάντηση στο πρώτο ερώτηµα είναι: «δεν υπάρχει εγγύηση ότι ένα έργο το οποίο

ικανοποίησε το πρόγραµµα εσωτερικών µετρήσεων θα έχει αντίστοιχα ικανοποιητικές

εξωτερικές µετρήσεις». Αυτό οφείλεται στο γεγονός ότι οι εσωτερικές µετρήσεις δεν

µπορούν να καλύψουν όλους τους εξωτερικούς ποιοτικούς παράγοντες. Αντίθετα για

το δεύτερο ερώτηµα η απάντηση είναι: «αποτυχία στο πρόγραµµα εσωτερικών µετρή-

σεων κατά κανόνα σηµαίνει και αποτυχία στις εξωτερικές µετρήσεις» [Xen96]. Αυτό

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

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

κώδικα, αδυναµία εντοπισµού εσωτερικών στόχων κτλ. Όλα αυτά, σχεδόν πάντα,

αντικατοπτρίζονται στην ποιότητα του τελικού προϊόντος όπως την αντιλαµβάνεται

ο χρήστης (πελάτης).

Είναι σχεδόν αδύνατο για ένα έργο να µην ικανοποιεί εσωτερικούς ποιοτικούς περιο-

ρισµούς και παρόλα αυτά να κρίνεται ικανοποιητικό από τους πελάτες. Ένα έργο

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

κώδικας, χωρίς τήρηση γενικών κανόνων προγραµµατισµού και αρχών της Τεχνο-

λογίας Λογισµικού. Κατά συνέπεια αποτυχία σε εσωτερικές µετρικές θα σηµαίνει

αποτυχία και στην άποψη των πελατών για την ποιότητα.

Αυτή η θέση βασίζεται στην αρχή της Τεχνολογίας Λογισµικού που τονίζει ότι «καλή

εσωτερική δοµή συνεπάγεται καλή εξωτερική ποιότητα». Όπως αναφέρει ο Fenton

[Fen97] εάν η παραπάνω υπόθεση δεν ισχύει τότε όλα τα χρόνια έρευνας στην Τεχνο-

1 4 35 . 4 ™ À ™ Ã ∂ ∆ π ™ ∏ ∂ ™ ø ∆ ∂ ƒ π ∫ ø ¡ ∫ ∞ π ∂ • ø ∆ ∂ ƒ π ∫ ø ¡ ª ∂ ∆ ƒ π ∫ ø ¡ § √ ° π ™ ª π ∫ √ À

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 143


λογία Λογισµικού είναι χωρίς νόηµα. Οι επιτυχείς εσωτερικές µετρήσεις µπορούν

να χαρακτηριστούν ως «επαλήθευση της τήρησης κανόνων και αρχών κατά τη δια-

δικασία παραγωγής λογισµικού και συνέπεια µε τις µετρήσιµες ποιοτικές προδια-

γραφές όπως αυτές καθορίζονται από την επιχείρηση». Αυτό συνεπάγεται ότι η επι-

χείρηση είναι σε θέση να παράγει κώδικα τηρώντας µια µεθοδολογία παραγωγής και

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

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

δή σε αποτυχία των εσωτερικών µετρικών, παρουσιάζονται αδυναµίες στην τήρηση

των εσωτερικών ποιοτικών προδιαγραφών και κώδικας που εσωτερικά χαρακτηρί-

ζεται ως «χαµηλής ποιότητας». Κατά κανόνα τέτοιος κώδικας δεν µπορεί να ικανο-

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

χία και στις εξωτερικές µετρήσεις.


Στο κεφάλαιο µιλήσαµε για τις µετρήσεις και τις µετρικές που εντάσσονται σε ένα

σύστηµα ποιότητας λογισµικού, δίνοντας παραδείγµατα µετρικών και παρουσιάζο-

ντας µετρήσεις µε χρήση επιλεγµένων εσωτερικών µετρικών καθώς και τις βασικές

αρχές των εξωτερικών µετρικών. Τέλος µιλήσαµε για τη συσχέτιση εσωτερικών και

εξωτερικών µετρικών.

Σε αρκετά σηµεία του κεφαλαίου δεν επεκταθήκαµε σε λεπτοµερή παρουσίαση όλων

των εσωτερικών µετρικών ή στην ανάλυση των εξωτερικών µετρήσεων, αφήνοντάς

σας να τις µελετήσετε από µόνοι σας. Σε αυτό το ζητούµενο θα σας βοηθήσει η βιβλιο-

γραφία που ακολουθεί µε προτεινόµενα βιβλία για περαιτέρω µελέτη και υποδείξεις

για το πού να επικεντρώσετε την προσοχή σας.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 144









Είναι ένα βιβλίο που ακολουθεί τη λογική της εκπαίδευσης από απόσταση (είναι

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

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

ρικών µετρήσεων των ποιοτικών χαρακτηριστικών που αφορούν στους τελικούς χρή-

στες, για τις οποίες µιλήσαµε στην ενότητα 5.3.



Το βιβλίο εξειδικεύεται στις µετρήσεις και µετρικές και το προτείνω ανεπιφύλακτα

σε όποιον θέλει να εµβαθύνει σε θέµατα µετρήσεων και µετρικών. Στα κεφάλαια 1

και 2 καθορίζονται µε ακρίβεια οι αρχές των µετρήσεων, ενώ τα κεφάλαια 7 έως 12

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

[Fit78] A. Fitzsimmons and T. Love, «A Review and Evaluation of Software Science»,

Computing Surveys, Volume 10, 1, (1978).

[Fun76] Y. Funami and M. Halstead, «A Software Physics Analysis of Akiyama’s

Debugging Data», Symposium on Computer Software Engineering, (1976).

[Gil87] Τ. Gilb, «Principles of Software Engineering Management», Addison Wesley,

(1987).

[Hal75] Μ. Η. Halstead, «Elements of Software Science», Elsevier Publications, N –

Holland, (1975).


Είναι ένα βιβλίο αφιερωµένο κυρίως στο πρότυπο ISO 9001 και στην οδηγία ISO

9000 – 3. Παρόλα αυτά, στο κεφάλαιο 6, θα βρείτε µια καλή παρουσίαση των µετρή-

σεων και πώς αυτές εντάσσονται στα πλαίσια του προτύπου.



1 4 5µ π µ § π √ ° ƒ∞ º π ∞ ∫ ∞ π ¶ ƒ √ ∆∞ ™ ∂ π ™ ° π ∞ ¶ ∂ ƒ∞ π ∆ ∂ ƒ ø ª ∂ § ∂ ∆ ∏

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 145


Όπως αναφέραµε και στο προηγούµενο κεφάλαιο, είναι ένα εύκολο στην ανάγνωση

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

από απόσταση, οπότε θα το βρείτε αρκετά εύκολο στη µελέτη. Για µετρήσεις στο

λογισµικό θα διαβάσετε στο κεφάλαιο 12.

[Jon91] C. Jones, «Applied Software Measurement: Assuring Productivity and

Quality», McGraw Hill, (1991).

Είναι ένα βιβλίο εξειδικευµένο για µετρήσεις. Αν και σχετικά παλιό, θα το βρείτε

αρκετά εύκολο στην ανάγνωση. Απευθύνεται κυρίως σε όσους θέλουν να εµβαθύ-

νουν στις τεχνικές µετρήσεων.

[Mcb76] T. J. McCabe, «A Complexity Measure», IEEE Transactions in Software

Engineering SE – 2(4), (1976).

[Wel00] E. Weller, «Practical Applications of Statistical Process Control», IEEE

Software, Vol. 17, No. 3, (2000).

[Xen96] M. Xenos et al., «The Correlation Between Developer – oriented and User

– oriented Software Quality Measurements (A Case Study)», 5th European

Conference on Software Quality, EOQ – SC, (1996).

Στα αγγλικά δυστυχώς, αλλά αναλύει αυτό που περιγράψαµε στην ενότητα 5.4, δηλα-

δή τη συσχέτιση εσωτερικών και εξωτερικών µετρήσεων. Σε όσους ξέρουν αγγλικά

θα φανεί πολύ χρήσιµο για παραπάνω µελέτη στο συγκεκριµένο θέµα.

[Xen97] M. Xenos and D. Christodoulakis, «Measuring Perceived Software Quality»,

Information Technology Journal, Vol. 39, (1997).


Είναι ένα βιβλίο που αναφέρεται στις διαδικασίες ποιότητας λογισµικού και σε µετρι-

κές διαδικασιών. Ιδανικό για εµβάθυνση στις µετρικές διαδικασιών τις οποίες δεν

αναλύσαµε σε βάθος σε αυτό το βιβλίο.

[Zhe95] F. Zahedi, «Quality Information Systems», International Thomson Publishing

Company, (1995).

Είναι επίσης ένα βιβλίο για ποιότητα λογισµικού και (όπως τα περισσότερα που

πραγµατεύονται την ποιότητα) για µετρήσεις. Στα κεφάλαια 8, 9 και 10 θα διαβά-

σετε για µετρήσεις και µετρικές. Ιδιαίτερα σε αυτό το βιβλίο θα βρείτε για την εφαρ-

µογή του στατιστικού ποιοτικού ελέγχου στο λογισµικό (κεφάλαιο 10).

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 146

¶ÚfiÙ˘· ¶ÔÈfiÙËÙ·˜ §ÔÁÈÛÌÈÎÔ‡

™ÎÔfi˜

Σκοπός του κεφαλαίου 6 είναι να παρουσιάσουµε τα πρότυπα που σχετίζονται µε την

ανάπτυξη του λογισµικού και ειδικότερα τα πρότυπα της σειράς ISO, καθώς και το

Capability Maturity Model (CMM) που είναι πιο εξειδικευµένο στο λογισµικό.



• Περιγράψετε τι είναι ο οργανισµός ISO, ποιους σκοπούς εξυπηρετεί και τι παρέ-

χει στις επιχειρήσεις,

• ορίσετε τα πρότυπα ISO 8402, ISO 9126, ISO 9001, ISO 9002, ISO 9003 και τις

οδηγίες ISO 9000 – 3 και ISO 9004,

• περιγράψετε τη διαδικασία πιστοποίησης µίας επιχείρησης µε ISO 9001,

• αναφέρετε τις βασικές αρχές των απαιτήσεων ποιότητας του προτύπου ISO 9001

και να περιγράψετε το σκοπό της οδηγίας ISO 9000 – 3,

• αναφέρετε τα πλεονεκτήµατα και µειονεκτήµατα σε µία επιχείρηση από την εφαρ-

µογή του προτύπου ISO 9001,

• περιγράψετε το CMM και τους λόγους που οδήγησαν στην ανάπτυξή του,

• εντοπίσετε και να εξηγήσετε τις οµοιότητες και διαφορές ανάµεσα στο ISO 9001

και στο CMM,

• αναφέρετε τα επίπεδα του CMM, να ορίσετε τις βασικές περιοχές της διαδικασίας

και τις βασικές πρακτικές,

• περιγράψετε συνοπτικά τι συµβαίνει στη διαδικασία ανάπτυξης λογισµικού σε κάθε

επίπεδο του CMM.


6∫ ∂ º ∞ § ∞ π √

• Πρότυπο (Standard)

• Τυποποίηση (Standardisation)

• Οδηγία (Guideline)

• Ωριµότητα (Maturity)

• Ικανότητα (Capability)

• Μοντέλο Ωριµότητας Ικανότητας

(Capability Maturity Model)

• Βασικές περιοχές της διαδικασίας

(Key process areas)

• Βασικές πρακτικές (Key practices)

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 147

1 4 8 K E º A § A I O 6 : ¶ ƒ √ ∆ À ¶ ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À


Στο προηγούµενο κεφάλαιο µιλήσαµε για τις µετρήσεις που εντάσσονται σε ένα σύστη-

µα ποιότητας λογισµικού. Σε αυτό το κεφάλαιο, συζητούµε για πρότυπα που σχετίζο-

νται µε την ανάπτυξη του λογισµικού. Ειδικότερα, στην ενότητα 6.1 µε τίτλο τα διε-

θνή πρότυπα ISO, παρουσιάζουµε τον οργανισµό ISO και τα πρότυπά του που σχετί-

ζονται µε την ποιότητα, δίνοντας έµφαση στο πρότυπο ISO 9001 και την οδηγία ISO

9000 – 3. Τέλος, στην ενότητα 6.2 µε τίτλο το πρότυπο αξιολόγησης CMM, παρου-

σιάζουµε το µοντέλο αξιολόγησης CMM, τα επίπεδα ωριµότητάς του και συζητούµε

τις οµοιότητες και διαφορές του CMM µε το ISO 9001.


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

µπορείτε να βρείτε και σύντοµες οδηγίες για το τι επιπλέον µπορείτε να διαβάσετε σε

κάθε βιβλίο.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 148

6.1 ∆· ‰ÈÂıÓ‹ ÚfiÙ˘· ISO

Το πρώτο πρότυπο ISO αναφέρθηκε στην ενότητα 4.1.4 του βιβλίου, όπου παρου-

σιάστηκε το πρότυπο ISO 9126, το οποίο προσδιορίζει τα χαρακτηριστικά που συν-

θέτουν αυτό που ονοµάζουµε ποιότητα λογισµικού. Ο ορισµός του προτύπου δίνε-

ται δίπλα. Στην ενότητα 4.2, παρουσιάζοντας το σύστηµα ποιότητας µίας επιχείρη-

σης, αναφέραµε ότι αυτό βασίζεται σε κάποιο πρότυπο. Αυτό το πρότυπο µπορεί να

είναι κάποιο διεθνές πρότυπο (από κάποιον οργανισµό τυποποίησης) ή ακόµα και

µία εσωτερική για την επιχείρηση τεκµηριωµένη σύµβαση που καθορίζει ένα επί-

πεδο τυποποίησης (standardisation). Συνήθως, όµως, είναι κάποιο διεθνές πρότυπο

µε πιο πιθανό το ISO 9001. Επειδή αναφέρθηκε αρκετές φορές ο οργανισµός ISO,

πριν συνεχίσουµε, ακολουθεί µία συνοπτική παρουσίασή του.

Το 1946, στο Λονδίνο πραγµατοποιήθηκε µία συνάντηση εκπροσώπων από 25 χώρες,

οι οποίοι αποφάσισαν να δηµιουργήσουν ένα νέο διεθνή οργανισµό, µε αντικείµενο

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

οποιουδήποτε τύπου βιοµηχανίας. Το αποτέλεσµα αυτής της απόφασης ήταν η δηµι-

ουργία του διεθνούς οργανισµού για τυποποίηση (International Organisation for

Standardisation) ο οποίος ξεκίνησε να λειτουργεί επίσηµα στις 23 Φεβρουαρίου 1947.

Η συντοµογραφία ISO, που προηγείται στην κωδικοποίηση κάθε προτύπου αυτού

του διεθνούς οργανισµού, παραπέµπει στα αρχικά του ονόµατός του (International

Organisation for Standardisation), αλλά η επιλογή της έγινε από το ελληνικό «ίσος»,

το οποίο είναι η ρίζα του προθέµατος «ίσο» που εµφανίζεται σε ένα πλήθος όρων

όπως «ισοµετρία, ισονοµία». Το πρώτο ISO πρότυπο δηµοσιεύτηκε το 1951 µε τίτλο

«Standard Reference Temperature For Industrial Length Measurement».

Στις µέρες µας, πάνω από 130 χώρες έχουν υιοθετήσει και χρησιµοποιούν τα πρό-

τυπα του οργανισµού ISO. Στην Ευρωπαϊκή Κοινότητα µόνο, πάνω από 75.000 επι-

χειρήσεις βασίζουν την τυποποίησή τους στα πρότυπα του ISO, στις Ηνωµένες Πολι-

τείες, πάνω από 10.000 επιχειρήσεις (ο αριθµός αυτός αυξάνει ραγδαία) και πάνω

από 1.500 επιχειρήσεις στον Καναδά.

Ο οργανισµός ISO εκδίδει πρότυπα (standards) και οδηγίες (guidelines) για την

εφαρµογή των προτύπων. Μερικά από τα πρότυπα του οργανισµού ISO που σχετί-

ζονται µε την ποιότητα και αναφέρθηκαν, ή θα αναφερθούν παρακάτω, είναι τα:

ISO 8402: Περιγράφει το λεξιλόγιο που χρησιµοποιείται όταν µιλάµε για

ποιότητα, δηλαδή όλους τους ορισµούς που χρησιµοποιήσαµε

(εγχειρίδια ποιότητας, αναφορές, διαδικασίες), ώστε να υπάρχει

κοινό λεξιλόγιο σε όλους.

1 4 96 . 1 ∆∞ ¢ π ∂ £ ¡ ∏ ¶ ƒ √ ∆ À ¶ ∞ I S O

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

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 149

1 5 0 K E º A § A I O 6 : ¶ ƒ √ ∆ À ¶ ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

ISO 9126: Πρότυπο που περιγράφει πώς η ποιότητα λογισµικού µπορεί να

διασπαστεί σε παράγοντες ποιότητας και κάθε παράγοντας σε

επιµέρους χαρακτηριστικά, χωρίς να υπάρχει επικάλυψη χαρα-

κτηριστικών ανάµεσα στους παράγοντες.

ISO 9001: Πρότυπο για διασφάλιση ποιότητας στη σχεδίαση, ανάπτυξη,

εγκατάσταση ή παροχή υπηρεσιών (όχι µόνο λογισµικού, αλλά

κάθε είδους προϊόντων).

ISO 9000 – 3: Οδηγίες για την εφαρµογή του προτύπου ISO 9001 στη σχεδία-

ση, ανάπτυξη, προµήθεια (εγκατάσταση, πώληση) και συντήρη-

ση του λογισµικού.

ISO 9002: Πρότυπο για διασφάλιση ποιότητας στην ανάπτυξη (που βασί-

ζεται σε καθορισµένο σχέδιο), εγκατάσταση ή παροχή υπηρεσιών

(όχι µόνο λογισµικού, αλλά κάθε είδους προϊόντων).

ISO 9003: Πρότυπο για διασφάλιση ποιότητας στην τελική επιθεώρηση και

έλεγχο του προϊόντος (όπου προϊόν µπορεί να είναι όχι µόνο το

λογισµικό, αλλά κάθε είδους προϊόν).

ISO 9004: Οδηγίες για τη διοίκηση ενός συστήµατος ποιότητας, δηλαδή για

το πώς µπορεί να αναπτυχθεί και να εφαρµοστεί ένα σύστηµα

ποιότητας.

Από το πρότυπο ISO 8402 χρησιµοποιήσαµε αρκετούς ορισµούς σε αυτό το βιβλίο,

ενώ για το ISO 9126 µιλήσαµε στο κεφάλαιο 4. Ακολούθως, θα αναφερθούµε στη

σειρά ISO 900x (όπου x = 1,2,3) και στην οδηγία ISO 9000 – 3 που αφορά στο λογι-

σµικό. Πολλές φορές όλα τα πρότυπα αυτής της σειράς αναφέρονται και ως ISO

9000 (κακώς κατά την άποψή µου). Η οδηγία ISO 9004 µπορεί και πρέπει να χρη-

σιµοποιείται συνοδευτικά µε κάθε πρότυπο ISO 900x, ώστε να βοηθά στη δηµιουρ-

γία και διαχείριση του συστήµατος ποιότητας.

Από τους παραπάνω ορισµούς των προτύπων είναι φανερό ότι το ISO 9001 είναι το

πιο περιεκτικό και αυστηρό πρότυπο της σειράς. Κατά κάποιο τρόπο καλύπτει όλα τα

απαιτούµενα στοιχεία που αναφέρονται στα ISO 9002 και ISO 9003. Η διαφορά του

ISO 9001 µε το ISO 9002 είναι ως προς την επέκταση του συστήµατος ποιότητας και

στη σχεδίαση. Αντίθετα, το ISO 9002 προϋποθέτει έτοιµα σχέδια στα οποία θα βασι-

στεί η ανάπτυξη. Το ISO 9002 είναι µε τη σειρά του πολύ πιο εκτεταµένο από το ISO

9003, µε βασικότερη διαφορά ότι το ISO 9003 περιορίζει τις απαιτήσεις ποιότητας

στις επιθεωρήσεις και στις δοκιµές και όχι στις δραστηριότητες που επηρεάζουν την

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 150

ποιότητα. Στο τµήµα 6.1.1 που ακολουθεί θα µιλήσουµε πιο αναλυτικά για το πιο

περιεκτικό πρότυπο της σειράς, το ISO 9001 και για την οδηγία ISO 9000 – 3.

1 5 16 . 1 ∆∞ ¢ π ∂ £ ¡ ∏ ¶ ƒ √ ∆ À ¶ ∞ I S O


Από το κεφάλαιο 2 του βιβλίου του Ελληνικού Ανοικτού Πανεπιστηµίου «∆ιασφά-

λιση Ποιότητας: ∆ιοίκηση της Ποιότητας» που σας προτείνουµε (βλέπε βιβλιογρα-

φία στο τέλος του κεφαλαίου), αλλά και από αναζητήσεις σας στο διαδίκτυο, ετοι-

µάστε µία αναφορά που θα περιγράφει τις διαφορές ανάµεσα στα πρότυπα ISO 9001,

ISO 9002 και ISO 9003, αναφέροντας σε ποιες επιχειρήσεις απευθύνεται καθένα από

αυτά. Προσπαθήστε να δώσετε παραδείγµατα επιχειρήσεων από την Ελλάδα (αντλώ-

ντας πληροφορίες από τις σελίδες τους στο διαδίκτυο), χωρίς να ξεπεράσετε τις 1000

λέξεις και συζητήστε την αναφορά σας µε το Σύµβουλο – Καθηγητή σας.

6.1.1 ∆Ô ÚfiÙ˘Ô ISO 9001 Î·È Ë Ô‰ËÁ›· ISO 9000 – 3

Όπως αναφέραµε, το πρότυπο ISO 9001 είναι γενικό και όχι εξειδικευµένο για το λογι-

σµικό. Η πιστοποίηση µιας επιχείρησης ή βιοµηχανίας µε το πρότυπο ISO 9001 απο-

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

κανόνες του προτύπου, αφορά σε ολόκληρη την εταιρεία και απαιτεί προσπάθεια από

την αρχή της διαχείρισης του έργου µέχρι την ολοκλήρωση του προϊόντος. Κάθε επι-

χείρηση που πιστοποιείται µε ISO 9001 ελέγχεται τόσο την πρώτη φορά, ώστε να

πιστοποιηθεί, όσο και περιοδικά (κάθε έξι ή δώδεκα µήνες) από έναν τελείως ανεξάρ-

τητο µε την εταιρεία ελεγκτή, ο οποίος ανήκει σε κάποιο οργανισµό εξουσιοδοτηµέ-

νο να πιστοποιεί µε ISO (στην Ελλάδα υπάρχουν περίπου 10 τέτοιοι οργανισµοί: ο

ΕΛΟΤ που είναι ο δηµόσιος «Ελληνικός Οργανισµός Τυποποίησης», και οι υπόλοι-

ποι που είναι ιδιωτικοί). Ο ελεγκτής κατευθύνεται από αυστηρούς διεθνείς κώδικες και

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

έτσι ώστε να επιβεβαιώνεται η διασφάλιση της ποιότητας σε όλους τους τοµείς της

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

που έχει δοθεί στην εταιρεία. Επιπλέον, το πρότυπο ISO απαιτεί την ύπαρξη προ-

γράµµατος αυτοαξιολόγησης στις πιστοποιηµένες εταιρείες, το οποίο θα είναι υπεύ-

θυνο για τον έλεγχο των ποιοτικών απαιτήσεων και του επιπέδου εφαρµογής τους.

Σε αυτό το σηµείο πρέπει να τονιστεί ότι, γενικά, τα πρότυπα (και κατά συνέπεια και

το ISO 9001) παρέχουν ένα σκελετό για το σύστηµα ποιότητας της επιχείρησης και

καθορίζουν το «τι» πρέπει να γίνει. ∆εν καθορίζουν το «πώς» πρέπει να γίνει κάτι.

Ο τρόπος ενέργειας αποτελεί έργο της επιχείρησης (όσον αφορά στο σχεδιασµό και

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

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 151

1 5 2 K E º A § A I O 6 : ¶ ƒ √ ∆ À ¶ ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

του προτύπου ISO 9001). Το ISO 9001 καθορίζει είκοσι τυποποιηµένα στοιχεία, που

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

χεια. Οι απαιτήσεις που θα οριστούν για το σύστηµα ποιότητας στοχεύουν στην απο-

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

προϊόντος (του λογισµικού για την περίπτωσή µας) µέχρι την εγκατάστασή του στο

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

για τη χρήση του λογισµικού). Οι απαιτήσεις του ISO 9001 δίνονται συνοπτικά:

1. Ευθύνη διοίκησης (management responsibility), που περιλαµβάνει την πολιτι-

κή ποιότητας (quality policy) την οργάνωση, την ευθύνη και εξουσιοδότηση,

τον έλεγχο των πηγών (πρώτων υλών για τη βιοµηχανία) και του προσωπικού.

2. Σύστηµα ποιότητας (quality system).

3. Ανασκόπηση συµβάσεων (contract review).

4. Έλεγχος σχεδιασµού (design control), που περιλαµβάνει τον αρχικό σχεδιασµό

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

(organizational and technical interfaces), τα στοιχεία εισόδου και εξόδου και τον

έλεγχο αλλαγών.

5. Έλεγχος εγγράφων (document control), που περιλαµβάνει την έγκριση και έκδο-

ση εγγράφων (document approval and issue) και τις αλλαγές ή µετατροπές

εγγράφων.

6. Αγορές (purchasing), που περιλαµβάνει την αξιολόγηση των υπεργολάβων

(assessment of sub – contractor) και τα δεδοµένα σχετικά µε την αγοραστική

ικανότητα.

7. Έλεγχος του προϊόντος που παρέχεται από τον προµηθευτή (purchaser supplied

product).

8. Αναγνώριση ταυτότητας και ανιχνευσιµότητα του προϊόντος (product

identification and traceability).

9. Έλεγχος της διεργασίας ανάπτυξης (process control).

10. Επισκόπηση και πειραµατικός έλεγχος (inspection and testing), που περιλαµ-

βάνει την επισκόπηση και τον πειραµατικό έλεγχο κατά την ανάπτυξη (in –

process inspection and testing), την τελική επισκόπηση και τον τελικό έλεγχο

(final inspection and testing) και την τήρηση αρχείων για την επισκόπηση και

τον πειραµατικό έλεγχο (inspection and test records).

11. Έλεγχος εξοπλισµού επισκόπησης, υπολογισµών και µετρήσεων (inspection,

measuring and test equipment).

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 152

12. Κατάσταση ελέγχων και επισκοπήσεων (inspection and test status).

13. Έλεγχος µη συµµορφούµενων προϊόντων (control of nonconforming product).

14. ∆ιορθωτικές και προληπτικές ενέργειες (corrective and preventive actions).

15. ∆ιακίνηση, αποθήκευση, συσκευασία και διανοµή (handling, storage, packaging

and delivery).

16. Αρχεία για την ποιότητα (quality records).

17. Εσωτερικές περιοδικές επιθεωρήσεις ποιότητας (internal quality audits).

18. Εκπαίδευση (training).

19. Εξυπηρέτηση (servicing).

20. Στατιστικές τεχνικές (statistical techniques).

Σε αυτό το σηµείο πρέπει να τονιστεί ότι το πρότυπο ISO 9001 δεν περιέχει τεχνι-

κές που θα µπορούσαν να ενταχθούν στο σύστηµα ποιότητας κάποιας επιχείρησης.

Κάτι τέτοιο δεν θα ήταν εφικτό, αφού το πρότυπο σκόπιµα είναι τόσο γενικό, ώστε

να απευθύνεται και σε µία βιοµηχανία που, για παράδειγµα, παράγει χρώµατα, αλλά

και σε µία επιχείρηση που αναπτύσσει λογισµικό, ή σε µία βιοτεχνία που σχεδιάζει

και παράγει υποδήµατα. Το πρότυπο παρέχει οδηγίες προς την επιχείρηση για το πού

πρέπει να χρησιµοποιεί τεχνικές ελέγχου και ποιες απαιτήσεις πρέπει να εκπληρώ-

νει, ώστε να είναι κατάλληλη να πιστοποιηθεί µε το ISO 9001. Σε αυτό το σηµείο

της µελέτης σας και πριν προχωρήσετε στη µελέτη της οδηγίας ISO 9000 – 3, προ-

σπαθήστε να υλοποιήσετε τη δραστηριότητα 6.2.

1 5 36 . 1 ∆∞ ¢ π ∂ £ ¡ ∏ ¶ ƒ √ ∆ À ¶ ∞ I S O


Ετοιµάστε µία αναφορά που θα σχετίζει κάθε µία από τις 20 απαιτήσεις του ISO 9001

µε λειτουργίες τµηµάτων µιας επιχείρησης λογισµικού. Πείτε ποιες αφορούν τη διοί-

κηση, το τµήµα ποιότητας, το τµήµα σχεδίασης, το τµήµα marketing, το τµήµα προ-

γραµµατισµού, το τµήµα ελέγχου, κτλ. Για την αναφορά αυτή µπορείτε να βρείτε

σηµαντική βοήθεια (αλλά όχι την απάντηση!) στο κεφάλαιο 3 του βιβλίου του Ελλη-

νικού Ανοικτού Πανεπιστηµίου «∆ιασφάλιση Ποιότητας: ∆ιοίκηση της Ποιότητας»

που σας προτείνουµε (βλέπε βιβλιογραφία στο τέλος του κεφαλαίου). Εκεί, θα βρεί-

τε τη σχετική απάντηση για βιοµηχανίες, ενώ εµείς σας τη ζητούµε για επιχειρήσεις

που παράγουν λογισµικό. Προσπαθήστε να παρουσιάσετε την απάντησή σας σε

µορφή πίνακα και συζητήστε την αναφορά σας µε το Σύµβουλο – Καθηγητή σας.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 153

1 5 4 K E º A § A I O 6 : ¶ ƒ √ ∆ À ¶ ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

Ακριβώς επειδή το πρότυπο ISO 9001 είναι πολύ γενικό, πολλές επιχειρήσεις και

κυρίως οι επιχειρήσεις που αναπτύσσουν λογισµικό, αντιµετωπίζουν πρόβληµα στην

προσπάθειά τους να το εφαρµόσουν. Αυτό συµβαίνει γιατί το λογισµικό παρουσιά-

ζει µια ιδιαιτερότητα που οφείλεται σε τρεις αιτίες:

• Η φύση των διαδικασιών ανάπτυξης στο λογισµικό διαφέρει, στην ουσία της, από

αυτή στη βιοµηχανική παραγωγή. Αυτό που στο λογισµικό είναι η βάση της ανά-

πτυξης, στη βιοµηχανική παραγωγή θα έµοιαζε ως διαδικασία σχεδίασης. Αντί-

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

παραγωγή σε πολλά αντίγραφα ενός τυποποιηµένου προϊόντος), στο λογισµικό είναι

ασήµαντη (αφού το λογισµικό «αναπαράγεται» σε αντίτυπα µε σχεδόν µηδενικό

κόστος και προσπάθεια και η βιοµηχανική ανάπτυξη περιορίζεται µόνο στην ανα-

παραγωγή των εγχειριδίων και των µέσων στα οποία αποθηκεύεται το λογισµικό).

• Ο κύκλος ζωής του λογισµικού, δηλαδή το πλαίσιο ανάπτυξης της διαδικασίας, παί-

ζει έναν ιδιαίτερα βασικό ρόλο. Για αυτό πρέπει να δοθεί σε αυτό η απαιτούµενη

έµφαση, δηλαδή να καθοριστεί ο κύκλος ζωής, ως περιγραφή της διαδικασίας ανά-

λυσης – σχεδιασµού – ανάπτυξης – ελέγχου – συντήρησης, και να καταχωρηθεί σε

ένα κατευθυντήριο έγγραφο που εντάσσεται στις απαιτήσεις του προτύπου.

• Κάποιες δραστηριότητες της παραγωγής λογισµικού, όπως η διαχείριση εκδόσεων

(που δεν είναι σηµαντική, ή λείπει από την παραγωγή υλικών αγαθών), παίζουν

έναν ιδιαίτερα βοηθητικό ρόλο στην ανάπτυξη και για αυτό πρέπει να τονιστεί η

σηµασία τους. Επίσης, σε αυτές τις δραστηριότητες πρέπει να αναφέρονται όροι

µε τους οποίους οι προγραµµατιστές να είναι εξοικειωµένοι, αφού οι όροι του ISO

9001 είναι προσανατολισµένοι στη βιοµηχανική παραγωγή υλικών αγαθών.

Για τους παραπάνω λόγους δηµιουργήθηκε η οδηγία ISO 9000 – 3, που χρησιµο-

ποιείται για την εξειδίκευση του ISO 9001 στην ανάπτυξη λογισµικού.

Ολοκληρώνοντας για το ISO 9001 και την οδηγία ISO 9000 – 3, θα αναφέρουµε πλε-

ονεκτήµατα αλλά και µειονεκτήµατα από την εφαρµογή του σε κάποια επιχείρηση.

Το ISO 9001 αποτελεί πρότυπο ποιότητας για αποτελεσµατική διαχείριση των διερ-

γασιών ανάπτυξης. Με άλλα λόγια, εµπίπτει στην κατηγορία των µεθοδολογιών βελ-

τίωσης διεργασίας (process improvement methodologies). Πιο συγκεκριµένα, καθο-

ρίζει τα απαραίτητα χαρακτηριστικά για τη σωστή ανάπτυξη του προϊόντος, θέτο-

ντας την αναγκαιότητα εκπλήρωσης κάποιων καθορισµένων απαιτήσεων ποιότητας.

Στόχος του είναι η βελτίωση της διεργασίας ανάπτυξης. Όπως αναφέραµε, το ISO

9001 καθορίζει το «τι» πρέπει να εκτελέσει ένας οργανισµός και όχι το «πώς» να το

πραγµατοποιήσει, συνεπώς αποτελεί ένα πλαίσιο, µια κατευθυντήρια γραµµή µοντε-

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 154

λοποίησης. Το γεγονός αυτό δίνει το πλεονέκτηµα σε µία επιχείρηση να έχει ένα

µεγάλο φάσµα επιλογών για το πώς να χειριστεί την κάθε απαίτηση ποιότητας (που

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

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

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

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

τουργίας. Παρόλα αυτά, οι περισσότερες επιχειρήσεις προτιµούν να έχουν πολλές

επιλογές στον καθορισµό του συστήµατος ποιότητάς τους.

Το ISO 9001 αποτελείται από ένα σύνολο απαιτήσεων ποιότητας, είναι δοµηµένο

δηλαδή µε βάση µία συνεχή αρχιτεκτονική (continuous architecture), γεγονός που

σηµαίνει ότι το µοντέλο δεν είναι δοµηµένο σε επίπεδα. Η συνεχής αρχιτεκτονική

προσφέρει µεγάλη ευελιξία, όσον αφορά στην εκτέλεση των δραστηριοτήτων, αφού

επιτρέπει στον κάθε οργανισµό να αποφασίσει για την προτεραιότητα και τη διάτα-

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

σύστηµα ποιότητας της επιχείρησης, αν αυτό κρίνεται απαραίτητο, χωρίς να αλλά-

ζει η πιστοποίηση κατά ISO.

Τέλος, το βασικότερο πλεονέκτηµα της πιστοποίησης µε ISO 9001 είναι ότι η επι-

χείρηση βεβαιώνει µε αυτή την πιστοποίηση την ικανότητά της να τηρεί διαδικασίες

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

των προϊόντων που παράγει.

Αναλύοντας τα µειονεκτήµατα, πρέπει να αναφέρουµε ότι το βασικότερο µειονέ-

κτηµα που προκύπτει από την εφαρµογή του προτύπου ISO 9001 είναι ότι αυτό

καθορίζει τις ελάχιστες απαιτήσεις ενός συστήµατος ποιότητας, δηλαδή δεν αποτε-

λεί ένα πλήρες σύστηµα διασφάλισης ποιότητας για έναν οργανισµό. Επίσης, λόγω

της γενικότητάς του, δεν λαµβάνει υπόψη του τις ιδιαιτερότητες του κάθε προϊόντος,

ώστε να είναι ικανό να προβλέψει κάθε πιθανό πρόβληµα και να θέσει µια πορεία

αντιµετώπισής του. Επίσης, το ISO 9001 δεν δίνει την απαραίτητη έµφαση στη συνε-

χή βελτίωση των διεργασιών ανάπτυξης της επιχείρησης. Αυτό, ίσως, εµπεριέχεται

στην απαίτηση ποιότητας «∆ιορθωτικές και προληπτικές ενέργειες (corrective and

preventive actions), αλλά επειδή ο ανταγωνισµός που επικρατεί σήµερα θέτει τη βελ-

τίωση της ποιότητας ως τον πιο σηµαντικό στόχο µιας επιχείρησης, θεωρείται ότι

ένα πρότυπο ποιότητας πρέπει να εστιάζει σε αυτό το σηµείο πιο δυναµικά. Τέλος,

το ISO 9001 διακρίνεται από µία ασάφεια σχετικά µε το ρόλο της µέτρησης σε ένα

σύστηµα διαχείρισης ποιότητας. Με άλλα λόγια, θέτει µεν την απαίτηση ένας οργα-

νισµός να τεκµηριώνει τα αντικείµενα ποιότητας, αλλά δεν θεωρεί ότι είναι ανα-

γκαία η ποσοτικοποίησή τους.

1 5 56 . 1 ∆∞ ¢ π ∂ £ ¡ ∏ ¶ ƒ √ ∆ À ¶ ∞ I S O

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 155

1 5 6 K E º A § A I O 6 : ¶ ƒ √ ∆ À ¶ ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

6.2 ∆Ô ÚfiÙ˘Ô ·ÍÈÔÏfiÁËÛË˜ CMM

Σε αυτή την ενότητα θα µιλήσουµε για το µοντέλο ωριµότητας ικανότητας

(Capability Maturity Model), που από αυτό το σηµείο και µετά θα το ονοµάζουµε

CMM. To CMM είναι ένα µοντέλο αξιολόγησης που εξελίχθηκε σταδιακά σε πρό-

τυπο όχι µόνο αξιολόγησης, αλλά και πρότυπο ποιότητας λογισµικού –ακολουθώντας

τις οδηγίες για κάθε βασική περιοχή της διαδικασίας (key process area) που θα συζη-

τήσουµε παρακάτω. Στο τµήµα 6.2.1 που ακολουθεί, παρουσιάζουµε συνοπτικά το

CMM, τους λόγους που οδήγησαν στη δηµιουργία του και την εξέλιξή του. Στο τµήµα

6.2.2, παρουσιάζονται οι οµοιότητες και διαφορές του CMM µε το ISO 9001, ενώ

στο τµήµα 6.2.3 παρουσιάζονται τα πέντε επίπεδα ωριµότητας σύµφωνα µε το CMM.






i) Το πρότυπο ISO 9001 αφορά στη διασφάλιση ποιότητας

στη βιοµηχανική παραγωγή, ενώ το πρότυπο ISO 9000 – 3

στην ανάπτυξη λογισµικού.

ii) Για να πιστοποιηθεί µία επιχείρηση µε το πρότυπο ISO 9001

πρέπει να ικανοποιεί τις 20 απαιτήσεις του προτύπου.

iii)Η πιστοποίηση µε το πρότυπο ISO 9001 σε µία επιχείρηση

γίνεται από έναν εξωτερικό ελεγκτή µία φορά και ισχύει

για πάντα.

iv) Το γεγονός ότι το πρότυπο ISO 9001 είναι πολύ γενικό είναι

και πλεονέκτηµα (γιατί επιτρέπει µεγάλη ελευθερία

στην επιχείρηση να εφαρµόσει το δικό της σύστηµα

ποιότητας), αλλά και µειονέκτηµα (γιατί λόγω

της γενικότητάς του, δεν λαµβάνει υπόψη του

τις ιδιαιτερότητες του κάθε προϊόντος, ώστε να είναι ικανό

να προβλέψει κάθε πιθανό πρόβληµα και να θέσει

µια πορεία αντιµετώπισής του).

v) Το ISO 9001 δεν είναι απόλυτα σαφές στο θέµα

των µετρήσεων για τη βελτίωση της ποιότητας.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 156

6.2.1 √ÚÈÛÌfi˜ Î·È ÂÍ¤ÏÈÍË ÙÔ˘ CMM

Η βασική ιδέα που οδήγησε στο CMM είναι η βελτίωση της διαδικασίας ανάπτυξης

λογισµικού και η συνεπέστερη εφαρµογή της στα πλαίσια µίας επιχείρησης. Το πρό-

βληµα, όµως, είναι ότι η θέσπιση στόχων για τη βελτίωση αυτής της διαδικασίας

σχετίζεται άµεσα µε την ωριµότητα (maturity) της κάθε επιχείρησης. Πιο απλά,

µόνο µία ώριµη επιχείρηση ανάπτυξης λογισµικού έχει την ικανότητα (capability)

διαχείρισης της ανάπτυξης του λογισµικού, καθώς και βελτίωσης των σχετικών δια-

δικασιών ανάπτυξης, µε σκοπό την ικανοποίηση του πελάτη. Αντίθετα, σε µία ανώ-

ριµη επιχείρηση, η διαδικασία ανάπτυξης λογισµικού βασίζεται στον αυτοσχεδια-

σµό των µηχανικών κατά τη διάρκεια του έργου. Τα παραπάνω δείχνουν ότι είναι

επιτακτική η ανάγκη ανάπτυξης ενός πλαισίου ωρίµανσης, το οποίο θα προσδιορί-

ζει την ικανότητα της επιχείρησης να καθορίζει και να διαχειρίζεται τη διαδικασία

ανάπτυξης λογισµικού. Το πλαίσιο αυτό περιγράφει ένα εξελικτικό µονοπάτι από

τυχαίες και χαοτικές διαδικασίες ανάπτυξης σε ώριµες και πειθαρχηµένες διαδικα-

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

Με δεδοµένη την ύπαρξη της κατάστασης αυτής το Νοέµβριο του 1986, το Ινστι-

τούτο Τεχνολογίας Λογισµικού (Software Engineering Institute) του Carnegie Mellon

University ξεκίνησε την ανάπτυξη πλαισίου ωρίµανσης διαδικασιών, µε στόχο την

προσφορά βοήθειας στους οργανισµούς προς την κατεύθυνση της βελτίωσης της

ικανότητάς τους να αναπτύσσουν λογισµικό. Έπειτα από τέσσερα χρόνια έρευνας

σχετικά µε το πλαίσιο ωριµότητας της διαδικασίας λογισµικού, το Ινστιτούτο Τεχνο-

λογίας Λογισµικού αναπτύσσει και εξελίσσει το πλαίσιο αυτό στο µοντέλο ωριµό-

τητας ικανότητας (CMM) για λογισµικό. Η έκδοση 1.1 του CMM [Pau93], στην

οποία αναφερόµαστε δηµοσιεύτηκε το 1993.

Συνοπτικά, το CMM είναι ένα µοντέλο που παρέχει συστηµατική δόµηση ενός συνό-

λου εργαλείων (συµπεριλαµβανοµένου ενός ερωτηµατολογίου αξιολόγησης της ωρι-

µότητας µίας επιχείρησης), µε αντικειµενικό σκοπό τη βελτίωση της ικανότητας παρα-

γωγής λογισµικού. Το ίδιο το µοντέλο αποτελεί τη βάση για τη βελτίωση της διαδι-

κασίας ανάπτυξης λογισµικού. Αν θέλαµε να το ορίσουµε απλά, θα λέγαµε ότι το

CMM είναι ένα µοντέλο µε το οποίο µπορεί µία επιχείρηση να αξιολογήσει πόσο

ώριµη είναι σχετικά µε την ικανότητά της να αναπτύσσει λογισµικό. Η αξιολό-

γηση βασίζεται σε κάποια κριτήρια (ένα αναλυτικό ερωτηµατολόγιο), κάτι αντίστοι-

χο δηλαδή µε τις 20 απαιτήσεις του ISO 9001. Πέρα από αυτό, όµως, το CMM παρέ-

χει και µία σειρά από βασικές περιοχές της διαδικασίας (key process areas) όπως

τις ονοµάζει, οι οποίες δίνουν οδηγίες για το τι πρέπει να έχει εντάξει µία επιχείρηση

στη διαδικασία ανάπτυξης ώστε να βρίσκεται σε κάποιο επίπεδο ωριµότητας. Αυτές

1 5 76 . 2 ∆ √ ¶ ƒ √ ∆ À ¶ √ ∞ • π √ § √ ° ∏ ™ ∏ ™ C M M

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 157

1 5 8 K E º A § A I O 6 : ¶ ƒ √ ∆ À ¶ ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

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

πο ποιότητας που βοηθά την κάθε επιχείρηση να βελτιώνεται βήµα µε βήµα.

Αυτή η δυνατότητα του CMM να βοηθά την επιχείρηση να εξελίσσεται σταδιακά, σε

συνδυασµό µε την εξειδίκευσή του αποκλειστικά για την ανάπτυξη λογισµικού, το

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

επιχειρήσεων που αναπτύσσουν λογισµικό παγκοσµίως. Έτσι πέρα από αυτό που ήταν

όταν αρχικά ξεκίνησε (ένα µοντέλο αξιολόγησης της ωριµότητας των επιχειρήσεων),

το CMM σήµερα καθορίζει τις διαδικασίες ποιότητας των επιχειρήσεων.




α) Το CMM είναι ένα …………… αξιολόγησης που εξελίχθηκε σε

………………. ποιότητας λογισµικού.

(πρότυπο, σύστηµα, µοντέλο, εγχειρίδιο) (πρότυπο, σύστηµα, µοντέλο, εγχειρίδιο)

β) Μία …………… επιχείρηση ανάπτυξης λογισµικού έχει …………… διαχείρι-

σης της ανάπτυξης του λογισµικού.

(ικανή, ώριµη, πιστοποιηµένη) (ωριµότητα, ικανότητα, εµπειρία)

γ) Το CMM είναι ένα µοντέλο µε το οποίο µπορεί µία επιχείρηση να αξιολογήσει

πόσο …………… είναι σχετικά µε την ……………… να αναπτύσσει λογισµι-

κό.

(ικανή, ώριµη, έµπειρη) (ωριµότητά της, ικανότητά της, εµπειρία της)

δ) Tο CMM βοηθά την επιχείρηση να εξελίσσεται ………………………………

(γρήγορα, σταδιακά, οικονοµικά, αξιόπιστα)

6.2.2 CMM Î·È ISO 9001: √ÌÔÈfiÙËÙÂ˜ Î·È ‰È·ÊÔÚ¤˜

Το ISO 9001 µε το CMM έχουν σηµαντικές οµοιότητες, αλλά και διαφορές [Pau94].

Βασική τους οµοιότητα είναι ότι και τα δύο αποτελούν πρότυπα ποιότητας για απο-

τελεσµατική διαχείριση των διαδικασιών ανάπτυξης λογισµικού. Και τα δύο παρέ-

χουν µεθοδολογίες βελτίωσης της διαδικασίας ανάπτυξης (process improvement

methodologies), δηλαδή, καθορίζουν τα απαραίτητα χαρακτηριστικά για τη «σωστή»

ανάπτυξη του προϊόντος, προς την κατεύθυνση της εκπλήρωσης κάποιων απαιτή-

σεων ποιότητας.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 158

Άλλη οµοιότητά τους έγκειται στον τρόπο εφαρµογής τους. Μία επιχείρηση πιστο-

ποιείται µε ISO 9001 από κάποιον εξωτερικό ελεγκτή και η πιστοποίηση αυτή επι-

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

επίπεδο ωριµότητάς της στο CMM, πάλι από κάποιον εξωτερικό ελεγκτή και αυτή

η αξιολόγηση επίσης επαναλαµβάνεται περιοδικά.

Σηµαντική οµοιότητα των ISO 9001 και CMM είναι το γεγονός ότι και τα δύο δεν

καθορίζουν µία συγκεκριµένη διαδικασία ανάπτυξης. Αντίθετα προσφέρουν καθο-

δήγηση στους υπεύθυνους για την ανάπτυξη διαδικασιών, για τον καθορισµό των

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

ανάπτυξης. Πιο απλά, τόσο το CMM όσο και το ISO 9001 καθορίζουν «τι» πρέπει

να κάνει µία επιχείρηση και όχι «πώς» να το κάνει. Στο σηµείο αυτό, πρέπει να τονι-

στεί ότι το CMM είναι πολύ πιο αναλυτικό και παρέχει πολύ πιο συγκεκριµένες

κατευθύνσεις από το ISO 9001 που είναι πιο γενικό. Χαρακτηριστικό των οµοιοτή-

των είναι ότι, ανάµεσα σε πολλές από τις απαιτήσεις του ISO 9001 και τις βασικές

περιοχές του CMM, υπάρχει άµεση αντιστοίχηση. Βέβαια, δεν υπάρχει ένα προς ένα

αντιστοιχία, αφού τότε τα δύο µοντέλα θα ταυτίζονταν.

Βασική διαφορά των δύο προτύπων είναι ότι, ενώ το CMM είναι εξειδικευµένο απο-

κλειστικά για το λογισµικό, το ISO 9001 είναι ένα γενικό πρότυπο που περιλαµβά-

νει κάθε είδους προϊόν (συµπεριλαµβανοµένου φυσικά και του λογισµικού) καθώς

και την παροχή υπηρεσιών προς τους πελάτες. Για αυτό το λόγο το CMM, είναι πολύ

πιο ειδικό και πιο εύκολα εφαρµόσιµο στο λογισµικό.

Άλλη διαφορά τους έγκειται στη φιλοσοφία βελτίωσης. Πιο συγκεκριµένα, το CMM

δίνει έµφαση στην ανάγκη για συνεχή βελτίωση των διαδικασιών ανάπτυξης. Ενώ

το ISO 9001 καθορίζει τις ελάχιστες απαιτήσεις ενός συστήµατος ποιότητας, το

CMM αντιµετωπίζει το ζήτηµα της συνεχούς βελτίωσης µε πολύ µεγαλύτερη σαφή-

νεια και θέτει, ως ανώτερο επίπεδο ωριµότητας µιας επιχείρησης, αυτό στο οποίο το

πρόγραµµα ποιότητας της επιχείρησης βελτιώνεται συστηµατικά.

∆ιαφορά, επίσης, αποτελεί το γεγονός ότι, στο CMM, µία επιχείρηση µπορεί να βρί-

σκεται σε ένα από πέντε διακριτά επίπεδα ωριµότητας και κάθε επίπεδο δηµιουργεί

τις προϋποθέσεις για τα επόµενα επίπεδα, µε στόχο την εφαρµογή των διαδικασιών

ανάπτυξης αποτελεσµατικά και αποδοτικά. Αντίθετα, το ISO 9001 καθορίζει τις απαι-

τήσεις του συστήµατος ποιότητας µε τη µορφή µιας σειράς απαιτήσεων, τις οποίες

η επιχείρηση είτε ικανοποιεί, είτε όχι.

Πέρα από τις παραπάνω διαφορές, υπάρχουν και µικροδιαφορές ανάµεσα στις απαι-

τήσεις του ISO 9001 και στις βασικές περιοχές του CMM, που συνήθως αναφέρο-

1 5 96 . 2 ∆ √ ¶ ƒ √ ∆ À ¶ √ ∞ • π √ § √ ° ∏ ™ ∏ ™ C M M

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 159

1 6 0 K E º A § A I O 6 : ¶ ƒ √ ∆ À ¶ ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

νται σε ελλείψεις του ISO 9001 (όπως για παράδειγµα στον καθορισµό διαδικασιών

µέτρησης), αλλά δεν είναι σηµαντικές. Μία επιχείρηση µπορεί να είναι πιστοποιη-

µένη µε ISO 9001 και ταυτόχρονα να έχει αξιολογηθεί σε κάποιο επίπεδο του CMM.

Συνήθως, µία επιχείρηση πρέπει να φτάσει στο 2ο επίπεδο του CMM και να διαθέ-

τει κάποιες βασικές περιοχές και του 3ου επίπεδου (θα µιλήσουµε αργότερα για τα

επίπεδα του CMM), ώστε να µπορέσει να πιστοποιηθεί µε ISO 9001. Στην Ευρώπη,

οι περισσότερες επιχειρήσεις που αναπτύσσουν λογισµικό είναι αξιολογηµένες µε

CMM και πιστοποιηµένες µε ISO 9001.

6.2.3 ∂›Â‰· ˆÚÈÌfiÙËÙ·˜ ÛÙÔ CMM

Μία επιχείρηση που αξιολογείται µε CMM µπορεί να βρίσκεται σε ένα από πέντε

επίπεδα. Η αξιολόγηση µε CMM βοηθά την επιχείρηση να «ξέρει πού βρίσκεται»,

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

γνωρίζει πού βρίσκεται, έτσι ώστε να προδιαγράψει πού θέλει να φτάσει, τότε θα

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

επίπεδα ωριµότητας του CMM είναι τα:

1. Αρχικό (Initial)

2. Επαναλαµβανόµενο (Repeatable)

3. Καθορισµένο (Defined)

4. ∆ιοικούµενο (Managed)

5. Βελτιστοποίησης (Optimising)

Με εξαίρεση το επίπεδο 1, κάθε επίπεδο αποτελείται από ένα σύνολο βασικών

περιοχών µιας διαδικασίας (key process areas), στις οποίες µία επιχείρηση πρέπει

να εστιάσει για τη βελτίωση των διαδικασιών ανάπτυξης λογισµικού. Αναλυτικά,

µία βασική περιοχή µιας διαδικασίας περιέχει µία δέσµη συσχετιζόµενων δραστη-

ριοτήτων, οι οποίες, όταν εκτελεστούν συλλογικά, οδηγούν στην επίτευξη ενός συνό-

λου από στόχους σηµαντικούς για την απόκτηση ικανότητας διαχείρισης της διαδι-

κασίας ανάπτυξης. Κάθε βασική περιοχή περιλαµβάνει ένα σύνολο από βασικές

πρακτικές (key practices), οι οποίες πιστοποιούν αν η διαδικασία και η βασική

περιοχή είναι αποτελεσµατική, επαναλαµβανόµενη και διαρκής.

Έτσι, το µοντέλο του CMM παρέχει στην επιχείρηση 5 επίπεδα, βασικές περιοχές

(αντίστοιχες µε τις απαιτήσεις του ISO 9001) για κάθε επίπεδο και βασικές πρακτι-

κές (που βοηθούν στην ανάλυση των βασικών περιοχών σε µεγάλο βαθµό λεπτοµέ-

ρειας, πράγµα που έλειπε από το ISO 9001) για κάθε περιοχή. ∆εν θα προχωρήσου-

«Αν δεν ξέρειςπου πηγαίνεις,

τότε θα φτάσειςσίγουρα εκεί».

Παλιά κινέζικηπαροιµία.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 160

µε στην ανάλυση όλων των βασικών περιοχών και των βασικών πρακτικών, σας

καλούµε όµως να υλοποιήσετε τη δραστηριότητα 6.3 που ακολουθεί. Σήµερα, στον

κόσµο, πολύ λίγες επιχειρήσεις λογισµικού βρίσκονται στο επίπεδο 5. Στην Ελλάδα,

οι περισσότερες επιχειρήσεις είναι στο επίπεδο 1 µε λίγες στο επίπεδο 2, ελάχιστες

στο 3 και καµία στο 4 και 5. Συνοπτικά, τι συµβαίνει σε µία επιχείρηση σε κάθε επί-

πεδο ωριµότητας του CMM, περιγράφεται στα τµήµατα που ακολουθούν µετά τη

δραστηριότητα 6.3.

1 6 16 . 2 ∆ √ ¶ ƒ √ ∆ À ¶ √ ∞ • π √ § √ ° ∏ ™ ∏ ™ C M M


Από τις πηγές που σας αναφέρουµε στη βιβλιογραφία και από αναζητήσεις στο δια-

δίκτυο (για παράδειγµα µια επίσκεψη στον κόµβο του Software Engineering

Institute µπορεί να είναι πολύ καλή ιδέα), ετοιµάστε µία αναφορά που θα παρου-

σιάζει σε λιγότερες από 2000 λέξεις τις βασικές περιοχές για κάθε επίπεδο και τις

βασικές πρακτικές για κάθε περιοχή. Συζητήστε την αναφορά σας µε το Σύµβου-

λο – Καθηγητή σας.

Επίπεδο 1 – Αρχικό Επίπεδο

Στο επίπεδο αυτό, η διαδικασία ανάπτυξης λογισµικού είναι τυχαία και χαοτική.

Πολύ λίγες διαδικασίες είναι καθορισµένες και η επιτυχία εξαρτάται από την ατοµι-

κή προσπάθεια. Η επιχείρηση δεν παρέχει ένα σταθερό περιβάλλον για την ανάπτυ-

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

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

λογισµικού δεν είναι προβλέψιµες (άρα και οι δυνατότητες και προοπτικές της επι-

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

διάρκεια της εξέλιξης του έργου. Γενικά, σε αυτό το επίπεδο, τα προγράµµατα, οι

προϋπολογισµοί, η λειτουργικότητα και η ποιότητα του προϊόντος είναι µη προβλέ-

ψιµοι παράγοντες.

Επίπεδο 2 – Επαναλαµβανόµενο Επίπεδο

Στο επίπεδο αυτό εγκαθιδρύονται οι βασικές διαδικασίες διαχείρισης του έργου για

την εκτίµηση κόστους, το χρονοπρογραµµατισµό, την παρακολούθηση (monitoring)

και τον καθορισµό της λειτουργικότητας. Υπάρχει πειθαρχία στην ανάπτυξη του

έργου, µε στόχο την επανάληψη προηγούµενων επιτυχιών σε έργα µε παρόµοια

χαρακτηριστικά. Ο σχεδιασµός και η διαχείριση νέων έργων βασίζονται στην προη-

γούµενη εµπειρία παρόµοιων έργων. Συνεπώς, βασική προϋπόθεση για την αξιολό-

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 161

1 6 2 K E º A § A I O 6 : ¶ ƒ √ ∆ À ¶ ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

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

γασιών διαχείρισης για έργα λογισµικού, οι οποίες να επιτρέπουν την επανάληψη

των επιτυχηµένων διαδικασιών προηγούµενων έργων. Η ικανότητα της διαδικασίας

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

πειθαρχηµένη (disciplined), επειδή ο σχεδιασµός και η παρακολούθηση του έργου

είναι σταθεροί παράγοντες και προηγούµενες επιτυχίες µπορούν να επαναληφθούν.

Επίπεδο 3 – Καθορισµένο Επίπεδο

Σε αυτό το επίπεδο, οι διαδικασίες για την ανάπτυξη και διαχείριση είναι τεκµη-

ριωµένες, τυποποιηµένες και ολοκληρωµένες σε µία καθορισµένη διαδικασία για

όλη την επιχείρηση. Ο οργανισµός εκµεταλλεύεται αποτελεσµατικά τις αρχές τεχνο-

λογίας λογισµικού, χρησιµοποιώντας τυποποιηµένες διαδικασίες ανάπτυξης. Η συνο-

λική καθορισµένη διαδικασία της επιχείρησης συµπεριλαµβάνει πρότυπα και τεχνι-

κές για την ολοκλήρωση επιµέρους εργασιών, µετρικές και µηχανισµούς ελέγχου

και επαλήθευσης. Η ικανότητα της διαδικασίας ανάπτυξης λογισµικού στους οργα-

νισµούς του επιπέδου αυτού χαρακτηρίζεται ως τυποποιηµένη (standard) και συνε-

πής (consistent) και βασίζεται στην κατανόηση των δραστηριοτήτων, των ρόλων και

των υπευθυνοτήτων στη λειτουργία της επιχείρησης.

Επίπεδο 4 – ∆ιοικούµενο Επίπεδο

Σε αυτό το επίπεδο ωριµότητας, πραγµατοποιείται συλλογή καθορισµένων µετρή-

σεων που αφορούν στη διαδικασία ανάπτυξης και την ποιότητα των προϊόντων, µε

συνέπεια τόσο οι διαδικασίες, όσο και τα προϊόντα να αξιολογούνται µε ποσοτικά

δεδοµένα. Με άλλα λόγια, ο οργανισµός θέτει ποσοτικούς στόχους ποιότητας για τις

διαδικασίες ανάπτυξης και το ίδιο το λογισµικό, ενώ η παραγωγικότητα και η ποιό-

τητα µετρώνται κατά τη διάρκεια εκτέλεσης όλων των έργων και εντάσσονται σε

ένα πρόγραµµα µέτρησης. Η ικανότητα της διαδικασίας ανάπτυξης λογισµικού στους

οργανισµούς του επιπέδου αυτού χαρακτηρίζεται ως προβλέψιµη (predictable) και

λειτουργεί µέσα σε καθορισµένα όρια. Σε περίπτωση υπέρβασης των ορίων αυτών

γίνονται ενέργειες για τη διόρθωση της κατάστασης.

Επίπεδο 5 – Επίπεδο Βελτιστοποίησης

Στο επίπεδο ωριµότητας 5, γίνεται δυνατή η συνεχής βελτίωση των διαδικασιών ανά-

πτυξης και διαχείρισης µέσω µιας ποσοτικής ανάδρασης από τις ίδιες τις διαδικασίες

και µε την εφαρµογή καινοτοµικών ιδεών και τεχνολογιών. Έτσι, ολόκληρος ο οργα-

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

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 162

λογισµικού αναλύουν τις ατέλειες µιας διαδικασίας, προκειµένου να καθορίσουν τις

βασικές αιτίες τους και οι διαδικασίες ποιότητας ακολουθούν και αυτές τον ίδιο τον

κανόνα (δηλαδή και το σύστηµα ποιότητας βελτιώνεται δυναµικά). Η ικανότητα της

διαδικασίας ανάπτυξης λογισµικού στους οργανισµούς του επιπέδου αυτού χαρα-

κτηρίζεται ως συνεχώς βελτιώσιµη (constantly improving). Η βελτίωση αυτή οφεί-

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

1 6 36 . 2 ∆ √ ¶ ƒ √ ∆ À ¶ √ ∞ • π √ § √ ° ∏ ™ ∏ ™ C M M






i) Οµοιότητα του CMM µε το ISO 9001 είναι ότι και τα δύο

είναι γενικά για όλα τα υλικά αγαθά και όχι εξειδικευµένα

στο λογισµικό.

ii) ∆ιαφορά του CMM µε το ISO 9001 είναι ότι, ενώ στο CMM

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

προσωπικό της επιχείρησης, στο ISO 9001 ο έλεγχος γίνεται

από εξωτερικό ελεγκτή.

iii)Μια επιχείρηση που αναπτύσσει λογισµικό πρέπει να επιλέξει

ή να πιστοποιηθεί µε ISO 9001, ή να αξιολογηθεί µε CMM,

αφού δεν µπορεί να έχει και τα δύο.

iv) Όλα τα επίπεδα του CMM χαρακτηρίζονται από βασικές

περιοχές που απαιτούνται για να βρίσκεται η επιχείρηση

σε αυτό το επίπεδο. Κάθε βασική περιοχή περιλαµβάνει

ένα σύνολο από βασικές πρακτικές, οι οποίες πιστοποιούν

αν η διαδικασία και η βασική περιοχή είναι αποτελεσµατική,

επαναλαµβανόµενη και διαρκής.

v) Η ικανότητα της διαδικασίας ανάπτυξης λογισµικού

στους οργανισµούς του επιπέδου 1 (αρχικό επίπεδο)

χαρακτηρίζεται ως πειθαρχηµένη, επειδή ο σχεδιασµός και

η παρακολούθηση του έργου είναι σταθερά και

προηγούµενες επιτυχίες µπορούν να επαναληφθούν.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 163

™‡ÓÔ„Ë ÎÂÊ·Ï·›Ô˘ Î·È ™˘Ì‚Ô˘Ï¤˜ ªÂÏ¤ÙË˜

Σε αυτό το κεφάλαιο, µιλήσαµε για πρότυπα που σχετίζονται µε την ανάπτυξη του

λογισµικού και ειδικότερα για τα πρότυπα του διεθνούς οργανισµού ISO που σχετί-

ζονται µε την ποιότητα, δίνοντας έµφαση στο πρότυπο ISO 9001 και στην οδηγία ISO

9000 – 3. Επίσης, παρουσιάσαµε το µοντέλο αξιολόγησης CMM, τα επίπεδα ωριµό-

τητάς του και αναλύσαµε τις οµοιότητες και διαφορές του µε το ISO 9001.

Σε αρκετά σηµεία του κεφαλαίου δεν επεκταθήκαµε σε λεπτοµερή παρουσίαση όλων

των εσωτερικών µετρικών, ή στην ανάλυση των εξωτερικών µετρήσεων, αφήνοντάς

σας να τις µελετήσετε από µόνοι σας. Σε αυτό το σκοπό θα σας βοηθήσει η βιβλιο-

γραφία που ακολουθεί µε προτεινόµενα βιβλία για περαιτέρω µελέτη, στα οποία σας

υποδεικνύουµε πού να επικεντρώσετε την προσοχή σας.

1 6 4 K E º A § A I O 6 : ¶ ƒ √ ∆ À ¶ ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

vi) Η ικανότητα της διαδικασίας ανάπτυξης λογισµικού

στους οργανισµούς του επιπέδου 5 (επίπεδο

βελτιστοποίησης) χαρακτηρίζεται ως τυποποιηµένη

και συνεπής και βασίζεται στην κατανόηση

των δραστηριοτήτων, των ρόλων και των υπευθυνοτήτων

στη λειτουργία της επιχείρησης.


Εκτός από τα πρότυπα της σειράς ISO και το CMM υπάρχουν και άλλα µοντέλα

ποιότητας, όπως τα πρότυπα του IEEE και τα πολύ διαδεδοµένα στην Αµερική βρα-

βεία ποιότητας Baldrige (που δεν είναι πρότυπο, αλλά βραβεία και οδηγίες για το

πώς να αναπτυχθεί ένα σύστηµα ποιότητας). Από αναζητήσεις στο διαδίκτυο, ετοι-

µάστε µία αναφορά που θα παρουσιάζει σε λιγότερες από 1000 λέξεις τα πρότυπα

του IEEE για την ποιότητα και τα βραβεία Baldrige. Συζητήστε την αναφορά σας

µε το Σύµβουλο – Καθηγητή σας.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 164

1 6 5X X X








Είναι ένα βιβλίο αφιερωµένο κυρίως στο πρότυπο ISO 9001 και στην οδηγία ISO

9000 – 3 και την εφαρµογή τους στη διαχείριση έργων λογισµικού. Παρουσιάζει

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

βρείτε πολύτιµο για να κατανοήσετε πώς εφαρµόζεται το πρότυπο ISO 9001 στο

λογισµικό και τι σηµαίνει αυτό για τη διοίκηση της επιχείρησης.

[Har97] J. Harrington and D. Mathers, «ISO 9000 and Beyond», McGraw–Hill,

(1997).

Είναι ένα βιβλίο που περιγράφει όλα τα πρότυπα της σειράς ISO 9000 και αναλυτι-

κές οδηγίες για την εφαρµογή τους στην πράξη, δίνοντας έµφαση στις διαδικασίες

παραγωγής.

[Inc94] Darrel Ince, «ISO 9001 and Software Quality Assurance», McGraw–Hill,

(1994).

Είναι ένα, εύκολο στην ανάγνωση, εισαγωγικό βιβλίο στο ποιότητα λογισµικού. Ο

Ince (που είναι καθηγητής στο αγγλικό Open University) έχει γράψει και αυτό το

βιβλίο του ακολουθώντας κανόνες για εκπαίδευση από απόσταση, οπότε θα το βρεί-

τε αρκετά εύκολο στη µελέτη. Όλο το βιβλίο είναι µία ανάλυση του προτύπου ISO

9001 ακολουθώντας τα 20 στοιχεία (απαιτήσεις) του και επεξηγώντας τις οδηγίες τις

ISO 9000 – 3 για κάθε περίπτωση. Σας το προτείνω ανεπιφύλακτα, αν θέλετε να εµβα-

θύνετε στο ISO 9001 και την εφαρµογή του στην ανάπτυξη λογισµικού.

[Pau93] M. Paulk et al., «Capability Maturity Model for Software (Version 1.1)»,

Carnegie Mellon University – Software Engineering Institute, Technical Report,

CMU/SEI – 93 – TR – 024, (1993).

[Pau94] M. Paulk, «A Comparison of ISO 9001 and the Capability Maturity Model

for Software», Carnegie Mellon University – Software Engineering Institute,

Technical Report, CMU/SEI – 94 – TR – 012, (1994).

[Psy00] Ν. Ψύχας, «∆ιασφάλιση Ποιότητας: ∆ιοίκηση της Ποιότητας», Ελληνικό

Ανοικτό Πανεπιστήµιο, ∆ΙΠ51/2, (2000).

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 165

Είναι ένα βιβλίο του ΕΑΠ που παρουσιάζει τα πρότυπα ποιότητας µε έµφαση στο

ISO 9001. Η παρουσίαση δεν γίνεται από τη σκοπιά της ανάπτυξης λογισµικού, αλλά

της παραγωγής αγαθών.

1 6 6 K E º A § A I O 6 : ¶ ƒ √ ∆ À ¶ ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 166

∂›ÏÔÁÔ˜

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

και της ποιότητας λογισµικού. Αν, ανοίγοντας κάθε σελίδα του βιβλίου, µπορείτε να

λύσετε κάθε άσκηση και δραστηριότητα, τότε είστε έτοιµοι για τις εξετάσεις του

Ελληνικού Ανοικτού Πανεπιστηµίου. Αν, επιπλέον, νιώθετε ότι αυτά που µάθατε

από αυτό το βιβλίο σας βοήθησαν πραγµατικά στην κατανόηση ενός µικρού µέρους

από αυτό που ονοµάζουµε «Πληροφορική», τότε το βιβλίο πέτυχε πραγµατικά το

σκοπό του.

«∆ÂÏÂÙ‹ ‰¤ ÙÉ˜ Ï¤ÍÂˆ˜ êÚÌÔÙÂÖ ì àÛ‡Ó‰ÂÙÔ˜ ¬ˆ˜ â›ÏÔÁÔ˜ àÏÏa Ìc ÏfiÁÔ˜

j «ÂúÚËÎ·, àÎËÎfi·ÙÂ, ö¯ÂÙÂ, ÎÚ›Ó·ÙÂ».

Aριστοτέλης, ΡΗΤΟΡΙΚΗ, Γ’, 19 1420α, 7 – 9

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 167

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 168

∞·ÓÙ‹ÛÂÈ˜ ·ÛÎ‹ÛÂˆÓ ·˘ÙÔ·ÍÈÔÏfiÁËÛË˜

1.1

i) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Το λογισµικό δεν κατασκευάζεται µε αντί-

στοιχο τρόπο µε την παραγωγή υλικών αγαθών, αλλά αναπτύσσεται.

ii) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Μπράβο σας αν απαντήσατε έτσι.

iii)Η σωστή απάντηση είναι «ΛΑΘΟΣ». Μιλήσαµε για τη διαφορά της διοίκησης

µε τον υπεύθυνο διαχείρισης ενός έργου λογισµικού. Βέβαια ο υπεύθυνος δια-

χείρισης ενός έργου λογισµικού θα µπορούσε να ήταν και µέλος της διοίκησης

του οργανισµού, αλλά δεν ισχύει πάντα κάτι τέτοιο.

iv) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Επειδή η τεχνολογία ανάπτυξης λογισµι-

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

δεν έχουµε καθόλου ιστορικά δεδοµένα, ή τα ιστορικά δεδοµένα δεν είναι αξιο-

ποιήσιµα. ∆εν σηµαίνει όµως αυτό ότι ποτέ δεν υπάρχουν ιστορικά δεδοµένα.

Μπράβο σας αν δώσατε τη σωστή απάντηση.

v) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Μην αγχώνεστε αν δεν δώσατε τη σωστή

απάντηση! Αυτή ήταν µια «πονηρή» ερώτηση περισσότερο για να σας κεντρίσει

το ενδιαφέρον και για να µπορέσουµε να συζητήσουµε λίγο τι εννοούµε «διαφά-

νεια». Όπως θα δούµε στη συνέχεια της µελέτης σας, µιλάµε για τη δυνατότητα

του υπεύθυνου έργου να παρακολουθεί πλήρως την πορεία εξέλιξης του έργου

και όχι για αυτό που στην καθοµιλουµένη εννοούµε όταν µιλάµε για «αδιαφανείς

διαδικασίες».

1.2

Η σωστή απάντηση είναι η iii) δηλαδή να συνεργαστεί µε την Ασπασία ώστε να ετοι-

µάσει αυτός µία πρόταση για νέο έργο, έχοντας τη βοήθεια της Ασπασίας για τα

τεχνικά θέµατα και να την παρουσιάσει µαζί µε την Ασπασία, αναφέροντας ότι είναι

ιδέα της Ασπασίας. Μπράβο σας αν απαντήσατε σωστά γιατί αν και µοιάζει εύκολο

δεν είναι καθόλου. Ας δούµε γιατί οι άλλες απαντήσεις είναι λάθος:

i) Αν κάνει κάτι τέτοιο, τότε µόλις το έργο εγκριθεί θα µαθευτεί από όλους τους

υφιστάµενους και πιθανότατα και προϊστάµενους αφού η Ασπασία ίσως να δια-

µαρτυρηθεί. Ακόµα κι αν δεν το κάνει, ο Περικλής θα γίνει αντιπαθής στους υφι-

σταµένους του και το σηµαντικότερο κανένας από αυτούς δεν θα του ξαναπεί

κάποια ιδέα, η ακόµα χειρότερα θα προτιµήσει να τον παρακάµψει.

ii) Η Ασπασία ως νεοδιοριζόµενη προγραµµατίστρια πιθανότατα δεν έχει την εµπει-

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 169

1 7 0 ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ∫ ∞ π ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

ρία του Περικλή στον καθορισµό του έργου, στην εκτίµηση, την ανάλυση ρίσκου,

την κοστολόγηση, τη συνεργασία µε τον πελάτη και την παρουσίασή του. Σίγου-

ρα η Ασπασία θα ήθελε τη βοήθεια του Περικλή σε αυτά τα θέµατα. Εάν δεν την

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

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

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

«να µην µπλέκεις µε πράγµατα που δεν είναι δουλειά σου».

iii)Είναι το καλύτερο που έχει να κάνει ο Περικλής. Η Ασπασία θα µάθει από την

πείρα του Περικλή και θα τον εκτιµήσει περισσότερο, βλέποντάς τον να διορ-

θώνει τα λάθη της και να προβάλει την ιδέα της. Επίσης θα νιώσει χαρά όταν θα

την παρουσιάσει µαζί µε τον Περικλή. Τέλος οι άλλοι υφιστάµενοι του Περικλή

θα θελήσουν να µιµηθούν την Ασπασία και θα έχουν και οι ίδιοι αντίστοιχες ιδέες.

Ίσως ο Περικλής για κάποιο διάστηµα να αρχίσει να βοµβαρδίζεται µε νέες ιδέες

που θα απορρίπτει τις περισσότερες (στην προσπάθεια όλων να µιµηθούν την

Ασπασία), αλλά σίγουρα αξίζει τον κόπο να τις ακούσει όλες.

iv) Ίσως να σας προξενήσει κατάπληξη, αλλά και αυτό εµπεριέχει µία δόση αλήθει-

ας! ∆εν µιλάµε για προσωπικές βλέψεις του Περικλή για την Ασπασία, αλλά όταν

το έργο (η ιδέα της Ασπασίας) εγκρινόταν, ένας καλός υπεύθυνος έργου θα έβγα-

ζε, όχι µόνο την Ασπασία, αλλά όλη την οµάδα των άµεσων συνεργατών του για

δείπνο πιθανότατα πληρωµένο από την εταιρία.

1.3

i) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Μη συγχέετε τη διαδικασία που γίνεται

στη φάση του προγραµµατισµού έργου µε τη σχεδίαση του έργου.

ii) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Είναι ο ορισµός του χρονοπρογραµµατισµού.

iii)Η σωστή απάντηση είναι «ΛΑΘΟΣ». Αυτό που ισχύει είναι το αντίστροφο. Η

επίτευξη ενός ορόσηµου θα πρέπει να οδηγεί σε τεκµηρίωση µε τη µορφή έκθε-

σης προόδου (progress report).

iv) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Είναι βασική δουλειά του υπεύθυνου έργου.

v) Η σωστή απάντηση είναι «ΣΩΣΤΟ».

vi) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Αντίθετα τονίσαµε τη σηµασία της τεκµηρίω-

σης και το ότι –κακώς– µερικές φορές η τεκµηρίωση υποτιµάται για κάποια έργα.

Μπράβο σας αν απαντήσατε σωστά σε όλες τις ερωτήσεις. Σε αντίθετη περίπτωση

πρέπει οπωσδήποτε να ξαναδιαβάσετε την ενότητα 1.2.1 και να επαναλάβετε την

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 170

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

κά είναι καλό να δοκιµάσετε να ξαναλύσετε τις ασκήσεις µετά την πάροδο κάποιου

χρόνου από την πρώτη φορά που τις λύσατε, ακόµα κι αν τις λύσατε σωστά την

πρώτη φορά.

1.4

i) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Εάν απαντήσατε διαφορετικά καλύτερα

αφιερώστε λίγο χρόνο για να διαβάσετε ξανά τις ενότητες 1.3.6 και 1.3.7. Προ-

σωπικό µίας επιχείρησης είναι και άνθρωποι που δεν συµµετέχουν στην ανάπτυ-

ξη λογισµικού. Επίσης ο πελάτης αν και συµµετέχει στη διαδικασία ανάπτυξης

λογισµικού δεν ανήκει στο προσωπικό της επιχείρησης.

ii) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Αν και θα µπορούσε να συµµετέχει (π.χ να

είναι µέλος του ∆ιοικητικού Συµβουλίου), αυτό δεν είναι κανόνας. Ο ρόλος του

συνήθως είναι να συµβουλεύει τη διοίκηση.

iii)Η σωστή απάντηση είναι «ΣΩΣΤΟ». Ο υπεύθυνος έργου έχει πιο εύκολο ρόλο

όταν µιλά µε τους ηγέτες οµάδων και αυτοί µε τη σειρά τους µεταβιβάζουν τις

εντολές του στις οµάδες τους.

iv) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Αυτό είναι δουλειά µηχανικού ανάπτυξης

και ειδικότερα του σχεδιαστή. Προσέξτε: κάποιος προγραµµατιστής θα µπορού-

σε να εξελιχθεί σε µηχανικό ανάπτυξης και να αναλάβει τη σχεδίαση, αλλά η πρό-

ταση δεν µιλάει για αυτό.

v) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Σε περίπτωση αντίθετης απάντησης θα πρό-

τεινα µία αρκετά καλή επανάληψη, όχι µόνο στην ενότητα 1.3.7, αλλά σε όλο το

κεφάλαιο.

Μπράβο σας αν απαντήσατε σωστά σε όλες τις ερωτήσεις. Μπορεί να µοιάζουν

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

χρόνο για επανάληψη της ενότητας 1.3, ίσως και διαβάζοντας ξανά τα σχετικά θέµα-

τα της τεχνολογίας λογισµικού που αφορούν τους συµµετέχοντες στην ανάπτυξη

λογισµικού. Ένα καλό βιβλίο να σας βοηθήσει είναι το βιβλίο του Ince [Inc95] που

σας προτείνουµε στη βιβλιογραφία.

1.5

i) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Και οι τρεις τρόποι οργάνωσης έχουν πλε-

ονεκτήµατα και µειονεκτήµατα και οι παράγοντες του προβλήµατος είναι αυτοί

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

1 7 1∞ ¶ ∞ ¡ ∆ ∏ ™ ∂ π ™ ∞ ™ ∫ ∏ ™ ∂ ø ¡ ∞ À ∆ √ ∞ • π √ § √ ° ∏ ™ ∏ ™

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 171

1 7 2 ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ∫ ∞ π ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

ii) Η σωστή απάντηση είναι «ΣΩΣΤΟ». ∆εν το αναλύσαµε στην ενότητα 1.4.1,

αλλά προκύπτει από τον ορισµό των δηµοκρατικά διοικούµενων οµάδων. Μπρά-

βο σας αν απαντήσατε σωστά.

iii) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Οι οµάδες αυτές έχουν πρόβληµα για έργα που

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

των αποφάσεων και των καθορισµένων ρόλων) για σύντοµης διάρκειας έργα.

iv) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Μιλήσαµε για αυτό στην ενότητα 1.4.2.


πρέπει οπωσδήποτε να ξαναδιαβάσετε την ενότητα 1.4 και να επαναλάβετε την άσκη-

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

2.1

Οι σωστές επιλογές είναι: Μέγεθος του έργου, πολυπλοκότητα του έργου, ιστορικά

δεδοµένα, λεπτοµερείς απαιτήσεις έργου και σταθερές απαιτήσεις έργου. Η ικανότητα

του προσωπικού ανάπτυξης σχετίζεται µε το αποτέλεσµα της εκτίµησης, αλλά όχι µε

την ακρίβειά της. Οι βάσεις δεδοµένων πιθανόν να σας µπέρδεψαν αφού σε βάσεις

δεδοµένων θα µπορούσαν να αποθηκεύονται τα ιστορικά δεδοµένα, ενώ ο σχεδια-

σµός του έργου είναι φάση της ανάπτυξης και δεν σχετίζεται µε την εκτίµηση παρα-

γόντων όπως οι ανάγκες σε ανθρώπινο δυναµικό, το κόστος και ο χρόνος.

2.2

Οι σωστές προτάσεις δίνονται παρακάτω. Μπράβο σας αν τις συµπληρώσατε µε επι-

τυχία.

α) Η καθυστέρηση της εκτίµησης είναι συνήθως η λύση που έχει τα καλύτερα απο-

τελέσµατα, αλλά δεν είναι πρακτική.

β) Το να βασιστεί η εκτίµηση σε παρόµοια έργα που έχουν ήδη ολοκληρωθεί, µπο-

ρεί να λειτουργήσει καλά, αν το συγκεκριµένο έργο το οποίο θέλουµε να εκτι-

µήσουµε είναι παρόµοιο µε εκείνο το οποίο συσχετίζουµε.

γ) Τα εµπειρικά µοντέλα µπορούν να χρησιµοποιηθούν επικουρικά στις τεχνικές

τµηµατοποίησης και να δώσουν πολύτιµες πληροφορίες σχετικά µε τα µεγέθη

που εξετάζονται.

2.3

i) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Κάτι τέτοιο συνήθως είναι απαραίτητο για

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 172

καλύτερη εκτίµηση.

ii) Η σωστή απάντηση είναι «ΣΩΣΤΟ».

iii)Η σωστή απάντηση είναι «ΛΑΘΟΣ». Το «από κάτω προς τα πάνω» αναφέρεται

στον τρόπο τµηµατοποίησης του έργου και όχι στην ιεραρχία αυτών που θα συµ-

µετάσχουν στη διαδικασία της εκτίµησης παραγόντων όπως οι ανάγκες σε ανθρώ-

πινο δυναµικό, το κόστος και ο χρόνος.

iv) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Στην πραγµατικότητα είναι η πιο διαδεδοµένη.

v) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Σε περίπτωση αντίθετης απάντησης θα πρό-

τεινα µία αρκετά καλή επανάληψη, όχι µόνο στην ενότητα 2.2.1.3, αλλά σε όλο

το κεφάλαιο.

vi) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Αυτή ήταν δύσκολη ερώτηση, αφού για τµη-

µατοποίηση µιλήσαµε σε διαφορετικό κεφάλαιο, αλλά αν προσέξετε τον τρόπο

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


θα πρέπει να αφιερώσετε κάποιο χρόνο για επανάληψη της ενότητας 2.2.

2.4

Η σωστή αντιστοίχηση είναι η παρακάτω:

οργανική κατηγορία άτοµα µε ικανοποιητική εµπειρία

µικρές οµάδες ανάπτυξης

άτοµα µε γνώση για το σύστηµα

χαµηλές απαιτήσεις έργων

µικρά έργα

ηµι – προσαρτηµένη κατηγορία άτοµα µε διαφορετική εµπειρία

άτοµα µε περιορισµένη γνώση για το σύστηµα

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

3.1


τυχία.

α) Ποιότητα είναι η συλλογή των χαρακτηριστικών και των ιδιοτήτων του προϊό-

1 7 3∞ ¶ ∞ ¡ ∆ ∏ ™ ∂ π ™ ∞ ™ ∫ ∏ ™ ∂ ø ¡ ∞ À ∆ √ ∞ • π √ § √ ° ∏ ™ ∏ ™

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 173

1 7 4 ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ∫ ∞ π ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

ντος που σχετίζονται µε τη δυνατότητά του να εκπληρώνει τις ζητούµενες ανά-

γκες των πελατών. ASQ, (1978).

β) Ποιότητα είναι το σύνολο των χαρακτηριστικών µιας οντότητας που της αποδί-

δουν την ικανότητα να ικανοποιεί εκφρασµένες και συνεπαγόµενες ανάγκες. ISO

8402, (1985).

γ) Μέτρηση είναι η διαδικασία µε την οποία αριθµοί ή σύµβολα αντιστοιχούνται

σε ιδιότητες οντοτήτων του πραγµατικού κόσµου, έτσι ώστε να τις περιγράφουν

σύµφωνα µε καθορισµένους κανόνες.

3.2

i) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Προκύπτει από τον ορισµό.

ii) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Η επισκόπηση πρέπει να χρησιµοποιείται

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

µας εξασφαλίσει ένα ποιοτικό προϊόν.

iii)Η σωστή απάντηση είναι «ΣΩΣΤΟ».

iv) Η σωστή απάντηση είναι «ΣΩΣΤΟ».

v) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Αυτός είναι ένας από τους βασικούς ρόλους

της επισκόπησης ποιότητας.

3.3

i) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Αυτό ακριβώς αναφέρεται και στην ενότητα 3.2.

ii) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Ο ορισµός τονίζει ότι η διαχείριση ολικής

ποιότητας είναι τρόπος διοίκησης ενός οργανισµού που εστιάζει στην ποιότητα,

ο οποίος βασίζεται στη συµµετοχή όλων των µελών του και στοχεύει στη µακρο-

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

σε όλα τα µέλη του οργανισµού και στην κοινωνία.

iii) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Αυτή είναι η βασική αρχή της φιλοσοφίας

του Phillip Crosby.

iv) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Αυτό ακριβώς αναφέρεται και στην ενότητα 3.2.3.

v) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Αναλύονται µε πληθώρα τεχνικών, από τις

οποίες η πιο διαδεδοµένη είναι τα διαγράµµατα ελέγχου (control charts).

vi) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Αυτό είναι ζητούµενο στην παραγωγή υλι-

κών αγαθών, αλλά όχι στην ποιότητα λογισµικού. Στο λογισµικό, ζητούµενο είναι

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 174

η διασφάλιση της ποιότητας ενός και µοναδικού πρωτότυπου του προϊόντος.

vii) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Αυτό ακριβώς αναφέρεται και στην ενό-

τητα 3.3.

4.1


τυχία.

α) Παράγοντες ποιότητας είναι οµάδες χαρακτηριστικών τα οποία συνθέτουν την

ποιότητα ενός προϊόντος, έχουν την ελάχιστη δυνατή επικάλυψη µεταξύ τους

και είναι επαρκή για τη σύνθεση της ποιότητας.

β) Η θεώρηση της ποιότητας από την πλευρά του χρήστη αντιµετωπίζει την ποιό-

τητα ως καταλληλότητα για χρήση.

γ) Αξιοπιστία είναι ένα σύνολο χαρακτηριστικών που είναι φορείς της δυνατότητας

του λογισµικού να διατηρεί το επίπεδο απόδοσής του σε καθορισµένες συνθή-

κες και για προκαθορισµένη χρονική περίοδο.

4.2

∆ίνεται η λίστα µε τις σωστές απαντήσεις. Μπράβο σας αν απαντήσατε σε όλα

σωστά, αφού ήταν µία αρκετά δύσκολη άσκηση. Εάν δεν απαντήσατε σωστά, του-

λάχιστον µελετήστε τους παράγοντες ποιότητας του ISO 9126 και φροντίστε να τους

γνωρίζετε και –το κυριότερο– να µπορείτε να εξηγήσετε τι σηµαίνουν.

Παράγοντας ποιότητας FCM Boehm ISO 9126

ακεραιότητα

αξιοπιστία

αποδοτικότητα

ασφάλεια

ελεγξιµότητα

διαλειτουργικότητα

επαναχρησιµοποιησιµότητα

ευελιξία

ευχρηστία

1 7 5∞ ¶ ∞ ¡ ∆ ∏ ™ ∂ π ™ ∞ ™ ∫ ∏ ™ ∂ ø ¡ ∞ À ∆ √ ∞ • π √ § √ ° ∏ ™ ∏ ™

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 175

1 7 6 ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ∫ ∞ π ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

κατανοησιµότητα

λειτουργικότητα

µεταφερσιµότητα

ορθότητα

προσαρµοστικότητα

συντηρησιµότητα

ωριµότητα

4.3

i) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Αυτή είναι η κωδικοποίηση των περισσό-

τερων προτύπων του διεθνούς οργανισµού προτοτυποποίησης ISO, αλλά υπάρ-

χουν και άλλα πρότυπα (όπως τα πρότυπα του IEEE) που δεν ακολουθούν αυτή

την κωδικοποίηση.

ii) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Προκύπτει από τον ορισµό της οδηγίας

στην ενότητα 4.2.

iii) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Προκύπτει από τον ορισµό της ανιχνευ-

σιµότητας.

iv) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Αυτό που ισχύει είναι το αντίστροφο,

δηλαδή η διασφάλιση ποιότητας διαδικασιών και πόρων έµµεσα στοχεύει στη

διασφάλιση ποιότητας του προϊόντος που είναι και ο απώτερος στόχος κάθε

συστήµατος ποιότητας.

v) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Το εγχειρίδιο ποιότητας είναι γενικό για

την επιχείρηση και συµπεριλαµβάνει όλες τις διαδικασίες, µεθόδους, τεχνικές,

κτλ. που µπορούν να χρησιµοποιηθούν σε κάθε έργο. Από το εγχειρίδιο αντλού-

νται κάποιες διαδικασίες –διαφορετικές για κάθε έργο– που συνθέτουν το πλάνο

ποιότητας ενός έργου.

vi) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Αυτό που εξελίσσεται δυναµικά είναι το

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

είναι δυνατόν οι προδιαγραφές ποιότητας που έχουµε θέσει για ένα έργο να µετα-

βάλλονται στην πορεία του έργου.

vii) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Αυτό αποτελεί εσφαλµένη άποψη που

έγκειται στο γεγονός συχνά ότι κανείς δεν υποχρεώνει τους υπεύθυνους ενός

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 176

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

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

επισηµάνσεις του αγνοούνται κάτω από την πίεση για την τήρηση των προθε-

σµιών των έργων.

4.4

Η σωστή αντιστοίχηση παρουσιάζεται παρακάτω. Μπράβο σας αν αντιστοιχήσατε

τα πάντα σωστά.

Κατηγορίες Χρηστών Τι παρέχει το σύστηµα ποιότητας

Υπεύθυνος έργου Τυποποίηςη αναφορών δραστηριοτήτων έργου.

∆ιαδικασία καταγραφής βασικών δεδοµένων

έργου.

Προγραµµατιστής Πρότυπα που να ορίζουν τον τρόπο µε τον οποίο

ένα πρόγραµµα πρέπει να αναπτυχθεί (κωδικο-

ποιηθεί).

Σχεδιαστής Κανόνες και οδηγίες για την ορθή σχεδίαση της

διεπιφάνειας χρήστη που να είναι προσαρµοσµέ-

νη στις ανάγκες και ιδιαιτερότητες των χρηστών

του συγκεκριµένου έργου.

Τυποποιηµένες διαδικασίες ανάλυσης και σχε-

δίασης.

Αναλυτής Πρότυπο για τον προσδιορισµό των απαιτήσεων.

Τυποποιηµένη περιγραφή της διαδικασίας επα-

φής µε τον πελάτη

4.5

i) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Η επιλογή των καλύτερων προγραµµατι-

στών χωρίς να υπάρχει τυποποίηση των διαδικασιών ανάπτυξης και χρήση προ-

γραµµατιστικών προτύπων, θα αναγκάσει την επιχείρηση να βασίζεται σε ad hoc

διαδικασίες που θα εφευρίσκουν αυτοί οι µηχανικοί, αυξάνοντας την εξάρτησή

της από τα άτοµα.

ii) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Το σύστηµα ποιότητας βοηθά σε αυτή την

κατεύθυνση.

1 7 7∞ ¶ ∞ ¡ ∆ ∏ ™ ∂ π ™ ∞ ™ ∫ ∏ ™ ∂ ø ¡ ∞ À ∆ √ ∞ • π √ § √ ° ∏ ™ ∏ ™

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 177

1 7 8 ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ∫ ∞ π ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

iii) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Αποθεµατικό σηµαίνει καλογραµµένα και

κατανοήσιµα τµήµατα κώδικα, σχολιασµένα και µε επαρκή τεκµηρίωση, που

έχουν υλοποιηθεί µε βάση κάποιο πρότυπο και είναι άµεσα επαναχρησιµοποιή-

σιµα. Η παραγωγή µεγάλων ποσοτήτων κώδικα που δεν πληρούν τις παραπάνω

προδιαγραφές δεν εγγυάται ότι κάποια τµήµατα θα µπορούν να επαναχρησιµο-

ποιηθούν.

iv) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Αυτές οι φάσεις είναι σηµαντικές και ο

χρόνος που θα επενδυθεί σε αυτές είναι πολύτιµος. Μιλούσαµε για τη φάση του

ελέγχου και της συντήρησης.

v) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Το σύστηµα ποιότητας βοηθά σε αυτή την

κατεύθυνση.

5.1

i) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Αν και πολλά βιβλία θεωρούν τους όρους

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

για την πρόβλεψη πιο πολύπλοκων χαρακτηριστικών, όπως το κόστος, ενώ ο

όρος µετρική χρησιµοποιείται για να χαρακτηρίσει πιο απλές ιδιότητες.

ii) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Ισχύει ακριβώς το αντίθετο, οι περισσό-

τερες µετρικές που έχουν προταθεί περιορίζονται στη µέτρηση εσωτερικών χαρα-

κτηριστικών του λογισµικού.

iii) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Προκύπτει από τον ορισµό της ερµηνείας

της µετρικής.

iv) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Οι περισσότεροι τρόποι συλλογής «µετρή-

σεων» των εξωτερικών µετρικών (ερωτηµατολόγια, παρατήρηση, κτλ) δεν ικα-

νοποιούν το ζητούµενο της αντικειµενικότητας.

v) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Είναι δυνατό να αποτελεί µετρική διαδι-

κασίας.

vi) Η σωστή απάντηση είναι «ΣΩΣΤΟ». ∆είτε στην τελευταία παράγραφο της ενό-

τητας 5.1.

Μπράβο σας αν απαντήσατε όλες τις ερωτήσεις σωστά. Σε αντίθετη περίπτωση είναι

καλό να κάνετε µία καλή επανάληψη στην ενότητα 5.1 πριν συνεχίσετε τη µελέτη σας.

5.2

i) Η σωστή απάντηση είναι «ΣΩΣΤΟ». ∆είτε την αρχή της ενότητας 5.2.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 178

ii) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Όχι µόνο µπορούν, αλλά και πρέπει να την

οδηγούν σε αποφάσεις.

iii)Η σωστή απάντηση είναι «ΛΑΘΟΣ». Αν συνέβαινε κάτι τέτοιο, τότε αυτές οι

µετρικές δεν θα µπορούσαν να εφαρµοστούν σε µεγάλη κλίµακα. Ακριβώς το

αντίθετο συµβαίνει: είναι πολύ εύκολο να αυτοµατοποιηθούν.

iv) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Προκύπτει από τον ορισµό της. ∆είτε την

ενότητα 5.2.1

5.3

i) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Αφορούν συνήθως στα ποιοτικά χαρακτη-

ριστικά που ενδιαφέρουν τους τελικούς χρήστες, αλλά δεν περιορίζονται µόνο σε

αυτά.

ii) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Συνήθως εµπεριέχουν υποκειµενικά στοι-

χεία και αυτό είναι και το µεγάλο τους πρόβληµα.

iii)Η σωστή απάντηση είναι «ΛΑΘΟΣ». Μόνο στις αναλυτικές µεθόδους δεν συµ-

µετέχουν οι τελικοί χρήστες, σε αντίθεση µε τις πειραµατικές µεθόδους και τις

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

iv) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Οι εξωτερικές µετρήσεις µε χρήση ερω-

τηµατολογίου είναι οικονοµική µέθοδος, συγκρινόµενη µε τις αντίστοιχες µεθό-

δους εξωτερικών µετρήσεων. Όµως, κάθε µέθοδος εξωτερικών µετρήσεων είναι

λιγότερο οικονοµική συγκρινόµενη µε τις αυτοµατοποιηµένες µεθόδους εσωτε-

ρικών µετρήσεων.

6.1

i) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Μάλιστα είναι πολλά τα λάθη! Το µόνο

που είναι πρότυπο είναι το ISO 9001, αφού το ISO 9000 – 3 δεν είναι πρότυπο,

αλλά οδηγία. Το πρότυπο ISO 9001 δεν περιορίζεται µόνο στη βιοµηχανική παρα-

γωγή, αλλά σε κάθε επιχείρηση στην οποία ένα προϊόν σχεδιάζεται, αναπτύσσε-

ται, ελέγχεται και εγκαθίστανται στον πελάτη, άρα και στο λογισµικό (µε τη βοή-

θεια της οδηγίας ISO 9000 – 3).

ii) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Αυτό ακριβώς είναι το ζητούµενο από την

επιχείρηση.

iii)Η σωστή απάντηση είναι «ΛΑΘΟΣ». Η πιστοποίηση µε το πρότυπο ISO 9001

σε µία επιχείρηση γίνεται από έναν εξωτερικό ελεγκτή την πρώτη φορά και ο

1 7 9∞ ¶ ∞ ¡ ∆ ∏ ™ ∂ π ™ ∞ ™ ∫ ∏ ™ ∂ ø ¡ ∞ À ∆ √ ∞ • π √ § √ ° ∏ ™ ∏ ™

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 179

1 8 0 ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ∫ ∞ π ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

έλεγχος επαναλαµβάνεται περιοδικά.

iv) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Η γενικότητα είναι ταυτόχρονα πλεονέ-

κτηµα και µειονέκτηµα του προτύπου.

v) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Σε αυτό το σηµείο το πρότυπο δεν καθορί-

ζει µε σαφήνεια την απαίτηση για διεξαγωγή µετρήσεων και τη χρήση µετρικών.

vi) Μπράβο σας αν απαντήσατε όλες τις ερωτήσεις σωστά. Σε αντίθετη περίπτωση

είναι καλό να κάνετε µία καλή επανάληψη στην ενότητα 6.1 πριν συνεχίσετε τη

µελέτη σας.

6.2


τυχία.

α) Το CMM είναι ένα µοντέλο αξιολόγησης που εξελίχθηκε σε πρότυπο ποιότητας


β) Μία ώριµη επιχείρηση ανάπτυξης λογισµικού έχει την ικανότητα διαχείρισης

της ανάπτυξης λογισµικού.

γ) Το CMM είναι ένα µοντέλο µε το οποίο µπορεί µία επιχείρηση να αξιολογήσει

πόσο ώριµη είναι σχετικά µε την ικανότητά της να αναπτύσσει λογισµικό.

δ) To CMM βοηθά την επιχείρηση να εξελίσσεται σταδιακά.

6.3

i) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Το ISO 9001 είναι ένα γενικό πρότυπο που

περιλαµβάνει κάθε είδους προϊόν (συµπεριλαµβανοµένου και του λογισµικού),

καθώς και την παροχή υπηρεσιών προς τους πελάτες, ενώ αντίθετα το CMM είναι

εξειδικευµένο αποκλειστικά στο λογισµικό.

ii) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Μία επιχείρηση πιστοποιείται µε ISO 9001

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

περιοδικούς ελέγχους. Ως προς το επίπεδο ωριµότητάς της στο CMM, αξιολο-

γείται επίσης από κάποιον εξωτερικό ελεγκτή και αυτή η αξιολόγηση πάλι επα-

ναλαµβάνεται περιοδικά. Άρα, είναι οµοιότητα και όχι διαφορά.

iii)Η σωστή απάντηση είναι «ΛΑΘΟΣ». Μία επιχείρηση µπορεί να είναι πιστοποι-

ηµένη µε ISO 9001 και ταυτόχρονα να έχει αξιολογηθεί σε κάποιο επίπεδο του

CMM.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 180

iv) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Αυτό ισχύει για όλα τα επίπεδα εκτός από

το 1ο επίπεδο (το αρχικό επίπεδο) όπου δεν υπάρχουν βασικές περιοχές.

v) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Η ικανότητα της διαδικασίας ανάπτυξης

λογισµικού στους οργανισµούς του αρχικού επιπέδου µόνο πειθαρχηµένη δεν

µπορεί να χαρακτηρίζεται. Αντίθετα είναι χαοτική. Ο ορισµός αναφέρεται στο 2ο

επίπεδο.

vi) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Τυποποιηµένη και συνεπής χαρακτηρίζε-

ται η ικανότητα στο 4ο επίπεδο και όχι στο 5ο.

Μπράβο σας αν απαντήσατε όλες τις ερωτήσεις σωστά. Σε αντίθετη περίπτωση, είναι

καλό να κάνετε µία καλή επανάληψη στην ενότητα 6.2.

1 8 1∞ ¶ ∞ ¡ ∆ ∏ ™ ∂ π ™ ∞ ™ ∫ ∏ ™ ∂ ø ¡ ∞ À ∆ √ ∞ • π √ § √ ° ∏ ™ ∏ ™

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 181

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 182

°ÂÓÈÎ‹ ‚È‚ÏÈÔÁÚ·Ê›·

∂ÏÏËÓfiÁÏˆÛÛË

Εδώ µπορείτε να βρείτε όλη τη βιβλιογραφία στην ελληνική γλώσσα που χρησιµο-

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



[Bar96] Γ. Βαρουφάκης, «Αρχαία Ελλάδα & Ποιότητα. Η ιστορία και ο έλεγχος των

υλικών που σηµάδεψαν τον ελληνικό πολιτισµό», Εκδόσεις Αίολος, (1996).

[Psy00] Ν. Ψύχας, «∆ιασφάλιση Ποιότητας: ∆ιοίκηση της Ποιότητας», Ελληνικό

Ανοικτό Πανεπιστήµιο, ∆ΙΠ51/2, (2000).

[Ste00] Σ. Στεφανάτος, «∆ιασφάλιση Ποιότητας: Ολική Ποιότητα», Ελληνικό Ανοι-

κτό Πανεπιστήµιο, ∆ΙΠ51/3, (2000).

[Ves00] Βασίλειος Βεσκούκης, «Τεχνολογία Λογισµικού Ι: Αρχές Τεχνολογίας Λογι-

σµικού», Ελληνικό Ανοικτό Πανεπιστήµιο, ΠΛΗ20/1, (2000).



[Xen96] Μιχάλης Ξένος, «Μεθοδολογία ελέγχου και εξασφάλισης της ποιότητας λογι-

σµικού βασισµένη στις µετρικές προϊόντος και στα εξωτερικά ποιοτικά χαρακτηρι-

στικά του λογισµικού», ∆ιδακτορική ∆ιατριβή, Πανεπιστήµιο Πατρών, (1996).

•ÂÓfiÁÏˆÛÛË

Εδώ µπορείτε να βρείτε όλη την ξενόγλωσση βιβλιογραφία που χρησιµοποιήθηκε

στο βιβλίο, διαταγµένη ανάλογα µε την κωδικοποίηση. Για µερικές από τις αναφο-

ρές (κυρίως για τα βιβλία) που παρατίθενται εδώ, θα βρείτε σχολιασµό και οδηγίες

µελέτης µετά το τέλος καθενός από τα κεφάλαια του βιβλίου.

[Alb83] A. J. Albrecht and J. E. Gaffney, «Software Function, Source Lines of Code

and Development Effort Prediction: A Software Science Validation», IEEE

Transactions on Software Engineering, (1983).

[Ame78] American Society for Quality Control, «Standard A3», (1978).

[Arn95] K. Arnold and M. Holler, «Quality Assurance. Methods and Technologies»,

McGraw – Hill, New York, (1995).

[Aub85] C. Aubrey, «Quality Management in Financial Service», Wheaton IL,

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 183

1 8 4 ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ∫ ∞ π ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

Hitchcock Publishing, (1985).

[Boe78] B. Boehm et al., «Characteristics of Software Quality», North Holland,

(1978).

[Boe81] B. Boehm, «Software Engineering Economics», Prentice–Hall, (1981).

[Boe89] B. Boehm, «Software Risk Management», IEEE Computer Society Press,

(1989).

[Bro97] Frederick P. Brooks, «The Mythical Man–Month. Essays on Software

Engineering», Anniversary edition, , Addison–Wesley, (1995).

[Con86] S. D. Conte et al., «Software Engineering Metrics and Models», Benjamin

Cummings, (1986).

[Cro79] Philip Crosby, «Quality is Free», New York, McGraw – Hill, (1979).

[Cro96] Philip Crosby, «Quality is Still Free», New York, McGraw – Hill, (1996).

[Cur88] B. Curtis et al., «A Field Study of the Software Design Process for Large

Systems», IEEE Transactions of Software Engineering, vol. 31, no. 11, pp.

1268–1287, (1988).

[Dem88] Edwards Deming, «Out of the Crisis», Massachusetts Institute of

Technology, Cambridge University Press, (1988).

[Dma82] Tomas DeMarco, «Controlling Software Projects», Prentice Hall, New –

York, (1982).

[Edg95] J. Edgemon, «Right Stuff: How to recognize it when selecting a Project

Manager», Application Development Trends, vol. 2, no. 5, (1995).

[Fei83] V. A. Feigenbaum, «Total Quality Control», 3rd ed. New York, McGraw –

Hill, (1983).



[Fit78] A. Fitzsimmons and T. Love, «A Review and Evaluation of Software Science»,

Computing Surveys, Volume 10, 1, (1978).

[Fun76] Y. Funami and M. Halstead, «A Software Physics Analysis of Akiyama’s

Debugging Data», Symposium on Computer Software Engineering, (1976).

[Gar84] David Garvin, «What Does Product Quality Really Mean?», Sloan

Management Review, Fall, (1984).

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 184

[Gil87] Τ. Gilb, «Principles of Software Engineering Management», Addison Wesley,

(1987).

[Hal75] Μ. Η. Halstead, «Elements of Software Science», Elsevier Publications, N –

Holland, (1975).


[Har97] J. Harrington and D. Mathers, «ISO 9000 and Beyond», McGraw–Hill,

(1997).

[Hig95] R. P. Higuera, «Team Risk Management», CrossTalk, U.S. Dept. of Defence,

(1995).

[Inc94] Darrel Ince, «ISO 9001 and Software Quality Assurance», McGraw–Hill,

(1994).



[Iso91] ISO, «Information technology – Evaluation of software – Quality

characteristics and guides for their use», International Standard, ISO/IEC 9126:

(1991).

[Jon91] C. Jones, «Applied Software Measurement: Assuring Productivity and

Quality», McGraw Hill, (1991).

[Jur80] Joseph Juran and F. Gryna, «Quality Planning and Analysis», 2nd ed. New

York, McGraw – Hill, (1980).

[Kap95] C. Kaplan et al., «Secrets of Software Quality», McGraw Hill, (1995).

[Kit96] B. Kitchenham and S. Pfleeger, «Software Quality: The Elusive Target»,

IEEE Software, January, (1996).

[Kra95] R. Kraul and L. Streeter, «Coordination in Software Development», CASM,

vol. 38, no. 3, (1995).

[Man81] M. Mantei, «The Effect of Programming Team Structures on Programming

Tasks», CACM, vol. 24, no. 3, (1981).

[Mcb76] T. J. McCabe, «A Complexity Measure», IEEE Transactions in Software

Engineering SE – 2(4), (1976).

[Mcc77] J. A. McCall et al., «Factors in Software Quality, Vols I, II, III», US Rome

Air Development Center Reports NTIS AD/A – 049 014, 015, 055, (1977).

1 8 5° ∂ ¡ π ∫ ∏ µ π µ § π √ ° ƒ∞ º π ∞

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 185

1 8 6 ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ∫ ∞ π ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

[Met73] P. W. Metzger, «Managing a Programming Project», Engelwood Cliffs,

Prentice–Hall, (1973).

[Mon91] D. C. Montgomery, «Introduction to Statistical Quality Control», second

edition, John Wiley & Sons, (1991).

[Pau93] M. Paulk et al., «Capability Maturity Model for Software (Version 1.1)»,

Carnegie Mellon University – Software Engineering Institute, Technical Report,

CMU/SEI – 93 – TR – 024, (1993).

[Pau94] M. Paulk, «A Comparison of ISO 9001 and the Capability Maturity Model

for Software», Carnegie Mellon University – Software Engineering Institute,

Technical Report, CMU/SEI – 94 – TR – 012, (1994).



[Sho93] Martin L. Shooman, «Software Engineering: Design, Reliability and

Management», McGraw–Hill, (1993).

[Som89] Ian Sommerville, «Software Engineering», Third edition, Addison–Wesley,

(1989).

[Sqm93] Software Quality Management, «A Review of the Managing Software

Quality in the 90’s», Conference by Elliott Marley, Issue 18, Spring, pp. 24 – 28,

(1993).

[Wel00] E. Weller, «Practical Applications of Statistical Process Control», IEEE

Software, Vol. 17, No. 3, (2000).

[Xen96] M. Xenos et al., «The Correlation Between Developer – oriented and User

– oriented Software Quality Measurements (A Case Study)», 5th European

Conference on Software Quality, EOQ – SC, (1996).

[Xen97] M. Xenos and D. Christodoulakis, «Measuring Perceived Software Quality»,

Information Technology Journal, Vol. 39, (1997).


[Zah94] R. Zahniser, «Timeboxing for Top Team Performance», Software

Development, vo. 3, (1994).

[Zhe95] F. Zahedi, «Quality Information Systems», International Thomson Publishing

Company, (1995).

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 186

∞ÏÊ·‚ËÙÈÎfi Â˘ÚÂÙ‹ÚÈÔ fiÚˆÓ (ÂÏÏËÓÈÎ¿ – ·ÁÁÏÈÎ¿)

Ακεραιότητα Integrity

Ακρίβεια Accuracy

Ανακτησιµότητα Recoverability

Ανάλυση κινδύνου Risk analysis

Αναλυσιµότητα Analyzability

Αναλυτής Analyst

Αναλυτικές µέθοδοι Analytic methods

Ανεκτικότητα σε λάθη Fault tolerance

Ανεξαρτησία Independence

Ανιχνευσιµότητα Traceability

Αντικαταστασιµότητα Replaceability

Αντικειµενοστραφής προγραµµατισµός Object – oriented programming

Αντίστροφη ανιχνευσιµότητα Reverse traceability

Ανώτερος προγραµµατιστής Senior Programmer

Ανώτερος υπεύθυνος έργων Senior projects manager

Αξιοπιστία Reliability

Αξιοποίηση πόρων Resource behaviour

Αποδοτικότητα Efficiency

Αρχικό επίπεδο CMM Initial CMM level

Ασφάλεια Security

Βασικές περιοχές της διαδικασίας Key process areas

Βασικές πρακτικές Key practices

Γραµµή κώδικα Line of Code ή LOC

Γράφηµα ∆ιασποράς Scatter plot

Γράφος ροής Flow graph

∆ειγµατοληψία Sampling

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 187

1 8 8 ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ∫ ∞ π ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

∆ιάγραµµα ανάθεσης έργου Staff allocation chart

∆ιάγραµµα αξιολόγησης έργου PERT Chart

∆ιαγράµµατα ελέγχου Control charts

∆ιαδικασία Procedure

∆ιαδικασίες ποιότητας Quality procedures

∆ιαλειτουργικότητα Interoperability

∆ιασφάλιση ποιότητας Quality assurance

∆ιασφάλιση ποιότητας διαδικασιών Process quality assurance

∆ιασφάλιση ποιότητας πόρων Resource quality assurance

∆ιασφάλιση ποιότητας προϊόντος Product quality assurance

∆ιαχείριση Management

∆ιαχείριση ολικής ποιότητας Total quality management

∆ιαχείριση ποιότητας Quality management

∆ιερευνητικές µέθοδοι Inquiry methods

∆ίκτυο δραστηριοτήτων Activity network

∆ιοίκηση Administration

∆ιοικούµενο επίπεδο CMM Managed CMM level

∆υνατότητα συνύπαρξης Conformance

Εγχειρίδιο ποιότητας Quality manual

Εγχειρίδιο ποιότητας Quality manual

Έκθεση προόδου Progress report

Εκτίµηση από κάτω προς τα πάνω Bottom – up estimation

Εκτίµηση που βασίζεται σε γραµµές κώδικα LOC based estimation

Εκτίµηση που βασίζεται σε λειτουργικά σηµεία Function point based estimation

Εκτίµηση που βασίζεται στο τελικό κόστος Pricing to win

Εκτίµηση Estimation

Ελεγξιµότητα Testability

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 188

Έλεγχος απόκλισης Deviation control

Εµπειρικά µοντέλα Empirical models

Ενδιάµεσες κατασκευές Intermediate constructs

Ενσωµατωµένη κατηγορία έργων Embedded mode projects

Εξωτερικά χαρακτηριστικά λογισµικού External software characteristics

Εξωτερικές µετρικές External metrics

Επαναλαµβανόµενο επίπεδο CMM Repeatable CMM level

Επαναχρησιµοποιησιµότητα Reusability

Επίβλεψη Surveillance

Επίπεδο Βελτιστοποίησης CMM Optimising CMM level

Επισκόπηση Inspection

Επισκόπηση ποιότητας Quality inspection

Έργο λογισµικού Software project

Ερµηνεία µετρικής Metric interpretation

Εσωτερικά χαρακτηριστικά λογισµικού Internal software characteristics

Εσωτερικές µετρικές Internal metrics

Εσωτερικός περιοδικός έλεγχος Audit

Ευελιξία Flexibility

Ευκολία εγκατάστασης Installability

Ευκολία εκµάθησης Learnability

Ευκολία χειρισµού Operability

Ευχρηστία Usability

Ηµι – προσαρτηµένη κατηγορία έργων Semi – detached mode projects

Ικανότητα Capability

Καθορισµένο επίπεδο CMM Defined CMM level

Καθορισµός Planning

Καταλληλότητα Suitability

1 8 9∞ § º ∞ µ ∏ ∆ π ∫ √ ∂ À ƒ ∂ ∆ ∏ ƒ π √ √ ƒ ø ¡ ( ∂ § § ∏ ¡ π ∫ ∞ – ∞ ° ° § π ∫ ∞ )

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 189

1 9 0 ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ∫ ∞ π ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

Κατανοησιµότητα Understandability

Κόστος Cost

Κρίσιµο µονοπάτι Critical Path

Κριτήρια Criteria

Κυκλωµατική πολυπλοκότητα Cyclomatic complexity

Λειτουργικό εγχειρίδιο Operating manual

Λειτουργικό σηµείο Function point

Λειτουργικότητα Functionality

Λογισµικό Software

Μέγεθος Size

Μεταφερσιµότητα Portability

Μέτρηση Measurement

Μετρικές διαδικασίας Process metrics

Μετρικές πόρων Resource metrics

Μετρικές προϊόντος Product metrics

Μετρική Metric

Μέτρο Measure

Μη εγωιστικός προγραµµατισµός Egoless programming

Μηχανικός ανάπτυξης Software engineer

Μηχανικός ελέγχου Test engineer

Μοντέλο Ωριµότητας Ικανότητας Capability Maturity Model

Οδηγία Guideline

Οργανική κατηγορία έργων Organic mode projects

Οργανόγραµµα διαχείρισης έργου Project management structure

Ορθή ανιχνευσιµότητα Forward traceability

Ορθότητα Correctness

Ορόσηµο Milestone

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 190

Παράγοντες ποιότητας Quality factors

Παράγοντες ρύθµισης πολυπλοκότητας Complexity adjustment factors

Πειραµατικές µέθοδοι Experimental methods

Πελάτης Customer

Πίνακας αξιολόγησης συνεπειών Impact assessment table

Πλάνο ποιότητας έργου Project Quality plan

Ποιότητα Quality

Ποιότητα λογισµικού Software quality

Ποιοτικός έλεγχος Quality control

Πρόγραµµα ποιότητας Quality program

Προγραµµατισµός βασισµένος σε ψηφίδες Component based programming

Προγραµµατιστής Programmer

Πρόοδος Progress

Προσαρµοσµένο λογισµικό Custom software

Προσαρµοστικότητα Adaptability

Προσπάθεια Effort

Προσωπικό Personnel

Πρότυπο Standard

Πρωταρχικές χρήσεις Primary uses

Πρωτογενείς κατασκευές Primitive constructs

Σταθερότητα Stability

Στατιστικός έλεγχος ποιότητας Statistical quality control

Συντήρηση Maintenance

Συντηρησιµότητα Maintainability

Σύστηµα ποιότητας Quality system

Σχεδιαστής Designer

Τεκµηρίωση Documentation

1 9 1∞ § º ∞ µ ∏ ∆ π ∫ √ ∂ À ƒ ∂ ∆ ∏ ƒ π √ √ ƒ ø ¡ ( ∂ § § ∏ ¡ π ∫ ∞ – ∞ ° ° § π ∫ ∞ )

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 191

1 9 2 ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ∫ ∞ π ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

Τεχνικές τµηµατοποίησης Decomposition techniques

Τεχνολογία λογισµικού Software engineering

Τεχνολογία ποιότητας Quality engineering

Τοµείς πληροφορίας Information domain values

Τροποποιησιµότητα Changeability

Τυποποίηση Standardisation

Υπεύθυνος διαχείρισης Manager

Υπεύθυνος διαχείρισης έργου λογισµικού Software project manager

Υπεύθυνος ποιότητας Quality manager

Χρήστης User

Χρονική συµπεριφορά Time behaviour

Χρονοδιάγραµµα Gantt chart

Χρόνος ανάπτυξης Development time

Ωριµότητα Maturity

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 192

∞ÏÊ·‚ËÙÈÎfi Â˘ÚÂÙ‹ÚÈÔ fiÚˆÓ (·ÁÁÏÈÎ¿ – ÂÏÏËÓÈÎ¿)

Accuracy Ακρίβεια

Activity network ∆ίκτυο δραστηριοτήτων

Adaptability Προσαρµοστικότητα

Administration ∆ιοίκηση

Analyst Αναλυτής

Analytic methods Αναλυτικές µέθοδοι

Analyzability Αναλυσιµότητα

Audit Εσωτερικός περιοδικός έλεγχος

Bottom – up estimation Εκτίµηση από κάτω προς τα πάνω

Capability Maturity Model Μοντέλο Ωριµότητας Ικανότητας

Capability Ικανότητα

Changeability Τροποποιησιµότητα

Complexity adjustment factors Παράγοντες ρύθµισης πολυπλοκότητας

Component based programming Προγραµµατισµός βασισµένος σε ψηφίδες

Conformance ∆υνατότητα συνύπαρξης

Control charts ∆ιαγράµµατα ελέγχου

Correctness Ορθότητα

Cost Κόστος

Criteria Κριτήρια

Critical Path Κρίσιµο µονοπάτι

Custom software Προσαρµοσµένο λογισµικό

Customer Πελάτης

Cyclomatic complexity Κυκλωµατική πολυπλοκότητα

Decomposition techniques Τεχνικές τµηµατοποίησης

Defined CMM level Καθορισµένο επίπεδο CMM

Designer Σχεδιαστής

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 193

1 9 4 ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ∫ ∞ π ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

Development time Χρόνος ανάπτυξης

Deviation control Έλεγχος απόκλισης

Documentation Τεκµηρίωση

Efficiency Αποδοτικότητα

Effort Προσπάθεια

Egoless programming Μη εγωιστικός προγραµµατισµός

Embedded mode projects Ενσωµατωµένη κατηγορία έργων

Empirical models Εµπειρικά µοντέλα

Estimation Εκτίµηση

Experimental methods Πειραµατικές µέθοδοι

External metrics Εξωτερικές µετρικές

External software characteristics Εξωτερικά χαρακτηριστικά λογισµικού

Fault tolerance Ανεκτικότητα σε λάθη

Flexibility Ευελιξία

Flow graph Γράφος ροής

Forward traceability Ορθή ανιχνευσιµότητα

Function point based estimation Εκτίµηση που βασίζεται σε λειτουργικά σηµεία

Function point Λειτουργικό σηµείο

Functionality Λειτουργικότητα

Gantt chart Χρονοδιάγραµµα

Guideline Οδηγία

Impact assessment table Πίνακας αξιολόγησης συνεπειών

Independence Ανεξαρτησία

Information domain values Τοµείς πληροφορίας

Initial CMM level Αρχικό επίπεδο CMM

Inquiry methods ∆ιερευνητικές µέθοδοι

Inspection Επισκόπηση

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 194

Installability Ευκολία εγκατάστασης

Integrity Ακεραιότητα

Intermediate constructs Ενδιάµεσες κατασκευές

Internal metrics Εσωτερικές µετρικές

Internal software characteristics Εσωτερικά χαρακτηριστικά λογισµικού

Interoperability ∆ιαλειτουργικότητα

Key practices Βασικές πρακτικές

Key process areas Βασικές περιοχές της διαδικασίας

Learnability Ευκολία εκµάθησης

Line of Code ή LOC Γραµµή κώδικα

LOC based estimation Εκτίµηση που βασίζεται σε γραµµές κώδικα

Maintainability Συντηρησιµότητα

Maintenance Συντήρηση

Managed CMM level ∆ιοικούµενο επίπεδο CMM

Management ∆ιαχείριση

Manager Υπεύθυνος διαχείρισης

Maturity Ωριµότητα

Measure Μέτρο

Measurement Μέτρηση

Metric interpretation Ερµηνεία µετρικής

Metric Μετρική

Milestone Ορόσηµο

Object – oriented programming Αντικειµενοστραφής προγραµµατισµός

Operability Ευκολία χειρισµού

Operating manual Λειτουργικό εγχειρίδιο

Optimising CMM level Επίπεδο Βελτιστοποίησης CMM

Organic mode projects Οργανική κατηγορία έργων

1 9 5∞ § º ∞ µ ∏ ∆ π ∫ √ ∂ À ƒ ∂ ∆ ∏ ƒ π √ √ ƒ ø ¡ ( ∞ ° ° § π ∫ ∞ – ∂ § § ∏ ¡ π ∫ ∞ )

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 195

1 9 6 ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ∫ ∞ π ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

Personnel Προσωπικό

PERT Chart ∆ιάγραµµα αξιολόγησης έργου

Planning Καθορισµός

Portability Μεταφερσιµότητα

Pricing to win Εκτίµηση που βασίζεται στο τελικό κόστος

Primary uses Πρωταρχικές χρήσεις

Primitive constructs Πρωτογενείς κατασκευές

Procedure ∆ιαδικασία

Process metrics Μετρικές διαδικασίας

Process quality assurance ∆ιασφάλιση ποιότητας διαδικασιών

Product metrics Μετρικές προϊόντος

Product quality assurance ∆ιασφάλιση ποιότητας προϊόντος

Programmer Προγραµµατιστής

Progress report Έκθεση προόδου

Progress Πρόοδος

Project management structure Οργανόγραµµα διαχείρισης έργου

Project Quality plan Πλάνο ποιότητας έργου

Quality assurance ∆ιασφάλιση ποιότητας

Quality control Ποιοτικός έλεγχος

Quality engineering Τεχνολογία ποιότητας

Quality factors Παράγοντες ποιότητας

Quality inspection Επισκόπηση ποιότητας

Quality management ∆ιαχείριση ποιότητας

Quality manager Υπεύθυνος ποιότητας

Quality manual Εγχειρίδιο ποιότητας

Quality manual Εγχειρίδιο ποιότητας

Quality procedures ∆ιαδικασίες ποιότητας

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 196

Quality program Πρόγραµµα ποιότητας

Quality system Σύστηµα ποιότητας

Quality Ποιότητα

Recoverability Ανακτησιµότητα

Reliability Αξιοπιστία

Repeatable CMM level Επαναλαµβανόµενο επίπεδο CMM

Replaceability Αντικαταστασιµότητα

Resource behaviour Αξιοποίηση πόρων

Resource metrics Μετρικές πόρων

Resource quality assurance ∆ιασφάλιση ποιότητας πόρων

Reusability Επαναχρησιµοποιησιµότητα

Reverse traceability Αντίστροφη ανιχνευσιµότητα

Risk analysis Ανάλυση κινδύνου

Sampling ∆ειγµατοληψία

Scatter plot Γράφηµα ∆ιασποράς

Security Ασφάλεια

Semi – detached mode projects Ηµι – προσαρτηµένη κατηγορία έργων

Senior Programmer Ανώτερος προγραµµατιστής

Senior projects manager Ανώτερος υπεύθυνος έργων

Size Μέγεθος

Software engineer Μηχανικός ανάπτυξης

Software engineering Τεχνολογία λογισµικού

Software project manager Υπεύθυνος διαχείρισης έργου λογισµικού

Software project Έργο λογισµικού

Software quality Ποιότητα λογισµικού

Software Λογισµικό

Stability Σταθερότητα

1 9 7∞ § º ∞ µ ∏ ∆ π ∫ √ ∂ À ƒ ∂ ∆ ∏ ƒ π √ √ ƒ ø ¡ ( ∞ ° ° § π ∫ ∞ – ∂ § § ∏ ¡ π ∫ ∞ )

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 197

1 9 8 ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ∫ ∞ π ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

Staff allocation chart ∆ιάγραµµα ανάθεσης έργου

Standard Πρότυπο

Standardisation Τυποποίηση

Statistical quality control Στατιστικός έλεγχος ποιότητας

Suitability Καταλληλότητα

Surveillance Επίβλεψη

Test engineer Μηχανικός ελέγχου

Testability Ελεγξιµότητα

Time behaviour Χρονική συµπεριφορά

Total quality management ∆ιαχείριση ολικής ποιότητας

Traceability Ανιχνευσιµότητα

Understandability Κατανοησιµότητα

Usability Ευχρηστία

User Χρήστης

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 198

°ÏˆÛÛ¿ÚÈ

Αρχική τµηµατοποίηση έργου

Αρχική τµηµατοποίηση του έργου καλούµε τη διαδικασία χωρισµού του έργου

σε τµήµατα, έτσι ώστε να υπολογιστούν οι αλληλεξαρτήσεις ανάµεσα στα τµή-

µατα και να εκτιµηθεί το απαιτούµενο ανθρώπινο δυναµικό. Πρέπει να εξηγηθεί

ότι δεν µιλάµε για σχεδίαση (design) του έργου.

Ανάλυση κινδύνου

Ανάλυση του κινδύνου είναι η µελέτη –που συνήθως γίνεται από τον υπεύθυνο

του έργου– όλων εκείνων των καταστάσεων που αν συµβούν (χωρίς να είναι

βέβαιο ότι θα συµβούν) θα έχουν αρνητικές συνέπειες για το έργο.

Ανώτερος υπεύθυνος έργων

Ανώτερος υπεύθυνος έργων είναι µέλος του προσωπικού µιας επιχείρησης ή

οργανισµού που έχει ανέβει σε ανώτερο διοικητικό επίπεδο από αυτό του υπεύ-

θυνου έργου και έχει αναλάβει την ευθύνη πολλών έργων, προερχόµενος συχνά

από προσωπικό που έχει διατελέσει για κάποια χρόνια ως υπεύθυνος έργου και

έχει αποδείξει τις ικανότητές του στην πράξη.

Αξιοπιστία

Αξιοπιστία είναι ένα σύνολο χαρακτηριστικών που είναι φορείς της δυνατότητας

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

και για προκαθορισµένη χρονική περίοδο.

Αποδοτικότητα

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

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

που χρησιµοποιεί, υπό καθορισµένες συνθήκες.

∆ειγµατοληψία

∆ειγµατοληψία είναι η περιοδική επιλογή ενός µικρού αριθµού προϊόντων από µία

παρτίδα προϊόντων, µε σκοπό να ελεγχθεί αν πληρούν τις αρχικές προδιαγραφές.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 199

2 0 0 ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ∫ ∞ π ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

∆ιαχείριση ανάπτυξης λογισµικού

∆ιαχείριση ανάπτυξης λογισµικού είναι η πράξη της παρακολούθησης των

ανθρώπινων, οικονοµικών και τεχνικών παραγόντων που σχετίζονται µε την ανά-

πτυξη του λογισµικού (software). Υπενθυµίζουµε ότι µε τον όρο «αναπτύσσεται»

αποδίδουµε τον αντίστοιχο αγγλικό όρο «engineered».

∆ιάγραµµα ανάθεσης έργου σε ανθρώπινο δυναµικό

Το διάγραµµα ανάθεσης έργου σε ανθρώπινο δυναµικό σχετίζει το χρονοδιά-

γραµµα του έργου µε το προσωπικό που έχει την ευθύνη της υλοποίησης κάθε

τµήµατος. Παρουσιάζει δηλαδή σε ένα διάγραµµα προσωπικό, τµήµατα, αλλη-

λουχία τµηµάτων στο χρόνο και ποσοστό απασχόλησης κάθε εργαζοµένου σε

κάθε τµήµα.

∆ιάγραµµα αξιολόγησης έργου

To διάγραµµα αξιολόγησης έργου (PERT Chart) είναι µία γραφική αναπαράστα-

ση των διαφόρων δραστηριοτήτων (activities ή tasks) που συνθέτουν ένα έργο,

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

∆ιαδικασία

∆ιαδικασία ενός συστήµατος ποιότητας είναι το κείµενο που περιγράφει πώς ένα

συγκεκριµένο κοµµάτι λογισµικού θα αναπτυχθεί.

∆ιασφάλιση ποιότητας

Η διασφάλιση ποιότητας είναι η διαδικασία που εµπεριέχει τη διαχείριση της ποι-

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

παραγωγής είναι συµβατό και λειτουργικά αποδοτικό.

∆ιαχείριση ποιότητας

∆ιαχείριση ποιότητας είναι η κατηγορία (τοµέας) µιας επιχείρησης η οποία έχει

την ευθύνη να ασκεί την ανώτατη διαχείριση και να ανατροφοδοτεί µε ακρίβεια

και εγκυρότητα την παραγωγή.

∆ίκτυο δραστηριοτήτων έργου

To δίκτυο δραστηριοτήτων έργου είναι µία γραφική αναπαράσταση των διαφό-

ρων δραστηριοτήτων (activities ή tasks) που συνθέτουν ένα έργο.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 200

Εγχειρίδιο ποιότητας

Το εγχειρίδιο ποιότητας συγκεντρώνει όλες τις δοµές, τις δραστηριότητες, τις

αρµοδιότητες, τις διαδικασίες, τους πόρους, τις µετρικές και τα εργαλεία µέτρη-

σης που η επιχείρηση έχει συµπεριλάβει στο σύστηµα ποιότητας και που είναι

δυνατόν να χρησιµοποιηθούν για τη διασφάλιση ή τον έλεγχο της ποιότητας

κάποιου έργου.

Έκθεση προόδου

Η έκθεση προόδου ή αναφορά προόδου εργασιών είναι ένα τεχνικό κείµενο το

οποίο συγγράφεται (συνήθως από τον υπεύθυνο έργου) µε την επίτευξη κάποιου

ορόσηµου. Στην έκθεση προόδου γίνεται ανάλυση της συνολικής προόδου του

έργου µε αφορµή την επίτευξη του ορόσηµου και περιέχει σύγκριση των αρχι-

κών στόχων του έργου µε τους στόχους που επιτεύχθηκαν.

Εκτίµηση παραγόντων όπως η προσπάθεια, το κόστος και ο χρόνος

Εκτίµηση παραγόντων όπως οι ανάγκες σε ανθρώπινο δυναµικό, το κόστος και

ο χρόνος είναι η ικανότητα πρόβλεψης της εξέλιξης µιας κατάστασης πριν ακόµα

αυτή δροµολογηθεί. Για τη γνώση αυτή χρησιµοποιούνται τεχνικές που βασίζο-

νται σε δεδοµένα από αντίστοιχες προηγούµενες καταστάσεις.

Εκτίµηση από κάτω προς τα πάνω

Η εκτίµηση από κάτω προς τα πάνω είναι µία τεχνική εκτίµησης που βασίζεται

στη λογική διάσπασης του έργου σε µικρότερα τµήµατα. Είναι δηλαδή µία τεχνι-

κή τµηµατοποίησης µε σκοπό την εκτίµηση.

Ελεγξιµότητα

Ελεγξιµότητα είναι ένα σύνολο χαρακτηριστικών που σχετίζονται µε την απαι-

τούµενη προσπάθεια για τον έλεγχο του βαθµού στον οποίο το λογισµικό ικανο-

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

Έλεγχος ποιότητας

Έλεγχος ποιότητας είναι ένας κανόνας δράσης κατά τον οποίο χρησιµοποιούµε

στρατηγικές, όπως οι επισκοπήσεις και ο στατιστικός έλεγχος απόδοσης για να

διασφαλίσουµε ότι το προϊόν που θα παραχθεί θα είναι ποιοτικά αποδεκτό.

2 0 1° § ø ™ ™ ∞ ƒ π

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 201

2 0 2 ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ∫ ∞ π ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

Έλεγχος απόκλισης

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

προϊόν ικανοποιεί τις αρχικές προδιαγραφές, λαµβάνοντας υπόψη κάποια απο-

δεκτά όρια απόκλισης.

Εξωτερικά χαρακτηριστικά του λογισµικού

Εξωτερικά χαρακτηριστικά λογισµικού είναι τα χαρακτηριστικά του λογισµικού

που χαρακτηρίζονται από υψηλό επίπεδο αφαίρεσης, τα οποία συνθέτουν την ποι-

ότητα του λογισµικού.

Εξωτερικές µετρικές

Εξωτερικές µετρικές είναι οι µετρικές αυτές που χρησιµοποιούνται για τη µέτρη-

ση χαρακτηριστικών του λογισµικού που χαρακτηρίζονται από υψηλό επίπεδο

αφαίρεσης και τα οποία σχετίζονται άµεσα µε την ποιότητα του λογισµικού.

Επαναχρησιµοποιησιµότητα

Επαναχρησιµοποιησιµότητα είναι ένα σύνολο χαρακτηριστικών που σχετίζονται

µε την απαιτούµενη προσπάθεια για επαναχρησιµοποίηση του συνόλου ή µέρους

του λογισµικού που έχει αναπτυχθεί.

Επίβλεψη

Επίβλεψη είναι µια χαλαρή διαδικασία επισκόπησης που χρησιµοποιεί µερικές

τεχνικές από τον περιοδικό έλεγχο και µερικές από την επισκόπηση.

Επισκόπηση

Επισκόπηση είναι η υψηλή οριοθέτηση και η λεπτοµερής εξέταση ενός προϊό-

ντος, ή µιας διαδικασίας.

Επισκόπηση ποιότητας

Επισκόπηση ποιότητας ονοµάζεται η κατηγορία (τοµέας) µιας επιχείρησης που

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

και τη συλλογή δεδοµένων για να αναγνωρίσει τη ρίζα των προβληµάτων στην

ποιότητα των προϊόντων και να βρει ένα διορθωτικό µοντέλο.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 202

Ερµηνεία µετρικής

Ερµηνεία µετρικής είναι ο καθορισµός του βαθµού συσχέτισης της µετρικής

αυτής µε κάποιο ή κάποια εξωτερικά χαρακτηριστικά του λογισµικού.

Έργο λογισµικού

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

έργο λογισµικού. Την ευθύνη για τη διαχείριση αυτού του έργου την έχει ο υπεύ-

θυνος διαχείρισης έργου λογισµικού.

Εσωτερικά χαρακτηριστικά του λογισµικού

Εσωτερικά χαρακτηριστικά λογισµικού είναι τα χαρακτηριστικά του λογισµικού

για τα οποία υπάρχει απτή φυσική αντίληψη και άµεσος τρόπος µέτρησης.

Εσωτερικές µετρικές

Εσωτερικές µετρικές είναι οι µετρικές αυτές που χρησιµοποιούνται για τη µέτρη-

ση χαρακτηριστικών του λογισµικού για τα οποία υπάρχει απτή αντίληψη για τη

φυσική τους σηµασία και δυνατότητα άµεσης µέτρησης.

Εσωτερικός περιοδικός έλεγχος

Εσωτερικός περιοδικός έλεγχος είναι η επισκόπηση σε έναν οργανισµό, µε περιο-

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

τύπου ποιότητας.

Ευχρηστία

Ευχρηστία, σύµφωνα µε το πρότυπο ISO 9241, ενός συστήµατος είναι η ικανό-

τητά του να λειτουργεί αποτελεσµατικά και αποδοτικά ενώ παρέχει υποκειµενι-

κή ικανοποίηση στους χρήστες του.

Κρίσιµο µονοπάτι

Κρίσιµο µονοπάτι είναι µια αλληλουχία δραστηριοτήτων από τις οποίες αν καθυ-

στερήσει κάποια από αυτές, αυτό θα έχει ως συνέπεια την καθυστέρηση όλου του

έργου.


Λειτουργικότητα είναι ένα σύνολο χαρακτηριστικών που είναι φορείς ενός συνό-

2 0 3° § ø ™ ™ ∞ ƒ π

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 203

2 0 4 ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ∫ ∞ π ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

λου λειτουργιών και των καθορισµένων ιδιοτήτων τους. Οι λειτουργίες αυτές ικα-

νοποιούν δηλωµένες ή συνεπαγόµενες ανάγκες.

Μέγεθος έργου

Μέγεθος στη γλώσσα του λογισµικού, ορίζουµε τη µετρήσιµη ποσότητα –που

συνήθως µετριέται σε γραµµές κώδικα– του εξαγόµενου προϊόντος.

Μεταφερσιµότητα

Μεταφερσιµότητα είναι ένα σύνολο χαρακτηριστικών που σχετίζονται µε τη

δυνατότητα του λογισµικού να µεταφέρεται από ένα περιβάλλον σε άλλο (αυτό

περιλαµβάνει το υλικό, λογισµικό ή οργανωτικό περιβάλλον).

Μέτρηση

Μέτρηση είναι η διαδικασία µε την οποία αριθµοί ή σύµβολα αντιστοιχούνται σε

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

φωνα µε καθορισµένους κανόνες.

Μετρική

Μετρική είναι µια εµπειρική αντικειµενική αντιστοίχηση ενός αριθµού (ή συµ-

βόλου) σε µια οντότητα µε στόχο να χαρακτηρίσει ένα συγκεκριµένο χαρακτη-

ριστικό της οντότητας αυτής.

Οδηγία

Οδηγία στα πλαίσια ενός συστήµατος ποιότητας είναι περιγραφικό κείµενο που

επεξηγεί την εφαρµογή ενός προτύπου.

∆ιαχείριση ολικής ποιότητας

∆ιαχείριση ολικής ποιότητας είναι τρόπος διοίκησης ενός οργανισµού που εστιά-

ζει στην ποιότητα, ο οποίος βασίζεται στη συµµετοχή όλων των µελών του και

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

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

Οργανόγραµµα διαχείρισης έργου

Το οργανόγραµµα διαχείρισης έργου παρουσιάζει σχηµατικά τη διοικητική δοµή

του έργου, παρουσιάζει δηλαδή τις οµάδες ανάπτυξης, το προσωπικό που συµµετέ-

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 204

χει σε αυτές και τους ρόλους καθενός που συµµετέχει στην ανάπτυξη λογισµικού.

Ορόσηµα

Ένα ορόσηµο καθορίζει ένα σηµαντικό σηµείο του έργου που σχετίζεται µε την

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

«milestones» από τα πέτρινα κολωνάκια που ήταν τοποθετηµένα παλαιότερα στην

άκρη των δρόµων και έδειχναν σε ποιο µίλι βρίσκεται ο οδηγός.

Παράγοντες ποιότητας

Παράγοντες ποιότητας είναι οµάδες χαρακτηριστικών τα οποία συνθέτουν την

ποιότητα ενός προϊόντος, έχουν την ελάχιστη δυνατή επικάλυψη µεταξύ τους και

είναι επαρκή για τη σύνθεση της ποιότητας.

Πλάνο ποιότητας

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

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

τας του συγκεκριµένου έργου.

Ποιότητα

Ποιότητα είναι η συλλογή των χαρακτηριστικών και των ιδιοτήτων του προϊό-

ντος που σχετίζονται µε τη δυνατότητά του να εκπληρώνει τις ζητούµενες ανά-

γκες των πελατών. (Ορισµός του American Society for Quality)

Ποιότητα είναι η συµµόρφωση µε τις απαιτήσεις των χρηστών. (Ορισµός του

Phillip Crosby)

Ποιότητα είναι καταλληλότητα προς χρήση. (Ορισµός του Joseph Juran)

Ποιότητα είναι η συλλογή των χαρακτηριστικών σχεδιασµού, κατασκευής και

συντήρησης, διά µέσου των οποίων το προϊόν κατά τη χρήση του θα εκπληρώ-

σει τις προσδοκίες των πελατών. (Ορισµός του Feigenbaum)

Ποιότητα είναι η συµµόρφωση µε τυποποιηµένες προδιαγραφές που περιγράφουν

τα βασικά χαρακτηριστικά του προϊόντος και έχουν βασιστεί στις ανάγκες και

προσδοκίες των πελατών. (Ορισµός του Aubrey)

Ποιότητα είναι το σύνολο των χαρακτηριστικών µιας οντότητας που της αποδί-

δουν την ικανότητα να ικανοποιεί εκφρασµένες και συνεπαγόµενες ανάγκες. (Ορι-

σµός του προτύπου ISO 8402)

2 0 5° § ø ™ ™ ∞ ƒ π

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 205

2 0 6 ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ∫ ∞ π ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

Πρόγραµµα ποιότητας

Πρόγραµµα ποιότητας µίας επιχείρησης ορίζεται ως το σύνολο των διαδικασιών,

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

παραγόµενου προϊόντος ή την ικανοποίηση των απαιτήσεων των πελατών.

Προγραµµατισµός βασισµένος σε ψηφίδες

Προγραµµατισµός βασισµένος σε ψηφίδες είναι η τεχνική ανάπτυξης τµηµάτων

λογισµικού τα οποία µπορούν να χρησιµοποιηθούν αυτόνοµα σε κάθε έργο. Υλο-

ποιείται µε συγκεκριµένες γλώσσες προγραµµατισµού που υποστηρίζουν τη δηµι-

ουργία ψηφίδων (components).

Προγραµµατισµός έργου

Προγραµµατισµός έργου είναι η αρχική φάση της ανάπτυξης λογισµικού κατά

την οποία καθορίζονται οι βασικές προδιαγραφές του λογισµικού, γίνεται η

κοστολόγηση του έργου, η τιµολόγηση του έργου (εάν είναι έργο που αναπτύσ-

σεται για συγκεκριµένο πελάτη), η εκτίµηση των µεγεθών του έργου, η µελέτη

του εφικτού και η ανάλυση του κινδύνου και η αρχική τµηµατοποίηση και ο χρο-

νοπρογραµµατισµός του έργου. Προσοχή: δεν πρέπει να συγχέουµε τον προ-

γραµµατισµό του έργου (planning) µε τον προγραµµατισµό / κωδικοποίηση

(programming) που γίνεται στη φάση της υλοποίησης του έργου.

Προγραµµατιστής

Ο προγραµµατιστής είναι αυτός που γνωρίζει µία γλώσσα προγραµµατισµού και

του δίνονται προδιαγραφές ώστε να υλοποιήσει ένα τµήµα λογισµικού σε αυτή

τη γλώσσα.

Προσαρµοσµένο λογισµικό

Το προσαρµοσµένο λογισµικό είναι λογισµικό το οποίο αναπτύσσεται για συγκε-

κριµένο πελάτη. Συνήθως αυτός ο πελάτης εντάσσεται τόσο στη διαδικασία ανά-

πτυξης, όσο και στο πρόγραµµα διασφάλισης ποιότητας.

Προσωπικό

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

εργάζονται σε αυτή.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 206

Πρότυπο

Πρότυπο είναι µία τεκµηριωµένη σύµβαση που περιέχει τεχνικές προδιαγραφές,

ή άλλα ακριβή κριτήρια χρησιµοποιούµενα ως κανόνες και κατευθυντήριες γραµ-

µές για την εξασφάλιση της τυποποίησης των κατάλληλων υλικών, προϊόντων,

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

και υπηρεσιών και της ανάπτυξης συνεργασίας στη σφαίρα των επιστηµονικών,

τεχνολογικών και οικονοµικών ενεργειών.

Συντήρηση

Η συντήρηση είναι η φάση της ανάπτυξης λογισµικού κατά την οποία διορθώ-

νουµε, αλλάζουµε ή βελτιώνουµε λογισµικό που έχει ήδη αναπτυχθεί και παρα-

δοθεί στον πελάτη.


Συντηρησιµότητα είναι ένα σύνολο χαρακτηριστικών που σχετίζονται µε την

απαιτούµενη προσπάθεια για να υλοποιηθούν συγκεκριµένες αλλαγές (που µπο-

ρεί να περιλαµβάνουν διορθώσεις, βελτιώσεις και προσαρµογές) στο λογισµικό,

στο περιβάλλον, ή στις απαιτήσεις.

Σύστηµα ποιότητας

Βλέπε «πρόγραµµα ποιότητας».

Τεκµηρίωση

Τεκµηρίωση ονοµάζεται κάθε είδος κειµένου που παράγεται στα πλαίσια ενός

έργου λογισµικού. Σε αυτή περιλαµβάνεται κάθε εσωτερικό κείµενο που θα δια-

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

θα κοινοποιηθεί ή θα παραδοθεί στον πελάτη.

Τεχνολογία ποιότητας

Τεχνολογία ποιότητας ονοµάζεται η κατηγορία (τοµέας) µιας επιχείρησης η οποία

έχει την ευθύνη να αναλύει τα προβλήµατα που σχετίζονται µε την ποιότητα, να

τα επιλύει, να εκπαιδεύει το προσωπικό και να εγκαθιδρύει προγράµµατα που

βελτιώνουν την ποιότητα.

2 0 7° § ø ™ ™ ∞ ƒ π

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 207

2 0 8 ¢ π ∞ Ã ∂ π ƒ π ™ ∏ ∫ ∞ π ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

Υπεύθυνος διαχείρισης έργου λογισµικού

Ο υπεύθυνος διαχείρισης έργου λογισµικού είναι αυτός που έχει την ευθύνη για

την πορεία του έργου, δηλαδή την τεχνική, οικονοµική και διαχειριστική ευθύνη

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

λόγους συντοµίας και ως υπεύθυνος έργου.

Υπεύθυνος έργων

Βλέπε «Ανώτερος υπεύθυνος έργων».

Υπεύθυνος έργου

Βλέπε «Υπεύθυνος διαχείρισης έργου λογισµικού».

Υπεύθυνος ποιότητας

Υπεύθυνος ποιότητας είναι το µέλος του προσωπικού που έχει την ευθύνη διοί-

κησης του τµήµατος ποιότητας, δηλαδή την ευθύνη της καταγραφής, επίβλεψης

και διαρκούς εξέλιξης όλων των δοµών, δραστηριοτήτων, αρµοδιοτήτων, διαδι-

κασιών, πόρων, µετρικών και εργαλείων µέτρησης που µπορούν να χρησιµοποι-

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

Χρονοδιάγραµµα

Το χρονοδιάγραµµα (Gantt chart) παρουσιάζει το χρόνο που εκτιµάται ότι θα χρει-

αστεί κάθε τµήµα του έργου, αλλά και χρησιµοποιείται από τον υπεύθυνο έργου

για την επίβλεψη του έργου και την παρακολούθηση του ποσοστού ολοκλήρω-

σης κάθε τµήµατος.

•¤ÓÔ˜ (208ÛÂÏ.) 2/9/2003 12:59 ™ÂÏ›‰· 208

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

Documents

Transcript of ΔΙΑΧΕΙΡΙΣΗ ΛΟΓΙΣΜΙΚΟΥ