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

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

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

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

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

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

ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ Σχολή Θετικών Επιστηµών και Τεχνολογίας Πρόγραµµα Σπουδών ΠΛHPOΦOPIKH Θεµατική Ενότητα EI∆IKA ΘEMATA TEXNOΛOΓIAΣ ΛOΓIΣMIKOY Τόµος Γ'

∆ιαχείριση και Ποιότητα Λογισµικού ΜΙΧΑΛΗΣ ΞΕΝΟΣ Λέκτορας Σχολής Θετικών Eπιστηµών & Tεχνολογίας Eλληνικό Aνοικτό Πανεπιστήµιο

ΠATPA 2003

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

ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ Σχολή Θετικών Επιστηµών και Τεχνολογίας Πρόγραµµα Σπουδών ΠΛ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 ™ÂÏ›‰· 5

¶ÂÚÈÂ¯ﬁÌÂÓ· Πρόλογος .................................................................................................................................................................................. 9 K∂º∞§∞π√ 1

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

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

................................................................................................

...............................................................................................................................

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

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

.............................................................. .........................................

........................................................................................................

................................................................................................................

...................................................................................................................

......................................................................................................................................................

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

∆ιαδικασίες διαχείρισης έργων 1.2.1 Aνάλυση διαδικασιών 1.2.2 Tεχνικές διαχείρισης

1.3

Oι άνθρωποι

1.3.1 Mέλος της διοίκησης ................................................................................................................... 38 1.3.2 Yπεύθυνος έργου ή έργων ...................................................................................................... 39 1.3.3 Hγέτης οµάδας .................................................................................................................................. 40 1.3.4 Mηχανικός ανάπτυξης ................................................................................................................ 40 1.3.5 Προγραµµατιστής

..........................................................................................................................

1.3.6 Tεχνικοί και υπόλοιπο προσωπικό 1.3.7 Πελάτες 1.4

..................................................................................

...................................................................................................................................................

Eργασία σε οµάδες ...................................................................................................................................... 43 1.4.1 Tρόποι οργάνωσης οµάδων ................................................................................................... 44 1.4.2 Πλεονεκτήµατα εργασίας σε οµάδες

............................................................................

1.4.3 Oργανόγραµµα ανάπτυξης λογισµικού ....................................................................... 45 Σύνοψη κεφαλαίου και συµβουλές µελέτης .............................................................................................. 47 Βιβλιογραφία και προτάσεις για περαιτέρω µελέτη ........................................................................... 48

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

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

K∂º∞§∞π√ 2

EÎÙ›ÌËÛË Î·È ·Ó¿Ï˘ÛË ÎÈÓ‰‡ÓÔ˘

Eκτίµηση παραγόντων όπως οι ανάγκες σε ανθρώπνο δυναµικό, το κόστος και ο χρόνος ............................................................................................................................ 54 2.1.1 Eισαγωγή στην εκτίµηση παραγόντων όπως οι ανάγκες σε ανθρώπινο δυναµικό, το κόστος και ο χρόνος ...................................................... 54 2.1.2 Παράγοντες που επιδρούν στην εκτίµηση ................................................................ 57 2.1.3 Mέθοδοι εκτίµησης ....................................................................................................................... 58

2.2

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

..........................................................................

2.2.1 Tεχνικές εκτίµησης ....................................................................................................................... 60 2.2.2 Eµπειρικά µοντέλα ........................................................................................................................ 67 2.3

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

......................................................................................................................................

Σύνοψη κεφαλαίου και συµβουλές µελέτης .............................................................................................. 74 Βιβλιογραφία και προτάσεις για περαιτέρω µελέτη ........................................................................... 75 K∂º∞§∞π√ 3

EÈÛ·ÁˆÁ‹ ÛÙËÓ ¶ÔÈﬁÙËÙ·

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

.....................................................................................................

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

...............................................................................................................................

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

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

............................................................................................... ............................................................................

..........................................................................................

3.2.2 Oι πρώτες απόψεις για την ποιότητα 3.2.3 Στατιστικός έλεγχος ποιότητας 3.3

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

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

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

¶EPIEXOMENA

Βιβλιογραφία και προτάσεις για περαιτέρω µελέτη ........................................................................... 94 K∂º∞§∞π√ 4

¶ÔÈﬁÙËÙ· ÏÔÁÈÛÌÈÎÔ‡

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

.......................................................................................

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 ...................................................................

109

........................................................................

113

.............................................................................

117

4.2.1 Eφαρµογή του συστήµατος ποιότητας 4.2.2 Xρήστες του συστήµατος ποιότητας 4.2.3 Oφέλη από το σύστηµα ποιότητας

Σύνοψη κεφαλαίου και συµβουλές µελέτης ........................................................................................... 120 Βιβλιογραφία και προτάσεις για περαιτέρω µελέτη

.......................................................................

121

K∂º∞§∞π√ 5

MÂÙÚ‹ÛÂÈ˜ Î·È MÂÙÚÈÎ¤˜ ¶ÔÈﬁÙËÙ·˜ §ÔÁÈÛÌÈÎÔ‡

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

5.2

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

....................................................................................................................... ............................................................

125 129

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

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

5.4

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

............................................................ .........................

139 142

Σύνοψη κεφαλαίου και συµβουλές µελέτης ........................................................................................... 144 Βιβλιογραφία και προτάσεις για περαιτέρω µελέτη

.......................................................................

145

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

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

K∂º∞§∞π√ 6

¶ÚﬁÙ˘· ¶ÔÈﬁÙËÙ·˜ §ÔÁÈÛÌÈÎÔ‡

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

.......................................................................................................................

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

..........................................

149 151

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

158

...................................................................................

160

6.2.2 CMM και ISO 9001: Oµοιότητες και διαφορές 6.2.3 Eπίπεδα ωριµότητας στο CMM

Σύνοψη κεφαλαίου και συµβουλές µελέτης ........................................................................................... 164 Βιβλιογραφία και προτάσεις για περαιτέρω µελέτη

.......................................................................

165

Eπίλογος ............................................................................................................................................................................. 167 Aπαντήσεις Aσκήσεων Aυτοαξιολόγησης ............................................................................................... 169 Γενική βιβλιογραφία

................................................................................................................................................

182

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

........................................................................

187

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

........................................................................

193

..........................................................................................................................................................................

199

Γλωσσάρι

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

¶ÚﬁÏÔÁÔ˜

Το βιβλίο που κρατάτε στα χέρια σας έχει γραφεί µε σκοπό την εισαγωγή σε δύο σηµαντικά θέµατα που σχετίζονται µε το λογισµικό. Τη διαχείριση της ανάπτυξης λογισµικού και την ποιότητα λογισµικού. Το βιβλίο βασίζεται στη µέθοδο της Εκπαίδευσης από απόσταση (δηλαδή είναι αναλυτικό, εµπλουτισµένο µε πολλές ασκήσεις επανάληψης και δραστηριότητες), αλλά είναι και βιβλίο που απευθύνεται σε έµπειρους φοιτητές (δηλαδή σας εισάγει σε αρκετά θέµατα και σας ενθαρρύνει να εµβαθύνετε σε αυτά µελετώντας και από άλλες πηγές). Όταν έγραψα το βιβλίο, είχα ήδη την εµπειρία συγγραφής άλλων δύο βιβλίων για το Ελληνικό Ανοικτό Πανεπιστήµιο, αλλά κυρίως είχα την εµπειρία του πρώτου χρόνου διδασκαλίας σε συµφοιτητές σας και εσάς. Αυτή η εµπειρία και οι συζητήσεις µαζί τους µε βοήθησαν να καταλάβω ακόµα καλύτερα τι θα θέλατε από ένα βιβλίο του Ελληνικού Ανοικτού Πανεπιστηµίου και να προσπαθήσω να το εφαρµόσω στο βιβλίο που κρατάτε στα χέρια σας. Πριν προχωρήσουµε στην ύλη που καλύπτει το βιβλίο, καλό είναι να σας δώσω µερικές συµβουλές για τη µελέτη σας, τις οποίες, αν θέλετε, µπορείτε να ακολουθήσετε. Το βιβλίο έχει πολλές ασκήσεις. Αυτές τις ασκήσεις πρέπει να τις χρησιµοποιείτε ως εργαλεία ελέγχου (για το αν µάθατε καλά) και επανάληψης. Προσέξτε όµως! ∆εν έχει νόηµα να διαβάσετε µία ενότητα και αµέσως µετά να απαντήσετε στην άσκηση που ακολουθεί. Αντίθετα, διαβάστε τη µία µέρα κάποιες ενότητες και την επόµενη (πριν αρχίσετε τη µελέτη σας) δοκιµάστε να λύσετε τις ασκήσεις που αναφέρονται σε αυτές. Εάν τις λύσετε σωστά, τότε προχωρήστε στην επόµενη ενότητα, αλλιώς καλύτερα να ξαναδιαβάσετε την προηγούµενη ενότητα και να επαναλάβετε τις ασκήσεις µέχρι να τις λύνετε σωστά. Το βιβλίο έχει και δύο τύπους δραστηριοτήτων. Ο πρώτος τύπος είναι οι δραστηριότητες στις οποίες η απάντηση δίνεται µέσα στο βιβλίο. Νοµίζω πως ότι καλύτερο για τη µελέτη σας είναι να λύνετε αυτές τις δραστηριότητες µόνοι σας (και πριν, φυσικά, διαβάσετε την απάντηση). Αυτός είναι και ο σκοπός των δραστηριοτήτων. ∆εν θα το βρείτε εύκολο και σε πολλές θα κάνετε λάθη, αλλά µέσα από αυτά τα λάθη θα µάθετε πολύ καλύτερα από το να διαβάσετε απλώς την απάντηση. Ο άλλος τύπος δραστηριοτήτων είναι αυτές που δεν λύνονται µέσα στο βιβλίο. Αυτές είναι οι δραστηριότητες για περαιτέρω µελέτη και σας καλούν να ανατρέξετε στη βιβλιογραφία ή στο διαδίκτυο. Πιθανότατα, για τεχνικούς λόγους (δεν έχετε ή δεν µπορείτε να βρείτε κάποια βιβλία) να µην µπορέσετε να τις υλοποιήσετε όλες, αλλά αξίζει να προσπαθήσετε να ολοκληρώσετε όσο περισσότερες µπορείτε. Συζητήστε τις λύσεις µε τους Συµβούλους – Καθηγητές σας!

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

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

Ας µιλήσουµε τώρα για την ύλη του βιβλίου. Το βιβλίο οργανώνεται σε 6 κεφάλαια. Στο 1ο κεφάλαιο, σας εισάγουµε στις βασικές αρχές της διαχείρισης της ανάπτυξης λογισµικού, παρουζιάσουµε τις βασικές δραστηριότητες που σχετίζονται µε τη διαχείριση, καθώς και τεχνικές διαχείρισης και περιγράφουµε τους ρόλους των συµµετεχόντων στην ανάπτυξη λογισµικού και τρόπους οργάνωσης της ανάπτυξης (εργασίας σε οµάδες, οργάνωση, κτλ). Στο 2ο κεφάλαιο, γίνεται παρουσίαση των εννοιών της εκτίµησης και της ανάλυσης κινδύνου. Παρουσιάζονται τεχνικές εκτίµησης και εµπειρικά µοντέλα εκτίµησης µε σκοπό τη γνώση της εφαρµογής των βασικότερων από αυτές σε έργα λογισµικού. Επίσης, συζητείται ο τρόπος εντοπισµού και κατηγοριοποίησης των περιπτώσεων κινδύνου για κάποιο έργο. Στο 3ο κεφάλαιο, γίνεται η εισαγωγή στις βασικές έννοιες και τους ορισµούς της ποιότητας γενικά, η σύντοµη περιγραφή των βασικών αρχών της ποιότητας στη βιοµηχανική παραγωγή και η εισαγωγή στο στατιστικό έλεγχο της ποιότητας. Επίσης, η επεξήγηση των ιδιαιτεροτήτων στην ποιότητα λογισµικού, σε σχέση µε την ποιότητα στην παραγωγή υλικών αγαθών. Στο 4ο κεφάλαιο, αναλύεται η έννοια της ποιότητας λογισµικού σε ποιοτικά χαρακτηριστικά και περιγράφονται τα πιο γνωστά µοντέλα ποιότητας και τα επιµέρους χαρακτηριστικά κάθε ενός από αυτά. Επίσης, παρουσιάζεται συνοπτικά το σύστηµα ποιότητας λογισµικού και η χρήση και συνεισφορά του στην ανάπτυξη λογισµικού. Στο 5ο κεφάλαιο, γίνεται µία εισαγωγή στις µετρήσεις που διεξάγονται στα πλαίσια ενός συστήµατος ποιότητας λογισµικού µε χρήση µετρικών και η παρουσίαση επιλεγµένων µετρικών και τρόπων µέτρησης. Τέλος, στο 6ο κεφάλαιο, παρουσιάζονται τα πρότυπα που σχετίζονται µε την ανάπτυξη του λογισµικού και ειδικότερα τα πρότυπα της σειράς ISO και το πιο εξειδικευµένο στο λογισµικό Capability Maturity Model (CMM). Στο τέλος κάθε κεφαλαίου υπάρχει η βιβλιογραφία του κεφαλαίου και σχολιασµένα βιβλία. Τα σχολιασµένα βιβλία είναι βιβλία που µπορείτε να χρησιµοποιήσετε για τη µελέτη σας. Πρέπει να σηµειωθεί ότι, για κάποια κεφάλαια που καλύπτονται σε µερικές σελίδες, µπορείτε, αν θέλετε να εµβαθύνετε, να βρείτε πολυσέλιδα βιβλία εξειδικευµένα στο θέµα. Θέληση να υπάρχει και η περαιτέρω µελέτη θα αποβεί πολύτιµη. (Προσέξτε ότι δεν είπα θέληση και χρόνος, γιατί αν υπάρχει θέληση χρόνο θα βρείτε είµαι βέβαιος!) Έχοντας την τύχη να δω ένα βιβλίο µου ήδη να διδάσκεται στο Ελληνικό Ανοικτό

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

¶ƒ√§√°√™

Πανεπιστήµιο, ξέρω ότι είναι αδύνατο το βιβλίο να µην έχει µερικά λάθη, παρόλο που µέχρι να φτάσει στα χέρια σας ελέγχθηκε από πολλούς ανθρώπους. Ελπίζω να δείτε αυτά τα λάθη µε κατανόηση και –το σηµαντικότερο– να τα επισηµάνετε στο Σύµβουλο – Καθηγητή σας ώστε να τα διορθώσουµε στην επόµενη έκδοση. Τελειώνοντας, θέλω να ευχαριστήσω όλους όσοι συνετέλεσαν ώστε να φτάσει το βιβλίο αυτό στα χέρια σας. Πρώτα από όλα τον Ακαδηµαϊκό Υπεύθυνο Καθηγητή Παναγιώτη Πιντέλα και τον κριτικό αναγνώστη Αναπληρωτή Καθηγητή Νίκο Αβούρη, που έλεγξαν την επιστηµονική ορθότητα των πρωτοτύπων και µε τις πολύτιµες παρατηρήσεις τους συνετέλεσαν στη µείωση (ελπίζω και εξάλειψη) των λαθών από την τελική έκδοση. Επίσης, την Οµάδα Εκτέλεσης Έργου του ΕΑΠ που έλεγξε το κείµενο από πλευράς εκπαίδευσης από απόσταση και έκανε τη γλωσσική επιµέλεια. Θέλω, επίσης, να ευχαριστήσω τους προπτυχιακούς φοιτητές και µεταπτυχιακούς φοιτητές µε τους οποίους κατά καιρούς συνεργάστηκα και µε βοήθησαν στη συλλογή του πρωτότυπου υλικού. Ευχαριστώ λοιπόν τους (αλφαβητικά): Γιώτα Ευαγγελιστή, Κωσταντινιά Ζηκούλη, Βασιλική Λάζαρη, Κώστα Λεώνη, Ελένη Μακοπούλου, ∆ηµήτρη Σταυρινούδη, Αντωνία Στεφανή και Βασίλη Συρίµπεη. Τέλος, θα ήθελα να απευθύνω ένα πολύ µεγάλο ευχαριστώ και σε όλους τους συντελεστές του βιβλίου αυτού που δεν γνωρίζω ακόµα (τεχνικό επιµελητή, γραφίστα, καλλιτεχνικό επιµελητή, υπεύθυνο σελιδοποίησης, κτλ). Μιχάλης Ξένος Λέκτορας Ελληνικού Ανοικτού Πανεπιστηµίου

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

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

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

∫

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

∂

1 º

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

¶ÚÔÛ‰ÔÎÒÌÂÓ· ·ÔÙÂÏ¤ÛÌ·Ù· Όταν θα έχετε ολοκληρώσει τη µελέτη αυτού του κεφαλαίου θα µπορείτε να: • εξηγήσετε τις βασικές έννοιες και ορισµούς της διαχείρισης λογισµικού, • εξηγήσετε τις ιδιαιτερότητες στην παραγωγή λογισµικού, • αναφέρετε τουλάχιστον πέντε λόγους γιατί αποτυγχάνουν έργα ανάπτυξης λογισµικού, • ορίσετε τα τρία σηµεία στα οποία πρέπει να επικεντρώνει η διαχείριση της ανάπτυξης έργων λογισµικού, • αναφέρετε και περιγράψετε τις δραστηριότητες που εκτελούνται στις πρώτες φάσεις της ανάπτυξης λογισµικού, • αναφέρετε και περιγράψετε τις δραστηριότητες που εκτελεί ο υπεύθυνος έργου σε όλη τη διάρκεια της ανάπτυξης λογισµικού, • περιγράψετε τι είναι η διαδικασία της ανάθεσης έργου σε ανθρώπινο δυναµικό, • σχεδιάσετε το διάγραµµα δραστηριοτήτων έργου για ένα συγκεκριµένο και σαφώς ορισµένο παράδειγµα έργου λογισµικού, • σχεδιάσετε το διάγραµµα αξιολόγησης έργου για ένα συγκεκριµένο και σαφώς ορισµένο παράδειγµα έργου λογισµικού και να εντοπίσετε τα ορόσηµα και τα κρίσιµα µονοπάτια του έργου, • σχεδιάσετε το χρονοδιάγραµµα έργου και το διάγραµµα ανάθεσης έργου σε ανθρώπινο δυναµικό για ένα συγκεκριµένο και σαφώς ορισµένο παράδειγµα έργου λογισµικού, • αναφέρετε τους συµµετέχοντες και να περιγράψετε τα ζητούµενα προσόντα και τους ρόλους τους στην ανάπτυξη λογισµικού, • σχεδιάσετε το οργανόγραµµα διαχείρισης έργου για ένα συγκεκριµένο και σαφώς

∞

√

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

KEºA§AIO 1: ∂π™∞°ø°∏ ™∆∏ ¢π∞Ã∂πƒπ™∏ §√°π™ªπ∫√À

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

ŒÓÓÔÈÂ˜ ÎÏÂÈ‰È¿ • ∆ιαχείριση (Management)

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

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

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

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

• ∆ιάγραµµα

• Υπεύθυνος διαχείρισης έργου λογισµικού (Software project manager)

ανάθεσης

έργου

σε

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

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

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

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

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

• Προγραµµατισµός έργου (Planning) • Προσπάθεια (Effort) • Πρόοδος (Progress)

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

• Έκθεση προόδου (Progress report) • Tεκµηρίωση (Documentation) • ∆ίκτυο δραστηριοτήτων (Activity network) • ∆ιάγραµµα αξιολόγησης έργου (PERT Chart)

• Πελάτης (Customer) • Μη εγωιστικός προγραµµατισµός (Egoless programming) • Οργανόγραµµα διαχείρισης έργου (Project management structure)

∂ÈÛ·ÁˆÁÈÎ¤˜ ·Ú·ÙËÚ‹ÛÂÈ˜ Στο κεφάλαιο αυτό θα µιλήσουµε για τη διαχείριση της ανάπτυξης λογισµικού, µία διαδικασία µε την οποία επιφορτίζεται ο υπεύθυνος έργου. Στην ενότητα 1.1, θα παρουσιάσουµε τις βασικές έννοιες και ορισµούς και θα συζητήσουµε για τις ιδιαι-

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

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

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

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

KEºA§AIO 1: ∂π™∞°ø°∏ ™∆∏ ¢π∞Ã∂πƒπ™∏ §√°π™ªπ∫√À

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

Στην ενότητα αυτή θα δοθούν αρκετοί βασικοί όροι και έννοιες που θα χρησιµοποιηθούν στο βιβλίο. Οι όροι που παρουσιάζονται για πρώτη φορά δίνονται τόσο στα Ελληνικά όσο και στα Αγγλικά (σε παρενθέσεις). Αυτό γίνεται ώστε να σας δοθεί η δυνατότητα να εξοικειωθείτε και µε την αγγλική ορολογία, µια και αρκετή από τη βιβλιογραφία που παρατίθεται στο τέλος του κεφαλαίου είναι στα αγγλικά. Στο πρώτο µέρος της ενότητας, µε τίτλο βασικές έννοιες, θα συζητήσουµε για κάποιους ορισµούς που θα χρησιµοποιηθούν σε όλη την έκταση του βιβλίου. Στο δεύτερο µέρος, µε τίτλο ιδιαιτερότητες στην ανάπτυξη λογισµικού, θα παρουσιάσουµε τις διαφορές µεταξύ της διαχείρισης ανάπτυξης λογισµικού και της κλασσικής παραγωγής υλικών αγαθών και, τέλος, στο τρίτο και τελευταίο µέρος της ενότητας θα συζητήσουµε τη λεγόµενη κρίση του λογισµικού, αντιµετωπίζοντάς την ως πρόβληµα διαχείρισης. 1.1.1 µ·ÛÈÎ¤˜ ¤ÓÓÔÈÂ˜

Όπως θα προσέξατε ο τίτλος της ενότητας είναι «∆ιαχείριση Ανάπτυξης Λογισµικού». Με τον όρο «διαχείριση» αποδίδουµε τον αγγλικό όρο «management». Σήµερα έχει πάντως επικρατήσει να αποδίδεται ο όρος «manager» ως «υπεύθυνος διαχείρισης» και έτσι θα τον αναφέρουµε στη συνέχεια του βιβλίου. Αν αναζητήσουµε στο «Λεξικό της Νέας Ελληνικής Γλώσσας» του Γ. Μπαµπινιώτη τη σηµασία της λέξης διαχείριση, θα βρούµε τον ορισµό που δίνεται δίπλα. ■ ∆ιαχείριση

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

Σαν ορισµός µπορεί να µοιάζει απλός, αλλά στην πραγµατικότητα η διαχείριση ενός έργου είναι µία πολύ δύσκολη δραστηριότητα στην οποία ο υπεύθυνος διαχείρισης πρέπει να δώσει έµφαση σε πολλούς παράγοντες, τόσο ανθρώπινους (κυρίως) όσο και τεχνολογικούς και οικονοµικούς. Τους παράγοντες αυτούς θα συζητήσουµε στην ενότητα 1.2 του κεφαλαίου 1. Ας επανέλθουµε όµως στον τίτλο της ενότητας που µιλά για «ανάπτυξη λογισµικού». Όπως θα συζητήσουµε στην ενότητα 1.1.2 που ακολουθεί, το λογισµικό δεν κατασκευάζεται µε τρόπο αντίστοιχο µε τα περισσότερα υλικά αγαθά. Με τον όρο «αναπτύσσεται» αποδίδουµε τον αντίστοιχο αγγλικό όρο «engineered». Με την εµπειρία που έχετε ως τώρα και µε τα µαθήµατα που έχετε διδαχθεί, γνωρίζετε καλά τι σηµαίνει τεχνολογία λογισµικού (software engineering) και γιατί διαφέρει από την παραγωγή υλικών αγαθών. Έχετε επίσης διδαχθεί τεχνικές ανάπτυξης λογισµικού στα πλαίσια των µαθηµάτων που έχετε παρακολουθήσει. Σε αυτό το βιβλίο θα µιλήσουµε λοιπόν για τη διαχείριση ανάπτυξης λογισµικού. Σε µία επιχείρηση ή οργανισµό που αναπτύσσει λογισµικό είναι πολύ πιθανό να ανα-

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

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

πτύσσονται παράλληλα αρκετά έργα λογισµικού (software projects). Για κάθε ένα από αυτά τα έργα θα υπάρχει κάποιος υπεύθυνος για τη διαχείρισή του, δηλαδή κάποιος υπεύθυνος διαχείρισης έργου λογισµικού (software project manager). Ο υπεύθυνος διαχείρισης έργου λογισµικού θα αναφέρεται, στο υπόλοιπο του βιβλίου, καθαρά για λόγους συντοµίας και υπεύθυνος έργου. Ο ορισµός δίπλα είναι πολύ συνοπτικός, αφού για τις ευθύνες, αρµοδιότητες και εξουσίες του υπεύθυνου έργου θα µιλήσουµε αναλυτικά στην ενότητα 1.3 του κεφαλαίου 1. Όπως θα δούµε, ο ίδιος άνθρωπος µπορεί να είναι υπεύθυνος για περισσότερα από ένα έργα. Ένας ακόµα λόγος που επιλέξαµε τον όρο «υπεύθυνος διαχείρισης έργου λογισµικού» για τον άνθρωπο που θα έχει την ευθύνη ενός ή περισσοτέρων έργων λογισµικού είναι για να τονίσουµε τη διαφορά µεταξύ του ρόλου του υπεύθυνου έργου και του ρόλου του υπεύθυνου για τη διοίκηση της επιχείρησης ή του οργανισµού. Η διοίκηση της επιχείρησης που αναπτύσσει λογισµικό µπορεί να είναι το διοικητικό συµβούλιο ή η συνέλευση των µετόχων (ανάλογα µε το είδος της επιχείρησης ή του οργανισµού) και όπως θα συζητήσουµε στην ενότητα 1.3 έχει διαφορετικές αρµοδιότητες, ευθύνες και στόχους από τον υπεύθυνο έργου. Για λόγους απλότητας, στο υπόλοιπο του βιβλίου, θα χρησιµοποιούµε τον όρο διοίκηση (administration) για τη διοίκηση της επιχείρησης ή του οργανισµού χωρίς να εισερχόµαστε σε λεπτοµέρειες για τη µορφή της επιχείρησης και πώς διοικείται. Πριν προχωρήσουµε στην επόµενη ενότητα, να διευκρινίσουµε ότι όσα θα αναφέρουµε στο βιβλίο αυτό έχουν καλύτερη εφαρµογή σε επιχειρήσεις πολλών ατόµων, όπου οι ρόλοι και οι αρµοδιότητες καθενός είναι σαφέστατα καθορισµένες. Αυτό όµως δεν σηµαίνει ότι όσα διαπραγµατευόµαστε δεν ισχύουν στις µικρές επιχειρήσεις που αναπτύσσουν λογισµικό. Στην Ελλάδα υπάρχουν πολλές επιχειρήσεις µε δύο έως πέντε άτοµα προσωπικό που αναπτύσσουν λογισµικό. Σε τέτοιες περιπτώσεις οι ρόλοι µοιράζονται και κάποιος µπορεί να είναι ταυτόχρονα συνεταίρος, υπεύθυνος έργου και προγραµµατιστής. Τότε οι ανάγκες για επικοινωνία και συντονισµό είναι µικρότερες, αλλά οι ανάγκες για οργάνωση της διαδικασίας ανάπτυξης είναι κοινές µε τις µεγάλες επιχειρήσεις και οι τεχνικές που θα καλύψουµε ισχύουν και πρέπει να εφαρµόζονται. 1.1.2 π‰È·ÈÙÂÚﬁÙËÙÂ˜ ÛÙËÓ ·Ó¿Ù˘ÍË ÏÔÁÈÛÌÈÎÔ‡

Με την εµπειρία που έχετε αποκτήσει ήδη από µαθήµατα όπως οι «Αρχές Τεχνολογίας Λογισµικού», γνωρίζετε ότι το λογισµικό ως προϊόν έχει αρκετές ιδιαιτερότητες που κάνουν τη διαχείρισή του περίπλοκη.

■ Υπεύθυνος

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

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

KEºA§AIO 1: ∂π™∞°ø°∏ ™∆∏ ¢π∞Ã∂πƒπ™∏ §√°π™ªπ∫√À

■ Το λογισµικό

αναπτύσσεται δεν κατασκευάζεται.

■ Για πολλά έργα

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

■ Η διαδικασία

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

■ Στην

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

Για την πρώτη διαφορά µιλήσαµε ήδη στην προηγούµενη ενότητα. Το λογισµικό, όπως γνωρίζετε πολύ καλά, σχεδιάζεται και αναπτύσσεται και δεν κατασκευάζεται µε τρόπο αντίστοιχο της παραγωγής υλικών αγαθών. Βασικές αρχές της παραγωγής υλικών αγαθών δεν εφαρµόζονται στην ανάπτυξη λογισµικού. Τέτοιες αρχές είναι η επεξεργασία πρώτων υλών για τη δηµιουργία τµηµάτων του προϊόντος, η σύνθεση έτοιµων τµηµάτων για τη δηµιουργία του τελικού προϊόντος, η δηµιουργία ενός πρωτοτύπου και η έµφαση στην πιστή αναπαραγωγή αντιγράφων µε ελάχιστες αποκλίσεις από το πρωτότυπο. Αυτές οι αρχές δεν σχετίζονται άµεσα µε την παραγωγή λογισµικού. Βέβαια ο αντικειµενοστραφής προγραµµατισµός (object – oriented programming) και ακόµα περισσότερο ο προγραµµατισµός που είναι βασισµένος σε ψηφίδες (component based programming) έχουν συντελέσει αρκετά στο να θεωρούµε ότι το λογισµικό αναπτύσσεται µε σύνθεση τµηµάτων, αλλά όχι ακόµα στους ρυθµούς και µε την αποτελεσµατικότητα παραγωγής υλικών αγαθών. Επειδή η τεχνολογία των ηλεκτρονικών υπολογιστών –και κατά συνέπεια και του λογισµικού– εξελίσσεται µε ταχύτατους ρυθµούς, για αρκετά έργα ανάπτυξης λογισµικού δεν έχουµε καθόλου ιστορικά δεδοµένα, ή τα ιστορικά δεδοµένα δεν είναι αξιοποιήσιµα. Ιστορικά δεδοµένα αποκαλούµε δεδοµένα από παρόµοια έργα που αναπτύχθηκαν κάτω από αντίστοιχες συνθήκες. Τέτοια δεδοµένα, είτε δεν υπάρχουν γιατί έργα κάποιων κατηγοριών αναπτύσσονται (συνήθως) για πρώτη φορά, είτε δεν µπορούν να χρησιµοποιηθούν (έστω κι αν προέρχονται από αντίστοιχα έργα) γιατί οι µηχανισµοί, οι διαδικασίες και τα εργαλεία ανάπτυξης έχουν αλλάξει σηµαντικά. Η διαδικασία ανάπτυξης λογισµικού δεν είναι τόσο διαφανής όσο είναι η διαδικασία κατασκευής σε αντίστοιχα κατασκευαστικά έργα ή έργα παραγωγής υλικών αγαθών, αλλά δεν είναι (ή δεν θα έπρεπε να είναι) αδιαφανής για τον υπεύθυνο του έργου. Φανταστείτε ένα κατασκευαστικό έργο (π.χ. την κατασκευή ενός σπιτιού) και πόσο εύκολα ακόµα και κάποιος που δεν έχει γνώση της διαδικασίας ανάπτυξης µπορεί να παρακολουθεί την εξέλιξη της κατασκευής και δείτε την αντιστοιχία του µε ένα έργο ανάπτυξης λογισµικού. Στην πραγµατικότητα ένας από τους στόχους της διαχείρισης της ανάπτυξης λογισµικού είναι η διαφάνεια στην ανάπτυξη. Η διαφάνεια αυτή, όπως θα δούµε και στη διάρκεια της µελέτης σας σχετίζεται, µεταξύ άλλων, µε την ωριµότητα της επιχείρησης. Σε έρευνα του Curtis [Cur88] αναφέρεται ότι η πλειοψηφία των έµπειρων διαχειριστών έργων λογισµικού θεωρεί τους ανθρώπους ως το σηµαντικότερο παράγοντα από τον οποίο εξαρτάται η επιτυχία του έργου. Σε αντίθεση µε την παραγωγή υλικών αγαθών όπου τα εργαλεία και οι πρώτες ύλες είναι πολύ σηµαντικές, στην ανάπτυξη λογισµικού, όπου τα εργαλεία και οι τεχνικές εξελίσσονται ραγδαία, η σηµα-

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

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

σία των ανθρώπων (µε τις ιδιαιτερότητες που αυτό συνεπάγεται) είναι κυρίαρχη. Επίσης, στην ανάπτυξη λογισµικού ένας µεγάλος αριθµός έργων είναι προσαρµοσµένο λογισµικό (custom software), δηλαδή λογισµικό το οποίο αναπτύσσεται για συγκεκριµένο πελάτη ο οποίος εντάσσεται στη διαδικασία ανάπτυξης, γεγονός που εµπλέκει έναν ακόµα ανθρώπινο παράγοντα. ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏﬁÁËÛË˜ 1.1 Ακολουθούν µερικές προτάσεις. Ποιες από αυτές είναι σωστές και ποιες λάθος; ∆είτε στο τέλος του βιβλίου τις σωστές απαντήσεις, αλλά και αιτιολόγηση για κάθε απάντηση. Σωστό

Λάθος

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

❏

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

❏

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

❏

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

❏

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

❏

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

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

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

KEºA§AIO 1: ∂π™∞°ø°∏ ™∆∏ ¢π∞Ã∂πƒπ™∏ §√°π™ªπ∫√À

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

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

Η λεγόµενη κρίση του λογισµικού είναι κυρίως συνέπεια προβληµάτων διαχείρισης και λαθών των υπευθύνων έργων ή της διοίκησης. Είναι χαρακτηριστικό ότι πολλές φορές στο βωµό της πυροσβεστικής αντιµετώπισης προβληµάτων παραβιάζονται δοκιµασµένες αρχές, µε αποτέλεσµα να επιβεβαιώνουν τη σηµασία αυτών των αρχών για µία φορά ακόµα. Για παράδειγµα, ενώ ο Brooks [Bro97] τονίζει ότι «προσθέτοντας ανθρώπους σε ένα έργο που έχει καθυστερήσει θα το καθυστερήσουµε περισσότερο», πολλές φορές µια διοίκηση σε κατάσταση πανικού καταφεύγει σε αυτή τη λύση.

¢Ú·ÛÙËÚÈﬁÙËÙ· 1.1 Μιλήσαµε για την κρίση του λογισµικού και αναφέραµε ότι πολλά έργα ανάπτυξης λογισµικού αποτυγχάνουν στην τήρηση του αρχικού τους χρονοδιαγράµµατος. Χωρίς να ξεπεράσετε τις 300 λέξεις προσπαθήστε –χρησιµοποιώντας την εµπειρία που έχετε αποκτήσει από τις σπουδές σας– να καταγράψετε και να τεκµηριώσετε λόγους για τους οποίους συµβαίνει αυτό. Αφού (και µόνο αφού) ολοκληρώσετε τη δραστηριότητα διαβάστε τι σας προτείνουµε εµείς ως απάντηση παρακάτω. Προσοχή, µελετήστε την απάντηση σαν να είναι διδακτέα ύλη. Ο λόγος που τοποθετούµε τις απαντήσεις (ή υποδείξεις) των δραστηριοτήτων µέσα στο κείµενο είναι ότι συµπληρώνουν τη διδακτέα ύλη.

Απάντηση Στο βιβλίο του «The mythical man–month» o Brooks για το ίδιο θέµα παρουσιάζει πέντε βασικούς λόγους γιατί πολλά έργα ανάπτυξης λογισµικού αποτυγχάνουν στην τήρηση του αρχικού τους χρονοδιαγράµµατος: i) Οι τεχνικές εκτίµησης είναι ανεπαρκείς µε αποτέλεσµα οι αρχικές εκτιµήσεις να είναι συνήθως υπερβολικά αισιόδοξες. ii) Συνήθως συγχέεται η προσπάθεια (effort) µε την πρόοδο (progress) και γίνονται αριθµητικές πράξεις µε ανθρωποµήνες που συχνά οδηγούν σε σοβαρά λάθη στην εκτίµηση. (Η λογική ότι ένα τµήµα του έργου που έγινε από 5 ανθρώπους σε 6 µήνες θα µπορέσει να γίνει από 10 ανθρώπους σε 3 µήνες είναι τελείως λάθος, γιατί θεωρεί ότι οι µήνες και οι άνθρωποι είναι απλές αριθµητικές µονάδες. Αν δεν σας έπεισα ακόµα, ας επεκτείνουµε στην ίδια λογική, θεωρώντας ότι ένας

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

1.2 ¢π∞¢π∫∞™π∂™ ¢π∞Ã∂πƒπ™∏™ ∂ƒ°ø¡

µήνας έχει 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 ∞Ó¿Ï˘ÛË ‰È·‰ÈÎ·ÛÈÒÓ

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

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

KEºA§AIO 1: ∂π™∞°ø°∏ ™∆∏ ¢π∞Ã∂πƒπ™∏ §√°π™ªπ∫√À

• ο προγραµµατισµός του έργου (µε όσα αυτός περικλείει), • η ανάθεση έργου σε ανθρώπινο δυναµικό, • η επίβλεψη του έργου και • η τεκµηρίωση – εκπροσώπηση. Από αυτές, οι δύο πρώτες γίνονται στα πρώτα στάδια της ανάπτυξης, ενώ οι δύο τελευταίες είναι συνεχείς διαδικασίες που ο διαχειριστής έργων λογισµικού εκτελεί σε όλη τη διάρκεια της ανάπτυξης του λογισµικού. Η ανάθεση έργου σε ανθρώπινο δυναµικό µπορεί είτε να γίνει στα πρώτα στάδια είτε να γίνεται σε συγκεκριµένα χρονικά σηµεία του έργου, αν και ο καθορισµός των αναγκών θα έχει γίνει στα πρώτα στάδια. Συγγραφή αρχικής πρότασης Τις περισσότερες φορές πριν την εκκίνηση ενός έργου έχει προηγηθεί µία αντίστοιχη αρχική πρόταση. Η πρόταση αυτή µπορεί να είναι προς τον πελάτη, ή γενικά προς κάποιον φορέα χρηµατοδότησης του έργου, ακόµα και προς το διοικητικό συµβούλιο για αυτοχρηµατοδοτούµενο έργο. Πολλές φορές αυτή η πρόταση, ξεκινά από µια αρχική ιδέα και µέχρι να ωριµάσει και να ξεκινήσει ένα έργο απαιτούνται πολλές συναντήσεις µε τον πελάτη, συγγραφή πολλών ενηµερωτικών και τεχνικών κειµένων, παρουσιάσεις του έργου κτλ. Την εργασία αυτή αναλαµβάνει ο υπεύθυνος έργου συνεπικουρούµενος από κάποιον ή κάποιους τεχνικούς. Στην εύλογη ερώτηση «πώς ο υπεύθυνος έργου θα έχει πάντα ιδέες για νέα έργα;», η απάντηση είναι ότι ο καλός υπεύθυνος έργων θα µπορεί να αντλεί ιδέες από τη συνεργασία του µε το προσωπικό που επιβλέπει στα έργα του. Ο καλός υπεύθυνος έργων θα πρέπει να εµπνέει τους συνεργάτες του ώστε να έχουν ιδέες και προτάσεις για το αντικείµενό τους και αυτός θα πρέπει µε την εµπειρία του να εντοπίζει αυτές που έχουν προοπτικές και να τις προωθεί, χωρίς ποτέ να αγνοεί το συνεργάτη του που είχε την αρχική ιδέα (δηλαδή να αναφέρει πάντα την ιδέα ως ιδέα του «Τάδε»). Ο καλός υπεύθυνος έργων γνωρίζει ότι είναι επίτευγµα και προσόν του να µπορεί να εντοπίζει και να προωθεί τις καλές ιδέες των υφιστάµενών του και ότι δεν είναι µειωτικό για αυτόν να είχε κάποιος άλλος µία καλή ιδέα.

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

1.2 ¢π∞¢π∫∞™π∂™ ¢π∞Ã∂πƒπ™∏™ ∂ƒ°ø¡

ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏﬁÁËÛË˜ 1.2 Σε µία επιχείρηση ο Περικλής είναι υπεύθυνος για ένα έργο ανάπτυξης λογισµικού. Μία νεοδιοριζόµενη προγραµµατίστρια, η Ασπασία έχει µία πολύ καλή ιδέα ότι ένα τµήµα του έργου που η ίδια ανέπτυξε θα µπορούσε να έχει εµπορική αξία και να πωλείται αυτόνοµα σε αρκετούς πελάτες, µε κάποια πρόσθετη ανάπτυξη (νέο έργο). Τι από τα παρακάτω θα ήταν το σωστότερο να κάνει ο Περικλής; i)

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

ii) Να ζητήσει από την Ασπασία να ετοιµάσει µία πρόταση για το νέο έργο και να της προτείνει να την παρουσιάσει αυτή, αφού αυτή είχε και την αρχική ιδέα; iii) Να συνεργαστεί µε την Ασπασία ώστε να ετοιµάσει αυτός µία πρόταση για νέο έργο, έχοντας την βοήθεια της Ασπασίας για τα τεχνικά θέµατα και να την παρουσιάσει µαζί µε την Ασπασία, αναφέροντας ότι είναι ιδέα της Ασπασίας; iv) Να βγάλει την Ασπασία για δείπνο.

Προγραµµατισµός έργου Η αρχική φάση του προγραµµατισµού (planning) του έργου, την οποία και έχετε διδαχθεί στα πλαίσια της τεχνολογίας λογισµικού, εµπεριέχει αρκετές δραστηριότητες διαχείρισης έργου. Στη φάση αυτή καθορίζονται οι βασικές προδιαγραφές του λογισµικού, γίνεται η κοστολόγηση του έργου, η τιµολόγηση του έργου (εάν είναι έργο που αναπτύσσεται για συγκεκριµένο πελάτη), η εκτίµηση των µεγεθών του έργου, η µελέτη του εφικτού, η ανάλυση του ρίσκου, η αρχική τµηµατοποίηση και ο χρονοπρογραµµατισµός του έργου. Την κοστολόγηση του έργου, την εκτίµηση και την ανάλυση του ρίσκου θα τις συζητήσουµε χωριστά στο κεφάλαιο 2, ώστε να έχουµε την άνεση να τις παρουσιάσουµε πιο αναλυτικά, από τη σκοπιά της διαχείρισης έργων. Η αρχική τµηµατοποίηση του έργου (χωρίς να µπαίνουµε σε θέµατα σχεδίασης που ήδη έχετε διδαχθεί) και ο χρονοπρογραµµατισµός είναι βασικές δραστηριότητες του υπεύθυνου έργου σε αυτή τη φάση. Κατά την αρχική τµηµατοποίηση του έργου ο υπεύθυνος έργου αναλαµβάνει να χωρίσει το έργο σε τµήµατα ώστε να υπολογίσει τις αλληλεξαρτήσεις ανάµεσα στα τµήµατα και να εκτιµήσει το απαιτούµενο ανθρώπινο δυναµικό. Χρονοπρογραµµατισµός είναι η διαδικασία κατά την οποία γίνεται εκτίµηση του χρόνου που θα πάρει κάθε τµήµα του έργου. Στο τµήµα 1.2.2 της ενότητας αυτής θα µιλήσουµε για τεχνικές που βοηθούν στην αρχική τµηµατοποίηση και χρονοπρογραµµατισµό του έργου.

■ Τα ορόσηµα

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

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

KEºA§AIO 1: ∂π™∞°ø°∏ ™∆∏ ¢π∞Ã∂πƒπ™∏ §√°π™ªπ∫√À

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

(progress report) είναι ένα τεχνικό κείµενο το οποίο συγγράφεται (συνήθως από τον υπεύθυνο έργου) µε την επίτευξη κάποιου ορόσηµου. Στην έκθεση προόδου γίνεται ανάλυση της συνολικής προόδου του έργου µε αφορµή την επίτευξη του ορόσηµου.

Βασικό στοιχείο του χρονοπρογραµµατισµού είναι ο καθορισµός των βασικών ορόσηµων (milestones) του έργου. Ο καθορισµός των ορόσηµων είναι σηµαντική και δύσκολη εργασία που θα βοηθήσει στην επίβλεψη του έργου. Ο Metzer [Met73] περιγράφει τη σηµασία των ορόσηµων και ορίζει ότι ένα ορόσηµο θα πρέπει να είναι ξεκάθαρο πότε επιτεύχθηκε. Για παράδειγµα η ολοκλήρωση της κωδικοποίησης είναι ένα µετρήσιµο ορόσηµο, αλλά η ολοκλήρωση του 50% του κώδικα δεν είναι καλή επιλογή για ορόσηµο. Πώς θα καταλάβουµε ότι είµαστε στο 50% και όχι στο 45%; Η επίτευξη ενός ορόσηµου πρέπει να οδηγεί σε τεκµηρίωση µε τη µορφή έκθεσης προόδου (progress report). Εάν λοιπόν σε ένα έργο τοποθετηθούν πολλά ορόσηµα τότε θα δηµιουργηθεί πρόβληµα, αφού η οµάδα υλοποίησης θα αναλωθεί στη συγγραφή αναφορών προόδου. Ο αριθµός των οροσήµων πρέπει να είναι µικρός και να τοποθετούνται στα σηµαντικά σηµεία του έργου.

¢Ú·ÛÙËÚÈﬁÙËÙ· 1.2 Στο προηγούµενο τµήµα του βιβλίου µιλήσαµε για την έκθεση προόδου (progress report). Αφού διαβάσετε τον ορισµό της έκθεσης προόδου στο γλωσσάριο, προσπαθήστε να γράψετε τον πίνακα περιεχοµένων µίας έκθεσης προόδου. ∆είτε (αφού απαντήσετε) τις δικές µας υποδείξεις που ακολουθούν.

Απάντηση Υπάρχουν πολλοί δυνατοί τρόποι να γράψει κανείς µία έκθεση προόδου. Έτσι –όπως θα κάνουµε και σε κάθε δραστηριότητα που δεν έχει µονοσήµαντη λύση– θα σας δώσουµε υποδείξεις για το τι θα έπρεπε να εντάξετε σε αυτή. Μπράβο σας αν τα είχατε προβλέψει όλα. Σε αντίθετη περίπτωση, ξαναγράψτε τον πίνακα περιεχοµένων, έχοντας διαβάσει τις οδηγίες µας. i)

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

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

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

1.2 ¢π∞¢π∫∞™π∂™ ¢π∞Ã∂πƒπ™∏™ ∂ƒ°ø¡

iii) Ανάλυση των παραδοτέων. Συνήθως ένα ορόσηµο αντιστοιχεί σε παράδοση (ή ολοκλήρωση) κάποιου σηµαντικού τµήµατος του έργου. Η ολοκλήρωση αυτού του τµήµατος συνεπάγεται κάποια παραδοτέα, που θα πρέπει να αναγράφονται και να αναλύονται και στην έκθεση προόδου. iv) Γενική παρουσίαση της πορείας του έργου και των συνεπειών απόκλισης από το συγκεκριµένο ορόσηµο. Συνήθως σε κάθε έργο η µη επίτευξη ενός ορόσηµου στο αρχικά καθορισµένο χρονικό πλαίσιο σηµαίνει ότι και άλλα ορόσηµα πιθανότατα θα καθυστερήσουν αν δεν γίνουν κάποιες ενέργειες. Η έκθεση προόδου πρέπει να τα επισηµαίνει. v) Απαιτούµενες ενέργειες (σε περίπτωση προβλήµατος φυσικά) που πρέπει να γίνουν ώστε να εξαλειφθούν (ή να ελαχιστοποιηθούν) οι συνέπειες από την µη επίτευξη αυτού του ορόσηµου. Ανάθεση έργου σε ανθρώπινο δυναµικό Η ανάθεση έργου σε ανθρώπινο δυναµικό σχετίζεται µε την εκτίµηση που θα συζητήσουµε αναλυτικά στο κεφάλαιο 2. Στα πρώτα στάδια του έργου, ο υπεύθυνος θα πρέπει να εντοπίσει τις ανάγκες του έργου σε προσωπικό γενικά, αλλά και να αναθέσει συγκεκριµένα τµήµατά του σε κάποιους από τους υφισταµένους του. Προφανώς τµήµατα του έργου που προβλέπεται να αρχίσουν πολύ µετά από την έναρξή του θα ανατεθούν σε προσωπικό εκείνη τη χρονική στιγµή, αλλά ο υπεύθυνος έργου θα πρέπει να έχει µεριµνήσει για τη διαθεσιµότητα του προσωπικού. Επειδή η διαθεσιµότητα του προσωπικού είναι σηµαντικός παράγοντας για την επιτυχία του έργου, η ανάθεση έργου σε ανθρώπινο δυναµικό σχετίζεται µε την αρχική τµηµατοποίηση του έργου, όπου θα πρέπει να εξεταστεί ο φόρτος εργασίας που επιφέρει η παράλληλη εκτέλεση κάποιων τµηµάτων του έργου. Για όλα αυτά όµως θα µιλήσουµε περισσότερο στην ενότητα 1.2.2. Επίβλεψη έργου Η επίβλεψη του έργου (project monitoring) είναι διαδικασία που εκτελείται σε όλη τη διάρκεια του έργου. Ο υπεύθυνος του έργου πρέπει να παρακολουθεί όλες τις διαδικασίες του έργου (την πορεία και την πρόοδο όλων των τµηµάτων του έργου) και να συγκρίνει το πραγµατικό µε το αρχικό χρονοδιάγραµµα, το πραγµατικό κόστος µε την αρχική εκτίµηση και την πραγµατική προσπάθεια υλοποίησης µε την αρχική εκτίµηση. Οι περισσότερες επιχειρήσεις ή οργανισµοί που παράγουν λογισµικό χρησιµοποιούν συγκεκριµένες τεχνικές (θα µιλήσουµε για µερικές στην ενότητα 1.2.2) και τα αντίστοιχα εργαλεία και µηχανισµούς, αλλά τις περισσότερες φορές ένας ανώ-

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

KEºA§AIO 1: ∂π™∞°ø°∏ ™∆∏ ¢π∞Ã∂πƒπ™∏ §√°π™ªπ∫√À

τερος υπεύθυνος έργου µπορεί να µάθει πολύ περισσότερα από µία κατ’ ιδίαν συνάντηση µε το προσωπικό που έχει αναλάβει κάθε τµήµα του έργου. Βέβαια οι συγκεκριµένες συναντήσεις συνήθως θα είναι ενταγµένες στη διαδικασία παρακολούθησης και στο µηχανισµό της επιχείρησης. Στο βιβλίο τους [Kra95] οι Kraul και Streeter, αναλύουν τους διάφορους τρόπους επικοινωνίας ανάµεσα στα µέλη της οµάδας ανάπτυξης έργου και τον υπεύθυνο του έργου. Οι τρόποι που προτείνουν µπορούν να συνδυαστούν σε δύο βασικούς τύπους επικοινωνίας: • Τυπική επικοινωνία. Περιλαµβάνει την καθορισµένη (τόσο χρονικά, όσο και διαδικαστικά) ανταλλαγή αναφορών όπως τεκµηρίωση, παραδοτέα (κώδικας), αναφορές προόδου (ατοµικής και τµήµατος που έχει αναλάβει κάποιος), αναφορές λαθών ή προβληµάτων, προτάσεις αλλαγών (στο έργο ή στη διαδικασία παραγωγής) και γενικά ό,τι καθορίζει η επιχείρηση για τη διαδικασία του έργου. Ο τρόπος που γίνεται µπορεί να είναι µε απλό ηλεκτρονικό ταχυδροµείο, ή µε τη χρήση του ενδοδικτύου (intranet) της επιχείρησης, ή και µε απλή ανταλλαγή τυπωµένων αναφορών, αν και οι ηλεκτρονικές µέθοδοι έχουν συνήθως καλύτερα αποτελέσµατα. • Άτυπη επικοινωνία. Περιλαµβάνει τη διαπροσωπική επικοινωνία του υπεύθυνου έργου µε κάθε µέλος της οµάδας υλοποίησης, αλλά και τις συναντήσεις οµάδων για ενηµέρωση και συλλογική επίλυση προβληµάτων, ακόµα και τη δηµιουργία ενός διευρυµένου κύκλου συναντήσεων στις οποίες θα συµµετέχει και προσωπικό έξω από τα πλαίσια του έργου το οποίο θα κληθεί για να βοηθήσει µε την εµπειρία του και τις γνώσεις του. Η τυπική και η άτυπη επικοινωνία είναι το ίδιο σηµαντικοί και συµπληρωµατικοί µηχανισµοί επικοινωνίας µεταξύ των µελών µίας οµάδας. Οι περισσότερο τυπικές προσεγγίσεις συνήθως φέρνουν καλύτερα αποτελέσµατα σε επιχειρήσεις ή οργανισµούς µε καλή διοικητική συγκρότηση και υψηλό επίπεδο ωριµότητας (θα συζητήσουµε για επίπεδα ωριµότητας µιας επιχείρησης σε επόµενα κεφάλαια, όταν θα µιλήσουµε για ποιότητα λογισµικού). Τελειώνοντας πρέπει να τονίσουµε, ότι παρόλο που η επίβλεψη του έργου είναι σηµαντικότατη δραστηριότητα του υπεύθυνου έργου, αυτός δεν πρέπει να δίνει την εντύπωση στους υφισταµένους του ότι είναι επιβλέπων, αλλά να δείχνει και να είναι δάσκαλος για αυτούς, να επισηµαίνει τα λάθη τους, αλλά και να τους κατευθύνει προς το σωστό δρόµο και να τους διδάσκει µε την εµπειρία του.

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

1.2 ¢π∞¢π∫∞™π∂™ ¢π∞Ã∂πƒπ™∏™ ∂ƒ°ø¡

Τεκµηρίωση και εκπροσώπηση Στα πλαίσια αυτής της ενότητας µιλήσαµε πολλές φορές για αναφορές που είναι ενταγµένες στα πλαίσια των διαδικασιών ανάπτυξης λογισµικού. Όλες αυτές οι αναφορές, καθώς και κάθε εσωτερικό κείµενο που θα διακινηθεί µόνο στα πλαίσια της επιχείρησης και κάθε εξωτερικό κείµενο που θα κοινοποιηθεί ή θα παραδοθεί στον πελάτη συνοψίζονται µε τον όρο τεκµηρίωση (documentation). ∆υστυχώς πολλές φορές η σηµασία της τεκµηρίωσης υποβαθµίζεται επειδή το βασικό παραδοτέο ενός έργου λογισµικού για πολλούς θεωρείται –κακώς– ότι είναι µόνο το λογισµικό. Για την αξία της τεκµηρίωσης θα αναφερθούµε συχνά στα πλαίσια αυτού του βιβλίου. Η τεκµηρίωση αν και θα είναι αρµοδιότητα πολλών από τα µέλη της οµάδας ανάπτυξης έργου, θα είναι τελική ευθύνη του υπεύθυνου έργου.

■ Tεκµηρίωση

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

Τέλος, η εκπροσώπηση στα πλαίσια ενός έργου είναι και αυτή ενταγµένη στις διαδικασίες ανάπτυξης έργων λογισµικού. Ο υπεύθυνος έργου θα πρέπει να µπορεί να εκπροσωπεί το έργο τόσο στον πελάτη, όσο και στη διοίκηση της επιχείρησης ή του οργανισµού και να παρουσιάζει την πορεία του έργου, τα προβλήµατα, καθώς και τις προτάσεις του για το έργο ή και για τις διαδικασίες ανάπτυξης. ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏﬁÁËÛË˜ 1.3 Ακολουθούν µερικές προτάσεις. Ποιες από αυτές είναι σωστές και ποιες λάθος; Σωστό

Λάθος

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

❏

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

❏

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

❏

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

❏

v) Το ενδοδίκτυο προσφέρεται για χρήση σε τυπική επικοινωνία του υπευθύνου έργου µε την οµάδα ανάπτυξης έργου. ❏

❏

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

❏

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

KEºA§AIO 1: ∂π™∞°ø°∏ ™∆∏ ¢π∞Ã∂πƒπ™∏ §√°π™ªπ∫√À

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

■ To δίκτυο

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

Στην ενότητα 1.2.1 µιλήσαµε για τις διαδικασίες του προγραµµατισµού έργου, της ανάθεσης έργου σε ανθρώπινο δυναµικό και της επίβλεψης έργου, χωρίς να παρουσιάσουµε τις τεχνικές µε τη βοήθεια των οποίων γίνονται όσα περιγράψαµε. Σε αυτή την ενότητα θα µιλήσουµε για τις πιο διαδεδοµένες από αυτές τις τεχνικές, δηλαδή το δίκτυο δραστηριοτήτων έργου, το διάγραµµα αξιολόγησης έργου, το χρονοδιάγραµµα και το διάγραµµα ανάθεσης έργου σε ανθρώπινο δυναµικό. Στο τέλος της ενότητας θα παρουσιάσουµε ένα πλήρες παράδειγµα ως απάντηση της δραστηριότητας 1.5. ∆ίκτυο δραστηριοτήτων έργου Το δίκτυο δραστηριοτήτων έργου θα το βρείτε στην αγγλική βιβλιογραφία τόσο ως activity network, όσο και ως task network. Στόχος του είναι να δείξει τις σχέσεις και εξαρτήσεις ανάµεσα στις διάφορες δραστηριότητες του έργου. Οι δραστηριότητες αυτές για µεγάλα έργα συχνά ονοµάζονται και τυπικά υποέργα. Στο σχήµα 1.1 µπορείτε να δείτε ένα παράδειγµα ενός δικτύου δραστηριοτήτων έργου στο οποίο αναλύεται ένα έργο σε 8 τυπικά υποέργα (στο σχήµα συµβολίζονται ως ΤΥ1 … ΤΥ8). Η σχεδίαση του δικτύου δραστηριοτήτων βοηθά στην καλύτερη αντίληψη των συσχετίσεων ανάµεσα στα διάφορα τµήµατα στα οποία διασπάται ένα έργο. TY 4 TY 1

™¯‹Ì· 1.1

Παράδειγµα δικτύου δραστηριοτήτων έργου

Aρχή

TY 7 TY 3

Tέλος

TY 5

TY 2 TY 6

TY 8

Στο σχήµα 1.1 µπορούµε να δούµε ότι µε την έναρξη του έργου αρχίζουν παράλληλα δύο τµήµατα του έργου, τα ΤΥ 1 και ΤΥ 2. Για να µπορέσει να αρχίσει το τµήµα ΤΥ 3 πρέπει να έχουν ολοκληρωθεί και τα δύο προαπαιτούµενα τµήµατα (ΤΥ 1 και ΤΥ 2). Μόνο µετά από την ολοκλήρωση του τµήµατος ΤΥ 3 θα µπορέσουν να ξεκινήσουν τα ΤΥ 4, ΤΥ 5 και ΤΥ 6, κ.ο.κ. Προσέξτε ότι στο συγκεκριµένο σχήµα µπορούµε να δούµε µόνο ποιο τµήµα είναι προαπαιτούµενο κάποιου άλλου, αλλά όχι πληροφορίες όπως ο χρόνος που θα χρειαστεί (κατ’ εκτίµηση) για την υλοποίηση ενός τµήµατος, ή πληροφορίες για τµήµατα που αν καθυστερήσουν θα καθυστερήσει και ολόκληρο το έργο. Αυτές οι πληροφορίες υπάρχουν στο διάγραµµα αξιολόγησης έργου το οποίο θα συζητήσουµε ακολούθως και που ουσιαστικά είναι ένα δίκτυο δραστηριοτήτων έργου µε περισσότερες πληροφορίες.

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

1.2 ¢π∞¢π∫∞™π∂™ ¢π∞Ã∂πƒπ™∏™ ∂ƒ°ø¡

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

1073

2,5 µ

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

3µ

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

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

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

Περιγραφή

15–04–2001

™¯‹Ì· 1.2

Eκτίµηση για ηµεροµηνία λήξης

Κόµβος PERT Chart

∆ιάγραµµα αξιολόγησης έργου (διάγραµµα 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 µήνες για το παράδειγµα). Για να είναι πιο φανερή η κανονική ηµεροµηνία έχει χρωµατιστεί. Στη µέση του κόµβου αναγράφεται η περιγραφή του τµήµατος στο οποίο αντιστοιχεί ο κόµβος και στο κάτω µέρος η εκτίµηση για την έναρξη (στα αριστερά) και την ολοκλήρωση (στα δεξιά) του τµήµατος. Σε πολλά παραδείγµατα

■ To διάγραµµα

αξιολόγησης έργου (Program Evaluation and Review Technique ή συνοπτικά PERT Chart) είναι µία γραφική αναπαράσταση των διαφόρων δραστηριοτήτων (activities ή tasks) που συνθέτουν ένα έργο, εµπλουτισµένη µε πληροφορίες όπως εκτιµήσεις διάρκειας και ορόσηµα.

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

KEºA§AIO 1: ∂π™∞°ø°∏ ™∆∏ ¢π∞Ã∂πƒπ™∏ §√°π™ªπ∫√À

PERT Chart µπορούν να υπάρχουν πολλές πιθανές ηµεροµηνίες έναρξης (που εξαρτώνται από τις εκτιµήσεις των προαπαιτούµενων τµηµάτων) και πολλές πιθανές ηµεροµηνίες λήξης (που εξαρτώνται τόσο από την ηµεροµηνία έναρξης όσο και από τη διάρκεια του τµήµατος). 2 1 ™¯‹Ì· 1.3

Παράδειγµα PERT Chart

■ Κρίσιµο µονο-

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

5 εβ 6 εβ 8 εβ

TY 1 08–01–07 16–02–07

3 εβ 4 εβ 6 εβ

TY 2 19–02–07 16–03–07 3

6 εβ 7 εβ 9 εβ

2 εβ 3 εβ 5 εβ

TY 4 09–04–07 27–05–07

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. Ένα θέµα για το οποίο δεν µιλήσαµε καθόλου είναι η διάρκεια που θα πρέπει να έχει κάθε τµήµα του έργου. Η απάντηση είναι ότι δεν υπάρχει κάποιος «µαγικός» αριθµός που να καθορίζει την ιδανική διάρκεια τµήµατος. Είναι πολύ λογικό τα τµήµα-

1 Θα ήταν επίσης σωστό (αν και λιγότερο διαδεδοµένο) να τελειώνει Κυριακή (δηλαδή να είναι 18/2/07 για το ΤΥ 1) αλλά το αφήσαµε Παρασκευή σεβόµενοι τις ηµέρες αργίας.

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

1.2 ¢π∞¢π∫∞™π∂™ ¢π∞Ã∂πƒπ™∏™ ∂ƒ°ø¡

τα ενός έργου συνολικής διαρκείας 5 ετών να έχουν µεγαλύτερη διάρκεια από τα τµήµατα ενός έργου διάρκειας 6 µηνών, αλλά ούτε αυτό είναι απόλυτος κανόνας. Η εµπειρία έχει δείξει ότι συνήθως τµήµατα έργων που έχουν διάρκεια 6 έως 14 εβδοµάδες (δηλαδή 1,5 µήνα µέχρι 3,5 µήνες) είναι πιο εύκολο να διαχειριστούν και να επιβλέπονται. Πολύ µικρά τµήµατα συνήθως δεν έχουν την απαιτούµενη αυτονοµία (άρα κακώς ορίστηκαν ως αυτόνοµα τµήµατα), ενώ πολύ µεγάλα τµήµατα συνήθως θα υποχρεωθούµε να τα χωρίσουµε σε µικρότερα. ¢Ú·ÛÙËÚÈﬁÙËÙ· 1.3 Όπως παρουσιάζεται το διάγραµµα αξιολόγησης έργου (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 ™ÂÏ›‰· 32

KEºA§AIO 1: ∂π™∞°ø°∏ ™∆∏ ¢π∞Ã∂πƒπ™∏ §√°π™ªπ∫√À

Mήνες

Iανουάριος ’07

Eβδοµάδες

15 22 29

Φεβρουάριος ’07 5

12 19 26

Mάρτιος ’07 5

12 19 26

Aπρίλιος ’07 2

16 23

TY 1 TY 2 ™¯‹Ì· 1.4

Παράδειγµα Gantt chart

TY 3

TY 4

Στο σχήµα 1.4 παρουσιάζεται ένα παράδειγµα Gantt chart που αντιστοιχεί στο PERT Chart του σχήµατος 1.3. Στο πάνω µέρος του χρονοδιαγράµµατος υπάρχει µία κλίµακα που συνήθως είναι µήνες (ή τρίµηνα) για µεγάλα έργα και εβδοµάδες για µικρά έργα. Κάθε τµήµα του έργου παρουσιάζεται µε µία οριζόντια µπάρα. Το ποσοστό της µπάρας που είναι χρωµατισµένη δείχνει το ποσοστό ολοκλήρωσης του κάθε τµήµατος. Στο σχήµα 1.4 βλέπουµε ότι το ΤΥ 1 έχει ολοκληρωθεί, ενώ τα ΤΥ 2 και ΤΥ 3 είναι σε εξέλιξη και το ΤΥ 4 δεν έχει ξεκινήσει. Το Gantt chart µπορεί να χρησιµοποιηθεί και για την παρακολούθηση του φόρτου εργασίας του προσωπικού όπως θα δούµε στο επόµενο τµήµα της ενότητας. ¢Ú·ÛÙËÚÈﬁÙËÙ· 1.4 Αν ο υπεύθυνος έργου έχει µπροστά του το 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 ™ÂÏ›‰· 33

1.2 ¢π∞¢π∫∞™π∂™ ¢π∞Ã∂πƒπ™∏™ ∂ƒ°ø¡

που σαρκάζει το γεγονός λέγοντας ότι: «το πρώτο 90% του έργου απαιτεί το 90% του χρόνου, ενώ το υπόλοιπο 10% απαιτεί πάλι το 90% του χρόνου!». Πάντως το γεγονός ότι αυτό δεν συνέβη στο ΤΥ 1 (το οποίο και έχει ολοκληρωθεί) σηµαίνει ότι πιθανότατα οι εκτιµήσεις είναι σωστές και ότι το έργο πηγαίνει πραγµατικά καλά. ∆ιάγραµµα ανάθεσης έργου σε ανθρώπινο δυναµικό Το διάγραµµα ανάθεσης έργου σε ανθρώπινο δυναµικό (staff allocation chart) σχετίζει το χρονοδιάγραµµα του έργου µε το προσωπικό που έχει την ευθύνη της υλοποίησης κάθε τµήµατος. Mήνες

Iανουάριος ’07

Eβδοµάδες

15 22 29

TY 1

Φεβρουάριος ’07 5

TY 2 TY 1

12 19 26

Aπρίλιος ’07 2

16 23

30%

Aσπασία

Xρήστος

12 19 26

Mάρτιος ’07

50%

™¯‹Ì· 1.5

100% 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 ™ÂÏ›‰· 34

KEºA§AIO 1: ∂π™∞°ø°∏ ™∆∏ ¢π∞Ã∂πƒπ™∏ §√°π™ªπ∫√À

τητα 1.2.2 και θα ήταν καλό πριν προχωρήσετε µε την εκπόνησή της να έχετε κάνει µία καλή επανάληψη στην αντίστοιχη ύλη. ¢Ú·ÛÙËÚÈﬁÙËÙ· 1.5 Ο Περικλής έχει αναλάβει υπεύθυνος ενός νέου έργου µε κωδικό όνοµα «Αρχείο» που αφορά τη δηµιουργία ενός συστήµατος αρχειοθέτησης για ένα πελάτη µε κύρια συστατικά του τη Βάση ∆εδοµένων και το λογισµικό διεπαφής µε τον πελάτη. Μέσα στις δραστηριότητες του έργου περιλαµβάνεται η αρχική επαφή µε τον πελάτη και ο έλεγχος και η εγκατάσταση του τελικού συστήµατος στον πελάτη. Μπορείτε να θεωρήσετε ότι το έργο αποτελείται από τις παρακάτω φάσεις (τυπικά υποέργα): ΤΥ1 Ανάλυση αναγκών πελάτη ΤΥ2 Σχεδίαση Βάσης ∆εδοµένων ΤΥ3 Σχεδίαση Λογισµικού και διεπαφής ΤΥ4 Ανάπτυξη Βάσης ∆εδοµένων ΤΥ5 Ανάπτυξη Λογισµικού και διεπαφής ΤΥ6 Ολοκλήρωση συστήµατος και Έλεγχος ΤΥ7 Εγκατάσταση στον πελάτη και αποδοχή Το έργο θα έχει διάρκεια ένα χρόνο (ας υποθέσουµε ότι ξεκινά 1/1/2007) και στη διάθεση του Περικλή θα είναι ο Γιώργος (ένας έµπειρος αναλυτής συστηµάτων), η Ασπασία (µία προγραµµατίστρια µε µεγάλη εµπειρία σε πολλά έργα και εξειδίκευση σε θέµατα σχεδίασης και ανάπτυξης Βάσεων ∆εδοµένων), η Έλενα (προγραµµατίστρια µε ειδίκευση στην ανάπτυξη διεπαφών χρήστη λογισµικού), ο Σπύρος (προγραµµατιστής µε εµπειρία και σε έλεγχο συστηµάτων) και η Στέλλα (έµπειρη στον έλεγχο και εγκατάσταση συστηµάτων). Η αρχική εκτίµηση της διοίκησης σε συνεργασία µε τον Περικλή είναι ότι το έργο θα χρειαστεί λιγότερο από 15 ανθρωποµήνες, που σηµαίνει ότι δεν θα εργαστούν όλοι οι παραπάνω για 12 µήνες στο 100% του χρόνου τους. Καλείστε αξιοποιώντας και την εµπειρία που έχετε από τις σπουδές σας έως τώρα, να βοηθήσετε τον Περικλή και να σχεδιάσετε το δίκτυο δραστηριοτήτων έργου, το διάγραµµα αξιολόγησης έργου, το χρονοδιάγραµµα έργου και το διάγραµµα ανάθεσης έργου σε ανθρώπινο δυναµικό. Επίσης να υπολογίσετε τους συνολικούς ανθρωποµήνες του έργου και πόσο θα εργαστεί κάθε ένας από το διαθέσιµο προσωπικό. Μη συµπεριλάβετε στους παραπάνω τον Περικλή. Η λύση δεν είναι µονο-

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

1.2 ¢π∞¢π∫∞™π∂™ ¢π∞Ã∂πƒπ™∏™ ∂ƒ°ø¡

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

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

TY 4

TY 2 Aρχή

TY 1

TY 6

1 µ 1,5 µ 2 µ

TY 2 15–02–07 31–03–07

1 µ 1,5 µ 2 µ

TY 1 01–01–07 15–02–07

Tέλος

™¯‹Ì· 1.6

∆ίκτυο δραστηριοτήτων έργου «Αρχείο»

TY 5

TY 3

TY 7

2 µ 13 µ 5 µ

TY 4 01–04–07 30–06–07 01–09–07

2 µ 2,5 µ 3,5 µ

TY 3 15–02–07 30–04–07

1µ 2µ 3µ

TY 7 01–11–07 31–12–07

2µ 3µ 5µ

TY 5 01–05–07 31–07–07

1µ 2µ 3µ

TY 6 01–09–07 31–10–07

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

™¯‹Ì· 1.7

PERT Chart έργου «Αρχείο»

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

KEºA§AIO 1: ∂π™∞°ø°∏ ™∆∏ ¢π∞Ã∂πƒπ™∏ §√°π™ªπ∫√À

θα είναι έτοιµο προς τον τελικό έλεγχο συστήµατος. Προσέξτε επίσης το κενό που άφησε το µήνα Αύγουστο (για πιθανές διακοπές στο προσωπικό ή για κάλυψη χαµένου χρόνου). Με βάση το PERT Chart του σχήµατος 1.7 το χρονοδιάγραµµα του έργου προκύπτει εύκολα και παρουσιάζεται στο σχήµα 1.8. (Αν και µικρό έργο δίνουµε την κλίµακα σε µήνες για να µην «γεµίσει» πολύ το σχήµα.) Mήνες

TY1 TY2 TY3 TY4 TY5 ™¯‹Ì· 1.8

Χρονοδιάγραµµα έργου «Αρχείο»

TY6 TY7

Τέλος, µε βάση τη διαθεσιµότητα του προσωπικού, τους αρχικούς περιορισµούς σε χρόνο και τα προσόντα κάθε ενός από τους διαθέσιµους συνεργάτες, ο Περικλής ετοίµασε το διάγραµµα ανάθεσης έργου σε ανθρώπινο δυναµικό που παρουσιάζεται στοσχήµα 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 ™ÂÏ›‰· 37

1.2 ¢π∞¢π∫∞™π∂™ ¢π∞Ã∂πƒπ™∏™ ∂ƒ°ø¡

ΤΥ7: 2 × 20% για την Ασπασία και 2 × 50% για τη Στέλλα, σύνολο 1,4 ανθρωποµήνες. Προσθέτοντας τα παραπάνω προκύπτει ότι το σύνολο του έργου είναι 14,45 ανθρωποµήνες κάτι που είναι µέσα στις αρχικές προδιαγραφές. Επίσης µε απλούς υπολογισµούς βρίσκουµε τους παρακάτω ανθρωποµήνες: (Γιώργος: 0,75. Ασπασία: 3,7. Έλενα: 5,5. Σπύρος: 2,5. Στέλλα: 2). Mήνες

TY 1

50%

TY 1

20%

Γιώργος

TY 2

Aσπασία

100% TY 4

50% TY 4

TY 3

50%

100% TY 5

Έλενα

TY 5

100%

50% TY 6

Σπύρος

50%

™¯‹Ì· 1.9

Στέλλα

TY 6

50%

TY 7

50%

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

∆ιάγραµµα ανάθεσης έργου σε ανθρώπινο δυναµικό για το έργο «Αρχείο»

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

KEºA§AIO 1: ∂π™∞°ø°∏ ™∆∏ ¢π∞Ã∂πƒπ™∏ §√°π™ªπ∫√À

1.3 √È ¿ÓıÚˆÔÈ

■ Προσωπικό

(personnel) µίας επιχείρησης ή οργανισµού είναι το σύνολο των ανθρώπων που εργάζονται σε αυτή.

Στην ενότητα 1.1.2 αναφέραµε ότι οι άνθρωποι είναι σηµαντικός παράγοντας της διαδικασίας ανάπτυξης λογισµικού. Για τη σηµασία των ανθρώπων στη διαδικασία ανάπτυξης λογισµικού µιλήσαµε και στην ενότητα 1.2. Σε αυτή την ενότητα θα αναλύσουµε τους ρόλους κάθε εργαζόµενου σε µία επιχείρηση ή οργανισµό που αναπτύσσει λογισµικό. Θα µιλήσουµε, δηλαδή για το προσωπικό. Οι άνθρωποι που εργάζονται σε µία επιχείρηση ή οργανισµό συνήθως αναφέρονται και ως προσωπικό (personnel). Μερικές φορές στην αγγλική βιβλιογραφία θα βρείτε τον όρο staff (θυµηθείτε το staff allocation chart για το οποίο µιλήσαµε στην ενότητα 1.2.2). Στην ενότητα αυτή θα µιλήσουµε για όσους συµµετέχουν στην ανάπτυξη λογισµικού. Αυτοί είναι το προσωπικό της επιχείρησης ή οργανισµού, αλλά και ο πελάτης. ∆εν θα επεκταθούµε σε τεχνικές λεπτοµέρειες για το τι κάνει καθένας από το προσωπικό, αφού αυτό είναι αντικείµενο της Τεχνολογίας Λογισµικού που έχετε ήδη διδαχθεί. Επειδή συχνά στα επόµενα κεφάλαια του βιβλίου θα αναφερθούµε στους συµµετέχοντες στην ανάπτυξη λογισµικού καλό θα ήταν να µελετήσετε προσεκτικά αυτό το κεφάλαιο πριν προχωρήσετε και γενικά να το συµπεριλάβετε στις επαναλήψεις σας. Εκτός από τους ρόλους που αναφέρουµε σε αυτή την ενότητα υπάρχουν πολλές ειδικότητες (εξειδικεύσεις των ρόλων) που δεν τις περιγράφουµε. Αφού ολοκληρώσετε αυτή την ενότητα και πριν προχωρήσετε στην ενότητα 1.4 δείτε τη δραστηριότητα για περαιτέρω µελέτη 1.1 και προσπαθήστε να υλοποιήσετε ό,τι ζητάει. 1.3.1 ª¤ÏÔ˜ ÙË˜ ‰ÈÔ›ÎËÛË˜

Είπαµε στην ενότητα 1.1.1 ότι θα διαχωρίσουµε το ρόλο του υπεύθυνου έργου από αυτόν της διοίκησης της επιχείρησης ή του οργανισµού. Σε όλη τη διάρκεια του βιβλίου θα αναφερόµαστε συχνά απρόσωπα στη διοίκηση του οργανισµού (θα µιλήσουµε για παράδειγµα για τη «δέσµευση της διοίκησης στο πρόγραµµα ποιότητας»). ∆εν πρέπει να ξεχνάµε ότι και η διοίκηση γίνεται από ανθρώπους και η άποψη της διοίκησης εκπροσωπείται από κάποιον άνθρωπο που συνήθως είναι ο Γενικός ∆ιευθυντής της επιχείρησης ή του οργανισµού. Σκοπός του βιβλίου είναι να µιλήσουµε για τη διαχείριση έργων λογισµικού και όχι για κανόνες διοίκησης επιχειρήσεων, οπότε δεν θα δώσουµε βάρος στους ρόλους, αρµοδιότητες και σκοπούς της διοίκησης. Σκόπιµα στο βιβλίο δεν θα µιλάµε συνήθως σε τρίτο ενικό πρόσωπο για τον εκπρόσωπο της διοίκησης, αλλά απρόσωπα για τη διοίκηση. Πάντως και για το µέλος της διοίκησης ισχύουν όσα θα πούµε και για τον υπεύθυνο έργων, αφού και αυτός είναι ένας άνθρωπος που έχει την ευθύνη να διοικεί ανθρώπους µε ό,τι προβλήµατα και ιδιαιτερότητες αυτό συνεπάγεται.

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

1.3 √π ∞¡£ƒø¶√π

Η διοίκηση της επιχείρησης ή του οργανισµού έχει ως µέριµνα την επιβίωση της επιχείρησης και το κέρδος. Θέλει τα έργα ανάπτυξης λογισµικού να αναπτύσσονται µέσα στα χρονοδιαγράµµατα (ώστε να συµβάλουν στην καλή εικόνα της επιχείρησης), να κοστίζουν λιγότερο από τα έσοδα που θα αποφέρουν (ώστε να αφήνουν κέρδος) και να δίνουν προοπτική για νέα έργα (είτε µε µεταπώληση τµηµάτων ή και ολόκληρων έργων, είτε µε ιδέες για νέα έργα). Μια καλή διοίκηση θα πρέπει να αντλεί ιδέες από το προσωπικό και να φροντίζει για τη συνεχή εξέλιξη και βελτίωση των συνθηκών ανάπτυξης και των διαδικασιών καθώς και για την ικανοποίηση του προσωπικού. Στο κεφάλαιο 3 θα µιλήσουµε περισσότερο για τη διοίκηση στα πλαίσια της «διαχείρισης της ποιότητας», οπότε ας µην επεκταθούµε άλλο σε αυτό το κεφάλαιο. 1.3.2 ÀÂ‡ı˘ÓÔ˜ ¤ÚÁÔ˘ ‹ ¤ÚÁˆÓ

Μιλήσαµε λίγο για τον υπεύθυνο διαχείρισης έργου λογισµικού ή υπεύθυνο έργου στην ενότητα 1.1.1. Ουσιαστικά τα δύο πρώτα κεφάλαια του βιβλίου αυτού είναι αφιερωµένα στον υπεύθυνο έργου, αφού όσα είπαµε στην ενότητα 1.2, αλλά και όλο το κεφάλαιο 2 αναλύει τις δραστηριότητες διαχείρισης για τις οποίες έχει την ευθύνη. Η ευθύνη του υπεύθυνου έργου ξεκινά συνήθως από τη συγγραφή της αρχικής πρότασης και συνεχίζεται µε τον προγραµµατισµό του έργου (στον προγραµµατισµό περιλαµβάνονται η εκτίµηση και ανάλυση ρίσκου που θα αναλύσουµε στο κεφάλαιο 2, καθώς και η αρχική τµηµατοποίηση, η ανάθεση έργου σε ανθρώπινο δυναµικό και ο χρονοπρογραµµατισµός που συζητήσαµε στην ενότητα 1.2). Η ευθύνη του υπεύθυνου έργου είναι ο καθηµερινός έλεγχος του έργου, η επίβλεψη του έργου και η εκπροσώπηση και τεκµηρίωση που επίσης συζητήσαµε. Για να µπορεί να επιτυγχάνει όλα τα παραπάνω ο υπεύθυνος έργου πρέπει να είναι άνθρωπος µε ικανότητες οργανωτικές, αλλά και ηγετικές. Πρέπει να µπορεί να εµπνέει και να εµψυχώνει τους υφισταµένους του, αλλά και να κατανοεί το προβλήµατα και τις δυσκολίες τους. Για αυτό το λόγο οι καλύτεροι υπεύθυνοι έργων είναι αυτοί που έχουν εµπλακεί στα διάφορα στάδια της ανάπτυξης και έχουν αποκτήσει την εµπειρία του µηχανικού ανάπτυξης που θα συζητήσουµε στην ενότητα 1.3.4. Επίσης, ο υπεύθυνος έργου πρέπει να µπορεί να επιλύει συστηµατικά προβλήµατα, να αξιοποιεί την εµπειρία του από προηγούµενα έργα και να διαθέτει ευελιξία ώστε να µπορεί να αλλάζει κατεύθυνση προλαβαίνοντας δύσκολες καταστάσεις. Πρέπει να δείχνει πάντα ότι έχει τον έλεγχο του έργου, αλλά και να αφήνει στους υφισταµένους του την πρωτοβουλία και να επιτρέπει (και να ενθαρρύνει µε τις ενέργειές του) την ανάληψη από τους υφισταµένους του πρωτοβουλιών (πάντα

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

KEºA§AIO 1: ∂π™∞°ø°∏ ™∆∏ ¢π∞Ã∂πƒπ™∏ §√°π™ªπ∫√À

µε µικρό ή ελεγχόµενο ρίσκο). Τέλος πρέπει να µπορεί να «χτίζει» να µεριµνά για το «δέσιµο» και να επιβλέπει οµάδες εργασίας (για τις οποίες θα µιλήσουµε στην ενότητα 1.4 που ακολουθεί) που θα αναλαµβάνουν τµήµατα του έργου. Είναι σαφές ότι τα παραπάνω διδάσκονται, αλλά κυρίως µαθαίνονται στην πράξη και πολλές φορές εξαρτάται από την προσωπικότητα, την ιδιοσυγκρασία και τον χαρακτήρα κάθε ανθρώπου πόσο επιτυχηµένος υπεύθυνος έργου θα γίνει. ■ Yπεύθυνοι

έργων ή ανώτεροι υπεύθυνοι έργων (senior project managers) είναι µέλη του προσωπικού µιας επιχείρησης ή οργανισµού που έχουν ανέβει σε ανώτερο διοικητικό επίπεδο από αυτό του υπεύθυνου έργου και έχουν αναλάβει την ευθύνη πολλών έργων.

Συχνά στη βιβλιογραφία θα βρείτε και τον όρο υπεύθυνοι έργων ή ανώτεροι υπεύθυνοι έργων, που στην αγγλική βιβλιογραφία αποδίδεται ως senior project managers. Οι ανώτεροι υπεύθυνοι έργων (όπως θα τους αποκαλούµε) έχουν συνήθως διατελέσει για κάποια χρόνια υπεύθυνοι έργου και έχουν αποδείξει τις ικανότητές τους στην πράξη ώστε να αναλάβουν τη διαχείριση παραπάνω του ενός έργου. Συνήθως είναι λίγοι σε κάθε επιχείρηση ή οργανισµό και οι απόψεις τους επηρεάζουν σε µεγάλο βαθµό την πολιτική της διοίκησης. Είναι δηλαδή οι άνθρωποι αυτοί στους οποίους θα στραφεί η διοίκηση για να ρωτήσει τη γνώµη τους πριν από σηµαντικές αποφάσεις. 1.3.3 ∏Á¤ÙË˜ ÔÌ¿‰·˜

Συχνά ο ρόλος του ηγέτη (leader) κάποιων ανθρώπων δεν ανήκει αποκλειστικά στον υπεύθυνο έργου. Ο Edgemon αναφέρει ότι «…πολύ συχνά µέλη του προσωπικού θα αποκτήσουν τυχαία το ρόλο του ηγέτη για κάποια οµάδα ανθρώπων…». Ακριβώς επειδή συχνά στα πλαίσια ενός έργου δηµιουργούνται διάφορες οµάδες, προκύπτει η ανάγκη κάποιοι άνθρωποι να ηγηθούν κάποιων άλλων στα πλαίσια της οµάδας. Αυτούς θα τους αποκαλούµε ηγέτες οµάδας, αφού έχουν αναγκαστικά ηγετικό (διαχειριστικό ρόλο), χωρίς όµως να έχουν τον τίτλο (και τις ευθύνες) του υπεύθυνου έργου. Η ανάδειξη των καλύτερων µηχανικών ανάπτυξης σε αυτούς τους ρόλους είναι συνήθως φυσική συνέπεια και στην περίπτωση που αποδείξουν τις διαχειριστικές τους ικανότητες φυσική εξέλιξη θα είναι και η µετάβασή τους στο ρόλο του υπευθύνου έργου. 1.3.4 ªË¯·ÓÈÎﬁ˜ ·Ó¿Ù˘ÍË˜

Με τον όρο µηχανικός ανάπτυξης (software engineer) θα αποκαλούµε όλους όσοι έχουν ενεργό ρόλο σε διάφορα στάδια της ανάπτυξης λογισµικού και που ο ρόλος αυτός απαιτεί γνώσεις τεχνολογίας λογισµικού και δεν περιορίζεται µόνο στον προγραµµατισµό συγκεκριµένων και καθορισµένων τµηµάτων. Χρησιµοποιούµε τον όρο µηχανικός ως απόδοση του engineer και όχι για να υπονοήσουµε τον τίτλο του Μηχανικού (ως απόφοιτος συγκεκριµένων σχολών). Ως µηχανικούς ανάπτυξης θεωρούµε τον αναλυτή (analyst), το σχεδιαστή (designer) και το µηχανικό ελέγχου (test

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

1.3 √π ∞¡£ƒø¶√π

engineer), ρόλους που γνωρίζετε από την Τεχνολογία Λογισµικού. Ο αναλυτής είναι υπεύθυνος για την επαφή µε τον πελάτη και τον καθορισµό των αρχικών προδιαγραφών, ο σχεδιαστής για τον καθορισµό της αρχιτεκτονικής του συστήµατος, την τµηµατοποίηση του συστήµατος και τις ενδοσυσχετίσεις ανάµεσα στα τµήµατα και ο µηχανικός ελέγχου έχει την ευθύνη του τελικού ελέγχου ως λευκό κουτί, δηλαδή τον έλεγχο των δοµών και λειτουργιών του προγράµµατος (Περισσότερα για το θέµα του ελέγχου ως λευκό κουτί δείτε στο βιβλίο του ΕΑΠ «Τεχνολογία Λογισµικού Ι», στην ενότητα 6.3.2.) Όλα αυτά τα µέλη του προσωπικού είναι µέλη µε σπουδές στην ανάπτυξη λογισµικού (συνήθως έχουν και τον τίτλο του «µηχανικού λογισµικού») και µε την εµπειρία τους στην ανάπτυξη θα πρέπει να είναι σε θέση να εξελιχθούν σε ηγέτες οµάδων, αλλά και να συνεισφέρουν µε ιδέες και προτάσεις τόσο για νέα έργα όσο και για τη βελτίωση και εξέλιξη της διαδικασίας ανάπτυξης. 1.3.5 ¶ÚÔÁÚ·ÌÌ·ÙÈÛÙ‹˜

Όπως βλέπετε και στον ορισµό ο προγραµµατιστής (programmer) είναι αυτός που θα αναλάβει τη βασική εργασία της ανάπτυξης λογισµικού, δηλαδή τη συγγραφή του κώδικα. Τη δραστηριότητα αυτή θα την ακούσετε ως προγραµµατισµό (programming), συγγραφή κώδικα (code authoring), κωδικοποίηση (coding), κτλ αν και έχει επικρατήσει η λέξη προγραµµατισµός. Πολλοί προγραµµατιστές που έχουν σπουδές στην ανάπτυξη λογισµικού και γνώσεις πολλών γλωσσών προγραµµατισµού συνήθως καλούνται ανώτεροι προγραµµατιστές (senior programmers) και πέρα από τον προγραµµατισµό έχουν ως ρόλο και την καθοδήγηση των νέων προγραµµατιστών στις διαδικασίες και µεθόδους ανάπτυξης. Συχνά άνθρωποι που έχουν σπουδάσει ως µηχανικοί λογισµικού ξεκινούν την εργασία τους σε κάποια επιχείρηση ή οργανισµό ως ανώτεροι προγραµµατιστές και σύντοµα εξελίσσονται στο ρόλο του µηχανικού ανάπτυξης. 1.3.6 ∆Â¯ÓÈÎÔ› Î·È ˘ﬁÏÔÈÔ ÚÔÛˆÈÎﬁ

Υπόλοιπο προσωπικό µιας επιχείρησης ή οργανισµού είναι τεχνικό προσωπικό που έχει την ευθύνη θεµάτων όπως έλεγχος µονάδων –συνήθως έλεγχος ως µαύρο κουτί– τεχνικές εγκαταστάσεις, συσκευασίες, υποστήριξη, κτλ. (Περισσότερα για το θέµα του ελέγχου ως µαύρο κουτί δείτε στο βιβλίο του ΕΑΠ «Τεχνολογία Λογισµικού Ι», στην ενότητα 6.3.2.) Επίσης µία επιχείρηση ή οργανισµός έχει διοικητικό προσωπικό, τµήµα προσωπικού µε τους ανθρώπους που είναι υπεύθυνοι για τη µισθοδοσία και τη στελέχωση της επιχείρησης, τµήµα πωλήσεων και προώθησης προϊόντων

■ Ο προγραµµατι-

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

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

KEºA§AIO 1: ∂π™∞°ø°∏ ™∆∏ ¢π∞Ã∂πƒπ™∏ §√°π™ªπ∫√À

(marketing), γραµµατειακό προσωπικό, κτλ. Όλοι αυτοί οι άνθρωποι είναι µέλη του προσωπικού µιας επιχείρησης και συχνά έχουν εξίσου σηµαντική συµβολή στην επιτυχία (ή αποτυχία) ενός έργου λογισµικού όσο και αυτοί που είναι επιφορτισµένοι µε αυτές καθαυτές τις διαδικασίες ανάπτυξης. 1.3.7 ¶ÂÏ¿ÙÂ˜

Ο πελάτης (customer), που συχνά αναφέρεται και ως χρήστης (user) του λογισµικού, δεν είναι µέλος του προσωπικού της επιχείρησης ή οργανισµού. Είναι όµως αναπόσπαστο µέλος της διαδικασίας ανάπτυξης λογισµικού και του προγράµµατος ποιότητας για το οποίο θα µιλήσουµε σε επόµενα κεφάλαια του βιβλίου. Όπως θα διδαχθείτε σε αυτό το βιβλίο, ένα από τα σηµαντικότερα λάθη της ανάπτυξης λογισµικού είναι να εξαιρέσει τον πελάτη από τη διαδικασία ανάπτυξης και το πρόγραµµα ποιότητας. Υπάρχουν πολλοί διαφορετικοί ρόλοι του πελάτη όπως: α) ο πελάτης – χρήστης, που θα αγοράσει λογισµικό γενικής χρήσης που έχει ετοιµασθεί βασισµένο σε γενικές προδιαγραφές, β) ο πελάτης – εξειδικευµένος χρήστης, που χρησιµοποιεί λογισµικό που έχει κατασκευαστεί εξειδικευµένα για τις δικές του ανάγκες, γ) ο πελάτης – οριστής, που ορίζει τις προδιαγραφές λειτουργικότητας του λογισµικού και δ) ο πελάτης – χρηµατοδότης, που επενδύει στην ανάπτυξη του λογισµικού. Πολλές φορές όλους αυτούς τους εµπλεκόµενους στην ανάπτυξη λογισµικού θα τους αποκαλούµε πελάτες, εκτός αν οι συνθήκες µας επιβάλλουν να το διαχωρίσουµε. Ας δούµε το εξής παράδειγµα: Έστω ότι το Ελληνικό Ανοικτό Πανεπιστήµιο θέλει να αναπτύξει ένα κόµβο ενηµέρωσης των ενδιαφεροµένων στο διαδίκτυο. Απευθύνεται στο Υπουργείο Εθνικής Παιδείας και Θρησκευµάτων (πιθανότατα υποβάλλοντας πρόταση για χρηµατοδότηση) και αφού πάρει την έγκριση αναθέτει (µετά από διαγωνισµό) σε µια εταιρία την ανάπτυξη. Η εταιρία αυτή θα έχει ως πελάτη – χρηµατοδότη το Υπουργείο, ως πελάτη – οριστή το Ελληνικό Ανοικτό Πανεπιστήµιο, ενώ πελάτες – χρήστες θα είναι όλοι οι ενδιαφερόµενοι που θα επισκέπτονται τον κόµβο. ¢Ú·ÛÙËÚÈﬁÙËÙ· ÁÈ· ÂÚ·ÈÙ¤Úˆ ÌÂÏ¤ÙË 1.1 Εκτός από τις κατηγορίες που αναφέραµε στην ενότητα 1.3 υπάρχουν και πολλές άλλες κατηγορίες εµπλεκοµένων στην ανάπτυξη λογισµικού που πηγάζουν από τις πιο σύνθετες ανάγκες των επιχειρήσεων που παράγουν λογισµικό. Αν αναζητήσετε τις αγγελίες που ζητούν προσωπικό δεν θα δείτε «ζητείται προγραµµατιστής», αλλά κάτι σαν «ζητείται στέλεχος εταιρίας πληροφορικής µε γνώσεις Java και εµπειρία σε πρωτόκολλα TCP – IP». Στην πραγµατικότητα και η δεύτερη αγγελία ζητά-

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

1 . 4 ∂ ƒ °∞ ™ π ∞ ™ ∂ √ ª ∞ ¢ ∂ ™

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

ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏﬁÁËÛË˜ 1.4 Ακολουθούν µερικές προτάσεις. Ποιες από αυτές είναι σωστές και ποιες λάθος; Σωστό

Λάθος

i) Προσωπικό µίας επιχείρησης είναι όλοι όσοι συµµετέχουν στην ανάπτυξη λογισµικού.

❏

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

❏

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

❏

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

❏

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

❏

1.4 ∂ÚÁ·Û›· ÛÂ ÔÌ¿‰Â˜

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

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

KEºA§AIO 1: ∂π™∞°ø°∏ ™∆∏ ¢π∞Ã∂πƒπ™∏ §√°π™ªπ∫√À

1.4.1 ∆ÚﬁÔÈ ÔÚÁ¿ÓˆÛË˜ ÔÌ¿‰ˆÓ

Ο Mantei [Man81] αναφέρει ότι η σύνθεση και ο τρόπος οργάνωσης των οµάδων σχετίζονται µε τη δυσκολία και το µέγεθος του προγράµµατος, τη διάρκεια ζωής της οµάδας, την ευκολία τµηµατοποίησης του έργου, το βαθµό επικοινωνίας που απαιτείται και µία σειρά από άλλους –λιγότερο σηµαντικούς– παράγοντες που επηρεάζουν τον τρόπο που θα πρέπει να οργανωθεί µία οµάδα ανάπτυξης. Προτείνει τρεις τρόπους οργάνωσης µίας οµάδας ανάλογα µε τους παράγοντες του έργου: δηµοκρατικά οργανωµένη, αποκεντρωµένα διοικούµενη και κεντρικά διοικούµενη. Στις δηµοκρατικά οργανωµένες οµάδες δεν υπάρχει ηγέτης οµάδας, αν και για κάποιο πρόβληµα µπορεί κάποιος να αναλάβει το ρόλο του ηγέτη, αλλά σύντοµα θα αφήσει σε κάποιον άλλο το ρόλο του ηγέτη για το επόµενο πρόβληµα που µε τη σειρά του θα τον αφήσει σε κάποιον άλλο. Έτσι όλα τα µέλη της οµάδας θα έχουν την ευκαιρία να την ηγηθούν κατά διαστήµατα. Όλα τα προβλήµατα θα συζητούνται από κοινού και αυτός που έχει το ρόλο του ηγέτη απλά θα συντονίζει. Στις αποκεντρωµένα διοικούµενες οµάδες υπάρχει κάποιος µόνιµος ηγέτης, αλλά τα προβλήµατα πάλι συζητούνται από κοινού και η επικοινωνία ανάµεσα στα µέλη της οµάδας είναι οριζόντια. Στις κεντρικά διοικούµενες οµάδες υπάρχει µόνιµος ηγέτης και υπάρχουν επιµέρους καθορισµένες εξουσίες. Η διοίκηση και η επικοινωνία γίνεται κάθετα (δηλαδή ο ηγέτης επικοινωνεί µε τους άµεσα υφισταµένους του, αυτοί µε τους επόµενους στην ιεραρχία, κτλ. Η επιλογή του τρόπου οργάνωσης εξαρτάται από το είδος του προβλήµατος. Τα µεγάλα προβλήµατα συνήθως απαιτούν κεντρικά διοικούµενες οµάδες, ενώ τα µικρά δηµοκρατικά διοικούµενες, τα προβλήµατα που χρειάζονται πολύ χρόνο συνήθως επιλύονται καλύτερα από δηµοκρατικά διοικούµενες οµάδες (αφού είναι η καλύτερη οργάνωση σε σχέση µε το ηθικό µιας οµάδας που θα εργαστεί για πολύ καιρό µαζί) και τα προβλήµατα που διασπώνται εύκολα σε τµήµατα είναι καλύτερα να επιλύονται από κεντρικά διοικούµενες οµάδες. Φυσικά ο υπεύθυνος έργου πρέπει να εκτιµήσει όλους τους παράγοντες του έργου και τις ιδιαιτερότητες του προσωπικού πριν αποφασίσει για τον τρόπο οργάνωσης της οµάδας. 1.4.2 ¶ÏÂÔÓÂÎÙ‹Ì·Ù· ÂÚÁ·Û›·˜ ÛÂ ÔÌ¿‰Â˜

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

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

1 . 4 ∂ ƒ °∞ ™ π ∞ ™ ∂ √ ª ∞ ¢ ∂ ™

οµάδας κοντά το ένα µε το άλλο, αναπτύσσοντας µία κοινή φιλοσοφία ανάπτυξης, να γνωρίζουν ο ένας τη δουλειά του άλλου. Όπως θα δούµε και σε επόµενα κεφάλαια βοηθά επίσης στην εφαρµογή διαδικασιών και προτύπων ποιότητας, αλλά –κυρίως– βοηθά σε αυτό που ο Sommerville [Som89] ονοµάζει «µη εγωιστικός προγραµµατισµός (egoless programming)», δηλαδή ο προγραµµατιστής να µη θεωρεί τον κώδικά του ως ιδιοκτησία του (δηµιουργία του), αλλά ως ιδιοκτησία (δηµιουργία) της οµάδας στην οποία έχει ενταχθεί. 1.4.3 √ÚÁ·ÓﬁÁÚ·ÌÌ· ·Ó¿Ù˘ÍË˜ ÏÔÁÈÛÌÈÎÔ‡

Οι περισσότεροι από εσάς έχετε διδαχθεί ή τουλάχιστον γνωρίζετε το οργανόγραµµα ως το µέσο µε το οποίο παρουσιάζονται µε σχηµατικό τρόπο οι σχέσεις και οι εξαρτήσεις (προϊστάµενοι – υφιστάµενοι) των µελών µίας επιχείρησης. Για µεγάλα έργα ανάπτυξης λογισµικού συνήθως γίνεται και ένα αντίστοιχο οργανόγραµµα διαχείρισης έργου (project management structure) που παρουσιάζει τις οµάδες ανάπτυξης και τους ρόλους καθενός που συµµετέχει στην ανάπτυξη λογισµικού. Έτσι ο υπεύθυνος έργου έχει καλύτερη αντίληψη για τους συµµετέχοντες στην ανάπτυξη λογισµικού και τις ευθύνες που έχει αναλάβει ο καθένας από αυτούς. Στο σχήµα 1.10 παρουσιάζεται ένα παράδειγµα οργανογράµµατος ενός µικρού έργου. (Το έργο που παρουσιάζεται στο σχήµα 1.10 είναι πολύ µικρό για να γίνει σε πραγµατικές συνθήκες οργανόγραµµα, αλλά για λόγους χώρου στο βιβλίο δεν θεωρήσαµε ανάγκη να βάλουµε ένα τεράστιο ρεαλιστικό οργανόγραµµα).

■ Το οργανόγραµ-

µα διαχείρισης έργου (project management structure) παρουσιάζει σχηµατικά τη διοικητική δοµή του έργου.

Περικλής Yπεύθυνος Έργου

Aσπασία

Xρήστος

Oµάδα UI

Oµάδα B∆

Στέλιος Προγρ/της

Xαρά Γραµµατεία έργου

Σοφία Bασίλης Έµπειρος Προγρ/της

Προγ/τρια

Άννα Σχεδιάστρια ER

Bασίλης Προγρ/της ™¯‹Ì· 1.10

Mάριος

Kώστας

Προγρ/της

Παράδειγµα οργανογράµµατος έργου

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

KEºA§AIO 1: ∂π™∞°ø°∏ ™∆∏ ¢π∞Ã∂πƒπ™∏ §√°π™ªπ∫√À

Στο σχήµα 1.10 βλέπουµε ότι ο Περικλής είναι υπεύθυνος ενός έργου µε γραµµατεία έργου τη Χαρά. Στο έργο υπάρχουν δύο οµάδες που λειτουργούν ως κεντρικά διοικούµενες. Στη µία οµάδα ηγέτης είναι η Ασπασία και στην άλλη ο Χρήστος. Βλέπουµε επίσης τα υπόλοιπα µέλη που εργάζονται στην ανάπτυξη του έργου ποιον έχουν άµεσα προϊστάµενο ο καθένας. ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏﬁÁËÛË˜ 1.5 Ακολουθούν µερικές προτάσεις. Ποιες από αυτές είναι σωστές και ποιες λάθος; Σωστό

Λάθος

❏

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

❏

iii) Οι κεντρικά διοικούµενες οµάδες αποδίδουν καλύτερα για έργα που έχουν µικρή διάρκεια.

❏

iv) Ο µη εγωιστικός προγραµµατισµός υποβοηθείται στα πλαίσια µιας οµάδας.

❏

i) Οι οµάδες ανάπτυξης λογισµικού πρέπει να οργανώνονται δηµοκρατικά.

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

™À¡√æ∏ ∫∂º∞§∞π√À ∫∞π ™Àªµ√À§∂™ ª∂§∂∆∏™

™‡ÓÔ„Ë ÎÂÊ·Ï·›Ô˘ Î·È Û˘Ì‚Ô˘Ï¤˜ ÌÂÏ¤ÙË˜ Στο κεφάλαιο µιλήσαµε για τη διαχείριση της ανάπτυξης λογισµικού. Θα συνεχίσουµε και στο επόµενο κεφάλαιο µε την εκτίµηση και την ανάλυση ρίσκου, αλλά µέχρι τώρα µιλήσαµε για τις περισσότερες διαδικασίες που αφορούν τη διαχείριση έργων λογισµικού. Πρέπει να γνωρίζετε τις βασικές έννοιες και ορισµούς που σχετίζονται µε τη διαχείριση έργων λογισµικού και τις ιδιαιτερότητες του λογισµικού και τα προβλήµατα διαχείρισης που εντάσσονται στη λεγόµενη κρίση του λογισµικού. ∆ώσαµε ιδιαίτερη έµφαση στις βασικές δραστηριότητες που σχετίζονται µε τη διαχείριση έργων λογισµικού και παρουσιάσαµε µερικές από τις πιο διαδεδοµένες τεχνικές που χρησιµοποιούν οι υπεύθυνοι έργων. Θα πρέπει να µπορείτε να εφαρµόσετε αυτές τις τεχνικές σε κάποιο παράδειγµα έργου λογισµικού και να λύνετε εργασίες αντίστοιχες µε τη δραστηριότητα 1.5. Τέλος µιλήσαµε για τους συµµετέχοντες στην ανάπτυξη λογισµικού το ρόλο τους και συνοπτικά για τα προσόντα που θα πρέπει να έχει ο καθένας από αυτούς, για οµάδες εργασίας και οργανόγραµµα διαχείρισης έργου. Εάν δυσκολευτήκατε στην ενότητα 1.3 του βιβλίου θα πρέπει να κάνετε µία καλή επανάληψη σε θέµατα Τεχνολογίας Λογισµικού που έχετε διδαχθεί. Σε αυτό µπορεί να σας βοηθήσει και η βιβλιογραφία που ακολουθεί. Γενικά η συµβουλή µας είναι να ανατρέχετε και σε βιβλιογραφικές πηγές πέρα από το βιβλίο αυτό, ώστε να εµπλουτίζετε τις γνώσεις σας, αλλά και να διαβάζετε µε εναλλακτικό τρόπο την ύλη που καλύψαµε. Ακολουθεί βιβλιογραφία µε αρκετά προτεινόµενα βιβλία για περαιτέρω µελέτη στα οποία σας υποδεικνύουµε που να επικεντρώσετε την προσοχή σας.

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

KEºA§AIO 1: ∂π™∞°ø°∏ ™∆∏ ¢π∞Ã∂πƒπ™∏ §√°π™ªπ∫√À

µÈ‚ÏÈÔÁÚ·Ê›· Î·È ÚÔÙ¿ÛÂÈ˜ ÁÈ· ÂÚ·ÈÙ¤Úˆ ÌÂÏ¤ÙË

Ακολουθεί η βιβλιογραφία του κεφαλαίου 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 ™ÂÏ›‰· 49

µ π µ § π √ ° ƒ∞ º π ∞ ∫ ∞ π ¶ ƒ √ ∆∞ ™ ∂ π ™ ° π ∞ ¶ ∂ ƒ∞ π ∆ ∂ ƒ ø ª ∂ § ∂ ∆ ∏

[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 έως σήµερα. Θα το πρότεινα µόνο

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

KEºA§AIO 1: ∂π™∞°ø°∏ ™∆∏ ¢π∞Ã∂πƒπ™∏ §√°π™ªπ∫√À

σε κάποιον που δεν µπορεί να διαβάσει αγγλικά βιβλία για να διαβάσει για την κρίση του λογισµικού και για µύθους και πραγµατικότητα της διαχείρισης έργων λογισµικού που αναφέρονται στο κεφάλαιο 1. [Zah94] R. Zahniser, «Timeboxing for Top Team Performance», Software Development, vo. 3, (1994).

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

∫

∂ÎÙ›ÌËÛË Î·È ∞Ó¿Ï˘ÛË ∫ÈÓ‰‡ÓÔ˘ ™ÎÔﬁ˜

∂

2 º

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

¶ÚÔÛ‰ÔÎÒÌÂÓ· ·ÔÙÂÏ¤ÛÌ·Ù· Όταν θα έχετε ολοκληρώσει τη µελέτη αυτού του κεφαλαίου θα µπορείτε να: • ορίσετε τι είναι εκτίµηση και ποιοι είναι οι παράγοντες που είναι αναγκαίο να εκτιµηθούν, • περιγράψετε την έννοια της ακρίβειας στην εκτίµηση κόστους ή χρόνου και τις συνέπειες πιθανών λαθών, • αναφέρετε τους παράγοντες που επιδρούν στην ακρίβεια της εκτίµησης κόστους ή χρόνου, • περιγράψετε τις µεθόδους (στρατηγικές) που µπορούν να ακολουθηθούν αναφορικά µε την εκτίµηση παραγόντων όπως οι ανάγκες σε ανθρώπινο δυναµικό, το κόστος και ο χρόνος, • αναφέρετε τις πιο διαδεδοµένες τεχνικές εκτίµησης παραγόντων όπως οι ανάγκες σε ανθρώπινο δυναµικό, το κόστος και ο χρόνος, • περιγράψετε τους παράγοντες που επιδρούν στην ακρίβεια της εκτίµησης παραγόντων όπως οι ανάγκες σε ανθρώπινο δυναµικό, το κόστος και ο χρόνος, • εξηγήσετε τον τρόπο µε τον οποίο γίνεται η εκτίµηση που βασίζεται σε γραµµές κώδικα και η εκτίµηση που βασίζεται σε λειτουργικά σηµεία, • αναφέρετε τους τύπους του εµπειρικού µοντέλου COCOMO και τις κατηγορίες στις οποίες κατατάσσει τα έργα λογισµικού, • περιγράψετε τον τρόπο εκτίµησης που βασίζεται στο εµπειρικό µοντέλο COCOMO, • περιγράψετε την έννοια του κινδύνου και να αναφέρετε τους παράγοντες που σχε-

∞

√

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

KEºA§AIO 2: ∂∫∆πª∏™∏ ∫∞π ∞¡∞§À™∏ ∫π¡¢À¡√À

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

ŒÓÓÔÈÂ˜ ÎÏÂÈ‰È¿ • Εκτίµηση (Estimation)

• Λειτουργικό σηµείο (Function point)

• Χρόνος ανάπτυξης (Development

• Εκτίµηση που βασίζεται σε λειτουργικά σηµεία (Function point based estimation)

time) • Κόστος έργου (Cost) • Τεχνικές

τµηµατοποίησης

(Decomposition techniques)

• Τοµείς πληροφορίας (Information domain values)

(Empirical

• Παράγοντες ρύθµισης πολυπλοκότητας (Complexity adjustment factors)

• Εκτίµηση από κάτω προς τα πάνω

• Οργανική κατηγορία έργων (Organic mode projects)

• Εµπειρικά

µοντέλα

models)

(Bottom – up estimation) • Εκτίµηση που βασίζεται στο τελικό κόστος (Pricing to win) • Μέγεθος έργου (size) • Γραµµή κώδικα (Line of Code ή LOC) • Εκτίµηση που βασίζεται σε γραµµές κώδικα (LOC based estimation)

• Ηµι – προσαρτηµένη κατηγορία έργων (Semi – detached mode projects) • Ενσωµατωµένη κατηγορία έργων (Embedded mode projects) • Ανάλυση κινδύνου (Risk analysis) • Πίνακας αξιολόγησης συνεπειών (Impact assessment table)

∂ÈÛ·ÁˆÁÈÎ¤˜ ·Ú·ÙËÚ‹ÛÂÈ˜ Στο προηγούµενο κεφάλαιο µιλήσαµε για τη διαχείριση έργων λογισµικού και παρουσιάσαµε τις δραστηριότητες που αναλαµβάνει ο υπεύθυνος έργου. Ανάµεσα σε αυτές αναφέρθηκαν η εκτίµηση και η ανάλυση κινδύνου οι οποίες αναλύονται σε αυτό το κεφάλαιο. Ειδικότερα, στην ενότητα 2.1, παρουσιάζεται η έννοια της εκτίµησης παρα-

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

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

γόντων όπως το κόστος ή ο χρόνος στο λογισµικό. Στην ενότητα 2.2 παρουσιάζονται µερικές από τις γνωστότερες µεθόδους εκτίµησης και το εµπειρικό µοντέλο εκτίµησης COCOMO. Τέλος στην ενότητα 2.3 παρουσιάζεται –πολύ συνοπτικά– η έννοια του κινδύνου που εµπεριέχει ένα έργο λογισµικού και συζητούνται οι τρόποι ανάλυσης (και κατηγοριοποίησης) αυτού του κινδύνου από τον υπεύθυνο έργου. Για τα περισσότερα από τα σηµεία που καλύπτουµε στο κεφάλαιο αυτό σας παραθέτουµε σχολιασµένη βιβλιογραφία για περαιτέρω µελέτη στο τέλος του κεφαλαίου, όπου µπορείτε να βρείτε οδηγίες για το τι να διαβάσετε, ώστε να εµπλουτίσετε τη µελέτη σας, αντλώντας γνώσεις από πολλαπλές πηγές.

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

KEºA§AIO 2: ∂∫∆πª∏™∏ ∫∞π ∞¡∞§À™∏ ∫π¡¢À¡√À

2.1 ∂ÎÙ›ÌËÛË ·Ú·ÁfiÓÙˆÓ fiˆ˜ ÔÈ ·Ó¿ÁÎÂ˜ ÛÂ ·ÓıÚÒÈÓÔ ‰˘Ó·ÌÈÎfi, ÙÔ ÎfiÛÙÔ˜ Î·È Ô ¯ÚfiÓÔ˜

Στην ενότητα αυτή θα µιλήσουµε για την εκτίµηση στο λογισµικό. Στο πρώτο τµήµα της ενότητας, µε τίτλο εισαγωγή στην εκτίµηση, παρουσιάζονται οι βασικοί όροι που σχετίζονται µε την εκτίµηση και οι στόχοι της εκτίµησης στο λογισµικό. Στο δεύτερο τµήµα της ενότητας, µε τίτλο παράγοντες που επιδρούν στην εκτίµηση, παρουσιάζονται οι παράγοντες που σχετίζονται µε την ακρίβεια της εκτίµησης, οι οποίοι µπορούν να επηρεάσουν τη διαδικασία της εκτίµησης. Τέλος, στο τρίτο τµήµα της ενότητας, µε τίτλο µέθοδοι εκτίµησης, παρουσιάζονται οι προσεγγίσεις σχετικά µε την εκτίµηση και οι επιλογές του υπευθύνου έργου σχετικά µε τον τρόπο µε τον οποίο µπορεί να προσεγγίσει το θέµα της εκτίµησης. 2.1.1 ∂ÈÛ·ÁˆÁ‹ ÛÙËÓ ÂÎÙ›ÌËÛË ·Ú·ÁfiÓÙˆÓ fiˆ˜ ÔÈ ·Ó¿ÁÎÂ˜ ÛÂ ·ÓıÚÒÈÓÔ ‰˘Ó·ÌÈÎfi, ÙÔ ÎfiÛÙÔ˜ Î·È Ô ¯ÚfiÓÔ˜ ■

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

Η εκτίµηση στο λογισµικό είναι στις περισσότερες περιπτώσεις η πρώτη προτεραιότητα του υπεύθυνου έργου πριν ακόµα αρχίσει η υλοποίηση του έργου. Ο Αριστοτέλης από το 330 π.Χ. έλεγε: «Είναι σηµάδι ενός δοµηµένου µυαλού, να µένει ικανοποιηµένο από το βαθµό της ακρίβειας που του δίνει η φύση ενός θέµατος και όχι να ψάχνει την ακρίβεια εκεί όπου υπάρχει κάτι περίπου αληθινό», δίνοντας την πραγµατική ερµηνεία στην έννοια «εκτίµηση». Η εκτίµηση των δυνατοτήτων της οµάδας ανάπτυξης (ή της επιχείρησης γενικότερα), του κόστους και του απαιτούµενου χρόνου απαιτεί εµπειρία, πρόσβαση σε αξιόπιστα και ακριβή ιστορικά δεδοµένα και βέβαια την ικανότητα να εξάγει κανείς ποσοτικά δεδοµένα, όταν αυτό που έχει στη διάθεσή του είναι οι ποιοτικές αναλύσεις. Αυτό εξάλλου πρέπει να είναι βασικό προσόν του υπεύθυνου έργου. Είναι προφανές λοιπόν πως η διαδικασία της εκτίµησης εµπεριέχει σε κάποιο βαθµό και ρίσκο, το οποίο οδηγεί στην αβεβαιότητα. Η εκτίµηση κάποιων παραγόντων είναι πολύ σηµαντική διαδικασία στην ανάπτυξη λογισµικού και αποτελεί τη βάση πάνω στην οποία προγραµµατίζεται ένα έργο, αφού αυτό έχει να κάνει µε ανθρώπινη προσπάθεια και κόστος. Οι παράγοντες που συνήθως αποτελούν αντικείµενο εκτίµησης σε ένα έργο είναι: • Οι ανάγκες σε ανθρώπινο δυναµικό, έτσι ώστε να εκτιµηθεί η προσπάθεια (effort). • Ο χρόνος που θα χρειαστεί για την ανάπτυξη του έργου. • Το κόστος του έργου. Συνήθως, στα πλαίσια της εκτίµησης υπολογίζονται πρώτα οι ανάγκες σε ανθρώπι-

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

2 . 1 ∂ ∫ ∆ π ª ∏ ™ ∏ ¶ ∞ ƒ∞ ° √ ¡ ∆ ø ¡ √ ¶ ø ™ √ π ∞ ¡ ∞ ° ∫ ∂ ™ ™ ∂ ∞ ¡ £ ƒ ø ¶ π ¡ √ ¢ À ¡ ∞ ª π ∫ √ , ∆ √ ∫ √ ™ ∆ √ ™ ∫ ∞ π √ Ã ƒ √ ¡ √ ™

νο δυναµικό και ο χρόνος και αυτό (προσθέτοντας και κόστη εξοπλισµού και λειτουργίας) οδηγεί στην κοστολόγηση του έργου και κατά συνέπεια στην τιµολόγησή του. ∆είτε τη δραστηριότητα 2.1 για αποσαφήνιση της διαφοράς κοστολόγησης και τιµολόγησης. Στα πρώτα έργα λογισµικού, η εκτίµηση παραγόντων όπως οι ανάγκες σε ανθρώπινο δυναµικό, το κόστος και ο χρόνος αποτελούσε δευτερεύουσα διαδικασία. Ακόµα και µια πολύ µεγάλη απόκλιση από το τελικό αποτέλεσµα, της τάξης του 200%, είχε σχετικά µικρές συνέπειες στην επιχείρηση. Σήµερα, λόγω του µεγάλου ανταγωνισµού στις επιχειρήσεις λογισµικού, τέτοιες αποκλίσεις δεν είναι ανεκτές, µε δεδοµένο ότι υπάρχει σηµαντικός αριθµός συστηµατοποιηµένων τεχνικών που χρησιµοποιούνται για να επιτευχθεί όσο το δυνατό µεγαλύτερη ακρίβεια στην εκτίµηση. Μία µεγάλη απόκλιση στην εκτίµηση παραγόντων όπως οι ανάγκες σε ανθρώπινο δυναµικό, το κόστος και ο χρόνος υλοποίηση κάποιου έργου θα µπορούσε να έχει καταστροφικές συνέπειες για κάποια επιχείρηση. Σαν παράδειγµα τέτοιων συνεπειών δείτε τη δραστηριότητα 2.1 που ακολουθεί. ¢Ú·ÛÙËÚÈﬁÙËÙ· 2.1 Ο Χρήστος είναι βασικός µέτοχος σε µία µικρή εταιρία ανάπτυξης λογισµικού. Αποφασίζει να υποβάλει προσφορά σε ένα διαγωνισµό που προκηρύσσει µια µεγάλη επιχείρηση που ζητά την ανάπτυξη ενός τµήµατος λογισµικού. Η επιχείρηση ζητά οικονοµική προσφορά και χρόνο υλοποίησης και τονίζει ότι θα επιλέξει την εταιρία που θα έχει τη καλύτερη πρόταση τόσο ως προς το κόστος, όσο και ως προς την ταχύτητα ανάπτυξης του έργου. Αναφέρει µάλιστα ότι για κάθε 10 ηµέρες καθυστέρησης από την αρχική προσφορά, θα υπάρχει ρήτρα ύψους 3.000 Euro. Ο Χρήστος, που στο συγκεκριµένο έργο θα έχει και το ρόλο του υπεύθυνου έργου, αναλαµβάνει τη συγγραφή και την υποβολή της σχετικής προσφοράς. Έπειτα από αρκετές ηµέρες εργασίας και βασισµένος στην προσωπική του εµπειρία, ο Χρήστος εκτιµά ότι το έργο θα χρειαστεί 8 µήνες και η κοστολόγηση του έργου στην εταιρία είναι 69.100 Euro. Για να έχει µία σχετική άνεση χρόνου (προβλέποντας και ένα πιθανό µικρό λάθος στην εκτίµηση) και για να υπάρχει και το σχετικό κέρδος (στην περίπτωση αυτή ο Χρήστος επιδιώκει κέρδος περίπου 28%), υποβάλλει πρόταση για 10 µήνες µε τιµολόγηση 88.200 (Αφήνει µικρά περιθώρια κέρδους για να είναι η πρότασή του ανταγωνιστική). Ας υποθέσουµε ότι τελικά η εταιρία του Χρήστου πήρε το έργο. Τι θα συµβεί αν ο Χρήστος έχει πέσει έξω στην εκτίµησή του κατά κάποιο ποσοστό (όλα τα λάθη

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

KEºA§AIO 2: ∂∫∆πª∏™∏ ∫∞π ∞¡∞§À™∏ ∫π¡¢À¡√À

θεωρήστε ότι είναι προς το χειρότερο και όχι προς το καλύτερο): α) 40% στο χρόνο που εκτίµησε. β) 40% στο κόστος που εκτίµησε. γ) 40% στο χρόνο και 40% στο κόστος που εκτίµησε. δ) 100% στο χρόνο και 100% στο κόστος που εκτίµησε.

Απάντηση Ο Χρήστος από αυτό το έργο επιδίωκε κέρδος 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.

Πραγµατικό κέρδος:

–20.540 Euro.

Εκτιµώµενο κέρδος:

+19.100 Euro.

Πραγµατικό κέρδος:

–122.000 Euro.

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

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

2.1.2 ¶·Ú¿ÁÔÓÙÂ˜ Ô˘ ÂÈ‰ÚÔ‡Ó ÛÙËÓ ÂÎÙ›ÌËÛË

Στην προηγούµενη ενότητα είδαµε (στα πλαίσια της δραστηριότητας 2.1) πόσο σηµαντική είναι η ακρίβεια στην εκτίµηση παραγόντων όπως οι ανάγκες σε ανθρώπινο δυναµικό, το κόστος και ο χρόνος. Από τι όµως επηρεάζεται η εκτίµηση αυτών των παραγόντων; Ποιοι είναι οι παράγοντες που επιδρούν στην ακρίβεια των εκτιµήσεων; Αυτές τις ερωτήσεις θα απαντήσουµε σε αυτό το τµήµα. Πριν συνεχίσουµε, πρέπει να τονιστεί ότι η εκτίµηση στο λογισµικό δεν θα είναι ποτέ µια επιστήµη µε την αυστηρή έννοια του όρου. Οι τεχνολογικές, ψυχολογικές, περιβαλλοντολογικές, ακόµα και πολιτικές επιρροές είναι σηµαντικές για τον ακριβή υπολογισµό των µεγεθών και πολλές φορές οδηγούν σε µεγάλες αποκλίσεις. Παρόλα αυτά, υπάρχουν συγκεκριµένοι παράγοντες του έργου που πρόκειται να αναπτυχθεί οι οποίοι έχουν κάποια επίδραση –άλλοτε σηµαντική και άλλοτε µικρότερη– στην εκτίµηση του κόστους, της ανθρώπινης προσπάθειας και του απαιτούµενου χρόνου. Ένας από τους πιο σηµαντικούς παράγοντες είναι το µέγεθος του έργου που θα υλοποιηθεί. Υπάρχουν διάφορες τεχνικές υπολογισµού του µεγέθους του έργου και αρκετές συζητήσεις για το ποια είναι η καλύτερη µέθοδος. Το γενικό συµπέρασµα, πάντως, είναι ότι όσο µεγαλώνει το µέγεθος του έργου τόσο αυξάνει και η αλληλεξάρτηση µεταξύ των επιµέρους στοιχείων του έργου, µε αποτέλεσµα, ακόµα και οι τεχνικές διάσπασης του προβλήµατος να µην είναι ικανές να απλοποιήσουν αρκετά τα επιµέρους κοµµάτια του έργου και να οδηγήσουν σε ακριβείς εκτιµήσεις. Η πολυπλοκότητα του έργου επίσης είναι ένας σηµαντικός, αν και σχετικά υποκειµενικός, παράγοντας που επηρεάζει την ακρίβεια της εκτίµησης. Ανάλογα µε την εµπειρία που υπάρχει από προηγούµενες προσπάθειες, ένα έργο µπορεί να είναι δύσκολο και πολύπλοκο, αν η οµάδα των ανθρώπων που το έχουν αναλάβει δεν είχε ασχοληθεί µε κάτι παρόµοιο στο παρελθόν, ή ευκολότερο αν έχουν γνώση και εµπειρία στο σχετικό αντικείµενο. Η ύπαρξη ιστορικών δεδοµένων, δηλαδή δεδοµένων από αντίστοιχα έργα που έχουν αναπτυχθεί υπό παρόµοιες συνθήκες, αποτελεί βασικό παράγοντα επίδρασης στην εκτίµηση, αφού τέτοια δεδοµένα αποτελούν ένα πολύτιµο µέτρο σύγκρισης και συντελούν στην αποφυγή λαθών. Τα µεγέθη που εξάγονται από τις µετρήσεις των προηγούµενων προσπαθειών είναι πολύ χρήσιµα στην εκτίµηση του κόστους και του χρόνου παράδοσης, ιδιαίτερα εάν και οι υπόλοιπες παράµετροι του τρέχοντος έργου συγκλίνουν µε αυτές του παλαιού. Τα µοντέλα εκτίµησης κόστους για τα οποία θα µιλήσουµε σε επόµενα τµήµατα της ενότητας βασίζουν τα αποτελέσµατά τους στα ιστορικά δεδοµένα µειώνοντας έτσι το συνολικό κίνδυνο της εκτίµησης.

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

KEºA§AIO 2: ∂∫∆πª∏™∏ ∫∞π ∞¡∞§À™∏ ∫π¡¢À¡√À

Τέλος, ένας εξίσου σηµαντικός παράγοντας που καθορίζει την ακρίβεια της εκτίµησης είναι η λεπτοµέρεια στον καθορισµό των απαιτήσεων του πελάτη και η σταθερότητα αυτών των απαιτήσεων. Αυτό σηµαίνει πως ο υπεύθυνος του έργου και η οµάδα που θα κάνουν τις εκτιµήσεις θα πρέπει να έχουν πλήρη και λεπτοµερή περιγραφή του συστήµατος, των λειτουργιών που θα επιτελεί και των επιµέρους στοιχείων του έργου που θα αναπτυχθεί. ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏﬁÁËÛË˜ 2.1 Επιλέξτε από την παρακάτω λίστα πέντε παράγοντες που επιδρούν στην ακρίβεια της εκτίµησης: • Ικανότητα του προσωπικού ανάπτυξης • Μέγεθος του έργου • Πολυπλοκότητα του έργου • Βάσεις δεδοµένων • Ιστορικά δεδοµένα • Λεπτοµερείς απαιτήσεις έργου • Σταθερές απαιτήσεις έργου • Σχεδιασµός έργου

2.1.3 ª¤ıÔ‰ÔÈ ÂÎÙ›ÌËÛË˜

Στόχος των µεθόδων εκτίµησης παραγόντων όπως οι ανάγκες σε ανθρώπινο δυναµικό, το κόστος και ο χρόνος είναι να µετατρέψουν την εκτίµηση κόστους, χρόνου και προσπάθειας στο λογισµικό από κάτι που µοιάζει µια εµπειρική διαδικασία σε µια σειρά από καθορισµένα βήµατα, τα οποία –σε συνδυασµό και µε αξιόπιστα ιστορικά δεδοµένα– να οδηγούν σε ακριβείς εκτιµήσεις των παραπάνω µεγεθών. Για να εξασφαλιστεί αυτή η ακρίβεια, σύµφωνα µε τον Pressman [Pre97] µπορούµε να: α) καθυστερήσουµε την εκτίµηση τόσο ώστε να έχει προχωρήσει αρκετά το έργο και να έχει αποκτηθεί αρκετή γνώση για αυτό, β) βασίσουµε τις εκτιµήσεις µας σε παρόµοια έργα που έχουν ήδη τελειώσει, γ) χρησιµοποιήσουµε σχετικά απλές τεχνικές τµηµατοποίησης, ώστε να διασπάσουµε το πρόβληµα και δ) χρησιµοποιήσουµε ένα ή περισσότερα εµπειρικά µοντέλα για εκτίµηση κόστους και προσπάθειας.

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

Η καθυστέρηση της εκτίµησης είναι η λύση που έχει τα καλύτερα αποτελέσµατα αλλά δεν είναι πρακτική, αφού η εκτίµηση πρέπει να γίνει πριν ακόµα αρχίσει η υλοποίηση του έργου ή έστω στα πρώτα στάδια αυτού. Η καλύτερη εκτίµηση (µε 100% ακρίβεια) θα επιτευχθεί αν περιµένουµε να τελειώσει το έργο, αλλά αυτή η «εκτίµηση» θα έχει µηδενική αξία. Ωστόσο, επειδή σε µερικά έργα δεν υπάρχουν καθόλου στοιχεία στα οποία µπορεί να βασιστεί η εκτίµηση, είναι αναγκαίο η εκτίµηση να γίνει αφού το έργο ξεκινήσει και προκύψουν κάποια δεδοµένα. Το να βασιστεί η εκτίµηση σε παρόµοια έργα που έχουν ήδη ολοκληρωθεί µπορεί να λειτουργήσει καλά, αν το συγκεκριµένο έργο το οποίο θέλουµε να εκτιµήσουµε έχει αρκετές οµοιότητες µε τα «παρόµοια έργα» µε τα οποία το συσχετίζουµε, συµπεριλαµβανοµένων όλων των παραγόντων που αναφέρθηκαν στην ενότητα 2.1.2. Συνήθως, στην πράξη αυτό δεν συµβαίνει. Αυτό που συµβαίνει είναι να έχουµε ιστορικά δεδοµένα από άλλα έργα που έχουν ολοκληρωθεί, αλλά οι συνθήκες να είναι αρκετά διαφορετικές ώστε αυτά να µην µπορούν να θεωρηθούν «παρόµοια έργα». Οι τεχνικές τµηµατοποίησης βασίζονται στη λογική του «διαίρει και βασίλευε», δηλαδή στη διάσπαση του έργου σε µικρότερες αλλά βασικές λειτουργίες, µε στόχο η εκτίµηση κόστους και προσπάθειας να µην γίνεται συνολικά για το έργο, αλλά να µπορεί να γίνει χωριστά για κάθε τµήµα. Αυτό δίνει τη δυνατότητα να υπάρχει πολύ µεγαλύτερη ακρίβεια στην εκτίµηση. Τα εµπειρικά µοντέλα µπορούν να χρησιµοποιηθούν επικουρικά στις τεχνικές τµηµατοποίησης και να δώσουν πολύτιµες πληροφορίες σχετικά µε τα µεγέθη που εξετάζονται. Η χρήση των εµπειρικών µοντέλων βασίζεται στην αξιοποίηση ιστορικών δεδοµένων από ποσότητες ανεξάρτητες από αυτές που στοχεύουµε να εκτιµήσουµε. Πάντως τέτοιου είδους εκτίµηση είναι τόσο καλή όσο και τα ιστορικά δεδοµένα που χρησιµοποιούνται για να οδηγηθούµε σε αυτή την εκτίµηση. Αν δεν υπάρχουν κατάλληλα ιστορικά δεδοµένα, η εκτίµηση στέκεται σε πολύ αβέβαιες βάσεις. Στην επόµενη ενότητα, θα µιλήσουµε περισσότερο για τεχνικές τµηµατοποίησης και εµπειρικά µοντέλα εκτίµησης. Σε αυτό το σηµείο, πρέπει να διευκρινίσουµε, όσον αφορά την έννοια του κόστους, ότι ένα έργο έχει κόστος υλικού, εκπαίδευσης και ταξιδιών της οµάδας που ασχολείται µε αυτό, καθώς και κόστος της προσπάθειας αυτών των ανθρώπων (η οποία µετράται σε ανθρωποµήνες). Το τελευταίο είναι και αυτό στο οποίο αναφερόµαστε εµείς εδώ, χωρίς αυτό να σηµαίνει πως τα υπόλοιπα είναι αµελητέα. Απλά συνήθως είναι πιο εύκολο να εκτιµηθούν.

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

KEºA§AIO 2: ∂∫∆πª∏™∏ ∫∞π ∞¡∞§À™∏ ∫π¡¢À¡√À

ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏﬁÁËÛË˜ 2.2 Συµπληρώστε τις παρακάτω προτάσεις επιλέγοντας µία από τις προτεινόµενες λέξεις που ακολουθούν: α) Η καθυστέρηση της εκτίµησης είναι συνήθως η λύση που έχει τα …………………… αποτελέσµατα, αλλά δεν είναι ………………. (καλύτερα, χειρότερα) (οικονοµική, πρακτική, βέλτιστη) β) Το να βασιστεί η εκτίµηση σε παρόµοια έργα που έχουν ήδη ολοκληρωθεί, µπορεί να λειτουργήσει καλά, αν το συγκεκριµένο έργο το οποίο θέλουµε να εκτιµήσουµε είναι ………………… µε εκείνο το οποίο συσχετίζουµε. (διαφορετικό, παρόµοιο, ισοδύναµο, παράλληλο) γ) Τα εµπειρικά µοντέλα µπορούν να χρησιµοποιηθούν ………………… στις τεχνικές τµηµατοποίησης και να δώσουν ………………… πληροφορίες σχετικά µε τα µεγέθη που εξετάζονται. (ανεξάρτητα, παράλληλα, επικουρικά) (αµφιλεγόµενες, πολύτιµες)

2.2 ∆Â¯ÓÈÎ¤˜ ÂÎÙ›ÌËÛË˜ Î·È ÂÌÂÈÚÈÎ¿ ÌÔÓÙ¤Ï·

Στην ενότητα αυτή θα µιλήσουµε συνοπτικά για µερικές από τις πιο γνωστές τεχνικές εκτίµησης, καθώς και για τα εµπειρικά µοντέλα µε έµφαση στο εµπειρικό µοντέλο COCOMO που είναι από τα πιο διαδεδοµένα. 2.2.1 ∆Â¯ÓÈÎ¤˜ ÂÎÙ›ÌËÛË˜

Έχουν υπάρξει διάφορες προσεγγίσεις του προβλήµατος της εκτίµησης παραγόντων όπως οι ανάγκες σε ανθρώπινο δυναµικό, το κόστος και ο χρόνος ενός έργου. Ο υπεύθυνος έργου αρχίζει µε τη µελέτη και την κατανόηση των απαιτήσεων και των προδιαγραφών του έργου και στη συνέχεια επιλέγει τους τρόπους επίλυσης του προβλήµατος της εκτίµησης. Υπάρχουν αρκετές τεχνικές εκτίµησης που έχουν προταθεί από το 1981 [Boe81] µε πιο σηµαντικές τις εξής: εκτίµηση από κάτω προς τα πάνω (bottom – up estimation) και εκτίµηση που βασίζεται στο τελικό κόστος (pricing to win). Κάθε µια από τις τεχνικές που έχουν προταθεί έχει τα πλεονεκτήµατα και τα µειονεκτήµατά της. Το σηµαντικότερο είναι πως καµία τεχνική δεν µπορεί να δώσει ικανοποιητικά αποτελέσµατα από µόνη της. Σε µεγάλου µεγέθους έργα είναι απαραίτητη η χρήση τουλάχιστον δυο από αυτές, ώστε να ελέγχεται η ακρίβεια της κάθε εκτίµησης σε συνάρτηση µε τις υπόλοιπες.

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

2.2 ∆∂Ã¡π∫∂™ ∂∫∆πª∏™∏™ ∫∞π ∂ª¶∂πƒπ∫∞ ª√¡∆∂§∞

Βασικό στοιχείο για την εκτίµηση παραγόντων, όπως οι ανάγκες σε ανθρώπινο δυναµικό, το κόστος και ο χρόνος είναι κυρίως η πρόβλεψη για το µέγεθος (size) του έργου έτσι ώστε µε βάση αυτό το µέγεθος να προκύψουν (συνήθως µετά από απλές αριθµητικές πράξεις) τα υπόλοιπα µεγέθη (κόστος και χρόνος). Για άµεση προσέγγιση, χρησιµοποιούµε εκτίµηση που βασίζεται σε γραµµές κώδικα (LOC based estimation), ενώ για µια έµµεση προσέγγιση, αλλά αρκετές φορές µε καλύτερα αποτελέσµατα, επιλέγουµε την εκτίµηση που βασίζεται σε λειτουργικά σηµεία (function point based estimation). Στις τεχνικές αυτές, που η εκτίµηση βασίζεται στην αρχική εκτίµηση του µεγέθους του έργου (είτε σε LOC, είτε σε FPs), η ακρίβεια της εκτίµησης σχετίζεται µε τα παρακάτω:

■ Μέγεθος

(size) στη γλώσσα του λογισµικού, εννοούµε τη µετρήσιµη ποσότητα –που συνή• Το βαθµό επιτυχίας της εκτίµησης του µεγέθους, θως µετριέται σε • την ικανότητα να µεταφραστεί αυτή η εκτίµηση του µεγέθους σε ανθρώπινη προ- γραµµές κώδικα– του εξαγόµεσπάθεια, χρόνο και χρήµατα, νου προϊόντος. • το βαθµό στον οποίο ο αρχικός προγραµµατισµός του έργου αντανακλά τις ικανότητες της οµάδας και • τη σταθερότητα των απαιτήσεων και το περιβάλλον που υποστηρίζει την προσπάθεια ανάπτυξης του έργου. Εκτίµηση από κάτω προς τα πάνω Η εκτίµηση από κάτω προς τα πάνω είναι µία τεχνική εκτίµησης που βασίζεται στη λογική διάσπασης του έργου σε µικρότερα τµήµατα. Είναι δηλαδή µία τεχνική τµηµατοποίησης (η πιο διαδεδοµένη από αυτές τις τεχνικές) που αναφέραµε στην ενότητα 2.1.3. Στη εκτίµηση από κάτω προς τα πάνω, το έργο διασπάται σε κοµµάτια και µετριέται το κόστος καθενός από αυτά. Τελικά, από το σύνολο των επιµέρους τµηµάτων εκτιµάται το συνολικό κόστος. Αυτή η τεχνική έχει στατιστικό πλεονέκτηµα σε σχέση µε τις υπόλοιπες τεχνικές µόνο αν οι ξεχωριστές µετρήσεις είναι ανεξάρτητες και απαλλαγµένες από προκατάληψη. Αυτό δεν είναι κάτι αυτονόητο και δεν είναι εύκολο να εξασφαλιστεί σε ένα περιβάλλον µε πολλούς εργαζόµενους που δουλεύουν µαζί. Για παράδειγµα, αν σε µία επιχείρηση κάποιος εκτιµά ένα δύσκολο τµήµα του έργου µε χαµηλό κόστος και κάποιος άλλος, ένα ευκολότερο κοµµάτι µε υψηλότερο κόστος, αυτό σίγουρα επηρεάζει τον πρώτο, ο οποίος συζητώντας γι αυτό θα σκεφτεί να αυξήσει το κόστος του δικού του τµήµατος. Αυτό θα είχε ως συνέπεια να µειώνεται η αντικειµενικότητα των µετρήσεων. Έστω m διαφορετικοί προγραµµατιστές που εκτιµούν ανεξάρτητα κάθε τµήµα (module) ενός έργου, κόστους ci και κάθε εκτίµηση έχει µια απόκλιση σi2. Τότε, το

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

KEºA§AIO 2: ∂∫∆πª∏™∏ ∫∞π ∞¡∞§À™∏ ∫π¡¢À¡√À

συνολικό εκτιµώµενο κόστος cp του έργου θα είναι: cp = c1 + c2 +…+ cm

(2.1)

Η συνολική απόκλιση σp είναι: σp2 = σ12 + σ22 +…+σm2

(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 ™ÂÏ›‰· 63

2.2 ∆∂Ã¡π∫∂™ ∂∫∆πª∏™∏™ ∫∞π ∂ª¶∂πƒπ∫∞ ª√¡∆∂§∞

Γενικά είναι σκόπιµο το έργο να χωρίζεται σε κοµµάτια ανάλογα µε το µέγεθος της οµάδας, το είδος κάθε λειτουργίας ή την πολυπλοκότητά της. Έτσι, σε κάθε τµήµα του έργου εφαρµόζεται η παραπάνω µέθοδος ανεξάρτητα. Στην περίπτωση των γραµµών κώδικα, η διάσπαση είναι εντελώς απαραίτητη και πρέπει να γίνει µε µεγάλο βαθµό λεπτοµέρειας. Όσα περισσότερα είναι τα επιµέρους έργα, τόσο πιο ακριβής θα είναι και η εκτίµηση, όπως είδαµε και στην τεχνική της εκτίµησης από κάτω προς τα πάνω. Χρησιµοποιώντας τα ιστορικά δεδοµένα (ή αν αυτά δεν είναι διαθέσιµα, την εµπειρία και τη διαίσθησή του) ο υπεύθυνος έργου εκτιµά 3 σηµεία. Αυτή είναι η λεγόµενη εκτίµηση της αναµενόµενης τιµής. Γίνεται δηλαδή εκτίµηση της πιο απαισιόδοξης, της πιο πιθανής και της πιο αισιόδοξης τιµής του µεγέθους όπως στη σχέση (2.5), όπου το EV είναι η αναµενόµενη τιµή (Expected Value) που µετράται σε γραµµές κώδικα και τα sopt, sm και spess, είναι η µέση τιµή αντίστοιχα της αισιόδοξης της πιθανής και της απαισιόδοξης εκτίµησης. Αυτή η εξίσωση δίνει µεγαλύτερο βάρος στην πιθανή λύση και ακολουθεί µια βήτα – κατανοµή: EV = (sopt + 4 sm + spess) / 6

(2.5)

Με αυτή την τεχνική υπάρχει µικρή πιθανότητα να ξεφύγουµε από την απαισιόδοξη και την αισιόδοξη εκτίµηση αφού υπάρχει και η δυνατότητα υπολογισµού της απόκλισης. Έτσι και αλλιώς, η εµπειρία, η διαίσθηση και η κοινή λογική είναι εκείνα τα στοιχεία που θα κάνουν πιο ασφαλείς τις εκτιµήσεις. Όσοι υποστηρίζουν αυτή την τεχνική, πιστεύουν πως η µέτρηση των γραµµών κώδικα µπορεί να χρησιµοποιηθεί σε όλα τα έργα ανάπτυξης λογισµικού, είναι εύκολα υλοποιήσιµη και υπάρχουν πολλά ιστορικά δεδοµένα πάνω σε αυτό το θέµα. Από την άλλη πλευρά, οι µετρήσεις των γραµµών κώδικα φαίνονται να εξαρτώνται από τη χρησιµοποιούµενη γλώσσα προγραµµατισµού, δεν µπορούν να διαχειριστούν εύκολα τις σύγχρονες γλώσσες και απαιτούν τέτοιο βαθµό διάσπασης και λεπτοµέρειας που είναι δύσκολο να επιτευχθεί, µε δεδοµένο ότι η εκτίµηση πρέπει να γίνει πολύ πριν τελειώσει η ανάλυση και ο σχεδιασµός του έργου. ¢Ú·ÛÙËÚÈﬁÙËÙ· 2.2 Ο Χρήστος πρέπει να εκτιµήσει το κόστος ενός έργου. Αυτή τη φορά θα βασίσει την εκτίµηση σε γραµµές κώδικα για τις οποίες έχει και εµπειρία και ιστορικά δεδοµένα. Από τα ιστορικά δεδοµένα γνωρίζει ότι έχει µία µέση τιµή 1.250 LOC/pm και ότι το κόστος του ανθρωποµήνα είναι 4.500 Euro. Ο Χρήστος σε συνεργασία µε άλλους δύο έµπειρους προγραµµατιστές έχουν διασπάσει το έργο σε 5 τµήµατα και για κάθε ένα έχουν υπολογίσει (βασισµένοι στην εµπειρία τους και στα ιστο-

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

KEºA§AIO 2: ∂∫∆πª∏™∏ ∫∞π ∞¡∞§À™∏ ∫π¡¢À¡√À

ρικά δεδοµένα) µία αισιόδοξη, µία κανονική και µία απαισιόδοξη εκτίµηση που δίνονται στον παρακάτω πίνακα (όλες οι τιµές είναι σε LOC): Τµήµατα

Αισιόδοξη

Κανονική

Απαισιόδοξη

1ο τµήµα

2200

2650

3500

2ο τµήµα

750

1100

1500

3ο τµήµα

1800

2350

3000

4ο τµήµα

800

1200

1700

5ο τµήµα

2500

3100

4000

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

Απάντηση Μπορούµε να υπολογίσουµε την εκτίµηση της αναµενόµενης τιµής είτε στα σύνολα των προβλέψεων είτε για κάθε τµήµα. Και οι δύο περιπτώσεις θα οδηγήσουν στο ίδιο αποτέλεσµα. Μια επιχείρηση βέβαια θα την υπολόγιζε ξεχωριστά για κάθε τµήµα, ώστε να µπορεί να ελέγχει την εκτίµηση τµηµατικά. Εµείς, για λόγους ευκολίας, θα την υπολογίσουµε συνολικά. Από τον πίνακα έχουµε (για όλο το έργο): sopt = sm

8.050 LOC

= 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 που είναι και η εκτίµηση του κόστους. Βέβαια σε αυτό το κόστος ο Χρήστος θα προσθέσει εκτιµήσεις για έξοδα ταξιδιών, αγοράς εξοπλισµού και αναλωσίµων (αν υπάρχει ανάγκη για το έργο) και θα προσθέσει και το κέρδος της εταιρίας του για να καταλήξει στην τελική τιµολόγηση (δηλαδή στο ποσό που θα χρεώσει ή θα ζητήσει από τον πελάτη).

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

2.2 ∆∂Ã¡π∫∂™ ∂∫∆πª∏™∏™ ∫∞π ∂ª¶∂πƒπ∫∞ ª√¡∆∂§∞

Εκτίµηση που βασίζεται σε λειτουργικά σηµεία Η εκτίµηση που βασίζεται σε λειτουργικά σηµεία ξεκινά πάλι µε τον προσδιορισµό των απαιτήσεων, στην περίπτωση αυτή όµως η διάσπαση λειτουργεί διαφορετικά. Το έργο δεν χωρίζεται σε τµήµατα, αλλά σε τοµείς πληροφορίας (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 παράγοντες ρύθµισης πολυπλοκότητας, πληροφορίες για το πώς υπολογίζονται και παραδείγµατα µετρήσεων για τους τοµείς πληροφορίας. Επειδή θα χρειάζονταν πολλές σελίδες για να τα αναλύσουµε όλα αυτά, δεν ενσωµατώθηκαν στην ύλη του βιβλίου, πιστεύουµε όµως πως η µελέτη τους θα είναι κάτι περισσότερο από χρήσιµη.

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

KEºA§AIO 2: ∂∫∆πª∏™∏ ∫∞π ∞¡∞§À™∏ ∫π¡¢À¡√À

¢Ú·ÛÙËÚÈﬁÙËÙ· 2.3 Ο Χρήστος αυτή τη φορά θα βασίσει την εκτίµησή του για το ίδιο έργο σε λειτουργικά σηµεία. Από τα ιστορικά δεδοµένα γνωρίζει ότι έχει µία µέση τιµή 7 FP/pm και ότι το κόστος του ανθρωποµήνα είναι 4.500 Euro. Ο Χρήστος σε συνεργασία µε άλλους δύο έµπειρους προγραµµατιστές έχει υπολογίσει (βασισµένος στην εµπειρία του και στα ιστορικά δεδοµένα) τα παρακάτω FP για κάθε τοµέα πληροφορίας: Τµήµατα

στοιχεία εισόδου

στοιχεία εξόδου

αρχεία

αναζητήσεις

εξωτερικές διεπαφές

Count C

Υπολογίστε το τελικό κόστος του έργου όπως θα το εκτιµήσει ο Χρήστος, θεωρώντας ότι το άθροισµα των τιµών από 0 έως 5 για τους 14 παράγοντες ρύθµισης πολυπλοκότητας που µέτρησε ο Χρήστος είναι ίσο µε 52.

Απάντηση Από την εξίσωση (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), παρατηρούµε µια µικρή απόκλιση στη µέτρηση της προσπάθειας. Τέτοιες αποκλίσεις µπορούν να οφείλονται σε ασυµβατότητες των ιστορικών δεδοµένων, είτε σε λάθη στη χρήση των γραµµών κώδικα ή των λειτουργικών σηµείων. Αυτός είναι και ο λόγος που συνήθως χρησιµοποιούνται περισσότερες από µία τεχνικές εκτίµησης για το ίδιο έργο. Στην περίπτωση αυτή η απόκλιση δεν είναι σηµαντική, αλλά εάν προκύπτουν µεγάλες διαφορές στα εξαγόµενα αποτελέσµατα, τότε δεν έχει γίνει κατανοητός ο στόχος του έργου ή τα δεδοµένα που χρησιµοποιήθηκαν για την µέτρηση της παραγωγικότητας δεν ισχύουν πια για τα συγκεκριµένα έργα. Σε αυτή την περίπτωση, ο Χρήστος ως υπεύθυνος του έργου θα πρέπει να επαναπροσδιορίσει το πρόβληµα και να συµβιβάσει τα αντίθετα αποτελέσµατα.

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

2.2 ∆∂Ã¡π∫∂™ ∂∫∆πª∏™∏™ ∫∞π ∂ª¶∂πƒπ∫∞ ª√¡∆∂§∞

ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏﬁÁËÛË˜ 2.3 Ακολουθούν µερικές προτάσεις. Ποιες από αυτές είναι σωστές και ποιες λάθος; ∆είτε στο τέλος του βιβλίου τις σωστές απαντήσεις, καθώς και την αιτιολόγηση για κάθε απάντηση. Σωστό

Λάθος

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

❏

ii) Στις τεχνικές που η εκτίµηση βασίζεται στο µέγεθος, η ακρίβεια της εκτίµησης σχετίζεται µε την ικανότητα να µεταφραστεί αυτή η εκτίµηση του µεγέθους σε ανθρώπινη προσπάθεια, χρόνο και χρήµατα.

❏

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

❏

iv) Η τεχνική της εκτίµησης που βασίζεται στο τελικό κόστος είναι η λιγότερο διαδεδοµένη στις µικρές επιχειρήσεις.

❏

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

❏

vi) H εκτίµηση που βασίζεται σε γραµµές κώδικα και η εκτίµηση που βασίζεται σε λειτουργικά σηµεία είναι τεχνικές εκτίµησης που ανήκουν στην κατηγορία «τεχνικές τµηµατοποίησης».

❏

2.2.2 ∂ÌÂÈÚÈÎ¿ ÌÔÓÙ¤Ï·

Τα εµπειρικά µοντέλα βασίζονται κυρίως σε ιστορικά δεδοµένα και οδηγούν σε µία σχέση της µορφής (2.7), όπου το d είναι ένα από τα µεγέθη που υπολογίζονται (συνήθως προσπάθεια, κόστος, διάρκεια έργου κτλ.) και το ui είναι µια σειρά από επιλεγµέ-

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

KEºA§AIO 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 ™ÂÏ›‰· 69

2.2 ∆∂Ã¡π∫∂™ ∂∫∆πª∏™∏™ ∫∞π ∂ª¶∂πƒπ∫∞ ª√¡∆∂§∞

έργο (διάρκεια έργου) δίνεται στην εξίσωση (2.9), ενώ ο αναγκαίος αριθµός ατόµων για να υλοποιηθεί το έργο στην εξίσωση (2.10), όπου ο χρόνος D µετράται σε µήνες και το Ν δίνει τον αριθµό των ατόµων που απαιτούνται για την ολοκλήρωση του έργου. Η σταθερά γ παίρνει τις παρακάτω τιµές για τους τρεις τύπους έργων λογισµικού (οργανική γ = 0,38, ηµι – προσαρτηµένη γ = 0,35 και ενσωµατωµένη γ = 0,32). D = 2,5E γ E N= D

(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 Το Πλήρες µοντέλο συγκεντρώνει τα χαρακτηριστικά των δυο προηγούµενων υπολογίζοντας και την επίδραση των παραπάνω παραγόντων σε κάθε βήµα της διαδι-

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

KEºA§AIO 2: ∂∫∆πª∏™∏ ∫∞π ∞¡∞§À™∏ ∫π¡¢À¡√À

κασίας ανάπτυξης. Υπολογίζει ολοκληρωµένα και σφαιρικά αυτούς τους παράγοντες που επηρεάζουν την προσπάθεια, µειώνοντας έτσι την πιθανότητα λάθους. ∆εν θα επεκταθούµε άλλο στο πλήρες µοντέλο, αφού όποιος επιθυµεί µπορεί να το µελετήσει στην προτεινόµενη βιβλιογραφία. Γενικά, και τα τρία µοντέλα COCOMO µπορούν να προσαρµοστούν σε συγκεκριµένες εφαρµογές, θέτοντας κάθε φορά τις σταθερές και τους εκθέτες ανάλογα µε τον τύπο του έργου που αναπτύσσεται και αντλώντας στοιχεία από ιστορικά δεδοµένα. Μια γρήγορη εξέταση κάποιων εµπειρικών µοντέλων εκτίµησης µας οδηγεί στο συµπέρασµα πως τα δεδοµένα θα πρέπει να υπολογίζονται σύµφωνα µε τις ανάγκες του κάθε έργου, εξετάζοντας τις τρέχουσες συνθήκες. Το µειονέκτηµα των µοντέλων COCOMO είναι το γεγονός ότι τα προϊόντα λογισµικού αποτελούνται συνήθως από διαφορετικούς τύπους τµηµάτων, κάθε ένα από τα οποία έχει ειδικές ανάγκες και διάφορες από τα υπόλοιπα, και έτσι πρέπει να αντιµετωπίζονται. Πάντως, όπως αναφέρει ο Pressman [Pre97], τα µοντέλα αυτά είναι επιτυχή, αν µπορούν να εκτιµούν το κόστος µε απόκλιση έως 20%, και τη διάρκεια του έργου µε απόκλιση έως 70% της πραγµατικής. Το ποσοστό αυτό µπορεί να µην είναι το ιδανικό, αλλά συνήθως αποτελεί µία πολύ καλή βοήθεια για οικονοµική ανάλυση και κυρίως για λήψη αποφάσεων. ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏﬁÁËÛË˜ 2.4 Αντιστοιχίστε τις φράσεις της δεξιάς στήλης µε την κατάλληλη κατηγορία έργων σύµφωνα µε την κατάταξη των έργων κατά το COCOMO, ανάλογα µε την κατηγορία στην οποία αναφέρονται. Προσοχή, κάθε φράση δεξιά αντιστοιχεί σε µόνο µία κατηγορία έργων στα αριστερά. οργανική κατηγορία

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

ηµι – προσαρτηµένη κατηγορία

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

ενσωµατωµένη κατηγορία

άτοµα µε περιορισµένη γνώση για το σύστηµα µικρά έργα

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

2.3 ∞¡∞§À™∏ ∫π¡¢À¡√À

2.3 ∞Ó¿Ï˘ÛË ÎÈÓ‰‡ÓÔ˘

Ο Hambling [Ham96] µιλώντας για την «παθολογία ενός αποτυχηµένου έργου λογισµικού», αναφέρει ότι ένα τέτοιο έργο περνάει από µία αρχική κατάσταση αισιοδοξίας (όπου γίνονται και τα περισσότερα λάθη) σε µία φάση ρεαλισµού (όπου οι πραγµατικές συνθήκες αρχίζουν να αποκαλύπτονται), µετά σε µία κατάσταση απαισιοδοξίας (όπου τα προβλήµατα που δεν είχαν προβλεφθεί αρχικά αρχίζουν να κάνουν αδύνατη την τήρηση των αρχικών σχεδίων) και µετά σε µία κατάσταση απογοήτευσης (όπου πια είναι βέβαιο ότι οι αρχικές εκτιµήσεις ήταν τελείως λανθασµένες και ότι το έργο θα αποτύχει). Ένα καλό γιατρικό –αλλά όχι πανάκεια– για να µην προκύψουν απρόβλεπτα προβλήµατα στην εξέλιξη του έργου, είναι η ανάλυση κινδύνου. Αν και δύσκολα κανείς θα βρει κάποιον κατάλληλο ορισµό του κινδύνου, το σίγουρο είναι ότι ο κίνδυνος εµπεριέχει [Hig95] αβεβαιότητα και απώλεια. Εάν κάτι είναι απόλυτα βέβαιο ότι θα συµβεί, ή δεν έχει αρνητικές συνέπειες τότε δεν αποτελεί κίνδυνο. Κατά συνέπεια, η ανάλυση του κινδύνου είναι η µελέτη (συνήθως από τον υπεύθυνο του έργου) όλων εκείνων των καταστάσεων που αν συµβούν (χωρίς να είναι βέβαιο ότι θα συµβούν) θα έχουν αρνητικές συνέπειες για το έργο. Στα πρώτα στάδια του προγραµµατισµού του έργου, ο υπεύθυνος του έργου πρέπει να εντοπίσει πού βρίσκεται ο κίνδυνος στο έργο (προβλέποντας καταστάσεις που θα είχαν αρνητικές συνέπειες). Ακόµα πιο σηµαντικό όµως είναι να προβλέψει και τους τρόπους για την αντιµετώπιση αυτών των καταστάσεων εάν συµβούν. Η ανάλυση κινδύνου βοηθά τον υπεύθυνο του έργου να προγραµµατίσει τα οικονοµικά του έργου και τα εναλλακτικά σενάρια που µπορεί να υλοποιήσει σε περίπτωση που κάτι δεν πάει καλά. Υπάρχουν πολλά θέµατα που σχετίζονται µε την ύπαρξη κινδύνου στα πλαίσια ενός έργου. Ενδεικτικά αναφέρουµε: • Το µέγεθος του έργου. Είναι γεγονός ότι όσο αυξάνεται το µέγεθος ενός έργου τόσο αυξάνεται και ο κίνδυνος. • Η εξάρτηση από τον ανθρώπινο παράγοντα. Αν το έργο στηρίζεται αποκλειστικά σε έναν άνθρωπο (ή µια µικρή οµάδα ανθρώπων) και αυτός φύγει από την επιχείρηση, τότε το έργο θα καθυστερήσει δραµατικά ή µπορεί ακόµα και να αποτύχει. • Οι εξελίξεις στην αγορά. Το έργο µπορεί να θεωρηθεί απαρχαιωµένο όταν θα ολοκληρωθεί. • Η τεχνολογία. Το έργο µπορεί να χρησιµοποιεί πρωτοποριακές αλλά ταυτόχρονα ανώριµες τεχνολογίες, ή τεχνολογίες που η επιχείρηση δεν είναι σε θέση να διαχειριστεί. • Το ποσοστό κατά το οποία τα προγράµµατα και οι προϋπολογισµοί που καθορί-

■ Αυτό που

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

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

KEºA§AIO 2: ∂∫∆πª∏™∏ ∫∞π ∞¡∞§À™∏ ∫π¡¢À¡√À

ζονται ανταποκρίνονται στην πραγµατικότητα. • Οι υπεργολαβίες. Η µη τήρηση προθεσµιών από εξωτερικούς προµηθευτές. • Ο πελάτης. Ο βαθµός στον οποίο ο πελάτης είναι εξοικειωµένος µε την τεχνολογία µπορεί να αποτελέσει αρνητικό παράγοντα στην εξέλιξη και πρόοδο του έργου. • Το περιβάλλον υλοποίησης. Η ύπαρξη, η διαθεσιµότητα και η ποιότητα του εξοπλισµού που απαιτείται για την ολοκλήρωση του έργου είναι παράγοντες κινδύνου. • Τα λάθη στον αρχικό σχεδιασµό των τµηµάτων ή του περιβάλλοντος αλληλεπίδρασης του λογισµικού, που είναι κι ένα από τα σηµαντικότερα σηµεία! Ο Boehm [Boe89] προτείνει στους υπεύθυνους έργου, αφού θέσουν µία σειρά από ερωτήµατα για να εντοπίσουν περιπτώσεις όπως αυτές που αναφέραµε παραπάνω, να δηµιουργήσουν ένα πίνακα όπου κάθε πιθανός κίνδυνος να τοποθετείται σε µία κατηγορία, ανάλογα µε τις συνέπειες που θα είχε για την επιχείρηση. Ο πίνακας αυτός ονοµάζεται πίνακας αξιολόγησης συνεπειών (impact assessment table) και οι κατηγορίες είναι: 1. καταστροφικό (catastrophic) 2. κρίσιµο (critical) 3. µέτριο (marginal) 4. αµελητέο (negligible) Στην πρώτη κατηγορία καταγράφονται περιπτώσεις κινδύνου που θα οδηγούσαν την επιχείρηση σε καταστροφή ή σηµαντικές απώλειες, ενώ στην τελευταία αυτές που δεν θα είχαν σηµαντικές αρνητικές συνέπειες για την επιχείρηση. Από τον πίνακα αξιολόγησης συνεπειών και παράλληλα εκτιµώντας την πιθανότητα να συµβεί κάτι, ο υπεύθυνος του έργου θα αποφασίσει αν πρέπει να προχωρήσει το έργο και τι ενέργειες πρέπει να γίνουν για να προληφθούν καταστάσεις. Σε αυτό το σηµείο, ο υπεύθυνος του έργου µπορεί να πάρει την απόφαση να µην ξεκινήσει κάποιο έργο ώστε να µην εµπλακεί η επιχείρηση σε περιπέτειες. Εδώ µπορεί να κάνει δύο είδη λάθους: α) Να αποφασίσει να µην ξεκινήσει ένα έργο που στην πραγµατικότητα έχει µικρό κίνδυνο για την επιχείρηση (µε συνέπεια η επιχείρηση να χάσει µία ευκαιρία), β) να επιτρέψει να ξεκινήσει ένα έργο που έχει µεγάλο κίνδυνο µε καταστροφικές συνέπειες (µε συνέπεια να θέσει την επιχείρηση σε κίνδυνο). Είναι σαφές ότι λάθος του δεύτερου είδους µπορεί να είναι άµεσα καταστροφικό, αλλά και συνεχόµενα λάθη του πρώτου είδους πιθανότατα θα οδηγήσουν την επιχείρηση σε συρρίκνωση, αφού ο αδικαιολόγητος δισταγµός δεν συγχωρείται σε µία ανταγωνιστική αγορά.

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

2.3 ∞¡∞§À™∏ ∫π¡¢À¡√À

¢Ú·ÛÙËÚÈﬁÙËÙ· 2.4 Ο Χρήστος αναλαµβάνει να εκτιµήσει τον κίνδυνο για ένα νέο έργο το οποίο η εταιρία του εξετάζει την προοπτική να αναλάβει. Εξετάζοντας µόνο τον κίνδυνο σχετικά µε τον πελάτη, σκεφτείτε τι ερωτήσεις θα έθετε ο Χρήστος για να µπορέσει να εκτιµήσει τον κίνδυνο σε σχέση µε τον πελάτη. Γράψτε σε χαρτί τουλάχιστον 5 ερωτήσεις (σε τέτοια µορφή που αν η απάντηση είναι «ναι» αυτό να σηµαίνει αυξηµένο κίνδυνο) και προτείνετε πιθανές λύσεις αν υπάρχει κίνδυνος. Απάντηση Οι ερωτήσεις που ετοίµασε ο Χρήστος και που σχετίζονται µε τον πελάτη είναι οι παρακάτω (στην παρένθεση τι σκέφτηκε σε περίπτωση θετικής απάντησης): 1. Είναι η πρώτη φορά που συνεργαζόµαστε µε το συγκεκριµένο πελάτη; (Αν ναι, έχει συνεργαστεί µε κάποια άλλη εταιρία ή µε ιδιώτες από τους οποίους µπορούµε να αντλήσουµε πληροφορίες;) 2. Οι προδιαγραφές του έργου µας δόθηκαν από τον πελάτη προφορικά; (Αν ναι, τότε έχει τις ικανότητες –και κυρίως τη διάθεση– να καταγράψει τις απαιτήσεις του;) 3. Ο πελάτης έχει ασαφή εικόνα για το τι θέλει να γίνει στο έργο; (Αν ναι, έχουµε συνεργάτες στην εταιρία που να γνωρίζουν το αντικείµενό του για να τον βοηθήσουν στον καθορισµό των απαιτήσεων, ώστε να µην ανακαλύπτει απαιτήσεις µετά την έναρξη της υλοποίησης;) 4. Ο πελάτης µήπως δεν διαθέτει χρόνο και προσωπικό να συνεργαστεί µαζί µας, έτσι ώστε να καταγράψουµε µαζί και µε δοµηµένο τρόπο τις προδιαγραφές του έργου; (Εάν ναι, µπορεί να διαθέσει χρόνο και προσωπικό;) 5. Ο πελάτης έχει άγνοια από τεχνικά θέµατα σχετικά µε το αντικείµενο; (Εάν ναι, έχει τη θέληση και το χρόνο να εκπαιδευτεί σύντοµα για τις δυνατότητες που µπορεί να του παρέχει η τεχνολογία πριν προχωρήσουµε στις προδιαγραφές του έργου;) Θα µπορούσαν να τεθούν κι άλλες ερωτήσεις, ή ερωτήσεις που θέτουν τα ίδια ερωτήµατα µε διαφορετικό τρόπο. Ο κίνδυνος που θέλει να εντοπίσει ο Χρήστος µε αυτές τις ερωτήσεις είναι µήπως ο πελάτης δεν έχει ξεκάθαρη γνώµη για το έργο (είτε γιατί δεν έχει τεχνικές γνώσεις, είτε γιατί δεν αφιέρωσε χρόνο σε αυτό) µε συνέπεια οι αρχικές απαιτήσεις του να ανατραπούν αργότερα. Επίσης τον ανησυχεί η διαθεσιµότητα του πελάτη να συνεργαστεί (να επενδύσει σε χρόνο) για τον αυστηρό καθορισµό του έργου.

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

KEºA§AIO 2: ∂∫∆πª∏™∏ ∫∞π ∞¡∞§À™∏ ∫π¡¢À¡√À

™‡ÓÔ„Ë ÎÂÊ·Ï·›Ô˘ Î·È Û˘Ì‚Ô˘Ï¤˜ ÌÂÏ¤ÙË˜ Στο κεφάλαιο αυτό µιλήσαµε για την εκτίµηση παραγόντων όπως οι ανάγκες σε ανθρώπινο δυναµικό, το κόστος και ο χρόνος και την ανάλυση κινδύνου. ∆ώσαµε παραδείγµατα τεχνικών εκτίµησης και µιλήσαµε για το εµπειρικό µοντέλο COCOMO. Πρέπει πια να γνωρίζετε τις βασικές έννοιες και τους ορισµούς που σχετίζονται µε την εκτίµηση παραγόντων όπως οι ανάγκες σε ανθρώπινο δυναµικό, το κόστος και ο χρόνος και την ανάλυση κινδύνου. Θα πρέπει, επίσης, να µπορείτε να εφαρµόσετε τις τεχνικές που περιγράψαµε σε κάποιο παράδειγµα έργου λογισµικού, µε την προϋπόθεση ότι έχετε τα αντίστοιχα ιστορικά δεδοµένα. Σε αρκετά σηµεία του κεφαλαίου δεν επεκταθήκαµε σε λεπτοµερή παρουσίαση κάποιων τεχνικών, αφήνοντάς σας να τις µελετήσετε από µόνοι σας. Σε αυτό το σηµείο θα σας βοηθήσει η βιβλιογραφία που ακολουθεί. Γενικά, η συµβουλή µας είναι να ανατρέχετε και σε βιβλιογραφικές πηγές πέρα από το βιβλίο αυτό, ώστε να εµπλουτίζετε τις γνώσεις σας, αλλά και να διαβάζετε µε εναλλακτικό τρόπο την ύλη που καλύψαµε. Ακολουθεί βιβλιογραφία µε προτεινόµενα βιβλία για περαιτέρω µελέτη και υποδείξεις για το πού να επικεντρώσετε την προσοχή σας.

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

µ π µ § π √ ° ƒ∞ º π ∞ ∫ ∞ π ¶ ƒ √ ∆∞ ™ ∂ π ™ ° π ∞ ¶ ∂ ƒ∞ π ∆ ∂ ƒ ø ª ∂ § ∂ ∆ ∏

µÈ‚ÏÈÔÁÚ·Ê›· Î·È ÚÔÙ¿ÛÂÈ˜ ÁÈ· ÂÚ·ÈÙ¤Úˆ ÌÂÏ¤ÙË

Ακολουθεί η βιβλιογραφία του κεφαλαίου 2. Τα επιλεγµένα βιβλία που σχολιάζονται είναι αυτά που σας προτείνονται για περαιτέρω µελέτη στα θέµατα που καλύψαµε στο κεφάλαιο 2. Τα βιβλία αυτά συνοδεύονται από σχόλια για το πού να επικεντρώσετε τη µελέτη σας σχετικά µε τα θέµατα του κεφαλαίου 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). [Pre97] Roger S. Pressman, «Software Engineering: A Practitioner’s Approach», Forth edition, European Adaptation, McGraw–Hill, (1997). Το βιβλίο αυτό σας το προτείναµε και στο προηγούµενο κεφάλαιο. Στο κεφάλαιο 5 θα βρείτε στοιχεία για την εκτίµηση παραγόντων όπως οι ανάγκες σε ανθρώπινο δυναµικό, το κόστος και ο χρόνος και στο κεφάλαιο 6 για την ανάλυση κινδύνου. Θα το πρότεινα ανεπιφύλακτα σε όποιον θέλει να επεκταθεί περισσότερο σε όσα αναπτύξαµε σε αυτό το κεφάλαιο και ιδιαίτερα στη µελέτη της εκτίµησης που βασίζεται σε λειτουργικά σηµεία στην οποία αφιερώνει αρκετές σελίδες.

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

KEºA§AIO 2: ∂∫∆πª∏™∏ ∫∞π ∞¡∞§À™∏ ∫π¡¢À¡√À

[Som89] Ian Sommerville, «Software Engineering», Third edition, Addison – Wesley, (1989). Και αυτό είναι ένα βιβλίο που σας το προτείναµε και στο κεφάλαιο 1. Στο κεφάλαιο 26 θα βρείτε στοιχεία για εκτίµηση και για το εµπειρικό µοντέλο COCOMO. [Xen94] Μιχάλης Ξένος και ∆ηµήτρης Χριστοδουλάκης, «Τεχνολογία Λογισµικού: Αρχές και Μεθοδολογίες», Εκδόσεις Πανεπιστηµίου Πατρών, (1994). Το βιβλίο αυτό διατίθεται στην Κεντρική Βιβλιοθήκη του Πανεπιστηµίου Πατρών και στη βιβλιοθήκη του Τµήµατος Μηχανικών Ηλεκτρονικών Υπολογιστών και Πληροφορικής, αλλά όχι στο εµπόριο. Ο αναγνώστης που θέλει να διαβάσει στα ελληνικά θα βρει συνοπτικά στοιχεία για ανάλυση κινδύνου και εκτίµηση παραγόντων όπως οι ανάγκες σε ανθρώπινο δυναµικό, το κόστος και ο χρόνος.

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

∫

∂ÈÛ·ÁˆÁ‹ ÛÙËÓ ¶ÔÈﬁÙËÙ· ™ÎÔﬁ˜

∂

3 º

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

¶ÚÔÛ‰ÔÎÒÌÂÓ· ·ÔÙÂÏ¤ÛÌ·Ù· Όταν θα έχετε ολοκληρώσει τη µελέτη αυτού του κεφαλαίου θα µπορείτε να: • περιγράψετε τους βασικούς ορισµούς της ποιότητας και της µέτρησης και να εξηγήσετε την κοινή συνισταµένη όλων των διαφορετικών ορισµών, • διακρίνετε ανάµεσα στη διασφάλιση ποιότητας και τον ποιοτικό έλεγχο, • περιγράψετε τους τοµείς ενός οργανισµού που ασχολούνται µε την ποιότητα και να αναφέρετε τις αρµοδιότητες και ευθύνες κάθε τοµέα, • αναφέρετε τις βασικές λειτουργίες του προγράµµατος ποιότητας στην παραγωγή υλικών αγαθών, • ορίσετε τη διαχείριση ολικής ποιότητας και τις απόψεις των πρωτοπόρων της ποιότητας για την ποιότητα, • εξηγήσετε τι είναι ο στατιστικός έλεγχος ποιότητας, • περιγράψετε τα διαγράµµατα ελέγχου και να τα σχεδιάσετε για γνωστές δειγµατοληπτικές µετρήσεις, • αναφέρετε τις διαφορές της ποιότητας λογισµικού µε την ποιότητα στην παραγωγή υλικών αγαθών, • περιγράψετε ποιες από τις τεχνικές που εφαρµόζονται στην παραγωγή υλικών αγαθών µπορούν να εφαρµοστούν στην ανάπτυξη λογισµικού και ποιες όχι και να εξηγήσετε τους λόγους για τους οποίους συµβαίνει αυτό.

∞

√

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

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 ™ÂÏ›‰· 79

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

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

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

K E º A § A I O 3 : ∂ π ™ ∞ ° ø ° ∏ ™ ∆ ∏ ¡ ¶ √ π √ ∆ ∏ ∆∞

3.1 √ÚÈÛÌÔ› Î·È ÈÛÙÔÚÈÎ‹ ·Ó·‰ÚÔÌ‹

Στην ενότητα αυτή εισάγουµε την έννοια της ποιότητας και παραθέτουµε µερικούς από τους πιο γνωστούς ορισµούς της ποιότητας. Επίσης, περιγράφουµε τις βασικές έννοιες που σχετίζονται µε την ποιότητα και µε τις οποίες θα ασχοληθούµε στα επόµενα κεφάλαια. Τέλος, παραθέτουµε µία σύντοµη ιστορική αναδροµή στην ποιότητα από την αρχαιότητα µέχρι σήµερα. 3.1.1 ¶ÔÈﬁÙËÙ· Î·È ÌÂÙÚ‹ÛÂÈ˜

Η έννοια της ποιότητας ξεκινάει από τα αρχαία χρόνια µε τον Αριστοτέλη (330 π.Χ.), που πρώτος διακρίνει το «ποιόν» και τα χαρακτηριστικά του και συνεχίζεται αργότερα µε τους σχολαστικούς φιλοσόφους. Με τη γενική σηµασία του όρου, ποιότητα είναι κάθε ιδιότητα είτε αυτή ανήκει στην ουσία ενός πράγµατος είτε αποδίδεται επιπρόσθετα σε αυτή. Ο επίσηµος ορισµός της ποιότητας δίνεται στο πρότυπο ISO 8402 (για τα πρότυπα που σχετίζονται µε την ποιότητα θα µιλήσουµε στο κεφάλαιο 6). Αυτός ο ορισµός έχει υιοθετηθεί και από τον Ελληνικό Οργανισµό Τυποποίησης (ΕΛ.Ο.Τ.). Προσέξτε ότι ο ορισµός µιλά τόσο για εκφρασµένες όσο και για συνεπαγόµενες ανάγκες. Θα µιλήσουµε για αυτές αναλυτικά στη συνέχεια. ■ Ποιότητα

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

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

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

3.1 √ƒπ™ª√π ∫∞π π™∆√ƒπ∫∏ ∞¡∞¢ƒ√ª∏

στοιχείων που απαρτίζουν την ποιότητα, καταλαβαίνουµε το είδος της. Η απόδοση ■ Μέτρηση είναι η κάποιου αριθµού σε κάποιο χαρακτηριστικό γίνεται µε τη διαδικασία της µέτρησης. διαδικασία µε την οποία αριθµοί ή Η διασφάλιση ποιότητας είναι συνυφασµένη µε την έννοια των µετρήσεων σύµβολα αντιστοι(measurements). Ο DeMarco τονίζει πως «είναι αδύνατο να ελέγξεις ότι δεν µπορείς χούνται σε ιδιότητες να µετρήσεις» [Dma82]. Πόσο µάλλον αδύνατο είναι να στοχεύεις να διασφαλίσεις οντοτήτων του πραγτην ποιότητα κάποιας οντότητας που δεν µπορείς να µετρήσεις. Αντικείµενο των µατικού κόσµου, έτσι µετρήσεων δεν είναι η µέτρηση των οντοτήτων, αλλά η µέτρηση των ιδιοτήτων οντο- ώστε να τις περιγράτήτων. Για παράδειγµα, δεν µετράµε έναν άνθρωπο αλλά ιδιότητές του που τον χαρα- φουν σύµφωνα µε κτηρίζουν, όπως το ύψος του ή το βάρος του. Με τις µετρήσεις (και ειδικότερα µε καθορισµένους τις µετρήσεις στο λογισµικό) θα ασχοληθούµε στο επόµενο κεφάλαιο. κανόνες. ¢Ú·ÛÙËÚÈﬁÙËÙ· 3.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 ™ÂÏ›‰· 82

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 ™ÂÏ›‰· 83

3.1 √ƒπ™ª√π ∫∞π π™∆√ƒπ∫∏ ∞¡∞¢ƒ√ª∏

■ Εσωτερικός

όν διαθέτει µια αποδεκτή ποιότητα.

περιοδικός έλεγχος είναι η επισκόπηση σε έναν οργανισµό, µε περιοδικότητα και επιµονή και έχοντας ως τελικό σκοπό την εγκαθίδρυση ενός προτύα) Τη διαχείριση ποιότητας (quality management), που έχει σχέση µε την άσκηση που ποιότητας. της ανώτατης διαχείρισης και την ανατροφοδότηση της παραγωγής µε ακρίβεια και εγκυρότητα. ■ Επίβλεψη είναι β) Την τεχνολογία ποιότητας (quality engineering), που έχει σχέση µε την ανάλυ- µια χαλαρή διαδιση των προβληµάτων που σχετίζονται µε την ποιότητα, την επίλυσή τους, την κασία επισκόπησης εκπαίδευση του προσωπικού και την εγκαθίδρυση προγραµµάτων που βελτιώ- που χρησιµοποιεί νουν την ποιότητα. µερικές τεχνικές από τον περιοδικό γ) Την επισκόπηση ποιότητας (quality inspection), που έχει ως βασικούς ρόλους έλεγχο και την πιστοποίηση και επικύρωση της ποιότητας, αλλά και τη συλλογή δεδοµένων µερικές από την για να αναγνωρίσει τη ρίζα των προβληµάτων στην ποιότητα των προϊόντων και επισκόπηση. να καταλήξει σε ένα διορθωτικό µοντέλο. Σε µία µεγάλη επιχείρηση ή βιοµηχανία που έχει εγκαθιδρύσει ένα πρόγραµµα ποιότητας (quality program) –πολλές φορές θα το δείτε και µε τον ισοδύναµο όρο σύστηµα ποιότητας (quality system)– οι τοµείς που ασχολούνται µε την ποιότητα του τελικού προϊόντος είναι αρκετοί και τα άτοµα που έχουν ως στόχο τη διασφάλιση ενός υψηλού ποιοτικού επιπέδου πρέπει να διαθέτουν την κατάλληλη εκπαίδευση, γνώσεις και υπευθυνότητα. Τυπικά, οι ευθύνες για τη διασφάλιση ποιότητας στους τοµείς ενός οργανισµού είναι χωρισµένες σε τρεις βασικές κατηγορίες:

ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏﬁÁËÛË˜ 3.2 Ακολουθούν µερικές προτάσεις. Ποιες από αυτές είναι σωστές και ποιες λάθος; ∆είτε στο τέλος του βιβλίου τις σωστές απαντήσεις και την αιτιολόγηση για κάθε απάντηση. Σωστό

Λάθος

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

❏

ii) Η επισκόπηση είναι η βασική µέθοδος που θα µας εξασφαλίσει ένα ποιοτικό προϊόν.

❏

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

❏

iv) Οι όροι πρόγραµµα ποιότητας και σύστηµα ποιότητας συχνά χρησιµοποιούνται µε την ίδια σηµασία. ❏

❏

■ Το Πρόγραµµα

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

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

K E º A § A I O 3 : ∂ π ™ ∞ ° ø ° ∏ ™ ∆ ∏ ¡ ¶ √ π √ ∆ ∏ ∆∞

v) Η τεχνολογία ποιότητας έχει ως βασικό ρόλο τη συλλογή δεδοµένων για να αναγνωρίσει τη ρίζα των προβληµάτων στην ποιότητα των προϊόντων και να καταλήξει σε ένα διορθωτικό µοντέλο.

❏

3.1.3 πÛÙÔÚÈÎ‹ ·Ó·‰ÚÔÌ‹ ÛÙËÓ ÔÈﬁÙËÙ· Î·È ÛÙÈ˜ ÌÂÙÚ‹ÛÂÈ˜

Σε όλες τις οργανωµένες κοινωνίες κάθε εποχής, από την αρχαιότητα µέχρι σήµερα, όπου υπάρχει υψηλή πολιτισµική στάθµη, αυτή συνοδεύεται πάντα από µία αναπτυγµένη τεχνολογία. Και –το πιο σηµαντικό– η τελευταία λειτουργεί στη βάση ενός µηχανισµού ελέγχου της ποιότητας και προστασίας του καταναλωτή. Χαρακτηριστικά παραδείγµατα µπορεί κανείς να συναντήσει στην αρχαία Βαβυλώνα, όπου ανάµεσα στους νόµους του Hammourabi υπάρχει και ο αρχαιότερος κανονισµός σχετικά µε την οικοδοµή. Σύµφωνα µε αυτόν, αν ένας οικοδόµος κτίσει µία κατοικία για κάποιον, αλλά δεν πραγµατοποιήσει την εργασία του σύµφωνα µε τους ισχύοντες κανονισµούς και πρότυπα µε αποτέλεσµα ένας τοίχος να παρουσιάσει κάποια κλίση, τότε ο οικοδόµος αυτός οφείλει να τον ενισχύσει µε δικά του έξοδα [Bar96]. Η αντιµετώπιση του προβλήµατος της ποιότητας, ο καθορισµός προτύπων και η χρήση µετρήσεων για τη διασφάλιση ποιότητας χρονολογείται αρκετά χρόνια πριν τη σηµερινή εποχή. Στην αρχαία Αίγυπτο είχαν τεθεί οι βασικές αρχές της ποιότητας και υπήρχε τυποποίηση των µετρήσεων βασισµένη στο µήκος του βραχίονα του Φαραώ. Με βάση αυτό το µήκος κατασκευαζόταν ένα «µοναδιαίο ραβδί». Κάθε κατασκευαστής έπρεπε να έχει ένα αντίστοιχο ραβδί που έπρεπε να το συγκρίνει µε το µοναδιαίο κάθε γεµάτο φεγγάρι. Η τήρηση των κανόνων ποιότητας (συµµόρφωση µε το µοναδιαίο ραβδί) ήταν αρκετά σηµαντικό θέµα, αφού σε περίπτωση διαφοράς µήκους ο κατασκευαστής αντιµετώπιζε τη θανατική ποινή [Arn95]. Στην κλασική Ελλάδα υπήρχε ένας µηχανισµός ελέγχου ποιότητας, τυποποίησης και πιστοποίησης των παραγόµενων και προσφερόµενων προϊόντων στον τόπο παραγωγής αλλά και στην αγορά. Οι αρχαίοι Έλληνες εφάρµοζαν πρότυπα µε πολύ αυστηρές προδιαγραφές που κάλυπταν όλο το φάσµα των τότε παραγόµενων προϊόντων, όπως τα µέταλλα και τα κράµατά τους, τα γεωργικά προϊόντα, τα τρόφιµα και τα ποτά, αλλά και τις ίδιες τις κατασκευές, χαρακτηριστικό παράδειγµα των οποίων αποτελεί ο Παρθενώνας, του οποίου ακόµα και σήµερα, µετά από διάστηµα περίπου 2500 χρόνων από την κατασκευή του (κτίστηκε το διάστηµα 447 – 438 π.Χ. και διακοσµήθηκε µεταξύ 438 και 432 π.Χ.), όλοι θαυµάζουµε τη συµµετρία και τη µετρική τελειότητα, αποτέλεσµα της προσήλωσης και της συνέπειας στην τήρηση

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

3 . 2 ¶ √ π √ ∆ ∏ ∆ ∞ ™ ∆ ∏ ¡ ¶ ∞ ƒ ∞ ° ø ° ∏ À § π ∫ ø ¡ ∞ °∞ £ ø ¡

των προδιαγραφών ποιότητας που βασίστηκαν σε µετρήσεις από τους αρχιτέκτονες Ικτίνο και Καλλικράτη. Ακόµα, στην Αθηναϊκή Πολιτεία ορίζονταν µε κλήρο δέκα µετρονόµοι που ευθύνονταν για όλα τα µέτρα και τα σταθµά της αγοράς και όφειλαν να µεριµνούν ώστε οι πωλητές να τα χρησιµοποιούν σωστά. Αλλά και στην αρχαία Ρώµη, η ποιότητα ήταν θέµα ζωής και θανάτου. Μόλις ολοκληρωνόταν η κατασκευή µιας γέφυρας και έπρεπε να αφαιρεθούν τα υποστηρίγµατα, ο αρχιµηχανικός στεκόταν κάτω από τη γέφυρα έτσι ώστε σε περίπτωση που αυτή καταρρεύσει να σκοτωθεί. ∆εν είναι παράξενο λοιπόν ότι αρκετές ρωµαϊκές γέφυρες όχι µόνο διατηρούνται αλλά χρησιµοποιούνται ακόµα και σήµερα. ¢Ú·ÛÙËÚÈﬁÙËÙ· ÁÈ· ÂÚ·ÈÙ¤Úˆ ÌÂÏ¤ÙË 3.1 Από τις πηγές που σας προτείνουµε (βλέπε βιβλιογραφία στο τέλος του κεφαλαίου), αλλά και από δικές σας πηγές, ή και από αναζητήσεις σας στο διαδίκτυο συλλέξτε επιπλέον πληροφορίες για το πώς αντιµετωπιζόταν η ποιότητα σε διάφορες περιόδους της ιστορίας. Με βάση αυτό το υλικό ετοιµάστε µία αναφορά (από 500 έως 2000 λέξεις) που να παρουσιάζει τα ευρήµατά σας. Την αναφορά αυτή µπορείτε να τη συζητήσετε µε τον Καθηγητή – Σύµβουλό σας.

3.2 ¶ÔÈﬁÙËÙ· ÛÙËÓ ¶·Ú·ÁˆÁ‹ ÀÏÈÎÒÓ ∞Á·ıÒÓ

Η διασφάλιση ποιότητας και η χρήση µετρήσεων έδωσε µεγάλη ώθηση στη βιοµηχανία τις τελευταίες δεκαετίες. Για τη µαζική παραγωγή ενός υλικού αγαθού τίθενται λεπτοµερείς και µετρήσιµοι ποιοτικοί στόχοι και τα προϊόντα ελέγχονται ως προς την εκπλήρωση αυτών των στόχων. Σήµερα, είναι αδιανόητη η µαζική παραγωγή ενός υλικού αγαθού χωρίς η διαδικασία παραγωγής να υποστηρίζεται από πρόγραµµα ποιότητας και χωρίς να υπάρχει µέθοδος µέτρησης των ιδιοτήτων του, οι οποίες επιθυµούµε να βρίσκονται µέσα στα όρια που καθορίζονται από το πρόγραµµα ποιότητας. Για παράδειγµα, για τη µαζική παραγωγή µιας βίδας καθορίζονται λεπτοµερώς ιδιότητες της βίδας όπως διαστάσεις, αντοχή σε πίεση, κτλ. καθώς και οι µέγιστες επιτρεπόµενες αποκλίσεις από αυτά τα όρια για να είναι το προϊόν αποδεκτό. Οι βασικές λειτουργίες του προγράµµατος ποιότητας στη µαζική παραγωγή υλικών αγαθών είναι: • ο καθορισµός των χαρακτηριστικών που θα µετρηθούν και των επιθυµητών ορίων,

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

K E º A § A I O 3 : ∂ π ™ ∞ ° ø ° ∏ ™ ∆ ∏ ¡ ¶ √ π √ ∆ ∏ ∆∞

• ο καθορισµός των διαδικασιών µέτρησης, • ο εντοπισµός και η απόρριψη των προϊόντων που δεν πληρούν τις ποιοτικές προδιαγραφές και • η βελτίωση της διαδικασίας παραγωγής, ώστε να ελαχιστοποιηθεί ο αριθµός των προϊόντων που απορρίπτονται. Στη βιοµηχανική παραγωγή υλικών αγαθών χρησιµοποιούνται τεχνικές δειγµατοληψίας και στατιστικές µέθοδοι –όπως για παράδειγµα τα διαγράµµατα ελέγχου (control charts)– ώστε να εντοπίζονται γρήγορα τα προβλήµατα στη διαδικασία παραγωγής που µπορούν να οδηγήσουν σε παραγωγή ποσοτήτων (παρτίδων) προϊόντων χαµηλής ποιότητας, µε βασικό στόχο τον έλεγχο της απόκλισης από τις αρχικές ποιοτικές προδιαγραφές. Η διαδικασία παραγωγής βασίζεται: α) στη δηµιουργία ενός µοντέλου το οποίο πληροί τις ποιοτικές προδιαγραφές και β) στη µαζική παραγωγή προϊόντων που είναι παρόµοια (µέσα στα όρια που καθορίζουν οι ποιοτικές προδιαγραφές) µε το πρωτότυπο. Οι τεχνικές ποιοτικού ελέγχου που χρησιµοποιούνται στην παραγωγή υλικών αγαθών δίνουν µεγάλη έµφαση στο λεγόµενο «µη καταστροφικό έλεγχο», δηλαδή στο να βρεθούν τρόποι να ελεγχθεί η ποιότητα του προϊόντος χωρίς να χρειαστεί να προβούµε σε καταστροφή του δείγµατος που εξετάζουµε. ■ ∆ιαχείριση

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

Στα τµήµατα της ενότητας που ακολουθούν θα µιλήσουµε για τη διαχείριση ολικής ποιότητας, τις απόψεις µερικών από τους πρώτους επιστήµονες που µελέτησαν και έγραψαν για την ποιότητα και για το στατιστικό έλεγχο ποιότητας, θέλοντας να σας δώσουµε το στίγµα για το πώς αντιµετωπίζεται η ποιότητα στη βιοµηχανική παραγωγή αγαθών. Σκοπός µας είναι µέσα από αυτή την παρουσίαση να αναδειχθούν και οι διαφορές µε την ανάπτυξη λογισµικού, για τις οποίες θα µιλήσουµε στην ενότητα 3.3. 3.2.1 ¢È·¯Â›ÚÈÛË ÔÏÈÎ‹˜ ÔÈﬁÙËÙ·˜

Η διαχείριση ολικής ποιότητας (total quality management) έχει γνωρίσει ευρεία αποδοχή στην παραγωγή υλικών αγαθών. Ο ορισµός του ISO 8402 που αναγράφεται δίπλα θεωρεί ως «οργανισµό» κάθε εταιρία, νοµικό πρόσωπο, επιχείρηση ή ίδρυµα που έχει τη δική του λειτουργική ή διοικητική δοµή. Η διαχείριση ολικής ποιότητας, ως τρόπος διοίκησης, µπορεί να απεικονιστεί µε το βρόγχο του σχήµατος 3.1.

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

3 . 2 ¶ √ π √ ∆ ∏ ∆ ∞ ™ ∆ ∏ ¡ ¶ ∞ ƒ ∞ ° ø ° ∏ À § π ∫ ø ¡ ∞ °∞ £ ø ¡

Σχεδίασε

∆ράσε

Πράξε

™¯‹Ì· 3.1 Έλεγξε

Βρόγχος ποιότητας

Τα επιθυµητά αποτελέσµατα, οι στόχοι και οι προδιαγραφές πρέπει να είναι από την αρχή σαφέστατα προσδιορισµένα, οι διαδικασίες να ακολουθούνται προκειµένου να διασφαλίζεται η ικανοποίηση των προδιαγραφών, ενώ τα αποτελέσµατα να παρακολουθούνται µε στόχο να ελέγχεται η συµµόρφωση µε τις προδιαγραφές. Πρόκειται, λοιπόν, για ένα δυναµικό σύστηµα το οποίο πρέπει να έχει ταχύτατη αντίδραση σε αλλαγές, νέες ιδέες και σε προβλήµατα που προκύπτουν, πάντα µε ελεγχόµενο τρόπο και στα πλαίσια µιας ξεκάθαρης µεθοδολογίας. ∆εν θα επεκταθούµε άλλο στη διαχείριση ολικής ποιότητας, αφού υπάρχει και ολόκληρο βιβλίο του Ελληνικού Ανοικτού Πανεπιστηµίου αφιερωµένο σε αυτή. ¢Ú·ÛÙËÚÈﬁÙËÙ· ÁÈ· ÂÚ·ÈÙ¤Úˆ ÌÂÏ¤ÙË 3.2 Από το βιβλίο του Ελληνικού Ανοικτού Πανεπιστηµίου «∆ιασφάλιση Ποιότητας: Ολική Ποιότητα» (βλέπε βιβλιογραφία του κεφαλαίου) αλλά και από όποιες άλλες πηγές επιθυµείτε, ετοιµάστε µία αναφορά για τη διαχείριση ολικής ποιότητας που να παρουσιάζει τον τρόπο εφαρµογής της, τους στόχους και τις διαδικασίες της χωρίς να ξεπεράσετε τις 1500 λέξεις.

3.2.2 √È ÚÒÙÂ˜ ·ﬁ„ÂÈ˜ ÁÈ· ÙËÓ ÔÈﬁÙËÙ·

Από τα τέλη της δεκαετίας του 1970 οι απόψεις ορισµένων από τους πρώτους επιστήµονες που µελέτησαν και έγραψαν για την ποιότητα, όπως ο Juran, ο Deming και ο Crosby, ήταν αυτές που πυροδότησαν την επανάσταση στην παραγωγή υλικών αγαθών και συνετέλεσαν στη δηµιουργία και εφαρµογή κανόνων ποιότητας σε δεκάδες επιχειρήσεις.

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

K E º A § A I O 3 : ∂ π ™ ∞ ° ø ° ∏ ™ ∆ ∏ ¡ ¶ √ π √ ∆ ∏ ∆∞

■ ∆ειγµατοληψία

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

Ο Joseph Juran βάσιζε τη φιλοσοφία ποιότητας στον πελάτη και στο τρίπτυχο: Σχεδιασµός για την ποιότητα, Βελτίωση της ποιότητας και Έλεγχος ποιότητας. Το τρίπτυχο αυτό είναι γνωστό και ως η τριλογία της ποιότητας. Ο Juran δίδαξε κυρίως στην Ιαπωνία και από εκεί οι αρχές του διαδόθηκαν παγκοσµίως. Ο Edward Deming δίδαξε κι αυτός στην Ιαπωνία και έχει γίνει διάσηµος για τα 14 σηµεία (14 οδηγίες για επιτυχία στην ποιότητα), τον κύκλο του Deming (που διδάσκει τον τρόπο λειτουργίας µιας επιχείρησης) και τις θανατηφόρες ασθένειες (που περιγράφουν τι δεν πρέπει να κάνει µία επιχείρηση αν θέλει να πετύχει το πρόγραµµα ποιότητάς της). O Phillip Crosby, που δίδαξε στην Αµερική, βασίζει τη φιλοσοφία του στο ρητό «κανένα ελάττωµα» (zero defects), τονίζοντας ότι η επιχείρηση θα πρέπει να ετοιµάζει το προϊόν σωστά από την πρώτη φορά.

¢Ú·ÛÙËÚÈﬁÙËÙ· ÁÈ· ÂÚ·ÈÙ¤Úˆ ÌÂÏ¤ÙË 3.3 Είτε από τις πρωτότυπες πηγές (τα βιβλία και των τριών πρωτοπόρων υπάρχουν στη βιβλιογραφία), είτε από το βιβλίο του Ελληνικού Ανοικτού Πανεπιστηµίου «∆ιασφάλιση Ποιότητας: Ολική Ποιότητα» (βλέπε βιβλιογραφία του κεφαλαίου), ετοιµάστε µία αναφορά που θα συνοψίζει τις απόψεις κάθε ενός από τους τρεις πρωτοπόρους, χωρίς να ξεπεράσετε τις 500 λέξεις για καθένα από αυτούς. Την αναφορά αυτή µπορείτε να τη συζητήσετε µε τον Καθηγητή – Σύµβουλό σας.

3.2.3 ™Ù·ÙÈÛÙÈÎﬁ˜ ¤ÏÂÁ¯Ô˜ ÔÈﬁÙËÙ·˜ ■ Έλεγχος

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

Ανεξάρτητα από τη φιλοσοφία διαχείρισης ποιότητας, ο στατιστικός έλεγχος ποιότητας (statistical quality control) των παραγόµενων προϊόντων είναι η βασική µέθοδος για τον έλεγχο της ποιότητας στην παραγωγή υλικών αγαθών. Οι βασικές αρχές του στατιστικού ελέγχου ποιότητας είναι η δειγµατοληψία (sampling) και ο έλεγχος της απόκλισης (deviation control). Ο έλεγχος δεν γίνεται σε ολόκληρη την παρτίδα των προϊόντων, αλλά σε ένα µικρό δείγµα. Ο έλεγχος µπορεί να είναι καταστροφικός (δηλαδή το δείγµα καταστρέφεται ως συνέπεια του ελέγχου) ή µη καταστροφικός (το δείγµα µένει ανέπαφο και µπορεί να προωθηθεί στον πελάτη. Στην παραγωγή υλικών αγαθών έµφαση έχει δοθεί στην έρευνα για τη δηµιουργία όλο και περισσότερων µεθόδων µη – καταστροφικού ελέγχου. Κατά τη διάρκεια του ελέγχου αυτού εξετάζεται αν το δείγµα των προϊόντων αποκλίνει ή όχι από τις αρχικές προδιαγραφές (λαµβάνοντας υπόψη κάποια όρια ανοχής).

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

3 . 2 ¶ √ π √ ∆ ∏ ∆ ∞ ™ ∆ ∏ ¡ ¶ ∞ ƒ ∞ ° ø ° ∏ À § π ∫ ø ¡ ∞ °∞ £ ø ¡

Άνω όριο

Mέση τιµή

Kάτω όριο

™¯‹Ì· 3.2

∆ιάγραµµα ελέγχου

∆είγµατα ανά χρονική περίοδο

Τα αποτελέσµατα του στατιστικού ελέγχου αναλύονται µε τη χρήση πληθώρας τεχνικών [Mon91] µε πιο διαδεδοµένη τα διαγράµµατα ελέγχου (control charts). Ένα παράδειγµα διαγράµµατος ελέγχου παρουσιάζεται στο σχήµα 3.2. Στον οριζόντιο άξονα παρουσιάζονται περιοδικές δειγµατοληψίες και στον κατακόρυφο άξονα η µέση τιµή του µετρούµενου χαρακτηριστικού του δείγµατος. Οι δύο οριζόντιες γραµµές πάνω και κάτω απεικονίζουν το ανώτερο και το κατώτερο αποδεκτό όριο, ενώ αυτή στη µέση την επιθυµητή µέση τιµή. Οι κουκίδες είναι η µέση τιµή του δείγµατος και οι διαδοχικές χρονικά δειγµατοληψίες έχουν συνδεθεί µε µία γραµµή µεταξύ τους για να είναι καλύτερα παρουσιάσιµα τα αποτελέσµατα. Ο υπεύθυνος παραγωγής, εξετάζοντας τα αποτελέσµατα του διαγράµµατος ελέγχου, εντοπίζει αν η διαδικασία εξελίσσεται κανονικά ή παρουσιάζει πρόβληµα (όπως λέµε είναι «εκτός ελέγχου») και αποφασίζει αν θα διακόψει την παραγωγή (για επιδιόρθωση των µηχανηµάτων ή της µεθόδου παραγωγής) ή όχι. Τα διαγράµµατα ελέγχου και ο στατιστικός έλεγχος ποιότητας έχουν εφαρµογή και στην ποιότητα λογισµικού (µε διαφορετικό όµως τρόπο προσέγγισης), όπως θα συζητήσουµε στο επόµενο κεφάλαιο. ¢Ú·ÛÙËÚÈﬁÙËÙ· 3.2 Η Μαρία είναι υπεύθυνη ποιότητας σε µία βιοµηχανία που παράγει µεταλλικά φύλλα που θα χρησιµοποιηθούν σε άλλο τµήµα της βιοµηχανίας. Εκτελεί δειγµατοληψία επιλέγοντας 10 φύλλα από κάθε παρτίδα 1.000 φύλλων κάθε 1 ώρα παρα-

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

K E º A § A I O 3 : ∂ π ™ ∞ ° ø ° ∏ ™ ∆ ∏ ¡ ¶ √ π √ ∆ ∏ ∆∞

γωγής. Ελέγχει το πάχος κάθε φύλλου µε επιθυµητή τιµή τα 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. Η διαδικασία θα µπορούσε να θεωρηθεί εντός ελέγχου (αφού όλα τα σηµεία είναι µέσα στα όρια), αλλά οι 9 συνεχόµενες τιµές πάνω από τη µέση τιµή στην πραγµατικότητα την θέτουν εκτός ελέγχου και η Μαρία θα σταµατήσει την παραγωγή για να εντοπίσει τι φταίει. ∆εν θα επεκταθούµε στο πότε µία διαδικασία είναι εντός ή εκτός ελέγχου (το αφήνουµε ως συµπληρωµατική µελέτη) αλλά αυτό το παράδειγµα δείχνει ότι η ικανοποίηση των ορίων δεν είναι η µόνη προϋπόθεση διαδικασίας που εξελίσσεται οµαλά.

2,10

Άνω όριο

2,00

Mέση τιµή

1,90

Kάτω όριο

™¯‹Ì· 3.3

∆ιάγραµµα ελέγχου δραστηριότητας 3.1

∆είγµατα ανά χρονική περίοδο

3.3 π‰È·ÈÙÂÚﬁÙËÙÂ˜ ÛÙËÓ ÔÈﬁÙËÙ· ÏÔÁÈÛÌÈÎÔ‡

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

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

3 . 3 π ¢ π ∞ π ∆ ∂ ƒ √ ∆ ∏ ∆ ∂ ™ ™ ∆ ∏ ¡ ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

ποσότητες ίδιων (φαινοµενικά) προϊόντων, το λογισµικό παράγεται µία φορά. Έτσι, µε εξαίρεση τις διαδικασίες συσκευασίας και συνοδευτικού υλικού (εγχειρίδια, οδηγίες εγκατάστασης, µέσο αποθήκευσης, κτλ), αυτό καθεαυτό το λογισµικό παράγεται µόνο µία φορά και αναπαράγεται σε αντίτυπα που είναι ακριβή αντίγραφα του πρωτοτύπου. Αυτό σηµαίνει ότι, αν και οι στόχοι του προγράµµατος ποιότητας είναι ίδιοι (δηλαδή η διασφάλιση της ποιότητας του τελικού προϊόντος), η εφαρµογή τους διαφέρει. ∆εν είναι το ζητούµενο ο εντοπισµός και η απόρριψη των προϊόντων που αποκλίνουν από τις προδιαγραφές, αλλά η διασφάλιση της ποιότητας ενός και µοναδικού πρωτότυπου του προϊόντος. Με πρώτη µατιά, κάτι τέτοιο µοιάζει πιο εύκολο από το αντίστοιχο πρόβληµα της µαζικής παραγωγής, αφού διασφαλίζοντας την ποιότητα ενός πρωτοτύπου αυτόµατα διασφαλίζεται η ποιότητα για όλα τα υπόλοιπα αντίγραφα. Όµως, αυτό συνεπάγεται ότι κάθε ατέλεια του πρωτοτύπου, αυτόµατα κληροδοτείται σε όλα τα αντίγραφα. Το βασικό πρόβληµα της διασφάλισης ποιότητας λογισµικού είναι η έλλειψη µετρήσιµων στόχων και διαδικασιών µέτρησης. Μπορεί να είναι εύκολο να ζητάµε µια βίδα να έχει διάµετρο κεφαλής 7 χιλιοστά µε απόκλιση ±1%, αλλά πώς µπορούµε να ζητάµε το λογισµικό να έχει «υψηλή συντηρησιµότητα», ή «να είναι επεκτάσιµο», ή «να έχει υψηλή αξιοπιστία». Είναι επίσης εφικτό να µετρήσουµε τις βίδες και να απορρίψουµε αυτές που έχουν διάµετρο κεφαλής έξω από τα επιθυµητά όρια, αλλά δεν είναι εξίσου εφικτό να πραγµατοποιήσουµε κάτι ανάλογο για το λογισµικό. Όπως αναφέρει ο Gustafsson [Sqm93]: «Όταν ένας εργάτης που δουλεύει σε µια γραµµή µαζικής παραγωγής κάνει ένα λάθος, τότε πετάει το εξάρτηµα που έφτιαχνε. Αν το κάνει συχνά, σε λίγο ένας επιστάτης θα θέλει να µάθει γιατί η στοίβα µε τα πεταµένα εξαρτήµατα είναι τόσο µεγάλη. Αυτό το κάνουµε συνέχεια µε το λογισµικό, αλλά κανένας δεν µπορεί να δει τη στοίβα µε τα πεταµένα εξαρτήµατα.» Άλλο πρόβληµα της διασφάλισης ποιότητας λογισµικού είναι ότι η πλειονότητα του λογισµικού έχει αναπτυχθεί ως ολότητα και όχι ως συναρµολόγηση ήδη υπαρχόντων συστατικών (κάτι που είναι συνηθισµένο στην παραγωγή υλικών αγαθών). Τέλος, µια άλλη ιδιαιτερότητα της διασφάλισης ποιότητας λογισµικού είναι ότι συνήθως δεν υπάρχει ιστορικό παρελθόν σηµαντικής διάρκειας στο οποίο να µπορούµε να ανατρέξουµε και να αναζητήσουµε ενδείξεις παραγωγικότητας, έτσι ώστε να µπορούµε να εκτιµήσουµε την αποτελεσµατικότητα νέων εργαλείων, µεθόδων και προτύπων. Ακόµα και επιχειρήσεις που λειτουργούν πολλά χρόνια και έχουν ιστορικά αρχεία, έχουν αλλάξει τόσο πολύ τις µεθόδους ανάπτυξης λογισµικού (λόγω των ραγδαίων εξελίξεων στις τεχνολογίες λογισµικού), ώστε αυτά τα αρχεία να µην είναι

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

K E º A § A I O 3 : ∂ π ™ ∞ ° ø ° ∏ ™ ∆ ∏ ¡ ¶ √ π √ ∆ ∏ ∆∞

απόλυτα αξιοποιήσιµα. Επίσης, το γεγονός ότι το λογισµικό είναι σχετικά νέο προϊόν κάνει πολύ δύσκολη τη σωστή επικοινωνία ανάµεσα στον πελάτη και στο δηµιουργό του λογισµικού. Πολύ συχνά οι πελάτες δε µένουν ικανοποιηµένοι από το αποτέλεσµα, διότι θεωρούν ότι οι απαιτήσεις τους δεν έγιναν αντιληπτές σωστά από τους δηµιουργούς. Πέρα από τα µειονεκτήµατα όµως, βασικό πλεονέκτηµα της διασφάλισης ποιότητας λογισµικού είναι ότι όλοι οι έλεγχοι (ανεξάρτητα από το βαθµό δυσκολίας τους) µπορούν να πραγµατοποιηθούν χωρίς να χρειάζεται να καταστραφεί το προϊόν (λογισµικό). Ο εντοπισµός τεχνικών µη καταστροφικού ελέγχου, που είναι µεγάλο πρόβληµα στην παραγωγή υλικών αγαθών, δεν έχει νόηµα για το λογισµικό. ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏﬁÁËÛË˜ 3.3 Ακολουθούν µερικές προτάσεις. Ποιες από αυτές είναι σωστές και ποιες λάθος; ∆είτε στο τέλος του βιβλίου τις σωστές απαντήσεις και την αιτιολόγηση για κάθε απάντηση. Σωστό

Λάθος

❏

ii) Η διαχείριση ολικής ποιότητας είναι τρόπος διοίκησης και όχι τεχνική παραγωγής. ❏

❏

iii) Η βασική αρχή της φιλοσοφίας του Joseph Juran είναι το ρητό «κανένα ελάττωµα».

❏

iv) Οι βασικές αρχές του στατιστικού ελέγχου ποιότητας είναι η δειγµατοληψία και ο έλεγχος της απόκλισης.

❏

v) Τα αποτελέσµατα του στατιστικού ελέγχου αναλύονται µόνο µε τη χρήση των διαγραµµάτων ελέγχου.

❏

vi) Στην ποιότητα λογισµικού ζητούµενο είναι ο εντοπισµός και η απόρριψη των προϊόντων που αποκλίνουν από τις προδιαγραφές.

❏

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

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

™À¡√æ∏ ∫∂º∞§∞π√À ∫∞π ™Àªµ√À§∂™ ª∂§∂∆∏™

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

❏

™‡ÓÔ„Ë ÎÂÊ·Ï·›Ô˘ Î·È Û˘Ì‚Ô˘Ï¤˜ ÌÂÏ¤ÙË˜ Στο κεφάλαιο αυτό µιλήσαµε για τις βασικές έννοιες και τους ορισµούς της ποιότητας στην παραγωγή υλικών αγαθών και για το στατιστικό έλεγχο της ποιότητας. Μετά από τη µελέτη των ιδιαιτεροτήτων στην ποιότητα λογισµικού σε σχέση µε την ποιότητα στην παραγωγή υλικών αγαθών, είστε προετοιµασµένοι για το επόµενο κεφάλαιο που είναι αφιερωµένο αποκλειστικά στην ποιότητα λογισµικού. Σε αρκετά σηµεία του κεφαλαίου και ειδικότερα στην ενότητα 3.2 (όπου αναφερόµαστε σε έννοιες που υπάρχουν και σε άλλα βιβλία του Ελληνικού Ανοικτού Πανεπιστηµίου), δεν επεκταθήκαµε σε λεπτοµερή παρουσίαση της ποιότητας στην παραγωγή υλικών αγαθών, αφήνοντάς σας να τις µελετήσετε από µόνοι σας. Μην ξεχνάτε τη συµβουλή µας να ανατρέχετε και σε βιβλιογραφικές πηγές πέρα από το βιβλίο αυτό, ώστε να εµπλουτίζετε τις γνώσεις σας, αλλά και να διαβάζετε µε εναλλακτικό τρόπο την ύλη που καλύψαµε. Ακολουθεί βιβλιογραφία µε προτεινόµενα βιβλία για περαιτέρω µελέτη µε σχόλια για το πού να επικεντρώσετε την προσοχή σας.

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

K E º A § A I O 3 : ∂ π ™ ∞ ° ø ° ∏ ™ ∆ ∏ ¡ ¶ √ π √ ∆ ∏ ∆∞

µÈ‚ÏÈÔÁÚ·Ê›· Î·È ÚÔÙ¿ÛÂÈ˜ ÁÈ· ÂÚ·ÈÙ¤Úˆ ÌÂÏ¤ÙË

Ακολουθεί η βιβλιογραφία του κεφαλαίου 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 ™ÂÏ›‰· 95

µ π µ § π √ ° ƒ∞ º π ∞ ∫ ∞ π ¶ ƒ √ ∆∞ ™ ∂ π ™ ° π ∞ ¶ ∂ ƒ∞ π ∆ ∂ ƒ ø ª ∂ § ∂ ∆ ∏

Κάποτε κυκλοφορούσε ένα ανέκδοτο που έλεγε ότι «για να γίνει κανείς «ειδικός» στην ποιότητα χρειάζονται 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 ™ÂÏ›‰· 96

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

∫

∂

¶ÔÈﬁÙËÙ· §ÔÁÈÛÌÈÎÔ‡ ™ÎÔﬁ˜

4 º

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

¶ÚÔÛ‰ÔÎÒÌÂÓ· ·ÔÙÂÏ¤ÛÌ·Ù· Όταν θα έχετε ολοκληρώσει τη µελέτη αυτού του κεφαλαίου, θα µπορείτε να: • αναφέρετε τα πιο γνωστά µοντέλα ποιότητας λογισµικού, • ορίσετε την έννοια των παραγόντων ποιότητας, αλλά και να αναφέρετε και ορίσετε τους βασικότερους παράγοντες ποιότητας λογισµικού, • αναφέρετε τους παράγοντες ποιότητας τους µοντέλου FCM και του µοντέλου του Boehm, • αναφέρετε και να ορίσετε τους παράγοντες ποιότητας του προτύπου ISO 9126 και να περιγράψετε τα χαρακτηριστικά που συνθέτουν κάθε παράγοντα, • περιγράψετε τι περιέχει ένα σύστηµα ποιότητας στο λογισµικό και να ορίσετε τις έννοιες του προτύπου, της οδηγίας και της διαδικασίας, • εξηγήσετε τις διαφορές ανάµεσα στο εγχειρίδιο ποιότητας και στο πλάνο ποιότητας και να περιγράψετε πώς εντάσσονται και τα δύο στο σύστηµα ποιότητας µίας επιχείρησης, • προσδιορίσετε τι θα µπορούσε να περιέχει ένα πρότυπο ή µια διαδικασία ποιότητας για µια συγκεκριµένη φάση ανάπτυξης (τα χαρακτηριστικά της οποίας γνωρίζετε σε βάθος), • αναφέρετε τι προσφέρει το σύστηµα ποιότητας σε κάθε χρήστη του και συνολικά στην επιχείρηση.

ŒÓÓÔÈÂ˜ ÎÏÂÈ‰È¿ • Ποιότητα λογισµικού (Software quality) • Λειτουργικότητα (Functionality)

• Ευχρηστία (Usability) • Συντηρησιµότητα (Maintainability) • Ελεγξιµότητα (Testability)

∞

√

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

K E º A § A I O 4 : ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

• Επαναχρησιµοποιησιµότητα (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)

∂ÈÛ·ÁˆÁÈÎ¤˜ ·Ú·ÙËÚ‹ÛÂÈ˜ Στο προηγούµενο κεφάλαιο µιλήσαµε για την ποιότητα στην παραγωγή υλικών αγαθών και τους τρόπους µε τους οποίους προσεγγίζεται η ποιότητα. Μιλήσαµε επίσης για τις ιδιαιτερότητες της ανάπτυξης λογισµικού και γιατί αρκετοί από τους τρόπους προσέγγισης της ποιότητας στην παραγωγή υλικών αγαθών δεν µπορούν να εφαρµοστούν στην ποιότητα λογισµικού. Σε αυτό το κεφάλαιο περιγράφουµε τις προσεγγίσεις στην ποιότητα λογισµικού, τα ποιοτικά χαρακτηριστικά του λογισµικού και το σύστηµα ποιότητας στην ανάπτυξη λογισµικού. Ειδικότερα, στην ενότητα 4.1 µε τίτλο ποιοτικά χαρακτηριστικά λογισµικού, εισάγουµε τις έννοιες των παραγόντων ποιότητας και των ποιοτικών χαρακτηριστικών και παρουσιάζουµε τα πιο διαδεδοµένα µοντέλα ποιότητας λογισµικού, µε έµφαση στο πρότυπο ISO 9126. Στην ενότητα 4.2 µε τίτλο σύστηµα ποιότητας λογισµικού, παρουσιάζουµε το σύστηµα ποιότητας επεξηγώντας τις διαφορές ανάµεσα στο εγχειρίδιο και στο πλάνο ποιότητας, αναλύουµε τους χρήστες του συστήµατος ποιότητας και τα οφέλη από αυτό. Για τα περισσότερα σηµεία που καλύπτουµε στο κεφάλαιο αυτό σας παραθέτουµε σχολιασµένη βιβλιογραφία για συµπληρωµατική µελέτη στο τέλος του κεφαλαίου, όπου µπορείτε να βρείτε και πληροφορίες για πρόσθετες πηγές.

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

4 . 1 ¶ √ π √ ∆ π ∫ ∞ Ã ∞ ƒ∞ ∫ ∆ ∏ ƒ π ™ ∆ π ∫ ∞ § √ ° π ™ ª π ∫ √ À

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 ¶·Ú¿ÁÔÓÙÂ˜ ÔÈﬁÙËÙ·˜

Υπάρχουν πολλές προσεγγίσεις στην έννοια της ποιότητας. Ο Garvin [Gar84] ορίζει την ποιότητα ως µια πολύπλοκη και πολυπρόσωπη έννοια που µπορεί να περιγραφεί µε πέντε διαφορετικές θεωρήσεις: • Εµπειρική θεώρηση (transcendental view): Θεωρεί ότι η ποιότητα είναι κάτι που µπορεί να αναγνωριστεί εµπειρικά, αλλά όχι να οριστεί ούτε να επιτευχθεί πλήρως. • Θεώρηση από την πλευρά του χρήστη (user view): Αντιµετωπίζει την ποιότητα ως καταλληλότητα για χρήση. • Κατασκευαστική θεώρηση (manufacturing view): Αντιµετωπίζει την ποιότητα ως ικανοποίηση των κατασκευαστικών προδιαγραφών του χρήστη. • Θεώρηση προϊόντος (product view): Θεωρεί ότι η ποιότητα ταυτίζεται µε τα ενδογενή (εσωτερικά) χαρακτηριστικά του προϊόντος.

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

100

K E º A § A I O 4 : ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

• Θεώρηση βάσει της αξίας (value – based view): Θεωρεί ότι η ποιότητα εξαρτάται από το ποσό που διατίθεται να πληρώσει ο χρήστης για το προϊόν. ■ Λειτουργικότητα

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

■ Ευχρηστία ενός

συστήµατος είναι η ικανότητά του να λειτουργεί αποτελεσµατικά και αποδοτικά ενώ παρέχει υποκειµενική ικανοποίηση στους χρήστες του. Πρότυπο ISO 9241.

Ανάλογα µε τη θεώρηση της ποιότητας, προκύπτουν και αντίστοιχοι παράγοντες ποιότητας που συνεισφέρουν σε αυτό που αφηρηµένα καλούµε «ποιότητα του προϊόντος». Αυτοί οι παράγοντες µπορεί να διαφέρουν για την επιχείρηση που αναπτύσσει το λογισµικό (θεώρηση του κατασκευαστή) σε σχέση µε αυτούς που ενδιαφέρουν τους τελικούς χρήστες. Ακόµα, µπορεί να βασίζονται σε πολιτισµικές ή κοινωνικές αντιλήψεις για την ποιότητα. Οι τελικοί χρήστες ενδιαφέρονται κυρίως για παράγοντες όπως η λειτουργικότητα (functionality) και η ευχρηστία (usability). Ακριβώς επειδή στον ορισµό της λειτουργικότητας µιλάµε και για «συνεπαγόµενες ανάγκες», είναι σαφές ότι ο παράγοντας αυτός σχετίζεται και µε τις κοινωνικές αντιλήψεις για την ποιότητα. Επίσης, για τους τελικούς χρήστες είναι σηµαντικό, πέρα από τις λειτουργίες που επιτελεί το λογισµικό, η χρήση του να είναι εύκολη και κατανοητή από αυτούς. Αναφορικά µε την οµάδα υλοποίησης, το ενδιαφέρον εντοπίζεται σε παράγοντες ποιότητας όπως η συντηρησιµότητα (maintainability), η ελεγξιµότητα (testability), η επαναχρησιµοποιησιµότητα (reusability) και η µεταφερσιµότητα (portability). Η οµάδα ανάπτυξης ενδιαφέρεται να µπορεί εύκολα να υλοποιεί αλλαγές στο λογισµικό. Για να µπορεί η οµάδα ανάπτυξης να υλοποιεί αλλαγές, χρειάζεται να µπορεί να ελέγχει το λογισµικό για λάθη και παραλείψεις, αλλά και να µπορεί να επαναχρησιµοποιεί τµήµατα του λογισµικού που αναπτύχθηκε για ένα έργο σε κάποιο άλλο έργο. Τέλος, η οµάδα ανάπτυξης επιθυµεί να µπορεί να µεταφέρει το λογισµικό που αναπτύχθηκε για ένα έργο εύκολα σε διαφορετικές πλατφόρµες υλικού ή λειτουργικών συστηµάτων. Για την κοινωνία, όπως εύκολα µπορούµε να παρατηρήσουµε, δε νοείται το λογισµικό να µην είναι αξιόπιστο και αποτελεσµατικό. Αυτοί οι παράγοντες ποιότητας, δηλαδή η αξιοπιστία (reliability) και η αποδοτικότητα (efficiency) είναι και αυτοί που συνήθως υπονοούνται στις προδιαγραφές των µικρών έργων. Φυσικά σε εξειδικευµένα έργα όπου η αξιοπιστία ή η αποδοτικότητα είναι καθοριστικοί παράγοντες, τότε αυτοί παύουν να αφορούν κοινωνικές αντιλήψεις και µεταφέρονται στις απαιτήσεις του χρήστη. Για παράδειγµα σε µία εφαρµογή πραγµατικού χρόνου, η αξιοπιστία και η αποδοτικότητα θα αντιµετωπιστούν τελείως διαφορετικά από µία εφαρµογή αυτοµατισµού γραφείου.

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

4 . 1 ¶ √ π √ ∆ π ∫ ∞ Ã ∞ ƒ∞ ∫ ∆ ∏ ƒ π ™ ∆ π ∫ ∞ § √ ° π ™ ª π ∫ √ À

101

ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏﬁÁËÛË˜ 4.1 Συµπληρώστε τις παρακάτω προτάσεις επιλέγοντας µία από τις προτεινόµενες λέξεις που ακολουθούν: α) Παράγοντες ποιότητας είναι οµάδες ………………… τα οποία συνθέτουν την ποιότητα ενός προϊόντος, έχουν την ελάχιστη δυνατή ……………… µεταξύ τους και είναι επαρκή για τη σύνθεση της ποιότητας. (δεδοµένων, χαρακτηριστικών) (επικάλυψη, σχέση) β) Η θεώρηση της ποιότητας από την πλευρά του χρήστη αντιµετωπίζει την ποιότητα ως …………………… για χρήση. (αδυναµία, συµβατότητα, καταλληλότητα, αυτοµατοποίηση) γ) Αξιοπιστία είναι ένα σύνολο χαρακτηριστικών που είναι φορείς της δυνατότητας του λογισµικού να διατηρεί το ……………… απόδοσής του σε ………………… συνθήκες και για προκαθορισµένη χρονική περίοδο. (επίπεδο, πρότυπο, υλικό, λογισµικό) (καθορισµένες, µεταβαλλόµενες, σχετικές)

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 και για τους υπόλοιπους θα σας παραπέµψουµε στη βιβλιογραφία στο τέλος του κεφαλαίου.

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

■ Ελεγξιµότητα

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

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

K E º A § A I O 4 : ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

102

■ Επαναχρησι-

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

Το µοντέλο αυτό αποτέλεσε ένα από τα πιο ολοκληρωµένα µοντέλα της εποχής του και έγινε η βάση για το διεθνές πρότυπο ISO 9126 [Iso91]. Παρά τα προβλήµατα της υποκειµενικότητας των ερωτήσεων, της ύπαρξης περιορισµένης κλίµακας (το µοντέλο δεχόταν µόνο απαντήσεις «ΝΑΙ» και «ΟΧΙ») και της αδυναµίας συνδυασµού µετρικών, το µοντέλο αυτό γνώρισε ευρεία αποδοχή και ακόµα και σήµερα, που το ISO 9126 κυριαρχεί, αρκετές επιχειρήσεις βασίζουν το σύστηµα ποιότητάς τους στην τµηΠαράγοντες

Kριτήρια

Mετρικές

Operability Training Eυχριστία

Communicattiveness I/O Volume

Aκεραιότητα

I/O rate Access control

Aποδοτικότητα ■ Μεταφερσιµότητα

Storage efficiency Oρθότητα

Execution efficiency Traceability

Aξιοπιστία

Completeness Accuracy

Συντηρησιµότητα

Error tolerance Concistrency

Eλεγξιµότητα

Simplicity Conciseness

Eυελιξία Eπαναχρησιµοποι- ησιµότητα

Instrumentation Expandability Generality Self–descriptiveness

Mεταφερσιµότητα

Modularity Machine independence

∆ιαλειτουργικότητα

™¯‹Ì· 4.1

Μοντέλο FCM

S/W system independence Comms commonality Data commonality

Metrics

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

Access audit

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

4 . 1 ¶ √ π √ ∆ π ∫ ∞ Ã ∞ ƒ∞ ∫ ∆ ∏ ƒ π ™ ∆ π ∫ ∞ § √ ° π ™ ª π ∫ √ À

103

µατοποίηση του FCM µοντέλου. Ο βασικότερος λόγος για αυτό είναι ότι είναι καλύτερα προσαρµοσµένο στην οµάδα υλοποίησης και πιο αναλυτικό από το ISO 9126. ¢Ú·ÛÙËÚÈﬁÙËÙ· ÁÈ· ÂÚ·ÈÙ¤Úˆ ÌÂÏ¤ÙË 4.1 Είτε από την προτεινόµενη βιβλιογραφία [Fen97], [Inc95], [Kit96], είτε από πηγές στο διαδίκτυο, βρείτε πληροφορίες για το FCM µοντέλο και περιγράψτε και τους 11 παράγοντες ποιότητας (πώς ορίζεται καθένας, τι σηµαίνει πρακτικά για µία επιχείρηση και πώς µπορεί να αναλυθεί;).

4.1.3 ∆Ô ÌÔÓÙ¤ÏÔ ÙÔ˘ Boehm

To µοντέλο του Boehm [Boe78] ακολουθεί παρόµοια ιεραρχική δοµή µε αυτή του FCM µοντέλου, σύµφωνα µε την οποία διασπά την ποιότητα του λογισµικού σε πρωταρχικές χρήσεις (primary uses) και αυτές σε ενδιάµεσες κατασκευές (intermediate constructs), ανάλογες µε τα κριτήρια ποιότητας του προηγούµενου µοντέλου, όπως φαίνεται και στο σχήµα 4.2. Οι ενδιάµεσες κατασκευές µε τη σειρά τους διασπώνται σε πρωτογενείς κατασκευές (primitive constructs) οι όποιες µετρώνται άµεσα µε µετρικές (metrics). Πρωταρχικές χρήσεις

Eνδιάµεσες κατασκευές

■ Αξιοπιστία είναι

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

Πρωτογενείς κατασκευές Device independence

Portability Reliability Πρακτικότητα ως είναι

Accuracy Consistency

Efficiency Human engineening

Device efficiency Accessibility Comunicativeness

Testability Συντηρησι- µότητα

Understandability

Metrics

Γενική πρακτικότητα

Completeness

Structuredness Self descriptiveness Conciseness

Modifiability

Legibility Augmentability ™¯‹Ì· 4.2

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

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

K E º A § A I O 4 : ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

104

■ Αποδοτικότητα

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

Όµως, ήταν το πρώτο µοντέλο που εισήγαγε την πρακτική της χρήσης µετρικών λογισµικού αντί για ερωτήσεις στο κατώτερο επίπεδο. Αυτή η πρακτική εφαρµόστηκε µε σχετική επιτυχία για τη µέτρηση των ποιοτικών χαρακτηριστικών, άσχετα αν το γενικό µοντέλο είναι το FCM, του Boehm, ή το ISO 9126. 4.1.4 ∆Ô ÚﬁÙ˘Ô 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 ™ÂÏ›‰· 105

4 . 1 ¶ √ π √ ∆ π ∫ ∞ Ã ∞ ƒ∞ ∫ ∆ ∏ ƒ π ™ ∆ π ∫ ∞ § √ ° π ™ ª π ∫ √ À

105

Kαταλληλότητα (Suitability) Λειτουργικότητα (Functionality)

Aκρίβεια (Accuracy) ∆ιαλειτουργοκότητα (Interoperability) Aσφάλεια (Security)

Ωριµότητα (Maturity) Aξιοπιστία (Reliability)

Aνεκτικότητα σε λάθη (Fault tolerance) Aνακτησιµότητα (Recoverability)

Kατανοησηµότητα (Understandability) Eυχριστία (Usability)

Eυκολία εκµάθηση (Learnability) Eυκολία χειρισµού (Operability)

Aποδοτικότητα (Efficiency)

Xρονική συµπεριφορά (Time behavior) Aξιοποίηση πόρων (Resource behavior)

Aναλυσιµότητα (Analyzability) Συντηρησιµότητα (Maintainability)

Tροποποιησηµότητα (Changeability) Σταθερότητα (Stability) Eλεγξιµότητα (Testability)

Προσαρµοστικότητα (Adaptability) Mεταφερσιµότητα (Portability)

Eυκολία εγκατάστασης (Installability) ∆υνατότητα συνύπρξης (Conformance) Aντικαταστασιµότητα (Replaceability)

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

™¯‹Ì· 4.3

Το πρότυπο ISO 9126

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

106

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 ™ÂÏ›‰· 107

4 . 1 ¶ √ π √ ∆ π ∫ ∞ Ã ∞ ƒ∞ ∫ ∆ ∏ ƒ π ™ ∆ π ∫ ∞ § √ ° π ™ ª π ∫ √ À

107

ανεπάρκειας, ή των βλαβών ή λαθών στο λογισµικό, ή στα τµήµατα που έχουν τροποποιηθεί. • Τροποποιησιµότητα (changeability) που είναι η ευκολία υλοποίησης αλλαγών και τροποποίησης του λογισµικού. • Σταθερότητα (stability) που είναι η δυνατότητα ελαχιστοποίησης ανεπιθύµητων αποτελεσµάτων που οφείλονται στις τροποποιήσεις του λογισµικού. • Ελεγξιµότητα (testability) που είναι η δυνατότητα ελέγχου της αξιοπιστίας του λογισµικού που έχει τροποποιηθεί, ή πρόκειται να τροποποιηθεί. Και τέλος, η µεταφερσιµότητα που, όπως είπαµε, σχετίζεται µε τη δυνατότητα του λογισµικού να µπορεί να µεταφερθεί από ένα περιβάλλον σε άλλο. • Προσαρµοστικότητα (adaptability) που είναι η δυνατότητα του λογισµικού να µπορεί να τροποποιηθεί, ώστε να εκτελεστεί σε διαφορετικά λειτουργικά περιβάλλοντα χωρίς να απαιτεί διαφορετικές πρακτικές χρήσης. • Ευκολία εγκατάστασης (installability) που είναι η δυνατότητα εγκατάστασης σε κάποιο περιβάλλον. • ∆υνατότητα συνύπαρξης (conformance) που αφορά τη δυνατότητα συνύπαρξής του ως ανεξάρτητου λογισµικού σε περιβάλλον κοινό µε άλλες εφαρµογές. • Αντικαταστασιµότητα (replaceability) που είναι η δυνατότητα του λογισµικού να µπορεί να χρησιµοποιηθεί στο περιβάλλον ενός άλλου λογισµικού (αντικαθιστώντας κάποιο τµήµα του). ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏﬁÁËÛË˜ 4.2 ∆ίνεται µία λίστα µε παράγοντες ποιότητας. Επιλέξτε ποιοι από αυτούς αποτελούν παράγοντες ποιότητας σύµφωνα µε το FCM µοντέλο, ποιοι µε το µοντέλο του Boehm και ποιοι µε το ISO 9126, βάζοντας ένα στην αντίστοιχη στήλη δίπλα σε κάθε έναν. Προσέξτε ότι κάποιοι µπορεί να µην αποτελούν παράγοντες σε κανένα µοντέλο, ενώ κάποιοι άλλοι να αποτελούν και στα τρία µοντέλα. Παράγοντας ποιότητας

FCM

Boehm

ISO 9126

ακεραιότητα

❏

αξιοπιστία

❏

αποδοτικότητα

❏

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

K E º A § A I O 4 : ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

108

■ Πρότυπο είναι

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

ασφάλεια

❏

ελεγξιµότητα

❏

διαλειτουργικότητα

❏

επαναχρησιµοποιησιµότητα

❏

ευελιξία

❏

ευχρηστία

❏

κατανοησιµότητα

❏

λειτουργικότητα

❏

µεταφερσιµότητα

❏

ορθότητα

❏

προσαρµοστικότητα

❏

συντηρησιµότητα

❏

ωριµότητα

❏

4.2 ™‡ÛÙËÌ· ¶ÔÈﬁÙËÙ·˜ §ÔÁÈÛÌÈÎÔ‡

Σε αυτή την ενότητα θα παρουσιάσουµε το σύστηµα ποιότητας (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 ™ÂÏ›‰· 109

4 . 2 ™ À ™ ∆ ∏ ª ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

109

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

■ Οδηγία είναι

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

Στην ενότητα 4.2.1 που ακολουθεί γίνεται η παρουσίαση του συστήµατος ποιότητας και των λειτουργιών που επιτελεί. Στην ενότητα 4.2.2 αναφερόµαστε στους χρήστες αυτού του συστήµατος και στο τι παρέχει σε αυτούς, ενώ στην ενότητα 4.2.3 παρουσιάζονται τα οφέλη που αποφέρει (µεσοµακροπρόθεσµα) στην επιχείρηση ένα σύστηµα ποιότητας. Πρότυπο (π.χ. ISO 9001)

■ ∆ιαδικασία ενός

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

Σύστηµα διασφάλισης ποιότητας Eγχειρίδιο ποιότητας Mετρικές και διαδικασίες ποιότητας

1ο Έργο

2ο Έργο

N–οστό Έργο

™¯‹Ì· 4.4

1ο πλάνο ποιότητας

2ο πλάνο ποιότητας

N–οστό πλάνο ποιότητας

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

4.2.1 ∂Ê·ÚÌÔÁ‹ ÙÔ˘ Û˘ÛÙ‹Ì·ÙÔ˜ ÔÈﬁÙËÙ·˜

Ένα πλήρες σύστηµα ποιότητας έχει τρεις βασικούς στόχους: τη διασφάλιση ποιότητας διαδικασιών παραγωγής, τη διασφάλιση ποιότητας πόρων και τη διασφάλιση ποιότητας προϊόντων. Η διασφάλιση ποιότητας διαδικασιών παραγωγής (process quality assurance) έχει ως αντικείµενο τη συνεχή βελτιστοποίηση, βάσει των προ-

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

110

■ Το εγχειρίδιο

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

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 ™ÂÏ›‰· 111

4 . 2 ™ À ™ ∆ ∏ ª ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

ποιότητας. Το πλάνο ποιότητας είναι ειδικό για κάθε έργο και επικεντρώνεται στα ποιοτικά χαρακτηριστικά στα οποία δίνει έµφαση το έργο. Για παράδειγµα, στο πλάνο ποιότητας ενός έργου, το οποίο η επιχείρηση σκοπεύει να εξελίξει µελλοντικά και να εκδώσει και σε άλλες πλατφόρµες (λειτουργικών συστηµάτων ή υλικού) θα δοθεί έµφαση στα ποιοτικά χαρακτηριστικά της «µεταφερσιµότητας» και της «συντηρησιµότητας». Αντίθετα, στο πλάνο εξασφάλισης ποιότητας ενός έργου, το οποίο υλοποιείται για την προσωρινή κάλυψη αναγκών του πελάτη και χωρίς να υπάρχουν µελλοντικοί στόχοι µεταφοράς και συντήρησης, δε θα δοθεί τόση έµφαση σε ποιοτικούς παράγοντες όπως η «µεταφερσιµότητα» και η «συντηρησιµότητα», µπορεί όµως να δοθεί έµφαση σε παράγοντες όπως για παράδειγµα η «ευχρηστία». Σε κάθε περίπτωση και τα δύο πλάνα εξασφάλισης ποιότητας θα πρέπει να περιέχουν έναν αριθµό ποιοτικών χαρακτηριστικών, τα οποία θα απαιτείται από το πρόγραµµα ποιότητας να ελέγχονται για κάθε έργο. Τέλος, το εγχειρίδιο ποιότητας δεν πρέπει να µένει στάσιµο, αλλά να εξελίσσεται µαζί µε την επιχείρηση. Αυτό συµβαίνει, είτε γιατί τα ποιοτικά κριτήρια της επιχείρησης γίνονται πιο αυστηρά, καθώς βελτιώνονται οι διαδικασίες παραγωγής µέτρησης και ελέγχου, είτε γιατί αναθεωρούνται οι µετρικές και οι µετρήσιµοι στόχοι ανάλογα µε τις απόψεις των πελατών. Άµεση αρµοδιότητα του τµήµατος ποιότητας (και φυσικά του υπευθύνου ποιότητας) είναι να ελέγχει αν οι µετρήσεις για τα ποιοτικά χαρακτηριστικά αντικατοπτρίζονται στην άποψη των πελατών για τα ίδια ποιοτικά χαρακτηριστικά. Στην περίπτωση διαφορών πιθανότατα το σύστηµα ποιότητας χρειάζεται αλλαγές οι οποίες σχετίζονται είτε µε την αξιοπιστία των µετρικών, είτε µε τις διαδικασίες µέτρησης. Είναι σηµαντικό σε αυτό το σηµείο να αναφέρουµε ότι κυριαρχούν δυο βασικές εσφαλµένες απόψεις σχετικές µε το σύστηµα ποιότητας στο λογισµικό, οι οποίες πρέπει να ξεπεραστούν. Η πρώτη εσφαλµένη άποψη θεωρεί πως ένα εγχειρίδιο ποιότητας είναι αρκετό για να διασφαλίσει την ποιότητα σε κάθε έργο. Το πρόβληµα µε αυτή την άποψη έγκειται στο γεγονός ότι κανείς δεν υποχρεώνει τους υπεύθυνους ενός έργου να τηρήσουν τους κανόνες του εγχειριδίου, είτε γιατί το τµήµα ποιότητας δεν λειτουργεί σωστά, ελέγχοντας την εφαρµογή των διαδικασιών, είτε γιατί οι επισηµάνσεις του αγνοούνται κάτω από την πίεση για την τήρηση των προθεσµιών των έργων.

111

■ Υπεύθυνος

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

■ Το πλάνο

ποιότητας είναι συγκεκριµένο για κάθε έργο και είναι το υποσύνολο του εγχειριδίου ποιότητας που έχει κριθεί ότι εξυπηρετεί τους στόχους ποιότητας Η δεύτερη εσφαλµένη άποψη θεωρεί ότι για να είναι ένα λογισµικό ποιοτικό, αρκεί του συγκεκριµένου να ικανοποιεί τον ορισµό της ποιότητας «κατάλληλο για τον προορισµό του». Το λογιέργου. σµικό όµως, δεν αρκεί µόνο να είναι κατάλληλο για το σκοπό του. Πρέπει να διαθέτει και κάποια, επιπλέον, ποιοτικά χαρακτηριστικά, τα οποία µπορεί να περιγράφο-

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

K E º A § A I O 4 : ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

112

νται στον προσδιορισµό των απαιτήσεων, να βασίζονται σε κοινωνικές παραδοχές ή να σχετίζονται µε τους στόχους της επιχείρησης. Ο προσδιορισµός των απαιτήσεων περιέχει µια περιγραφή του τι µπορεί να κάνει το λογισµικό, καθώς επίσης και περιορισµούς, όπως ο χρόνος απόκρισης, που πρέπει να συµπεριληφθούν στο πλάνο ποιότητας. Ωστόσο, και άλλοι παράγοντες που οι προγραµµατιστές θεωρούν σηµαντικούς και που δεν έχουν απασχολήσει τους πελάτες και δεν αναγράφονται στον προσδιορισµό των απαιτήσεων (για παράδειγµα η ικανότητα του λογισµικού να επαναχρησιµοποιηθεί) πρέπει και αυτοί να συµπεριληφθούν στο πλάνο ποιότητας. ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏﬁÁËÛË˜ 4.3 Ακολουθούν µερικές προτάσεις. Ποιες από αυτές είναι σωστές και ποιες λάθος; ∆είτε στο τέλος του βιβλίου τις σωστές απαντήσεις και την αιτιολόγηση για κάθε απάντηση. Σωστό

Λάθος

Τα πρότυπα κωδικοποιούνται µε τα αρχικά ISO ακολουθούµενα από ένα αριθµό.

❏

ii) Οδηγία είναι περιγραφικό κείµενο που επεξηγεί την εφαρµογή ενός προτύπου.

❏

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

❏

iv) Η διασφάλιση ποιότητας προϊόντος στοχεύει έµµεσα στη διασφάλιση ποιότητας διαδικασιών και πόρων.

❏

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

❏

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

❏

vii) Ένα εγχειρίδιο ποιότητας είναι αρκετό για να διασφαλίσει την ποιότητα σε κάθε έργο. ❏

❏

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

4 . 2 ™ À ™ ∆ ∏ ª ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

4.2.2 ÃÚ‹ÛÙÂ˜ ÙÔ˘ Û˘ÛÙ‹Ì·ÙÔ˜ ÔÈﬁÙËÙ·˜

Στην ενότητα 1.3 του κεφαλαίου 1 µιλήσαµε για τους ανθρώπους που σχετίζονται µε την ανάπτυξη λογισµικού. Σε αυτή την ενότητα παρουσιάζεται τι προσφέρει [Inc95] το σύστηµα ποιότητας στον υπεύθυνο έργου, στους προγραµµατιστές, στους µηχανικούς που έχουν αναλάβει τη σχεδίαση, τον έλεγχο ή τη συντήρηση του λογισµικού, στον αναλυτή, καθώς και στον πελάτη. Το σύστηµα ποιότητας πρέπει να διευκολύνει τον υπεύθυνο έργου στη διαδικασία της εκτίµησης παραγόντων όπως οι ανάγκες σε ανθρώπινο δυναµικό, το κόστος και ο χρόνος και ανάλυσης κινδύνου. Θα πρέπει να διαθέτει έναν κατάλογο που να αναφέρει τους παράγοντες εκείνους που θα µπορούσαν να κάνουν το πρόγραµµα να αποτύχει ως προς τα χρονικά περιθώρια ή τον προϋπολογισµό του. Θα πρέπει, επίσης, να καθορίζει τη διαδικασία καταγραφής των δεδοµένων του έργου µε τυποποιηµένη µορφή, έτσι ώστε τα ιστορικά δεδοµένα από προηγούµενα έργα να υπάρχουν καταγεγραµµένα σε εύκολα επεξεργάσιµη τυποποιηµένη µορφή, ώστε ο διαχειριστής ποιότητας να µπορεί να βασίζει την εκτίµησή του για µελλοντικά έργα σε αυτά τα δεδοµένα. Ακόµα, το εγχειρίδιο ποιότητας θα πρέπει να προδιαγράφει έναν τρόπο, ώστε να συλλέγονται και να αναλύονται στατιστικά δεδοµένα που αφορούν σε λάθη ή ατέλειες και τη σοβαρότητά τους για το λογισµικό. Επίσης, το σύστηµα ποιότητας θα πρέπει να προσδιορίζει έναν οµοιόµορφο τρόπο µε τον οποίο το προσωπικό θα υποβάλλει αναφορά για τις δραστηριότητές του, διευκολύνοντας την παρακολούθηση του έργου. Τέλος, το σύστηµα ποιότητας πρέπει να προδιαγράφει την υποβολή αναφορών σχετικά µε τους στόχους που επιτεύχθηκαν έναντι των στόχων που τέθηκαν στην αρχή του έργου, για κάθε ένα από τα έργα. Αναφορικά µε τον προγραµµατιστή, το σύστηµα ποιότητας πρέπει να θέτει πρότυπα προγραµµατισµού που ορίζουν τον τρόπο µε τον οποίο ένα πρόγραµµα πρέπει να αναπτυχθεί (κωδικοποιηθεί) και να παρουσιαστεί. Ένα καλό πρότυπο ποιότητας θα πρέπει (µε την τυποποίηση που θα επιφέρει) να βοηθά τον προγραµµατιστή να διαβάζει πηγαίο κώδικα και να κατανοεί εύκολα τη συνεισφορά κάθε κοµµατιού του πηγαίου κώδικα στο γενικό, µεγάλο τµήµα του λογισµικού που εξετάζεται. Ακόµα, το εγχειρίδιο ποιότητας πρέπει να εµπεριέχει οδηγίες προς τον προγραµµατιστή για το πώς να αποθηκεύει τα δεδοµένα ελέγχου. Τέλος, το εγχειρίδιο ποιότητας πρέπει να παρέχει στον προγραµµατιστή ένα πρότυπο που να διασφαλίζει ότι τα ονόµατα και οι µεταβλητές που έχει χρησιµοποιήσει συµφωνούν µε τα αρχεία που χρησιµοποιήθηκαν για να αποθηκεύσουν τον πηγαίο κώδικα, το αντικείµενο του κώδικα και τα δεδοµένα ελέγχου.

113

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

114

K E º A § A I O 4 : ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

Το σύστηµα ποιότητας πρέπει να παρέχει ένα πρότυπο που να καθορίζει τον τρόπο περιγραφής της αρχιτεκτονικής του συστήµατος από το σχεδιαστή. Επίσης το εγχειρίδιο ποιότητας πρέπει να εµπεριέχει τυποποιηµένες διαδικασίες ανάλυσης και σχεδίασης. Ένα καλό πρότυπο πρέπει να βοηθά το µηχανικό σχεδίασης να ελέγχει αν το σύστηµα που έχει σχεδιάσει πραγµατικά υλοποιεί τις λειτουργίες που περιγράφονται στον προσδιορισµό των απαιτήσεων. Ιδιαίτερη έµφαση πρέπει να δίνεται στο σχεδιασµό της διεπιφάνειας χρήστη [Abo00], παρέχοντας κανόνες και οδηγίες για την ορθή σχεδίαση που θα είναι προσαρµοσµένη στις ανάγκες και ιδιαιτερότητες των χρηστών του συγκεκριµένου έργου. Το σύστηµα ποιότητας πρέπει να επιµένει σε ένα προγραµµατιστικό πρότυπο το οποίο εξασφαλίζει ότι οι µηχανικοί που θα αναλάβουν τη συντήρηση θα µπορούν εύκολα να ανιχνεύσουν ποια λειτουργία εκτελείται κάθε φορά από συγκεκριµένο τµήµα κώδικα. Ακόµα, πρέπει να παρέχει διαδικασίες που βοηθούν τους µηχανικούς συντήρησης να εντοπίζουν και να εποπτεύουν τις διάφορες εκδόσεις του συστήµατος που δηµιουργούνται κατά τη διαδικασία της συντήρησης. Τέλος, το σύστηµα ποιότητας πρέπει να εξασφαλίζει (παρέχοντας διαδικασίες) ότι οι µηχανικοί του τµήµατος ελέγχου αποθηκεύουν εξωτερικά τα δεδοµένα που έχουν προκύψει κατά τη διάρκεια του ελέγχου, έτσι ώστε οι συντηρητές να µην χρειάζεται να δηµιουργήσουν καινούργια δεδοµένα για επανέλεγχο. Το σύστηµα ποιότητας πρέπει να εξασφαλίζει ότι ο προσδιορισµός των απαιτήσεων έχει γίνει µε τέτοιο τρόπο, ώστε οι µηχανικοί που αναλαµβάνουν τον έλεγχο να µπορούν εύκολα να παράγουν δεδοµένα και διαδικασίες ελέγχου. Ακόµα, το εγχειρίδιο ποιότητας πρέπει να διασφαλίζει (παρέχοντας οδηγίες ή πρότυπα) ότι οι διαδικασίες που ακολουθούνται για την παραγωγή δεδοµένων και αποτελεσµάτων κατά τη διάρκεια του ελέγχου µπορούν να αποθηκευτούν σε µια βιβλιοθήκη, ώστε να είναι επαναχρησιµοποιήσιµες. Σηµαντικό είναι επίσης το εγχειρίδιο να προβλέπει διαδικασίες για την αξιολόγηση της διεπιφάνειας χρήστη [Abo00], παρέχοντας καταλόγους ελέγχου για την αξιολόγησή της. Αναφορικά µε τον αναλυτή, το σύστηµα ποιότητας πρέπει να παρέχει ένα πρότυπο για τον προσδιορισµό των απαιτήσεων, τέτοιο που να αναδεικνύει στον οργανισµό λειτουργίες οι οποίες είναι σχετικές µε άλλες και θα µπορούσαν να χρησιµοποιηθούν αυτούσιες σε παρόµοιες περιπτώσεις. Επίσης, το σύστηµα ποιότητας πρέπει να περιλαµβάνει έναν κατάλογο που θα δίνει τη δυνατότητα στον αναλυτή να εξασφαλίζει ότι τα χαρακτηριστικά ενός συγκεκριµένου έργου που αναπτύσσεται θα περιγραφούν µε επαρκή λεπτοµέρεια. Τέλος, πρέπει να παρέχει τυποποιηµένη (αλλά όχι σε τέτοιο βαθµό που να µην αφήνει κανένα περιθώριο ελευθερίας κατά περίπτωση)

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

4 . 2 ™ À ™ ∆ ∏ ª ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

115

περιγραφή της περίπλοκης διαδικασίας που θα ακολουθηθεί όταν ο αναλυτής έρθει σε επαφή µε τον πελάτη. Το σύστηµα ποιότητας πρέπει να παρέχει οδηγίες για το πώς θα οργανώνονται οι συναντήσεις µεταξύ του πελάτη και του αναλυτή ή του υπεύθυνου έργου, που θα βοηθούν στην εξελικτική πορεία του έργου. Επίσης, πρέπει να προδιαγράφεται ένα τυποποιηµένο έγγραφο που να παρέχει λεπτοµερή περιγραφή του τρόπου που οι κατασκευαστές σκοπεύουν να ελέγξουν αν ικανοποιούνται οι απαιτήσεις του πελάτη. Τέλος, το σύστηµα ποιότητας πρέπει να προσδιορίσει τον τύπο των αναφορών που θα σταλθούν στον πελάτη σχετικά µε την εξέλιξη του έργου και να καθορίζει τη συχνότητα µε την οποία θα στέλνονται. ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏﬁÁËÛË˜ 4.4 Αντιστοιχίστε τους χρήστες της αριστερής στήλης µε τις φράσεις της δεξιάς στήλης που περιγράφουν τι παρέχει το σύστηµα ποιότητας. Προσέξτε ότι µία φράση της δεξιάς στήλης αντιστοιχεί σε µία µόνο κατηγορία χρηστών, ενώ σε µία κατηγορία χρηστών µπορούν να αντιστοιχηθούν πολλές φράσεις που περιγράφουν τι παρέχει το σύστηµα ποιότητας Κατηγορίες Χρηστών

Τι παρέχει το σύστηµα ποιότητας

Υπεύθυνος έργου

Πρότυπα που να ορίζουν τον τρόπο µε τον οποίο ένα πρόγραµµα πρέπει να αναπτυχθεί (κωδικοποιηθεί).

Αναλυτής

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

Προγραµµατιστής

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

Σχεδιαστής

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

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

K E º A § A I O 4 : ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

116

¢Ú·ÛÙËÚÈﬁÙËÙ· 4.1 Η Μαρία έχει αναλάβει υπεύθυνη ποιότητας σε µία επιχείρηση που τώρα ετοιµάζει το εγχειρίδιο ποιότητας και προσπαθεί να αποφασίσει τι θα συµπεριλάβει σε αυτό. Στην παρούσα φάση της εργασίας της εξετάζει τη δηµιουργία ενός προγραµµατιστικού προτύπου. Εργαστείτε ως βοηθοί της Μαρίας και προτείνετέ της τι θα µπορούσε να συµπεριλάβει σε αυτό το πρότυπο. Γράψτε την απάντησή σας συνοπτικά χωρίς να ξεπεράσετε τις 500 λέξεις. Μετά δείτε τι προτείνουµε εµείς στην απάντηση που ακολουθεί.

Απάντηση Η Μαρία προτείνει να υπάρχει στο πρότυπο αναλυτική περιγραφή του τρόπου ανάπτυξης του κώδικα η οποία περιλαµβάνει τις παρακάτω οδηγίες: • Στην αρχή κάθε τµήµατος του προγράµµατος πρέπει να αναφέρονται σχόλια µε πληροφορίες για τον προγραµµατιστή ή την οµάδα ανάπτυξης, την έκδοση και την ηµεροµηνία τελευταίας αναθεώρησης. • Στην αρχή κάθε τµήµατος του προγράµµατος πρέπει να αναφέρονται σχόλια µε τις σχέσεις αυτού του τµήµατος µε άλλα. • Στην αρχή κάθε τµήµατος πρέπει να αναφέρονται οι λειτουργίες που επιτελεί αυτό το τµήµα (µε αναφορές στα αντίστοιχα κείµενα των αρχικών προδιαγραφών). • Κάθε µεταβλητή πρέπει να συνοδεύεται από σχόλια στο σηµείο που ορίζεται και σε κάθε σηµείο που γίνεται αλλαγή της τιµής της. • Κάθε προγραµµατιστική δοµή πρέπει να συνοδεύεται από σχόλια για το σκοπό που επιτελεί. • Για κάθε γραµµή κώδικα που δεν είναι αυτονόητη η χρήση της ή δεν έχει επεξηγηθεί µε άλλο τρόπο πρέπει να υπάρχει και µια γραµµή επεξηγηµατικών σχολίων. Επίσης η Μαρία προτείνει µία τυποποίηση για τα παρακάτω: • Καθορισµός µορφής αρχικοποιήσεων (για παράδειγµα αρχικοποιήσεις µεταβλητών θα γίνονται µόνο στην αρχή του κώδικα και σε τµήµα που θα ορίζεται από σχόλια που θα το προσδιορίζουν). • Καθορισµός ονοµατολογίας µεταβλητών, σταθερών και τµηµάτων κώδικα (για παράδειγµα κάθε global µεταβλητή θα έχει όνοµα που να αρχίζει από «g_» και κάθε σταθερά από «s_», ενώ όλες οι µεταβλητές θα έχουν όνοµα τουλάχιστον 6

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

4 . 2 ™ À ™ ∆ ∏ ª ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

χαρακτήρων και που θα περιγράφει µε κάποιο τρόπο τη χρήση τους). Ακόµα, η Μαρία προτείνει για λόγους σαφήνειας και αναγνωσιµότητας να αποφεύγονται: • οι δοµές που δηµιουργούν ασάφειες, • µεγάλες και δυσανάγνωστες εκφράσεις, • περιττές αναφορές στις global µεταβλητές, • πολλές εµφωλεύσεις τµηµάτων κώδικα. Τέλος, η Μαρία προτείνει κάθε τµήµα κώδικα να συνοδεύεται από τα παρακάτω εγχειρίδια: • Εγχειρίδιο συντήρησης (που περιγράφει αναλυτικά τις λειτουργίες που επιτελούνται, τις µεταβλητές που χρησιµοποιούνται, τις προγραµµατιστικές δοµές και τις αναθέσεις τιµών και δίνει οδηγίες για το πώς µπορεί να γίνουν αλλαγές στον κώδικα, ποια σηµεία πρέπει να προσεχθούν, µε ποια άλλα τµήµατα του κώδικα υπάρχει σύζευξη και τι ενέργειες πρέπει να γίνουν σε αυτά). • Εγχειρίδιο ελέγχου (που περιγράφει πώς ελέγχθηκε το συγκεκριµένο τµήµα, τι δεδοµένα χρησιµοποιήθηκαν αναλυτικά και πώς πρέπει να ελεγχθεί σε περίπτωση αλλαγών). Ένα τέτοιο πρότυπο σε µία επιχείρηση πρέπει να είναι πολύ λεπτοµερές και να περιλαµβάνει αναλυτικές οδηγίες για την εφαρµογή του σε κάθε περίπτωση. Συνήθως είναι ένα πολυσέλιδο εγχειρίδιο που είναι άµεσα διαθέσιµο και ηλεκτρονικά στους προγραµµατιστές, ενώ συχνά διδάσκεται σε αυτούς και µε σεµινάρια εκπαίδευσης. Στην απάντηση σας δώσαµε τις βασικές κατευθύνσεις για αυτό. 4.2.3 √Ê¤ÏË ·ﬁ ÙÔ Û‡ÛÙËÌ· ÔÈﬁÙËÙ·˜

Η εφαρµογή ενός συστήµατος ποιότητας σε µία επιχείρηση που αναπτύσσει λογισµικό εξασφαλίζει σηµαντικά οφέλη για αυτή. Τα σηµαντικότερα από αυτά παρουσιάζονται συνοπτικά παρακάτω: • Μείωση κόστους παραγωγής (κυρίως λόγω της ελαχιστοποίησης απωλειών από τη µείωση της χαµένης ή επαναλαµβανόµενης εργασίας και τη µείωση λαθών). • Μείωση δαπανηρών και χρονοβόρων φάσεων παραγωγής (µείωση του χρόνου που δαπανάται για έλεγχο και διορθωτική συντήρηση). • Καλύτερη οργάνωση της επιχείρησης (που επιτυγχάνεται µε την καταγραφή και

117

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

K E º A § A I O 4 : ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

118

εφαρµογή τυποποιηµένων διαδικασιών παραγωγής και τη χρήση προτύπων που τυποποιούν τη διαδικασία ανάπτυξης). • ∆υνατότητα παρακολούθησης (monitoring) έργων (που µεταφράζεται σε αύξηση της παραγωγικότητας, καλύτερη αξιοποίηση πόρων, αποφυγή λανθασµένων κατευθύνσεων στα έργα και σωστή αξιοποίηση των δυνατοτήτων του προσωπικού). • Καλά και µε ακρίβεια καθορισµένες αρµοδιότητες και ευθύνες για κάθε µέλος της οµάδας υλοποίησης ενός έργου που συνεπάγεται καθορισµό ρόλων µέσα στην επιχείρηση. • Ανεξαρτητοποίηση της επιχείρησης από τα άτοµα (που επιτυγχάνεται µε την τυποποίηση των διαδικασιών ανάπτυξης και τη χρήση προγραµµατιστικών προτύπων). • ∆ηµιουργία αποθεµατικού στην επιχείρηση (καλογραµµένα και κατανοήσιµα τµήµατα κώδικα, σχολιασµένα και µε επαρκή τεκµηρίωση που έχουν υλοποιηθεί µε βάση κάποιο πρότυπο και είναι άµεσα επαναχρησιµοποιήσιµα). • Καταγραφή και τεκµηρίωση της πορείας (επιτυχία ή αποτυχία) κάθε έργου και δηµιουργία αρχείου δεδοµένων που µπορεί να χρησιµοποιηθεί στις διαδικασίες εκτίµησης παραγόντων όπως οι ανάγκες σε ανθρώπινο δυναµικό, το κόστος και ο χρόνος µελλοντικών έργων. • Καλύτερη οργάνωση των µελλοντικών στόχων της επιχείρησης που βασίζεται στην καταγραφή των επιτυχιών, προβληµάτων και δυνατοτήτων της. • Καλύτερη επαφή µε τον πελάτη (που βασίζεται σε καθορισµένες διαδικασίες επικοινωνίας που είναι κοινοποιηµένες και στον πελάτη). ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏﬁÁËÛË˜ 4.5 Ακολουθούν µερικές προτάσεις. Ποιες από αυτές είναι σωστές και ποιες λάθος; ∆είτε στο τέλος του βιβλίου τις σωστές απαντήσεις και την αιτιολόγηση για κάθε απάντηση.

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

Σωστό

Λάθος

❏

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

4 . 2 ™ À ™ ∆ ∏ ª ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

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

119

❏

iv) Η µείωση δαπανηρών και χρονοβόρων φάσεων παραγωγής αναφέρεται στη µείωση των φάσεων ανάλυσης απαιτήσεων και σχεδίαςης. ❏

❏

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

❏

iii) Η δηµιουργία αποθεµατικού στην επιχείρηση σχετίζεται µε την παραγωγή µεγάλων ποσοτήτων κώδικα.

❏

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

120

K E º A § A I O 4 : ¶ √ π √ ∆ ∏ ∆∞ § √ ° π ™ ª π ∫ √ À

™‡ÓÔ„Ë ÎÂÊ·Ï·›Ô˘ Î·È Û˘Ì‚Ô˘Ï¤˜ ÌÂÏ¤ÙË˜ Στο κεφάλαιο µιλήσαµε για την ποιότητα λογισµικού, εισάγοντας τις έννοιες των παραγόντων ποιότητας και των ποιοτικών χαρακτηριστικών και παρουσιάσαµε τα πιο διαδεδοµένα µοντέλα ποιότητας λογισµικού µε έµφαση στο πρότυπο ISO 9126. Επίσης παρουσιάσαµε το σύστηµα ποιότητας λογισµικού, επεξηγώντας τις διαφορές ανάµεσα στο εγχειρίδιο και στο πλάνο ποιότητας. Μιλήσαµε για διαδικασίες και πρότυπα ποιότητας, αναφέραµε τις µετρικές (για τις οποίες θα µιλήσουµε στο επόµενο κεφάλαιο) και τους χρήστες του συστήµατος ποιότητας, καθώς και τα οφέλη µιας επιχείρησης από την εφαρµογή ενός συστήµατος ποιότητας. Σε αρκετά σηµεία του κεφαλαίου δεν επεκταθήκαµε σε λεπτοµερή παρουσίαση κάποιων µοντέλων ή στην εφαρµογή του συστήµατος ποιότητας για κάθε φάση της παραγωγής, αφήνοντάς σας να τις µελετήσετε από µόνοι σας. Σε αυτό το σηµείο πρέπει να σας βοηθήσει και η βιβλιογραφία που ακολουθεί. Γενικά, η συµβουλή µας είναι να ανατρέχετε και σε βιβλιογραφικές πηγές πέρα από το βιβλίο αυτό, ώστε να εµπλουτίζετε τις γνώσεις σας, αλλά και να µελετήσετε εναλλακτικές απόψεις για την ύλη που καλύψαµε. Ακολουθεί βιβλιογραφία µε προτεινόµενα βιβλία για περαιτέρω µελέτη στα οποία σας υποδεικνύουµε πού να επικεντρώσετε την προσοχή σας.

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

µ π µ § π √ ° ƒ∞ º π ∞ ∫ ∞ π ¶ ƒ √ ∆∞ ™ ∂ π ™ ° π ∞ ¶ ∂ ƒ∞ π ∆ ∂ ƒ ø ª ∂ § ∂ ∆ ∏

µÈ‚ÏÈÔÁÚ·Ê›· Î·È ÚÔÙ¿ÛÂÈ˜ ÁÈ· ÂÚ·ÈÙ¤Úˆ ÌÂÏ¤ÙË

Ακολουθεί η βιβλιογραφία του κεφαλαίου 4. Τα επιλεγµένα βιβλία που σχολιάζονται είναι αυτά που σας προτείνονται για περαιτέρω µελέτη στα θέµατα που καλύψαµε στο κεφάλαιο 4. Τα βιβλία αυτά συνοδεύονται από σχόλια για το πού να επικεντρώσετε τη µελέτη σας σχετικά µε τα θέµατα του κεφαλαίου 4, αλλά και πληροφορίες για τη µελέτη σας. [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). [Inc95] Darrel Ince, «Software Quality Assurance: A Student Introduction», McGraw–Hill, (1995). Είναι ένα εύκολο στην ανάγνωση εισαγωγικό βιβλίο στην ποιότητα λογισµικού. Ο Ince (που είναι καθηγητής στο αγγλικό Open University) έχει γράψει το βιβλίο του ακολουθώντας κανόνες εκπαίδευσης από απόσταση, οπότε θα το βρείτε αρκετά εύκολο στη µελέτη. Στα κεφάλαια 1 και 2 παρουσιάζεται το σύστηµα ποιότητας και οι χρήστες του (για τους οποίους µιλήσαµε στην ενότητα 4.2.2). Τα κεφάλαια 3 – 10 περιγράφουν τι προσφέρει το σύστηµα ποιότητας στις διάφορες φάσεις ανάπτυξης λογισµικού (το θέµα της ενότητας 4.2.3 του βιβλίου αυτού), ενώ αναλύονται θέµατα σχετικά µε µετρικές (κεφάλαιο 11) και για πρότυπα ποιότητας (κεφάλαια 13 και

121

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

122

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 ™ÂÏ›‰· 123

∫

ªÂÙÚ‹ÛÂÈ˜ Î·È ªÂÙÚÈÎ¤˜ ¶ÔÈﬁÙËÙ·˜ §ÔÁÈÛÌÈÎÔ‡ ™ÎÔﬁ˜

∂

5 º

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

¶ÚÔÛ‰ÔÎÒÌÂÓ· ·ÔÙÂÏ¤ÛÌ·Ù· Όταν θα έχετε ολοκληρώσει τη µελέτη αυτού του κεφαλαίου θα µπορείτε να: • περιγράψετε τους όρους µέτρο και µετρική και να αναλύσετε τις διαφορές τους, • ορίσετε τα εσωτερικά και εξωτερικά χαρακτηριστικά του λογισµικού, τις εσωτερικές και εξωτερικές µετρικές και την ερµηνεία της µετρικής, • ορίσετε τις έννοιες των µετρικών διαδικασίας, πόρων και προϊόντος και να περιγράψετε τα ερωτήµατα στα οποία δίνουν απαντήσεις µε τη χρήση τους, • περιγράψετε τον τρόπο εφαρµογής των εσωτερικών µετρήσεων, • διεξάγετε µετρήσεις που να βασίζονται σε µετρικές µεγέθους και µετρικές κυκλωµατικής πολυπλοκότητας, • περιγράψετε τα πλεονεκτήµατα και τα µειονεκτήµατα της χρήσης εσωτερικών µετρήσεων και µετρικών, • ορίζετε τις εξωτερικές µετρήσεις και να αναφέρετε τις κατηγορίες των εξωτερικών µετρήσεων για ποιοτικά χαρακτηριστικά που αφορούν στον τελικό χρήστη, • περιγράψετε τα πλεονεκτήµατα και τα µειονεκτήµατα της χρήσης εξωτερικών µετρήσεων και µετρικών.

ŒÓÓÔÈÂ˜ ÎÏÂÈ‰È¿ • Μέτρηση (Measurement) • Μετρική (Metric) • Μέτρο (Measure) • Εσωτερικά χαρακτηριστικά λογισµικού (Internal software

characteristics) • Εξωτερικά χαρακτηριστικά λογισµικού (External software characteristics) • Ερµηνεία µετρικής (Metric

∞

√

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

K E º A § A I O 5 : ª ∂ ∆ ƒ ∏ ™ ∂ π ™ ∫ ∞ π ª ∂ ∆ ƒ π ∫ ∂ ™ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

124

interpretation)

• Γράφηµα ∆ιασποράς (Scatter plot)

• Εσωτερικές µετρικές (Internal metrics)

• Κυκλωµατική πολυπλοκότητα (Cyclomatic complexity)

• Εξωτερικές µετρικές (External metrics)

• Γράφος ροής (Flow graph)

• Μετρικές διαδικασίας (Process metrics)

• Αναλυτικές µέθοδοι (Analytic methods)

• Μετρικές πόρων (Resource metrics)

• Πειραµατικές µέθοδοι (Experimental methods)

• Μετρικές προϊόντος (Product metrics)

• ∆ιερευνητικές µέθοδοι (Inquiry methods)

∂ÈÛ·ÁˆÁÈÎ¤˜ ·Ú·ÙËÚ‹ÛÂÈ˜ Στο προηγούµενο κεφάλαιο µιλήσαµε για την ποιότητα λογισµικού και αναφέραµε ότι είναι συνυφασµένη µε µετρήσεις και µετρικές. Σε αυτό το κεφάλαιο, δίνουµε παραδείγµατα µετρικών και παρουσιάζουµε µετρήσεις µε χρήση επιλεγµένων µετρικών, δίνοντας έµφαση στις εσωτερικές µετρικές και παρουσιάζοντας τις βασικές αρχές των εξωτερικών µετρικών. Ειδικότερα, στην ενότητα 5.1 µε τίτλο µετρήσεις και µετρικές, παρουσιάζουµε τις βασικές έννοιες που σχετίζονται µε τις µετρικές και κατηγοριοποιούµε τις µετρικές σε εσωτερικές και εξωτερικές, ανάλογα µε τα χαρακτηριστικά που µετρούν, ή σε µετρικές διαδικασιών, πόρων και προϊόντος ανάλογα µε το στόχο του συστήµατος ποιότητας. Στην ενότητα 5.2 µε τίτλο εσωτερικές µετρήσεις και µετρικές λογισµικού, δίνονται παραδείγµατα (υπό µορφή δραστηριοτήτων) από µετρήσεις που βασίζονται στις γραµµές κώδικα και στην κυκλωµατική πολυπλοκότητα. Στην ενότητα 5.3 µε τίτλο εξωτερικές µετρήσεις και µετρικές λογισµικού, παρουσιάζεται η φιλοσοφία των εξωτερικών µετρήσεων και οι κατηγορίες των µεθόδων µέτρησης των ποιοτικών χαρακτηριστικών που αφορούν στους τελικούς χρήστες και τέλος στην ενότητα 5.4 συζητούµε τη συσχέτιση ανάµεσα στις εσωτερικές και εξωτερικές µετρικές λογισµικού. Για τα περισσότερα σηµεία που καλύπτουµε στο κεφάλαιο αυτό, σας παραθέτουµε σχολιασµένη βιβλιογραφία για συµπληρωµατική µελέτη στο τέλος του κεφαλαίου, όπου µπορείτε να βρείτε και σύντοµες οδηγίες για το πού να αναζητήσετε τι και τι µπορείτε να διαβάσετε επιπλέον.

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

5.1 ª∂∆ƒ∏™∂π™ ∫∞π ª∂∆ƒπ∫∂™

125

5.1 ªÂÙÚ‹ÛÂÈ˜ Î·È ÌÂÙÚÈÎ¤˜

Όπως αναφέραµε και στο 3ο κεφάλαιο, η ποιότητα λογισµικού είναι συνυφασµένη µε την έννοια των µετρήσεων. Αναφέραµε ότι αντικείµενο των µετρήσεων δεν είναι η µέτρηση των οντοτήτων, αλλά η µέτρηση των ιδιοτήτων των οντοτήτων. Επίσης, δώσαµε τον ορισµό της µέτρησης (measurement). Στη βιβλιογραφία αναφέρονται οι όροι µετρική (metric) και µέτρο (measure). Ο ορισµός της µετρικής [Fen97] δίνεται δίπλα. Αν και πολλά βιβλία θεωρούν τους όρους ισοδύναµους, συνήθως ο όρος µετρική χρησιµοποιείται για να χαρακτηρίσει απλές ιδιότητες, όπως για παράδειγµα το µήκος γραµµών κώδικα, ή η κυκλωµατική πολυπλοκότητα (που θα περιγραφεί στα πλαίσια αυτής της ενότητας), ενώ ο όρος µέτρο χρησιµοποιείται για συσχετισµούς ιδιοτήτων και για την πρόβλεψη πιο πολύπλοκων χαρακτηριστικών όπως για παράδειγµα το κόστος, ή η πολυπλοκότητα ενός τµήµατος κώδικα. Παραδείγµατος χάριν αναφέρουµε ότι: «η µετρική V(g) είναι ένα µέτρο της πολυπλοκότητας». Τιµές σε µετρικές ανατίθενται µε τη διαδικασία της µέτρησης, ενώ συσχετισµοί µετρικών και αποτελέσµατα που προκύπτουν από µετρήσεις παρέχουν πληροφορίες για κάποια µέτρα. Η χρήση µέτρων και µετρικών, στην τεχνολογία λογισµικού, έρχεται να λύσει το βασικό πρόβληµα του λογισµικού, που σχετίζεται µε την αδυναµία καθορισµού µετρήσιµων ποσοτήτων, κατά τη σχεδίαση και ανάπτυξη ενός έργου. Υποσχόµαστε, για παράδειγµα, πως ένα πρόγραµµα θα είναι «αξιόπιστο», «φιλικό προς το χρήστη» και «συντηρήσιµο», χωρίς να προσδιορίζουµε µε µετρήσιµες ποσότητες τι σηµαίνει κάθε ένα από αυτά. Έτσι, σε πολλά έργα, η αποτυχία επίτευξης των στόχων τους είναι φυσιολογική συνέπεια. Όπως ορίζει ο Gilb [Gil87]: «το µόνο ξεκάθαρο για έργα που δεν έχουν ξεκάθαρους στόχους, είναι πως δε θα πετύχουν τους στόχους τους». Επίσης, αποτυγχάνουµε να εκτιµήσουµε βασικά ποσοτικά χαρακτηριστικά που σχετίζονται µε το έργο, όπως για παράδειγµα το χρόνο που απαιτείται για τη µεταφορά σε κάποιο άλλο σύστηµα, ή την αξιοπιστία του συστήµατος χρησιµοποιώντας όρους όπως είναι ο «αριθµός αποτυχιών σε δεδοµένη χρονική περίοδο». Αντίθετα, αν κανείς δει τις διαφηµίσεις εµπορικού λογισµικού θα διαβάσει πληθώρα διαφηµιστικών σλόγκαν που µιλάνε για «µείωση του χρόνου συντήρησης κατά 80%», «αυξηµένη αξιοπιστία κατά 75%» κτλ, χωρίς την παραµικρή ένδειξη για το πώς προκύπτουν αυτοί οι αριθµοί και βάσει ποιων µετρικών.

■ Μέτρηση είναι

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

■ Μετρική είναι

µια εµπειρική αντικειµενική αντιστοίχηση ενός αριθµού (ή συµβόλου) σε µια οντότητα µε στόχο να χαρακτηρίσει ένα συγκεκριµένο χαρακτηριστικό Οι πρώτες µετρικές λογισµικού παρουσιάστηκαν προς το τέλος της δεκαετίας του της οντότητας 70. Εκείνη την περίοδο δηµοσιεύθηκαν οι πρώτες εργασίες σχετικά µε τις µετρικές αυτής. λογισµικού, όπως αυτή του Halstead [Hal75] και του McCabe [Mcb76]. Οι δύο αυτές πρωτοποριακές εργασίες στον τοµέα της εξασφάλισης ποιότητας, θεωρούνται ως το έναυσµα για τη θεωρία των µετρήσεων και µετρικών και είναι σίγουρα οι εργασίες

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

K E º A § A I O 5 : ª ∂ ∆ ƒ ∏ ™ ∂ π ™ ∫ ∞ π ª ∂ ∆ ƒ π ∫ ∂ ™ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

126

■

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

■ Εξωτερικά

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

■ Ερµηνεία

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

µε τις περισσότερες αναφορές στην επιστήµη της ποιότητας λογισµικού. Παρόλα αυτά, καµία από τις δύο δεν παρουσίαζε τις µετρικές µε στόχο τη διασφάλιση ποιότητας, αφού οι µετρικές του 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 ™ÂÏ›‰· 127

5.1 ª∂∆ƒ∏™∂π™ ∫∞π ª∂∆ƒπ∫∂™

τερικά ποιοτικά χαρακτηριστικά, ορίζουµε τις εσωτερικές µετρικές (internal metrics) και τις εξωτερικές µετρικές (external metrics). Έτσι, οι εσωτερικές µετρικές µετρούν χαρακτηριστικά όπως οι γραµµές κώδικα, το ποσοστό σχολίων στον κώδικα, ο αριθµός των «goto» εντολών σε µία συνάρτηση, το βάθος δέντρου κληρονοµικότητας, κτλ. Οι εσωτερικές µετρικές µπορούν να υπολογιστούν εύκολα, αλλά το ζητούµενο δεν είναι τόσο ο τρόπος µέτρησής τους, όσο η σύνδεσή τους µε τα εξωτερικά χαρακτηριστικά του λογισµικού τα οποία επιθυµούµε να µετρήσουµε, δηλαδή η ερµηνεία των εσωτερικών µετρικών. Αντίθετα µε τις εσωτερικές µετρικές, οι εξωτερικές µετρικές δεν ικανοποιούν απόλυτα τον ορισµό της µετρικής, αφού εµπεριέχουν –συνήθως– το στοιχείο της υποκειµενικότητας. Αυτές οι µετρικές δεν µπορούν, εκ των πραγµάτων, στην πλειοψηφία των περιπτώσεων να βασιστούν σε µετρήσεις φυσικών ποσοτήτων (όπως στο παράδειγµα των εσωτερικών µετρικών), αλλά βασίζονται σε έρευνες για τη γνώµη των πελατών (συνήθως µε χρήση ερωτηµατολογίων ή συνεντεύξεων), σε παρατήρηση του χρήστη και µελέτη της συµπεριφοράς του, κτλ. Αν και σύµφωνα µε τον ορισµό της µετρικής που προηγήθηκε αυτές δεν είναι τυπικά µετρικές, σε αρκετά βιβλία τις αναφέρουν και τις χρησιµοποιούν ως µετρικές ποιότητας (ενδεικτικά αναφέρουµε τα: [Con86] [Jon91] [Kap95]). Στα πλαίσια του βιβλίου χρησιµοποιούµε τον όρο µετρικές τόσο για τις εσωτερικές µετρικές, όσο και για τις εξωτερικές µετρικές, όµως δεν πρέπει να αγνοούνται οι ιδιαιτερότητες των εξωτερικών µετρικών. Σύµφωνα µε τη δεύτερη κατηγοριοποίηση, διακρίνουµε τις µετρικές σε µετρικές διαδικασίας (process metrics), µετρικές πόρων (resource metrics) και µετρικές προϊόντος (product metrics). Οι µετρικές διαδικασίας µας δίνουν απαντήσεις σε ερωτήµατα σχετικά µε το χρόνο που χρειάστηκε µία δραστηριότητα για να ολοκληρωθεί, πόσο θα κοστίσει, πώς συγκρίνεται µε εναλλακτικές διαδικασίες που θα µπορούσαν να είχαν επιλεγεί, κτλ. Ένας µικρός µόνο αριθµός των χαρακτηριστικών της διαδικασίας µπορεί να µετρηθεί άµεσα (µε χρήση εσωτερικών µετρικών). Τέτοια χαρακτηριστικά για παράδειγµα είναι η διάρκεια µιας διαδικασίας, η προσπάθεια (σε ανθρωποµήνες) για την ολοκλήρωσή της καθώς και ο αριθµός γεγονότων καθορισµένου τύπου που συνέβησαν κατά τη διάρκειά της. Τέτοια γεγονότα µπορεί, για παράδειγµα, να είναι ο αριθµός των λαθών που εντοπίστηκαν κατά τη διάρκεια µίας ώρας ελέγχου µονάδας, ο αριθµός των συναντήσεων µε τον πελάτη που απαιτήθηκαν για την ολοκλήρωση των προδιαγραφών, ο αριθµός των αναφορών λαθών που ελήφθησαν από Ν επιλεγµένους πελάτες κατά τη διάρκεια Μ εβδοµάδων ελέγχου βήτα (beta testing), κτλ.

127

■ Εσωτερικές

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

■ Εξωτερικές

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

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

128

K E º A § A I O 5 : ª ∂ ∆ ƒ ∏ ™ ∂ π ™ ∫ ∞ π ª ∂ ∆ ƒ π ∫ ∂ ™ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

στικά). Τέτοια χαρακτηριστικά για παράδειγµα είναι η σταθερότητα της διαδικασίας, η δυνατότητα παρακολούθησής της από τον Υπεύθυνο έργου, κτλ. Οι µετρικές διαδικασίας σχετίζονται κυρίως µε την εκτίµηση για την οποία µιλήσαµε στο κεφάλαιο 2 και για αυτό το λόγο δεν θα επεκταθούµε περισσότερο. Με τη χρήση µετρικών διαδικασιών σχετίζεται και ο στατιστικός έλεγχος ποιότητας, για τον οποίο µιλήσαµε στην ενότητα 3.2.3. Τεχνικές στατιστικού ελέγχου στο λογισµικό [Wel00] εφαρµόζουν τεχνικές αντίστοιχες µε αυτές που παρουσιάστηκαν στην ενότητα 3.2.3, προκειµένου να µετρήσουν γεγονότα που σχετίζονται µε µία διαδικασία και µπορούν να οδηγήσουν σε εκτιµήσεις για το αν αυτή η διαδικασία είναι εντός ή εκτός ελέγχου. Τα πιο τυπικά παραδείγµατα τέτοιων γεγονότων είναι τα λάθη (defects) ανά διαδικασία ανάπτυξης, τα προβλήµατα ανά εβδοµάδα, η συσχέτιση των γραµµών κώδικα ανά ώρα µε τις επισκοπήσεις που χρειάστηκαν, κτλ. Οι µετρικές πόρων µας δίνουν απαντήσεις σε ερωτήµατα σχετικά µε το προσωπικό, τα υλικά (αναλώσιµα, εξοπλισµός γραφείου, κτλ) που χρησιµοποιήθηκαν, τα εργαλεία (τόσο σε επίπεδο υλικού όσο και λογισµικού) και τις µεθόδους ανάπτυξης. Οι περισσότερες µετρικές πόρων µετρούν εσωτερικά χαρακτηριστικά τα οποία είναι σχετικά εύκολο να µετρηθούν και για αυτό δεν θα επεκταθούµε περισσότερο σε αυτές (για παράδειγµα είναι εύκολο να µετρηθεί χωρίς κάτι τέτοιο να απαιτεί κάποια ιδιαίτερη ανάλυση, ο αριθµός των δισκετών που αγοράστηκαν για ένα έργο και το κόστος τους). Εκτός από τα εσωτερικά χαρακτηριστικά υπάρχουν και εξωτερικά χαρακτηριστικά που σχετίζονται µε τους πόρους και είναι δύσκολο να µετρηθούν, όπως για παράδειγµα η παραγωγικότητα του προσωπικού. Τέλος, οι µετρικές προϊόντος σχετίζονται µε οτιδήποτε θα παραδοθεί στον πελάτη. Έµφαση θα δώσουµε φυσικά στις µετρικές λογισµικού. Οι µετρικές λογισµικού µπορεί να είναι εσωτερικές ή εξωτερικές. Στην ενότητα 5.2 που ακολουθεί θα εµβαθύνουµε στις εσωτερικές µετρήσεις και µετρικές λογισµικού, ενώ στην ενότητα 5.3 θα αναφερθούµε στις εξωτερικές µετρήσεις και µετρικές λογισµικού.

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

5.2 ∂™ø∆∂ƒπ∫∂™ ª∂∆ƒ∏™∂π™ ∫∞π ª∂∆ƒπ∫∂™ §√°π™ªπ∫√À

129

ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏﬁÁËÛË˜ 5.1 Ακολουθούν µερικές προτάσεις. Ποιες από αυτές είναι σωστές και ποιες λάθος; ∆είτε στο τέλος του βιβλίου τις σωστές απαντήσεις, καθώς και την αιτιολόγηση για κάθε απάντηση. Σωστό

Λάθος

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

❏

ii) Οι περισσότερες µετρικές που έχουν προταθεί περιορίζονται στη µέτρηση εξωτερικών χαρακτηριστικών του λογισµικού.

❏

iii) Μια µετρική είναι εύκολο να ερµηνευτεί, όταν υπάρχει συσχέτιση, σε κάποιο βαθµό, αυτής της µετρικής µε κάποιο ή κάποια εξωτερικά χαρακτηριστικά του λογισµικού. ❏

❏

iv) Οι εξωτερικές µετρικές δεν ικανοποιούν απόλυτα τον ορισµό της µετρικής, αφού είναι σχετικά υποκειµενικές. ❏

❏

v) Ο αριθµός γεγονότων καθορισµένου τύπου που συνέβησαν κατά τη διάρκεια µίας διαδικασίας είναι δυνατό να αποτελεί µετρική προϊόντος. ❏

❏

vi) Οι µετρικές προϊόντος σχετίζονται µε οτιδήποτε παραδίδεται στον πελάτη.

❏

5.2 ∂ÛˆÙÂÚÈÎ¤˜ ÌÂÙÚ‹ÛÂÈ˜ Î·È ÌÂÙÚÈÎ¤˜ ÏÔÁÈÛÌÈÎÔ‡

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

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

K E º A § A I O 5 : ª ∂ ∆ ƒ ∏ ™ ∂ π ™ ∫ ∞ π ª ∂ ∆ ƒ π ∫ ∂ ™ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

130

¢Ú·ÛÙËÚÈﬁÙËÙ· 5.1 Η Αντωνία, είναι µηχανικός ποιότητας σε µία επιχείρηση και αναλαµβάνει να µετρήσει τις γραµµές κώδικα του παρακάτω προγράµµατος σε 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 */

Απάντηση Η Αντωνία αρχικά µέτρησε τις γραµµές του προγράµµατος και βρήκε ότι αυτές είναι 20. ∆εν απάντησε όµως LOC = 20 αµέσως. Αντίθετα διάβασε το εγχειρίδιο ποιότητας της επιχείρησης για να δει πώς ορίζονται οι γραµµές κώδικα στη γλώσσα C. Εκεί

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

5.2 ∂™ø∆∂ƒπ∫∂™ ª∂∆ƒ∏™∂π™ ∫∞π ª∂∆ƒπ∫∂™ §√°π™ªπ∫√À

βρήκε ότι, ως γραµµές κώδικα, ορίζονται οι γραµµές του προγράµµατος που προκύπτουν αφού αφαιρεθούν κενές γραµµές και γραµµές σχολίων και συνδεθούν οι αγκύλες µε τα αντίστοιχα τµήµατα που περικλείουν (ώστε να µην καταλαµβάνουν γραµµή). Ακολουθώντας τις παραπάνω οδηγίες η Αντωνία µετέτρεψε το πρόγραµµα στην παρακάτω µορφή: 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), µπορεί να

131

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

K E º A § A I O 5 : ª ∂ ∆ ƒ ∏ ™ ∂ π ™ ∫ ∞ π ª ∂ ∆ ƒ π ∫ ∂ ™ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

132

συσχετίσει την εσωτερική µέτρηση LOC µε τα λάθη που εντοπίζει ο πελάτης. Έτσι, θα προέκυπτε µία ανάλυση που θα συσχέτιζε τα λάθη που εντοπίζει ο πελάτης µε τις γραµµές κώδικα, δίνοντας µετρήσεις σε µονάδες «λάθη πελάτη ανά ΚLOC». Αναλύοντας στατιστικά τα δεδοµένα για κάθε τµήµα κώδικα, η επιχείρηση θα αποκτούσε εξειδικευµένη γνώση για κάθε τµήµα, αλλά –το κυριότερο– δεδοµένα για το ιδανικό µέγεθος (σε LOC) κάθε τµήµατος, ή για το όριο στο οποίο ένα τµήµα πρέπει να κοπεί σε µικρότερα. Αντίστοιχες συσχετίσεις µπορούν να γίνουν µε την παραγωγικότητα και τις γραµµές κώδικα, ή άλλες εσωτερικές µετρικές. Παρόµοιες µετρήσεις µπορούν να συγκεντρωθούν για πολλές εσωτερικές µετρικές και αυτές να οδηγήσουν την επιχείρηση σε αποφάσεις. Αυτές οι αποφάσεις πρέπει να αντικατοπτρίζονται στο εγχειρίδιο ποιότητας. Οι αποφάσεις που βασίζονται σε εσωτερικές µετρικές έχουν ως κύριο σκοπό τους την πρόληψη. Έτσι, για παράδειγµα, αν µία επιχείρηση έχοντας αναλύσει δεδοµένα από µετρήσεις, αποφασίσει ότι κάθε τµήµα δεν πρέπει να ξεπερνά τις 500 LOC (για κάποια συγκεκριµένη γλώσσα προγραµµατισµού), αυτό δεν σηµαίνει ότι ένα τµήµα 600 LOC (για το οποίο απαιτείται προσπάθεια, προκειµένου να διασπαστεί σε 2 µικρότερα τµήµατα) απαραίτητα θα δηµιουργήσει προβλήµατα. Όµως, επειδή η πιθανότητα να δηµιουργήσει προβλήµατα είναι υψηλή, η επιχείρηση αναλαµβάνει το κόστος των αλλαγών, ελπίζοντας να προλάβει τα λάθη που θα εντοπίσει ο πελάτης. Τέτοια λάθη, κοστίζουν περισσότερο στην επιχείρηση (και πέρα από το υλικό κόστος υπάρχουν και έµµεσες ζηµιές που σχετίζονται µε την εικόνα της επιχείρησης προς τον πελάτη). ¢Ú·ÛÙËÚÈﬁÙËÙ· 5.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 ™ÂÏ›‰· 133

5.2 ∂™ø∆∂ƒπ∫∂™ ª∂∆ƒ∏™∂π™ ∫∞π ª∂∆ƒπ∫∂™ §√°π™ªπ∫√À

133

Απάντηση Αν προσθέσουµε τις γραµµές κώδικα για όλα τα τµήµατα του έργου προκύπτει ότι: LOCΟΛΙΚΟ = 6060 Προσθέτοντας αντίστοιχα τα λάθη προκύπτει ότι: ΛΟΛΙΚΟ = 30. Από τις δύο τιµές συνολικά για το έργο προκύπτει ότι το µέσο ποσοστό λαθών είναι 30/6060 λάθη ανά ΚLOC που υπολογίζεται σε 4,95 λάθη/KLOC. Παρατηρώντας τα λάθη ανά τµήµα, παρατηρούµε ότι, όσο µεγαλώνει το τµήµα µεγαλώνει και ο αριθµός των λαθών, αλλά αυτό είναι κάτι αναµενόµενο. Αν σε ένα τµήµα 200 γραµµών έχουµε περίπου ένα λάθος, τότε σε ένα τµήµα 400 γραµµών είναι λογικό να έχουµε 2 λάθη. Για αυτό το λόγο, το τµήµα ποιότητας της επιχείρησης δεν ενδιαφέρεται τόσο για τον απόλυτο αριθµό λαθών ανά τµήµα, όσο για τα λάθη ανά ΚLOC σε κάθε τµήµα. Όλα αυτά παρουσιάζονται στον πίνακα που ακολουθεί: Τµήµα

LOC

Λάθη

Λάθη ανά ΚLOC

267

3,75

413

2,42

830

6,02

∆

503

5,96

1483

6,07

442

4,52

208

0,00

488

2,05

1045

6,70

381

2,62

Έργο

6060

4,95

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

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

K E º A § A I O 5 : ª ∂ ∆ ƒ ∏ ™ ∂ π ™ ∫ ∞ π ª ∂ ∆ ƒ π ∫ ∂ ™ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

134

στάσεις αποτελούν τον κανόνα και όχι την εξαίρεση. Για να δείξουµε µε γραφικό τρόπο την αύξηση του ποσοστού των λαθών ανά ΚLOC, όσο µεγαλώνει το µέγεθος ενός δείγµατος, χρησιµοποιούµε ένα γνωστό στατιστικό είδος γραφήµατος, τα γραφήµατα διασποράς (scatter plots), όπως αυτό του σχήµατος 5.1: 8,00

Λάθη ανά KLOC

7,00 6,00 5,00 4,00 3,00 2,00 1,00 ™¯‹Ì· 5.1

Γράφηµα διασποράς

0,00 0

200

400

600

800

1000

1200

1400

1600

Mέγεθος σε LOC

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

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

5.2 ∂™ø∆∂ƒπ∫∂™ ª∂∆ƒ∏™∂π™ ∫∞π ª∂∆ƒπ∫∂™ §√°π™ªπ∫√À

Συνοψίζοντας, µπορούµε να πούµε ότι οι εσωτερικές µετρικές είναι –συνήθως– εύκολο να συγκεντρωθούν και να αναλυθούν, ότι η συλλογή δεδοµένων που βασίζονται σε εσωτερικές µετρικές είναι πολύ οικονοµική (συγκρινόµενη και µε την αντίστοιχη συλλογή δεδοµένων για εξωτερικές µετρικές) και τα αποτελέσµατα που προκύπτουν είναι εύκολο να αναλυθούν µε στατιστικές µεθόδους. Το κυριότερο είναι ότι τα δεδοµένα από αυτές µπορούν να συγκεντρωθούν και να οδηγήσουν σε αποφάσεις πολύ πριν την ολοκλήρωση και τελική παράδοση του λογισµικού. Από την άλλη, τα αποτελέσµατά τους είναι –συνήθως– δύσκολο να ερµηνευτούν (συγκρινόµενα µε αυτά των εξωτερικών µετρήσεων) αφού πολλές φορές δεν είναι ξεκάθαρη η σύνδεσή τους µε κάποιο ή κάποια εξωτερικά ποιοτικά χαρακτηριστικά. Έρευνες [Xen96] [Xen97] έχουν αποδείξει ότι η χρήση εσωτερικών µετρικών µπορεί να εντοπίσει σχεδόν όλα τα τµήµατα του κώδικα που θα δηµιουργήσουν προβλήµατα, αλλά µπορεί να υποδείξει και τµήµατα κώδικα που τελικά δεν θα δηµιουργήσουν προβλήµατα. Ακόµα κι έτσι, όµως, το όφελος από την πρώτη περίπτωση (εντοπισµός προβληµατικών τµηµάτων πριν παραδοθούν) είναι πολύ σηµαντικότερο από το κόστος που συνεπάγεται η δεύτερη περίπτωση (επιβολή αλλαγών σε «υγιή» τµήµατα). Συνεχίζοντας, θα δώσουµε ένα παράδειγµα µίας ακόµα πολύ γνωστής µετρικής, αυτής της κυκλωµατικής πολυπλοκότητας. 5.2.1 ∫˘ÎÏˆÌ·ÙÈÎ‹ ÔÏ˘ÏÔÎﬁÙËÙ·

Η µετρική της κυκλωµατικής πολυπλοκότητας (cyclomatic complexity) [Mcb76] είναι ένα µέτρο της πολυπλοκότητας ενός τµήµατος, που βασίζεται στο γράφο ροής (flow graph) του τµήµατος αυτού. Βασικό στοιχείο της µετρικής είναι ο εντοπισµός εκείνων των τµηµάτων του λογισµικού, τα οποία θα είναι δύσκολο να κατανοηθούν, να ελεγχθούν και να συντηρηθούν. Η µελέτη του τµήµατος λογισµικού, από τη σκοπιά αυτής της µετρικής, σχετίζεται µε τους πιθανούς δρόµους (µονοπάτια) που µπορεί να ακολουθήσει η εκτέλεση ενός τµήµατος κώδικα. Μια ένδειξη των δυνατών επιλογών κατεύθυνσης ενός προγράµµατος παρέχει ο γράφος ροής του προγράµµατος που µας δίνει, ίσως, την καλύτερη ένδειξη για τη δοµή του προγράµµατος. Πάνω στο γράφο ροής βασίζονται οι µετρήσεις. Ο γράφος ροής ενός προγράµµατος δείχνει σχηµατικά τους πιθανούς «δρόµους» που µπορεί να ακολουθήσει η εκτέλεση του προγράµµατος, επιλέγοντας κάθε φορά ένα διαφορετικό µονοπάτι από τις δυνατότητες επιλογής. Οι τέσσερις περιπτώσεις οι οποίες συναντιόνται συχνότερα στο γράφο ροής είναι: ακολουθιακές εντολές, εντολή διακλάδωσης, κύκλος µε έξοδο στην αρχή, κύκλος µε έξοδο στο τέλος. Ακολουθιακές εντολές είναι ακολουθίες εντολών κατά τις οποίες δεν γίνεται επι-

135

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

K E º A § A I O 5 : ª ∂ ∆ ƒ ∏ ™ ∂ π ™ ∫ ∞ π ª ∂ ∆ ƒ π ∫ ∂ ™ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

136

λογή. Τέτοιες εντολές θα εκτελεστούν σειριακά, χωρίς να υπάρχει επιλογή διαφορετικού τρόπου (µονοπατιού) εκτέλεσής τους. Εντολές διακλάδωσης (όπως η εντολή «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 ™ÂÏ›‰· 137

5.2 ∂™ø∆∂ƒπ∫∂™ ª∂∆ƒ∏™∂π™ ∫∞π ª∂∆ƒπ∫∂™ §√°π™ªπ∫√À

V(g) = e – n + 2p

137

(5.1)

Η µετρική της κυκλωµατικής πολυπλοκότητας είναι από τις πιο διαδεδοµένες µετρικές και έχει ενταχθεί στα προγράµµατα µετρήσεων των περισσοτέρων εταιριών. Αρκετές εταιρίες έχουν καθορίσει στα πρότυπα ποιότητάς τους, όπως περιγράφονται στα εγχειρίδια ποιότητάς τους, ότι τµήµατα κώδικα µε πολυπλοκότητα V(g)>10 δεν θα γίνονται αποδεκτά, αφού τα ιστορικά τους δεδοµένα έδειχναν υποβάθµιση της ποιότητας για τµήµατα µε τέτοια χαρακτηριστικά (κυκλωµατική πολυπλοκότητα µεγαλύτερη του 10). Βασικό πλεονέκτηµα της µετρικής είναι ότι είναι τελείως ανεξάρτητη από τη γλώσσα προγραµµατισµού. Στη βιβλιογραφία µπορείτε να διαβάσετε, αναλυτικά, για την εφαρµογή της, καθώς και για αρκετές παραλλαγές της που έχουν προταθεί. ¢Ú·ÛÙËÚÈﬁÙËÙ· 5.3 Η Αντωνία έχει να µετρήσει (δυστυχώς πάλι «µε το χέρι») την κυκλωµατική πολυπλοκότητα για το παρακάτω πρόγραµµα (το πρόγραµµα είναι πλασµατικό για τις ανάγκες της δραστηριότητας και δεν υλοποιεί απολύτως τίποτε!). Υπολογίστε το κι εσείς, σχεδιάζοντας το γράφο ροής και µετά συγκρίνετε τη λύση που δώσατε µε την απάντηση που ακολουθεί. 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 ™ÂÏ›‰· 138

K E º A § A I O 5 : ª ∂ ∆ ƒ ∏ ™ ∂ π ™ ∫ ∞ π ª ∂ ∆ ƒ π ∫ ∂ ™ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

138

™¯‹Ì· 5.3

Γράφος ροής δραστηριότητας 5.3

Απάντηση Ο γράφος ελέγχου g του προγράµµατος παρουσιάζεται στο σχήµα 5.3 και σχεδιάζεται µε βάση το πρόγραµµα. Από το σχήµα 5.3 προκύπτει ότι ο αριθµός ακµών e = 9, ο αριθµός κόµβων n = 7 και οι συνεκτικές συνιστώσες p = 1. Αντικαθιστώντας στη σχέση (5.1), υπολογίζουµε την κυκλωµατική πολυπλοκότητα V(g) = 9 ∠ 7 + 2 ⇒ V(g) = 4. Φυσικά, σε ένα πρόγραµµα ποιότητας µίας επιχείρησης αυτοί οι υπολογισµοί θα γίνονταν αυτόµατα και τα τµήµατα του κώδικα που ξεπερνούν τα όρια που θέτει το πρότυπο της επιχείρησης θα εντοπίζονταν επίσης αυτόµατα. ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏﬁÁËÛË˜ 5.2 Ακολουθούν µερικές προτάσεις. Ποιες από αυτές είναι σωστές και ποιες λάθος; ∆είτε στο τέλος του βιβλίου τις σωστές απαντήσεις, καθώς και την αιτιολόγηση για κάθε απάντηση. Σωστό i) Οι εσωτερικές µετρικές χρησιµοποιούνται για τη συλλογή δεδοµένων που σχετίζονται µε χαρακτηριστικά του λογισµικού τα οποία µπορούν να οριστούν ξεκάθαρα (χωρίς να εισέρχεται το στοιχείο της υποκειµενικότητας) και να µετρηθούν µε ένα απλό και σαφώς καθορισµένο τρόπο. ❏

Λάθος

❏

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

5.3 ∂•ø∆∂ƒπ∫∂™ ª∂∆ƒ∏™∂π™ ∫∞π ª∂∆ƒπ∫∂™ §√°π™ªπ∫√À

139

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

❏

iii) Οι γραµµές κώδικα και η κυκλωµατική πολυπλοκότητα υπολογίζονται µόνο «µε το χέρι».

❏

iv) Η κυκλωµατική πολυπλοκότητα είναι ένα µέτρο της πολυπλοκότητας ενός τµήµατος, που βασίζεται στο γράφο ροής του.

❏

5.3 ∂ÍˆÙÂÚÈÎ¤˜ ªÂÙÚ‹ÛÂÈ˜ Î·È ªÂÙÚÈÎ¤˜ §ÔÁÈÛÌÈÎÔ‡

Πριν προχωρήσουµε στις εξωτερικές µετρήσεις, πρέπει να τονιστεί ότι, αν και οι εξωτερικές µετρήσεις συνήθως σχετίζονται µε το χρήστη, δεν περιορίζονται µόνο στα ποιοτικά χαρακτηριστικά της λειτουργικότητας, της ευχρηστίας, της αποδοτικότητας και της αξιοπιστίας. Εξωτερικές µετρήσεις µπορούν να γίνουν και για τα ποιοτικά χαρακτηριστικά της µεταφερσιµότητας και της συντηρησιµότητας. Το τµήµα συντήρησης, εξάλλου, µπορεί να θεωρηθεί ως χρήστης του κώδικα µε σκοπό την υλοποίηση αλλαγών. Μετρήσεις εξωτερικές για τη συντηρησιµότητα θα µπορούσαν να είναι: η εκτίµηση για το µέσο χρόνο εντοπισµού και υλοποίησης µίας διόρθωσης, το ποσοστό επιτυχίας της διόρθωσης, το µέσο µέγεθος του κώδικα που χρειάζεται να τροποποιηθεί για µία διόρθωση, το µέσο µέγεθος του κώδικα που χρειάστηκε να διαβαστεί (εξεταστεί) µέχρι να εντοπιστεί το τµήµα στο οποίο υπάρχει το λάθος, κτλ. Όπως βλέπετε, οι παραπάνω εξωτερικές µετρικές εµπεριέχουν το στοιχείο της υποκειµενικότητας. Βέβαια, στα περισσότερα εγχειρίδια ποιότητας, η περιγραφή τους γίνεται µε αυστηρούς τυπικούς περιορισµούς, έτσι ώστε να µειώνονται τα περιθώρια της υποκειµενικότητας. Εξάλλου, οι µετρήσεις που προκύπτουν από την χρήση τους είναι άµεσα αξιοποιήσιµες για εξαγωγή συµπερασµάτων σχετικά µε τη συντηρησιµότητα και δεν χρειάζεται η αναζήτηση συσχετίσεων µε εξωτερικά ποιοτικά χαρακτηριστικά (όπως στην περίπτωση των εσωτερικών µετρικών). ¢Ú·ÛÙËÚÈﬁÙËÙ· ÁÈ· ÂÚ·ÈÙ¤Úˆ ÌÂÏ¤ÙË 5.1 Από το κεφάλαιο 9 του βιβλίου «Software Metrics A Rigorous & Practical Approach» που σας προτείνουµε (βλέπε βιβλιογραφία στο τέλος του κεφαλαίου), αλλά και από αναζητήσεις σας στο διαδίκτυο, ετοιµάστε µία αναφορά για εξωτερικές µετρήσεις µεταφερσιµότητας και συντηρησιµότητας. Η αναφορά σας θα πρέ-

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

140

K E º A § A I O 5 : ª ∂ ∆ ƒ ∏ ™ ∂ π ™ ∫ ∞ π ª ∂ ∆ ƒ π ∫ ∂ ™ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

πει να περιγράφει τον ορισµό κάθε µετρικής και να επεξηγεί τον τρόπο µέτρησης. Προσπαθήστε να µην ξεπεράσετε τις 1000 λέξεις και συζητήστε την αναφορά σας µε το Σύµβουλο – Καθηγητή σας.

Οι εξωτερικές µετρήσεις για ποιοτικά χαρακτηριστικά που αφορούν τον τελικό χρήστη µπορούν να βασιστούν σε τρεις κατηγορίες µεθόδων [Abo00]: α) Αναλυτικές µέθοδοι (analytic methods) β) Πειραµατικές µέθοδοι (experimental methods) γ) ∆ιερευνητικές µέθοδοι (inquiry methods) Οι αναλυτικές µέθοδοι εκτελούνται στο εργαστήριο και δεν συµµετέχουν οι τελικοί χρήστες. Ως ενδεικτικά παραδείγµατα τέτοιων µεθόδων, αναφέρουµε την ανάλυση πληκτρολογήσεων (όπου χρησιµοποιείται ένα µοντέλο ανάλυσης εργασιών και µε υπολογισµό των χρόνων που προβλέπονται για τυπικές ενέργειες του χρήστη, εκτιµάται ο χρόνος ολοκλήρωσης ενός έργου µε τη χρήση του προγράµµατος), την ευρετική αξιολόγηση (όπου εξωτερικοί κριτές εξετάζουν την τήρηση κανόνων µε βάση κάποια κριτήρια σπουδαιότητας, εξειδικευµένα για κάθε εφαρµογή) και τον έλεγχο συµβατότητας µε κανόνες σχεδιασµού και πρότυπα (όπου οι κανόνες δίδονται υπό µορφή καταλόγων ελέγχου και οι ειδικοί αξιολογούν την ικανοποίησή τους ή όχι από το σύστηµα). Οι πειραµατικές µέθοδοι γίνονται στο εργαστήριο αλλά –σε αντίθεση µε τις αναλυτικές µεθόδους– υπάρχει συµµετοχή των τελικών χρηστών. Σε αυτές τις µεθόδους οι χρήστες χρησιµοποιούν το πρόγραµµα µέσα σε ένα εργαστήριο, ενώ οι ειδικοί (συνήθως αθέατα και µε χρήση εξειδικευµένου εξοπλισµού, όπως βίντεο, ή σύστηµα καταγραφής συµβάντων) τους παρακολουθούν και σηµειώνουν (µετρούν) τις αντιδράσεις τους. Τέλος, οι διερευνητικές µέθοδοι εκτελούνται εκτός εργαστηρίου και προϋποθέτουν ενεργή συµµετοχή χρηστών. Ως ενδεικτικά παραδείγµατα τέτοιων µεθόδων αναφέρουµε τις συνεντεύξεις των χρηστών (όπου κάποιος αξιολογητής καταγράφει τις απόψεις του χρήστη) και τη συµπλήρωση ερωτηµατολογίων (όπου οι χρήστες καλούνται να εκφέρουν άποψη για τα ποιοτικά χαρακτηριστικά του λογισµικού).

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

5.3 ∂•ø∆∂ƒπ∫∂™ ª∂∆ƒ∏™∂π™ ∫∞π ª∂∆ƒπ∫∂™ §√°π™ªπ∫√À

141

¢Ú·ÛÙËÚÈﬁÙËÙ· ÁÈ· ÂÚ·ÈÙ¤Úˆ ÌÂÏ¤ÙË 5.2 Από το κεφάλαιο 8 του βιβλίου «Εισαγωγή στην Επικοινωνία Ανθρώπου – Υπολογιστή» που σας προτείνουµε (βλέπε βιβλιογραφία στο τέλος του κεφαλαίου), αλλά και από αναζητήσεις σας στο διαδίκτυο, ετοιµάστε µία αναφορά µέχρι 1000 λέξεις περιγράφοντας µε λεπτοµέρεια µία αναλυτική, µία πειραµατική και µία διερευνητική µέθοδο. Για αυτή τη δραστηριότητα είναι καλό να συνεργαστείτε µε το Σύµβουλο – Καθηγητή σας, ώστε να σας βοηθήσει στην επιλογή των µεθόδων.

Από τις µεθόδους που αναφέραµε, η πιο διαδεδοµένη στην πράξη είναι η χρήση ερωτηµατολογίου. Τα πλεονεκτήµατα της µεθόδου αυτής είναι ότι µία επιχείρηση µπορεί να ζητήσει την άποψη των χρηστών για ποιοτικά χαρακτηριστικά του λογισµικού µε µικρό κόστος (τα ερωτηµατολόγια µπορεί να αποστέλλονται στους χρήστες ηλεκτρονικά, ή να βρίσκονται στον κόµβο της επιχείρησης στο διαδίκτυο και οι χρήστες να τα συµπληρώνουν εκεί). Μετρήσεις τέτοιου τύπου είναι απόλυτα συµβατές µε τον ορισµό της ποιότητας (που σχετίζεται άµεσα µε την άποψη των χρηστών) και οδηγούν σε άµεσα αναλύσιµα δεδοµένα. Τα µειονεκτήµατα αυτής της µεθόδου είναι η υποκειµενικότητα των απαντήσεων και τα συχνά λάθη. Όσον αφορά το πρώτο µειονέκτηµα, ένας καλός τρόπος αντιµετώπισής του από το σχεδιαστή του ερωτηµατολογίου είναι η ορθή δόµηση του ερωτηµατολογίου, η σαφήνεια και ο έλεγχος των απαντήσεων (µε χρήση διπλών ερωτήσεων, ερωτήσεων ασφαλείας, κτλ). Για τον εντοπισµό των χρηστών που έχουν πολλά λάθη στις απαντήσεις τους –και κατά συνέπεια δεν θα πρέπει να συµπεριληφθούν στην ανάλυση των αποτελεσµάτων– υπάρχουν τεχνικές που βασίζονται σε ερωτήσεις ασφαλείας (ερωτήσεις που δεν έχουν στόχο να µετρήσουν την άποψη του χρήστη για κάποιο ποιοτικό χαρακτηριστικό, αλλά να ελέγξουν την εγκυρότητα των απαντήσεων του χρήστη). Συνοψίζοντας, πρέπει να τονιστεί ότι οι εξωτερικές µετρήσεις βασίζονται στον ορισµό της ποιότητας (ικανοποίηση των τελικών χρηστών) και µετρούν άµεσα τα επιθυµητά εξωτερικά χαρακτηριστικά, χωρίς να χρειάζεται περαιτέρω ανάλυση, ή ερµηνεία. Όµως, αρκετές από τις µεθόδους µέτρησης δεν είναι καθόλου οικονοµικές (ιδιαίτερα συγκρινόµενες µε τις εσωτερικές µετρήσεις) και τα αποτελέσµατα βασίζονται συχνά σε υποκειµενικές κρίσεις ή απόψεις. Παρά τα προβλήµατα αυτά, οι εξωτερικές µετρήσεις είναι πολύτιµο εργαλείο για το τµήµα ποιότητας κάθε επιχείρησης.

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

K E º A § A I O 5 : ª ∂ ∆ ƒ ∏ ™ ∂ π ™ ∫ ∞ π ª ∂ ∆ ƒ π ∫ ∂ ™ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

142

ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏﬁÁËÛË˜ 5.3 Ακολουθούν µερικές προτάσεις. Ποιες από αυτές είναι σωστές και ποιες λάθος; ∆είτε στο τέλος του βιβλίου τις σωστές απαντήσεις, καθώς και την αιτιολόγηση για κάθε απάντηση. Σωστό

Λάθος

i) Οι εξωτερικές µετρήσεις αφορούν στα ποιοτικά χαρακτηριστικά που ενδιαφέρουν τους τελικούς χρήστες.

❏

ii) Οι εξωτερικές µετρικές είναι συνήθως απόλυτα αντικειµενικές.

❏

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

❏

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

❏

5.4 ™˘Û¯¤ÙÈÛË ÂÛˆÙÂÚÈÎÒÓ Î·È ÂÍˆÙÂÚÈÎÒÓ ÌÂÙÚÈÎÒÓ ÏÔÁÈÛÌÈÎÔ‡

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

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

5.4 ™À™Ã∂∆π™∏ ∂™ø∆∂ƒπ∫ø¡ ∫∞π ∂•ø∆∂ƒπ∫ø¡ ª∂∆ƒπ∫ø¡ §√°π™ªπ∫√À

να εντοπίσουν τµήµατα του λογισµικού τα οποία ενδέχεται να δηµιουργήσουν προβλήµατα, τόσο κατά τις εσωτερικές στην επιχείρηση φάσεις αξιολόγησης (έλεγχο και συντήρηση), όσο και κατά την τελική αξιολόγηση από τους χρήστες. Η χρήση εσωτερικών µετρήσεων και µετρικών, για τις οποίες µιλήσαµε στην ενότητα 5.2, είναι µία µέθοδος η οποία µπορεί να εντοπίσει τέτοια προβληµατικά τµήµατα του λογισµικού. Ζητούµενο είναι κατά πόσο συσχετίζονται οι εσωτερικές µετρήσεις που γίνονται µε αυτή τη µέθοδο µε τις εξωτερικές µετρήσεις που πραγµατοποιούνται µε τη µέθοδο που περιγράψαµε στην ενότητα 5.3. Αυτό το ζητούµενο µπορεί να αναλυθεί στα δύο ερωτήµατα που ακολουθούν: α) Ένα έργο το οποίο ικανοποιεί ένα πρόγραµµα ποιότητας βασισµένο σε εσωτερικές µετρήσεις, θα έχει αντίστοιχη επιτυχία στις µετρήσεις της άποψης των πελατών για την ποιότητά του; β) Ένα έργο το οποίο απέτυχε να ικανοποιήσει ένα πρόγραµµα ποιότητας βασισµένο σε εσωτερικές µετρήσεις, θα γνωρίσει επίσης αποτυχία στις µετρήσεις της άποψης των πελατών για την ποιότητά του; Η απάντηση στο πρώτο ερώτηµα είναι: «δεν υπάρχει εγγύηση ότι ένα έργο το οποίο ικανοποίησε το πρόγραµµα εσωτερικών µετρήσεων θα έχει αντίστοιχα ικανοποιητικές εξωτερικές µετρήσεις». Αυτό οφείλεται στο γεγονός ότι οι εσωτερικές µετρήσεις δεν µπορούν να καλύψουν όλους τους εξωτερικούς ποιοτικούς παράγοντες. Αντίθετα για το δεύτερο ερώτηµα η απάντηση είναι: «αποτυχία στο πρόγραµµα εσωτερικών µετρήσεων κατά κανόνα σηµαίνει και αποτυχία στις εξωτερικές µετρήσεις» [Xen96]. Αυτό οφείλεται στο γεγονός ότι αποτυχία στις εσωτερικές µετρήσεις σηµαίνει αποτυχία τήρησης κανόνων και αρχών στην παραγωγή του λογισµικού, αδυναµία ελέγχου του κώδικα, αδυναµία εντοπισµού εσωτερικών στόχων κτλ. Όλα αυτά, σχεδόν πάντα, αντικατοπτρίζονται στην ποιότητα του τελικού προϊόντος όπως την αντιλαµβάνεται ο χρήστης (πελάτης). Είναι σχεδόν αδύνατο για ένα έργο να µην ικανοποιεί εσωτερικούς ποιοτικούς περιορισµούς και παρόλα αυτά να κρίνεται ικανοποιητικό από τους πελάτες. Ένα έργο που αποτυγχάνει στις εσωτερικές µετρήσεις πρακτικά σηµαίνει προχειροφτιαγµένος κώδικας, χωρίς τήρηση γενικών κανόνων προγραµµατισµού και αρχών της Τεχνολογίας Λογισµικού. Κατά συνέπεια αποτυχία σε εσωτερικές µετρικές θα σηµαίνει αποτυχία και στην άποψη των πελατών για την ποιότητα. Αυτή η θέση βασίζεται στην αρχή της Τεχνολογίας Λογισµικού που τονίζει ότι «καλή εσωτερική δοµή συνεπάγεται καλή εξωτερική ποιότητα». Όπως αναφέρει ο Fenton [Fen97] εάν η παραπάνω υπόθεση δεν ισχύει τότε όλα τα χρόνια έρευνας στην Τεχνο-

143

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

144

K E º A § A I O 5 : ª ∂ ∆ ƒ ∏ ™ ∂ π ™ ∫ ∞ π ª ∂ ∆ ƒ π ∫ ∂ ™ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

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

™‡ÓÔ„Ë ÎÂÊ·Ï·›Ô˘ Î·È Û˘Ì‚Ô˘Ï¤˜ ÌÂÏ¤ÙË˜ Στο κεφάλαιο µιλήσαµε για τις µετρήσεις και τις µετρικές που εντάσσονται σε ένα σύστηµα ποιότητας λογισµικού, δίνοντας παραδείγµατα µετρικών και παρουσιάζοντας µετρήσεις µε χρήση επιλεγµένων εσωτερικών µετρικών καθώς και τις βασικές αρχές των εξωτερικών µετρικών. Τέλος µιλήσαµε για τη συσχέτιση εσωτερικών και εξωτερικών µετρικών. Σε αρκετά σηµεία του κεφαλαίου δεν επεκταθήκαµε σε λεπτοµερή παρουσίαση όλων των εσωτερικών µετρικών ή στην ανάλυση των εξωτερικών µετρήσεων, αφήνοντάς σας να τις µελετήσετε από µόνοι σας. Σε αυτό το ζητούµενο θα σας βοηθήσει η βιβλιογραφία που ακολουθεί µε προτεινόµενα βιβλία για περαιτέρω µελέτη και υποδείξεις για το πού να επικεντρώσετε την προσοχή σας.

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

µ π µ § π √ ° ƒ∞ º π ∞ ∫ ∞ π ¶ ƒ √ ∆∞ ™ ∂ π ™ ° π ∞ ¶ ∂ ƒ∞ π ∆ ∂ ƒ ø ª ∂ § ∂ ∆ ∏

µÈ‚ÏÈÔÁÚ·Ê›· Î·È ÚÔÙ¿ÛÂÈ˜ ÁÈ· ÂÚ·ÈÙ¤Úˆ ÌÂÏ¤ÙË

Ακολουθεί η βιβλιογραφία του κεφαλαίου 5. Τα επιλεγµένα βιβλία που σχολιάζονται είναι αυτά που σας προτείνονται για περαιτέρω µελέτη στα θέµατα που καλύψαµε στο κεφάλαιο 5. Τα βιβλία αυτά συνοδεύονται από σχόλια για το πού να επικεντρώσετε τη µελέτη σας σχετικά µε τα θέµατα του κεφαλαίου 5, αλλά και πληροφορίες για τη µελέτη σας. [Abo00] Νικόλαος Αβούρης, «Εισαγωγή στην Επικοινωνία Ανθρώπου – Υπολογιστή», Εκδόσεις ∆ΙΑΥΛΟΣ, (2000). Είναι ένα βιβλίο που ακολουθεί τη λογική της εκπαίδευσης από απόσταση (είναι δηλαδή αναλυτικό, έχει πολλά παραδείγµατα και ασκήσεις) και θα το βρείτε πολύ χρήσιµο στη µελέτη σας. Στο κεφάλαιο 8, θα βρείτε αναλυτικά τις µεθόδους εξωτερικών µετρήσεων των ποιοτικών χαρακτηριστικών που αφορούν στους τελικούς χρήστες, για τις οποίες µιλήσαµε στην ενότητα 5.3. [Fen97] N. Fenton and S. Pfleeger, «Software Metrics A Rigorous & Practical Approach», Thomson Computer Press, (1997). Το βιβλίο εξειδικεύεται στις µετρήσεις και µετρικές και το προτείνω ανεπιφύλακτα σε όποιον θέλει να εµβαθύνει σε θέµατα µετρήσεων και µετρικών. Στα κεφάλαια 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). [Ham96] Brian Hambling, «Managing Software Quality», McGraw–Hill, (1996). Είναι ένα βιβλίο αφιερωµένο κυρίως στο πρότυπο ISO 9001 και στην οδηγία ISO 9000 – 3. Παρόλα αυτά, στο κεφάλαιο 6, θα βρείτε µια καλή παρουσίαση των µετρήσεων και πώς αυτές εντάσσονται στα πλαίσια του προτύπου. [Inc95] Darrel Ince, «Software Quality Assurance: A Student Introduction», McGraw–Hill, (1995).

145

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

146

K E º A § A I O 5 : ª ∂ ∆ ƒ ∏ ™ ∂ π ™ ∫ ∞ π ª ∂ ∆ ƒ π ∫ ∂ ™ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

Όπως αναφέραµε και στο προηγούµενο κεφάλαιο, είναι ένα εύκολο στην ανάγνωση εισαγωγικό βιβλίο στην ποιότητα λογισµικού, που ακολουθεί κανόνες εκπαίδευσης από απόσταση, οπότε θα το βρείτε αρκετά εύκολο στη µελέτη. Για µετρήσεις στο λογισµικό θα διαβάσετε στο κεφάλαιο 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). [Yeh93] H. T. Yeh, «Software Process Quality», McGraw Hill, (1993). Είναι ένα βιβλίο που αναφέρεται στις διαδικασίες ποιότητας λογισµικού και σε µετρικές διαδικασιών. Ιδανικό για εµβάθυνση στις µετρικές διαδικασιών τις οποίες δεν αναλύσαµε σε βάθος σε αυτό το βιβλίο. [Zhe95] F. Zahedi, «Quality Information Systems», International Thomson Publishing Company, (1995). Είναι επίσης ένα βιβλίο για ποιότητα λογισµικού και (όπως τα περισσότερα που πραγµατεύονται την ποιότητα) για µετρήσεις. Στα κεφάλαια 8, 9 και 10 θα διαβάσετε για µετρήσεις και µετρικές. Ιδιαίτερα σε αυτό το βιβλίο θα βρείτε για την εφαρµογή του στατιστικού ποιοτικού ελέγχου στο λογισµικό (κεφάλαιο 10).

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

∫

¶ÚfiÙ˘· ¶ÔÈfiÙËÙ·˜ §ÔÁÈÛÌÈÎÔ‡ ™ÎÔfi˜

∂

6 º

Σκοπός του κεφαλαίου 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.

ŒÓÓÔÈÂ˜ ÎÏÂÈ‰È¿ • Πρότυπο (Standard) • Τυποποίηση (Standardisation) • Οδηγία (Guideline) • Ωριµότητα (Maturity) • Ικανότητα (Capability)

• Μοντέλο Ωριµότητας Ικανότητας (Capability Maturity Model) • Βασικές περιοχές της διαδικασίας (Key process areas) • Βασικές πρακτικές (Key practices)

∞

√

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

K E º A § A I O 6 : ¶ ƒ √ ∆ À ¶ ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

148

∂ÈÛ·ÁˆÁÈÎ¤˜ ·Ú·ÙËÚ‹ÛÂÈ˜ Στο προηγούµενο κεφάλαιο µιλήσαµε για τις µετρήσεις που εντάσσονται σε ένα σύστηµα ποιότητας λογισµικού. Σε αυτό το κεφάλαιο, συζητούµε για πρότυπα που σχετίζονται µε την ανάπτυξη του λογισµικού. Ειδικότερα, στην ενότητα 6.1 µε τίτλο τα διεθνή πρότυπα ISO, παρουσιάζουµε τον οργανισµό ISO και τα πρότυπά του που σχετίζονται µε την ποιότητα, δίνοντας έµφαση στο πρότυπο ISO 9001 και την οδηγία ISO 9000 – 3. Τέλος, στην ενότητα 6.2 µε τίτλο το πρότυπο αξιολόγησης CMM, παρουσιάζουµε το µοντέλο αξιολόγησης CMM, τα επίπεδα ωριµότητάς του και συζητούµε τις οµοιότητες και διαφορές του CMM µε το ISO 9001. Για τα περισσότερα σηµεία που καλύπτουµε στο κεφάλαιο αυτό σας παραθέτουµε σχολιασµένη βιβλιογραφία για συµπληρωµατική µελέτη στο τέλος του κεφαλαίου, όπου µπορείτε να βρείτε και σύντοµες οδηγίες για το τι επιπλέον µπορείτε να διαβάσετε σε κάθε βιβλίο.

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

6 . 1 ∆∞ ¢ π ∂ £ ¡ ∏ ¶ ƒ √ ∆ À ¶ ∞ I S O

149

6.1 ∆· ‰ÈÂıÓ‹ ÚﬁÙ˘· 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:

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

■ Πρότυπο είναι

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

K E º A § A I O 6 : ¶ ƒ √ ∆ À ¶ ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

150

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 ™ÂÏ›‰· 151

6 . 1 ∆∞ ¢ π ∂ £ ¡ ∏ ¶ ƒ √ ∆ À ¶ ∞ I S O

151

ποιότητα. Στο τµήµα 6.1.1 που ακολουθεί θα µιλήσουµε πιο αναλυτικά για το πιο περιεκτικό πρότυπο της σειράς, το ISO 9001 και για την οδηγία ISO 9000 – 3. ¢Ú·ÛÙËÚÈﬁÙËÙ· ÁÈ· ÂÚ·ÈÙ¤Úˆ ÌÂÏ¤ÙË 6.1 Από το κεφάλαιο 2 του βιβλίου του Ελληνικού Ανοικτού Πανεπιστηµίου «∆ιασφάλιση Ποιότητας: ∆ιοίκηση της Ποιότητας» που σας προτείνουµε (βλέπε βιβλιογραφία στο τέλος του κεφαλαίου), αλλά και από αναζητήσεις σας στο διαδίκτυο, ετοιµάστε µία αναφορά που θα περιγράφει τις διαφορές ανάµεσα στα πρότυπα ISO 9001, ISO 9002 και ISO 9003, αναφέροντας σε ποιες επιχειρήσεις απευθύνεται καθένα από αυτά. Προσπαθήστε να δώσετε παραδείγµατα επιχειρήσεων από την Ελλάδα (αντλώντας πληροφορίες από τις σελίδες τους στο διαδίκτυο), χωρίς να ξεπεράσετε τις 1000 λέξεις και συζητήστε την αναφορά σας µε το Σύµβουλο – Καθηγητή σας. 6.1.1 ∆Ô ÚﬁÙ˘Ô ISO 9001 Î·È Ë Ô‰ËÁ›· ISO 9000 – 3

Όπως αναφέραµε, το πρότυπο ISO 9001 είναι γενικό και όχι εξειδικευµένο για το λογισµικό. Η πιστοποίηση µιας επιχείρησης ή βιοµηχανίας µε το πρότυπο ISO 9001 αποδεικνύει τη δέσµευσή της στην ποιότητα. Η ανάπτυξη (ή παραγωγή), σύµφωνα µε τους κανόνες του προτύπου, αφορά σε ολόκληρη την εταιρεία και απαιτεί προσπάθεια από την αρχή της διαχείρισης του έργου µέχρι την ολοκλήρωση του προϊόντος. Κάθε επιχείρηση που πιστοποιείται µε ISO 9001 ελέγχεται τόσο την πρώτη φορά, ώστε να πιστοποιηθεί, όσο και περιοδικά (κάθε έξι ή δώδεκα µήνες) από έναν τελείως ανεξάρτητο µε την εταιρεία ελεγκτή, ο οποίος ανήκει σε κάποιο οργανισµό εξουσιοδοτηµένο να πιστοποιεί µε ISO (στην Ελλάδα υπάρχουν περίπου 10 τέτοιοι οργανισµοί: ο ΕΛΟΤ που είναι ο δηµόσιος «Ελληνικός Οργανισµός Τυποποίησης», και οι υπόλοιποι που είναι ιδιωτικοί). Ο ελεγκτής κατευθύνεται από αυστηρούς διεθνείς κώδικες και συµφωνίες που υπαγορεύουν τις µεθόδους ελέγχου και τους περιορισµούς ποιότητας, έτσι ώστε να επιβεβαιώνεται η διασφάλιση της ποιότητας σε όλους τους τοµείς της εταιρείας. Εάν ο ελεγκτής διαπιστώσει παρέκκλιση, τότε αφαιρείται η πιστοποίηση που έχει δοθεί στην εταιρεία. Επιπλέον, το πρότυπο ISO απαιτεί την ύπαρξη προγράµµατος αυτοαξιολόγησης στις πιστοποιηµένες εταιρείες, το οποίο θα είναι υπεύθυνο για τον έλεγχο των ποιοτικών απαιτήσεων και του επιπέδου εφαρµογής τους. Σε αυτό το σηµείο πρέπει να τονιστεί ότι, γενικά, τα πρότυπα (και κατά συνέπεια και το ISO 9001) παρέχουν ένα σκελετό για το σύστηµα ποιότητας της επιχείρησης και καθορίζουν το «τι» πρέπει να γίνει. ∆εν καθορίζουν το «πώς» πρέπει να γίνει κάτι. Ο τρόπος ενέργειας αποτελεί έργο της επιχείρησης (όσον αφορά στο σχεδιασµό και την εφαρµογή κάποιας αποτελεσµατικής διεργασίας ανάπτυξης, µέσα στο πλαίσιο

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

K E º A § A I O 6 : ¶ ƒ √ ∆ À ¶ ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

152

του προτύπου ISO 9001). Το ISO 9001 καθορίζει είκοσι τυποποιηµένα στοιχεία, που λειτουργούν ως απαιτήσεις του συστήµατος ποιότητας και παρατίθενται στη συνέχεια. Οι απαιτήσεις που θα οριστούν για το σύστηµα ποιότητας στοχεύουν στην αποφυγή ανωµαλιών σε όλα τα στάδια της ανάπτυξης, από τον αρχικό σχεδιασµό του προϊόντος (του λογισµικού για την περίπτωσή µας) µέχρι την εγκατάστασή του στο χώρο του πελάτη και την παροχή των τελικών υπηρεσιών (όπως είναι η εκπαίδευση για τη χρήση του λογισµικού). Οι απαιτήσεις του ISO 9001 δίνονται συνοπτικά: 1.

Ευθύνη διοίκησης (management responsibility), που περιλαµβάνει την πολιτική ποιότητας (quality policy) την οργάνωση, την ευθύνη και εξουσιοδότηση, τον έλεγχο των πηγών (πρώτων υλών για τη βιοµηχανία) και του προσωπικού.

Σύστηµα ποιότητας (quality system).

Ανασκόπηση συµβάσεων (contract review).

Έλεγχος σχεδιασµού (design control), που περιλαµβάνει τον αρχικό σχεδιασµό και ανάπτυξη των σχεδίων, τις οργανωτικές και τεχνικές αλληλοσυνδέσεις (organizational and technical interfaces), τα στοιχεία εισόδου και εξόδου και τον έλεγχο αλλαγών.

Έλεγχος εγγράφων (document control), που περιλαµβάνει την έγκριση και έκδοση εγγράφων (document approval and issue) και τις αλλαγές ή µετατροπές εγγράφων.

Αγορές (purchasing), που περιλαµβάνει την αξιολόγηση των υπεργολάβων (assessment of sub – contractor) και τα δεδοµένα σχετικά µε την αγοραστική ικανότητα.

Έλεγχος του προϊόντος που παρέχεται από τον προµηθευτή (purchaser supplied product).

Αναγνώριση ταυτότητας και ανιχνευσιµότητα του προϊόντος (product identification and traceability).

Έλεγχος της διεργασίας ανάπτυξης (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 ™ÂÏ›‰· 153

6 . 1 ∆∞ ¢ π ∂ £ ¡ ∏ ¶ ƒ √ ∆ À ¶ ∞ I S O

153

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. ¢Ú·ÛÙËÚÈﬁÙËÙ· ÁÈ· ÂÚ·ÈÙ¤Úˆ ÌÂÏ¤ÙË 6.2 Ετοιµάστε µία αναφορά που θα σχετίζει κάθε µία από τις 20 απαιτήσεις του ISO 9001 µε λειτουργίες τµηµάτων µιας επιχείρησης λογισµικού. Πείτε ποιες αφορούν τη διοίκηση, το τµήµα ποιότητας, το τµήµα σχεδίασης, το τµήµα marketing, το τµήµα προγραµµατισµού, το τµήµα ελέγχου, κτλ. Για την αναφορά αυτή µπορείτε να βρείτε σηµαντική βοήθεια (αλλά όχι την απάντηση!) στο κεφάλαιο 3 του βιβλίου του Ελληνικού Ανοικτού Πανεπιστηµίου «∆ιασφάλιση Ποιότητας: ∆ιοίκηση της Ποιότητας» που σας προτείνουµε (βλέπε βιβλιογραφία στο τέλος του κεφαλαίου). Εκεί, θα βρείτε τη σχετική απάντηση για βιοµηχανίες, ενώ εµείς σας τη ζητούµε για επιχειρήσεις που παράγουν λογισµικό. Προσπαθήστε να παρουσιάσετε την απάντησή σας σε µορφή πίνακα και συζητήστε την αναφορά σας µε το Σύµβουλο – Καθηγητή σας.

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

154

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 ™ÂÏ›‰· 155

6 . 1 ∆∞ ¢ π ∂ £ ¡ ∏ ¶ ƒ √ ∆ À ¶ ∞ I S O

λοποίησης. Το γεγονός αυτό δίνει το πλεονέκτηµα σε µία επιχείρηση να έχει ένα µεγάλο φάσµα επιλογών για το πώς να χειριστεί την κάθε απαίτηση ποιότητας (που θέτει το συγκεκριµένο πρότυπο), σύµφωνα µε τις ανάγκες και ιδιαιτερότητες της επιχείρησης. Βέβαια, αυτό το χαρακτηριστικό του προτύπου αποτελεί, ανάλογα µε τις συνθήκες, και µειονέκτηµα, αφού δεν περιλαµβάνει όλες εκείνες τις λεπτοµέρειες που είναι απαραίτητο να ληφθούν υπόψη για την ολοκλήρωση µε επιτυχία µιας λειτουργίας. Παρόλα αυτά, οι περισσότερες επιχειρήσεις προτιµούν να έχουν πολλές επιλογές στον καθορισµό του συστήµατος ποιότητάς τους. Το ISO 9001 αποτελείται από ένα σύνολο απαιτήσεων ποιότητας, είναι δοµηµένο δηλαδή µε βάση µία συνεχή αρχιτεκτονική (continuous architecture), γεγονός που σηµαίνει ότι το µοντέλο δεν είναι δοµηµένο σε επίπεδα. Η συνεχής αρχιτεκτονική προσφέρει µεγάλη ευελιξία, όσον αφορά στην εκτέλεση των δραστηριοτήτων, αφού επιτρέπει στον κάθε οργανισµό να αποφασίσει για την προτεραιότητα και τη διάταξη των διεργασιών. Επιπλέον, είναι δυνατή η προσθήκη νέων απαιτήσεων στο σύστηµα ποιότητας της επιχείρησης, αν αυτό κρίνεται απαραίτητο, χωρίς να αλλάζει η πιστοποίηση κατά ISO. Τέλος, το βασικότερο πλεονέκτηµα της πιστοποίησης µε ISO 9001 είναι ότι η επιχείρηση βεβαιώνει µε αυτή την πιστοποίηση την ικανότητά της να τηρεί διαδικασίες ποιότητας που της εξασφαλίζουν την αποδοχή σε συµβάσεις έργων, ή στην αγορά των προϊόντων που παράγει. Αναλύοντας τα µειονεκτήµατα, πρέπει να αναφέρουµε ότι το βασικότερο µειονέκτηµα που προκύπτει από την εφαρµογή του προτύπου ISO 9001 είναι ότι αυτό καθορίζει τις ελάχιστες απαιτήσεις ενός συστήµατος ποιότητας, δηλαδή δεν αποτελεί ένα πλήρες σύστηµα διασφάλισης ποιότητας για έναν οργανισµό. Επίσης, λόγω της γενικότητάς του, δεν λαµβάνει υπόψη του τις ιδιαιτερότητες του κάθε προϊόντος, ώστε να είναι ικανό να προβλέψει κάθε πιθανό πρόβληµα και να θέσει µια πορεία αντιµετώπισής του. Επίσης, το ISO 9001 δεν δίνει την απαραίτητη έµφαση στη συνεχή βελτίωση των διεργασιών ανάπτυξης της επιχείρησης. Αυτό, ίσως, εµπεριέχεται στην απαίτηση ποιότητας «∆ιορθωτικές και προληπτικές ενέργειες (corrective and preventive actions), αλλά επειδή ο ανταγωνισµός που επικρατεί σήµερα θέτει τη βελτίωση της ποιότητας ως τον πιο σηµαντικό στόχο µιας επιχείρησης, θεωρείται ότι ένα πρότυπο ποιότητας πρέπει να εστιάζει σε αυτό το σηµείο πιο δυναµικά. Τέλος, το ISO 9001 διακρίνεται από µία ασάφεια σχετικά µε το ρόλο της µέτρησης σε ένα σύστηµα διαχείρισης ποιότητας. Με άλλα λόγια, θέτει µεν την απαίτηση ένας οργανισµός να τεκµηριώνει τα αντικείµενα ποιότητας, αλλά δεν θεωρεί ότι είναι αναγκαία η ποσοτικοποίησή τους.

155

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

K E º A § A I O 6 : ¶ ƒ √ ∆ À ¶ ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

156

ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏﬁÁËÛË˜ 6.1 Ακολουθούν µερικές προτάσεις. Ποιες από αυτές είναι σωστές και ποιες λάθος; ∆είτε στο τέλος του βιβλίου τις σωστές απαντήσεις, καθώς και την αιτιολόγηση για κάθε απάντηση. Σωστό

Λάθος

❏

ii) Για να πιστοποιηθεί µία επιχείρηση µε το πρότυπο ISO 9001 πρέπει να ικανοποιεί τις 20 απαιτήσεις του προτύπου. ❏

❏

iii) Η πιστοποίηση µε το πρότυπο ISO 9001 σε µία επιχείρηση γίνεται από έναν εξωτερικό ελεγκτή µία φορά και ισχύει για πάντα.

❏

iv) Το γεγονός ότι το πρότυπο ISO 9001 είναι πολύ γενικό είναι και πλεονέκτηµα (γιατί επιτρέπει µεγάλη ελευθερία στην επιχείρηση να εφαρµόσει το δικό της σύστηµα ποιότητας), αλλά και µειονέκτηµα (γιατί λόγω της γενικότητάς του, δεν λαµβάνει υπόψη του τις ιδιαιτερότητες του κάθε προϊόντος, ώστε να είναι ικανό να προβλέψει κάθε πιθανό πρόβληµα και να θέσει µια πορεία αντιµετώπισής του). ❏

❏

v) Το ISO 9001 δεν είναι απόλυτα σαφές στο θέµα των µετρήσεων για τη βελτίωση της ποιότητας.

❏

i) Το πρότυπο ISO 9001 αφορά στη διασφάλιση ποιότητας στη βιοµηχανική παραγωγή, ενώ το πρότυπο ISO 9000 – 3 στην ανάπτυξη λογισµικού.

❏

6.2 ∆Ô ÚﬁÙ˘Ô ·ÍÈÔÏﬁÁËÛË˜ CMM

Σε αυτή την ενότητα θα µιλήσουµε για το µοντέλο ωριµότητας ικανότητας (Capability Maturity Model), που από αυτό το σηµείο και µετά θα το ονοµάζουµε CMM. To CMM είναι ένα µοντέλο αξιολόγησης που εξελίχθηκε σταδιακά σε πρότυπο όχι µόνο αξιολόγησης, αλλά και πρότυπο ποιότητας λογισµικού –ακολουθώντας τις οδηγίες για κάθε βασική περιοχή της διαδικασίας (key process area) που θα συζητήσουµε παρακάτω. Στο τµήµα 6.2.1 που ακολουθεί, παρουσιάζουµε συνοπτικά το CMM, τους λόγους που οδήγησαν στη δηµιουργία του και την εξέλιξή του. Στο τµήµα 6.2.2, παρουσιάζονται οι οµοιότητες και διαφορές του CMM µε το ISO 9001, ενώ στο τµήµα 6.2.3 παρουσιάζονται τα πέντε επίπεδα ωριµότητας σύµφωνα µε το CMM.

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

6.2 ∆√ ¶ƒ√∆À¶√ ∞•π√§√°∏™∏™ CMM

6.2.1 √ÚÈÛÌﬁ˜ Î·È ÂÍ¤ÏÈÍË ÙÔ˘ 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) όπως τις ονοµάζει, οι οποίες δίνουν οδηγίες για το τι πρέπει να έχει εντάξει µία επιχείρηση στη διαδικασία ανάπτυξης ώστε να βρίσκεται σε κάποιο επίπεδο ωριµότητας. Αυτές

157

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

K E º A § A I O 6 : ¶ ƒ √ ∆ À ¶ ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

158

οι βασικές περιοχές της διαδικασίας, ουσιαστικά, αποτελούν ένα κλιµακωτό πρότυπο ποιότητας που βοηθά την κάθε επιχείρηση να βελτιώνεται βήµα µε βήµα. Αυτή η δυνατότητα του CMM να βοηθά την επιχείρηση να εξελίσσεται σταδιακά, σε συνδυασµό µε την εξειδίκευσή του αποκλειστικά για την ανάπτυξη λογισµικού, το έχουν καταστήσει ως το κυρίαρχο πρότυπο στα περισσότερα συστήµατα ποιότητας επιχειρήσεων που αναπτύσσουν λογισµικό παγκοσµίως. Έτσι πέρα από αυτό που ήταν όταν αρχικά ξεκίνησε (ένα µοντέλο αξιολόγησης της ωριµότητας των επιχειρήσεων), το CMM σήµερα καθορίζει τις διαδικασίες ποιότητας των επιχειρήσεων. ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏﬁÁËÛË˜ 6.2 Συµπληρώστε τις παρακάτω προτάσεις επιλέγοντας µία από τις προτεινόµενες λέξεις που ακολουθούν: α) Το CMM είναι ένα …………… αξιολόγησης που εξελίχθηκε σε ………………. ποιότητας λογισµικού. (πρότυπο, σύστηµα, µοντέλο, εγχειρίδιο) (πρότυπο, σύστηµα, µοντέλο, εγχειρίδιο) β) Μία …………… επιχείρηση ανάπτυξης λογισµικού έχει …………… διαχείρισης της ανάπτυξης του λογισµικού. (ικανή, ώριµη, πιστοποιηµένη) (ωριµότητα, ικανότητα, εµπειρία) γ) Το CMM είναι ένα µοντέλο µε το οποίο µπορεί µία επιχείρηση να αξιολογήσει πόσο …………… είναι σχετικά µε την ……………… να αναπτύσσει λογισµικό. (ικανή, ώριµη, έµπειρη) (ωριµότητά της, ικανότητά της, εµπειρία της) δ) Tο CMM βοηθά την επιχείρηση να εξελίσσεται ……………………………… (γρήγορα, σταδιακά, οικονοµικά, αξιόπιστα)

6.2.2 CMM Î·È ISO 9001: √ÌÔÈﬁÙËÙÂ˜ Î·È ‰È·ÊÔÚ¤˜

Το ISO 9001 µε το CMM έχουν σηµαντικές οµοιότητες, αλλά και διαφορές [Pau94]. Βασική τους οµοιότητα είναι ότι και τα δύο αποτελούν πρότυπα ποιότητας για αποτελεσµατική διαχείριση των διαδικασιών ανάπτυξης λογισµικού. Και τα δύο παρέχουν µεθοδολογίες βελτίωσης της διαδικασίας ανάπτυξης (process improvement methodologies), δηλαδή, καθορίζουν τα απαραίτητα χαρακτηριστικά για τη «σωστή» ανάπτυξη του προϊόντος, προς την κατεύθυνση της εκπλήρωσης κάποιων απαιτήσεων ποιότητας.

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

6.2 ∆√ ¶ƒ√∆À¶√ ∞•π√§√°∏™∏™ CMM

Άλλη οµοιότητά τους έγκειται στον τρόπο εφαρµογής τους. Μία επιχείρηση πιστοποιείται µε 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, που συνήθως αναφέρο-

159

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

K E º A § A I O 6 : ¶ ƒ √ ∆ À ¶ ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

160

■ «Αν δεν ξέρεις

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

νται σε ελλείψεις του ISO 9001 (όπως για παράδειγµα στον καθορισµό διαδικασιών µέτρησης), αλλά δεν είναι σηµαντικές. Μία επιχείρηση µπορεί να είναι πιστοποιηµένη µε ISO 9001 και ταυτόχρονα να έχει αξιολογηθεί σε κάποιο επίπεδο του CMM. Συνήθως, µία επιχείρηση πρέπει να φτάσει στο 2ο επίπεδο του CMM και να διαθέτει κάποιες βασικές περιοχές και του 3ου επίπεδου (θα µιλήσουµε αργότερα για τα επίπεδα του CMM), ώστε να µπορέσει να πιστοποιηθεί µε ISO 9001. Στην Ευρώπη, οι περισσότερες επιχειρήσεις που αναπτύσσουν λογισµικό είναι αξιολογηµένες µε CMM και πιστοποιηµένες µε ISO 9001. 6.2.3 ∂›Â‰· ˆÚÈÌﬁÙËÙ·˜ ÛÙÔ 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 ™ÂÏ›‰· 161

6.2 ∆√ ¶ƒ√∆À¶√ ∞•π√§√°∏™∏™ CMM

161

µε στην ανάλυση όλων των βασικών περιοχών και των βασικών πρακτικών, σας καλούµε όµως να υλοποιήσετε τη δραστηριότητα 6.3 που ακολουθεί. Σήµερα, στον κόσµο, πολύ λίγες επιχειρήσεις λογισµικού βρίσκονται στο επίπεδο 5. Στην Ελλάδα, οι περισσότερες επιχειρήσεις είναι στο επίπεδο 1 µε λίγες στο επίπεδο 2, ελάχιστες στο 3 και καµία στο 4 και 5. Συνοπτικά, τι συµβαίνει σε µία επιχείρηση σε κάθε επίπεδο ωριµότητας του CMM, περιγράφεται στα τµήµατα που ακολουθούν µετά τη δραστηριότητα 6.3. ¢Ú·ÛÙËÚÈﬁÙËÙ· ÁÈ· ÂÚ·ÈÙ¤Úˆ ÌÂÏ¤ÙË 6.3 Από τις πηγές που σας αναφέρουµε στη βιβλιογραφία και από αναζητήσεις στο διαδίκτυο (για παράδειγµα µια επίσκεψη στον κόµβο του Software Engineering Institute µπορεί να είναι πολύ καλή ιδέα), ετοιµάστε µία αναφορά που θα παρουσιάζει σε λιγότερες από 2000 λέξεις τις βασικές περιοχές για κάθε επίπεδο και τις βασικές πρακτικές για κάθε περιοχή. Συζητήστε την αναφορά σας µε το Σύµβουλο – Καθηγητή σας.

Επίπεδο 1 – Αρχικό Επίπεδο Στο επίπεδο αυτό, η διαδικασία ανάπτυξης λογισµικού είναι τυχαία και χαοτική. Πολύ λίγες διαδικασίες είναι καθορισµένες και η επιτυχία εξαρτάται από την ατοµική προσπάθεια. Η επιχείρηση δεν παρέχει ένα σταθερό περιβάλλον για την ανάπτυξη και τη συντήρηση του λογισµικού. Η επιτυχία εξαρτάται, συνήθως, από τις ηρωικές προσπάθειες ικανότατων στελεχών. Οι δυνατότητες της διαδικασίας ανάπτυξης λογισµικού δεν είναι προβλέψιµες (άρα και οι δυνατότητες και προοπτικές της επιχείρησης), εξαιτίας του γεγονότος ότι η διαδικασία αλλάζει ή τροποποιείται κατά τη διάρκεια της εξέλιξης του έργου. Γενικά, σε αυτό το επίπεδο, τα προγράµµατα, οι προϋπολογισµοί, η λειτουργικότητα και η ποιότητα του προϊόντος είναι µη προβλέψιµοι παράγοντες. Επίπεδο 2 – Επαναλαµβανόµενο Επίπεδο Στο επίπεδο αυτό εγκαθιδρύονται οι βασικές διαδικασίες διαχείρισης του έργου για την εκτίµηση κόστους, το χρονοπρογραµµατισµό, την παρακολούθηση (monitoring) και τον καθορισµό της λειτουργικότητας. Υπάρχει πειθαρχία στην ανάπτυξη του έργου, µε στόχο την επανάληψη προηγούµενων επιτυχιών σε έργα µε παρόµοια χαρακτηριστικά. Ο σχεδιασµός και η διαχείριση νέων έργων βασίζονται στην προηγούµενη εµπειρία παρόµοιων έργων. Συνεπώς, βασική προϋπόθεση για την αξιολό-

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

K E º A § A I O 6 : ¶ ƒ √ ∆ À ¶ ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

162

γηση µίας επιχείρησης στο επίπεδο αυτό είναι η εγκαθίδρυση αποτελεσµατικών διεργασιών διαχείρισης για έργα λογισµικού, οι οποίες να επιτρέπουν την επανάληψη των επιτυχηµένων διαδικασιών προηγούµενων έργων. Η ικανότητα της διαδικασίας ανάπτυξης λογισµικού, στους οργανισµούς του επιπέδου αυτού, χαρακτηρίζεται ως πειθαρχηµένη (disciplined), επειδή ο σχεδιασµός και η παρακολούθηση του έργου είναι σταθεροί παράγοντες και προηγούµενες επιτυχίες µπορούν να επαναληφθούν. Επίπεδο 3 – Καθορισµένο Επίπεδο Σε αυτό το επίπεδο, οι διαδικασίες για την ανάπτυξη και διαχείριση είναι τεκµηριωµένες, τυποποιηµένες και ολοκληρωµένες σε µία καθορισµένη διαδικασία για όλη την επιχείρηση. Ο οργανισµός εκµεταλλεύεται αποτελεσµατικά τις αρχές τεχνολογίας λογισµικού, χρησιµοποιώντας τυποποιηµένες διαδικασίες ανάπτυξης. Η συνολική καθορισµένη διαδικασία της επιχείρησης συµπεριλαµβάνει πρότυπα και τεχνικές για την ολοκλήρωση επιµέρους εργασιών, µετρικές και µηχανισµούς ελέγχου και επαλήθευσης. Η ικανότητα της διαδικασίας ανάπτυξης λογισµικού στους οργανισµούς του επιπέδου αυτού χαρακτηρίζεται ως τυποποιηµένη (standard) και συνεπής (consistent) και βασίζεται στην κατανόηση των δραστηριοτήτων, των ρόλων και των υπευθυνοτήτων στη λειτουργία της επιχείρησης. Επίπεδο 4 – ∆ιοικούµενο Επίπεδο Σε αυτό το επίπεδο ωριµότητας, πραγµατοποιείται συλλογή καθορισµένων µετρήσεων που αφορούν στη διαδικασία ανάπτυξης και την ποιότητα των προϊόντων, µε συνέπεια τόσο οι διαδικασίες, όσο και τα προϊόντα να αξιολογούνται µε ποσοτικά δεδοµένα. Με άλλα λόγια, ο οργανισµός θέτει ποσοτικούς στόχους ποιότητας για τις διαδικασίες ανάπτυξης και το ίδιο το λογισµικό, ενώ η παραγωγικότητα και η ποιότητα µετρώνται κατά τη διάρκεια εκτέλεσης όλων των έργων και εντάσσονται σε ένα πρόγραµµα µέτρησης. Η ικανότητα της διαδικασίας ανάπτυξης λογισµικού στους οργανισµούς του επιπέδου αυτού χαρακτηρίζεται ως προβλέψιµη (predictable) και λειτουργεί µέσα σε καθορισµένα όρια. Σε περίπτωση υπέρβασης των ορίων αυτών γίνονται ενέργειες για τη διόρθωση της κατάστασης. Επίπεδο 5 – Επίπεδο Βελτιστοποίησης Στο επίπεδο ωριµότητας 5, γίνεται δυνατή η συνεχής βελτίωση των διαδικασιών ανάπτυξης και διαχείρισης µέσω µιας ποσοτικής ανάδρασης από τις ίδιες τις διαδικασίες και µε την εφαρµογή καινοτοµικών ιδεών και τεχνολογιών. Έτσι, ολόκληρος ο οργανισµός εστιάζει στη συνεχή βελτίωση της ανάπτυξης λογισµικού. Οι οµάδες του έργου

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

6.2 ∆√ ¶ƒ√∆À¶√ ∞•π√§√°∏™∏™ CMM

163

λογισµικού αναλύουν τις ατέλειες µιας διαδικασίας, προκειµένου να καθορίσουν τις βασικές αιτίες τους και οι διαδικασίες ποιότητας ακολουθούν και αυτές τον ίδιο τον κανόνα (δηλαδή και το σύστηµα ποιότητας βελτιώνεται δυναµικά). Η ικανότητα της διαδικασίας ανάπτυξης λογισµικού στους οργανισµούς του επιπέδου αυτού χαρακτηρίζεται ως συνεχώς βελτιώσιµη (constantly improving). Η βελτίωση αυτή οφείλεται σε καινοτοµίες από την εφαρµογή νέων τεχνολογιών και µεθόδων. ÕÛÎËÛË ·˘ÙÔ·ÍÈÔÏﬁÁËÛË˜ 6.3 Ακολουθούν µερικές προτάσεις. Ποιες από αυτές είναι σωστές και ποιες λάθος; ∆είτε στο τέλος του βιβλίου τις σωστές απαντήσεις, καθώς και την αιτιολόγηση για κάθε απάντηση. Σωστό

Λάθος

❏

ii) ∆ιαφορά του CMM µε το ISO 9001 είναι ότι, ενώ στο CMM η αξιολόγηση γίνεται εσωτερικά στην επιχείρηση από προσωπικό της επιχείρησης, στο ISO 9001 ο έλεγχος γίνεται από εξωτερικό ελεγκτή. ❏

❏

iii) Μια επιχείρηση που αναπτύσσει λογισµικό πρέπει να επιλέξει ή να πιστοποιηθεί µε ISO 9001, ή να αξιολογηθεί µε CMM, αφού δεν µπορεί να έχει και τα δύο. ❏

❏

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

❏

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

❏

i) Οµοιότητα του CMM µε το ISO 9001 είναι ότι και τα δύο είναι γενικά για όλα τα υλικά αγαθά και όχι εξειδικευµένα στο λογισµικό.

❏

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

K E º A § A I O 6 : ¶ ƒ √ ∆ À ¶ ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

164

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

❏

¢Ú·ÛÙËÚÈﬁÙËÙ· ÁÈ· ÂÚ·ÈÙ¤Úˆ ÌÂÏ¤ÙË 6.4 Εκτός από τα πρότυπα της σειράς ISO και το CMM υπάρχουν και άλλα µοντέλα ποιότητας, όπως τα πρότυπα του IEEE και τα πολύ διαδεδοµένα στην Αµερική βραβεία ποιότητας Baldrige (που δεν είναι πρότυπο, αλλά βραβεία και οδηγίες για το πώς να αναπτυχθεί ένα σύστηµα ποιότητας). Από αναζητήσεις στο διαδίκτυο, ετοιµάστε µία αναφορά που θα παρουσιάζει σε λιγότερες από 1000 λέξεις τα πρότυπα του IEEE για την ποιότητα και τα βραβεία Baldrige. Συζητήστε την αναφορά σας µε το Σύµβουλο – Καθηγητή σας.

™‡ÓÔ„Ë ÎÂÊ·Ï·›Ô˘ Î·È ™˘Ì‚Ô˘Ï¤˜ ªÂÏ¤ÙË˜ Σε αυτό το κεφάλαιο, µιλήσαµε για πρότυπα που σχετίζονται µε την ανάπτυξη του λογισµικού και ειδικότερα για τα πρότυπα του διεθνούς οργανισµού ISO που σχετίζονται µε την ποιότητα, δίνοντας έµφαση στο πρότυπο ISO 9001 και στην οδηγία ISO 9000 – 3. Επίσης, παρουσιάσαµε το µοντέλο αξιολόγησης CMM, τα επίπεδα ωριµότητάς του και αναλύσαµε τις οµοιότητες και διαφορές του µε το ISO 9001. Σε αρκετά σηµεία του κεφαλαίου δεν επεκταθήκαµε σε λεπτοµερή παρουσίαση όλων των εσωτερικών µετρικών, ή στην ανάλυση των εξωτερικών µετρήσεων, αφήνοντάς σας να τις µελετήσετε από µόνοι σας. Σε αυτό το σκοπό θα σας βοηθήσει η βιβλιογραφία που ακολουθεί µε προτεινόµενα βιβλία για περαιτέρω µελέτη, στα οποία σας υποδεικνύουµε πού να επικεντρώσετε την προσοχή σας.

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

XXX

µÈ‚ÏÈÔÁÚ·Ê›· Î·È ÚÔÙ¿ÛÂÈ˜ ÁÈ· ÂÚ·ÈÙ¤Úˆ ÌÂÏ¤ÙË

Ακολουθεί η βιβλιογραφία του κεφαλαίου 6. Τα επιλεγµένα βιβλία που σχολιάζονται είναι αυτά που σας προτείνονται για περαιτέρω µελέτη στα θέµατα που καλύψαµε στο κεφάλαιο 6. Τα βιβλία αυτά συνοδεύονται από σχόλια για το πού να επικεντρώσετε τη µελέτη σας σχετικά µε τα θέµατα του κεφαλαίου 6, αλλά και πληροφορίες για τη µελέτη σας. [Ham96] Brian Hambling, «Managing Software Quality», McGraw–Hill, (1996). Είναι ένα βιβλίο αφιερωµένο κυρίως στο πρότυπο 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).

165

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

166

K E º A § A I O 6 : ¶ ƒ √ ∆ À ¶ ∞ ¶ √ π √ ∆ ∏ ∆∞ ™ § √ ° π ™ ª π ∫ √ À

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

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

∂›ÏÔÁÔ˜

Σε αυτό το βιβλίο, καλύψαµε τα θέµατα της διαχείρισης της ανάπτυξης λογισµικού και της ποιότητας λογισµικού. Αν, ανοίγοντας κάθε σελίδα του βιβλίου, µπορείτε να λύσετε κάθε άσκηση και δραστηριότητα, τότε είστε έτοιµοι για τις εξετάσεις του Ελληνικού Ανοικτού Πανεπιστηµίου. Αν, επιπλέον, νιώθετε ότι αυτά που µάθατε από αυτό το βιβλίο σας βοήθησαν πραγµατικά στην κατανόηση ενός µικρού µέρους από αυτό που ονοµάζουµε «Πληροφορική», τότε το βιβλίο πέτυχε πραγµατικά το σκοπό του. «∆ÂÏÂÙ‹ ‰¤ ÙÉ˜ Ï¤ÍÂˆ˜ êÚÌÔÙÂÖ ì àÛ‡Ó‰ÂÙÔ˜ ¬ˆ˜ â›ÏÔÁÔ˜ àÏÏa Ìc ÏﬁÁÔ˜ j «ÂúÚËÎ·, àÎËÎﬁ·ÙÂ, ö¯ÂÙÂ, ÎÚ›Ó·ÙÂ». Aριστοτέλης, ΡΗΤΟΡΙΚΗ, Γ’, 19 1420α, 7 – 9

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

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

∞·ÓÙ‹ÛÂÈ˜ ·ÛÎ‹ÛÂˆÓ ·˘ÙÔ·ÍÈÔÏﬁÁËÛË˜

1.1 i) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Το λογισµικό δεν κατασκευάζεται µε αντίστοιχο τρόπο µε την παραγωγή υλικών αγαθών, αλλά αναπτύσσεται. ii) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Μπράβο σας αν απαντήσατε έτσι. iii) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Μιλήσαµε για τη διαφορά της διοίκησης µε τον υπεύθυνο διαχείρισης ενός έργου λογισµικού. Βέβαια ο υπεύθυνος διαχείρισης ενός έργου λογισµικού θα µπορούσε να ήταν και µέλος της διοίκησης του οργανισµού, αλλά δεν ισχύει πάντα κάτι τέτοιο. iv) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Επειδή η τεχνολογία ανάπτυξης λογισµικού εξελίσσεται µε ταχύτατους ρυθµούς, για αρκετά έργα ανάπτυξης λογισµικού δεν έχουµε καθόλου ιστορικά δεδοµένα, ή τα ιστορικά δεδοµένα δεν είναι αξιοποιήσιµα. ∆εν σηµαίνει όµως αυτό ότι ποτέ δεν υπάρχουν ιστορικά δεδοµένα. Μπράβο σας αν δώσατε τη σωστή απάντηση. v) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Μην αγχώνεστε αν δεν δώσατε τη σωστή απάντηση! Αυτή ήταν µια «πονηρή» ερώτηση περισσότερο για να σας κεντρίσει το ενδιαφέρον και για να µπορέσουµε να συζητήσουµε λίγο τι εννοούµε «διαφάνεια». Όπως θα δούµε στη συνέχεια της µελέτης σας, µιλάµε για τη δυνατότητα του υπεύθυνου έργου να παρακολουθεί πλήρως την πορεία εξέλιξης του έργου και όχι για αυτό που στην καθοµιλουµένη εννοούµε όταν µιλάµε για «αδιαφανείς διαδικασίες». 1.2 Η σωστή απάντηση είναι η iii) δηλαδή να συνεργαστεί µε την Ασπασία ώστε να ετοιµάσει αυτός µία πρόταση για νέο έργο, έχοντας τη βοήθεια της Ασπασίας για τα τεχνικά θέµατα και να την παρουσιάσει µαζί µε την Ασπασία, αναφέροντας ότι είναι ιδέα της Ασπασίας. Μπράβο σας αν απαντήσατε σωστά γιατί αν και µοιάζει εύκολο δεν είναι καθόλου. Ας δούµε γιατί οι άλλες απαντήσεις είναι λάθος: i) Αν κάνει κάτι τέτοιο, τότε µόλις το έργο εγκριθεί θα µαθευτεί από όλους τους υφιστάµενους και πιθανότατα και προϊστάµενους αφού η Ασπασία ίσως να διαµαρτυρηθεί. Ακόµα κι αν δεν το κάνει, ο Περικλής θα γίνει αντιπαθής στους υφισταµένους του και το σηµαντικότερο κανένας από αυτούς δεν θα του ξαναπεί κάποια ιδέα, η ακόµα χειρότερα θα προτιµήσει να τον παρακάµψει. ii) Η Ασπασία ως νεοδιοριζόµενη προγραµµατίστρια πιθανότατα δεν έχει την εµπει-

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

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

170

ρία του Περικλή στον καθορισµό του έργου, στην εκτίµηση, την ανάλυση ρίσκου, την κοστολόγηση, τη συνεργασία µε τον πελάτη και την παρουσίασή του. Σίγουρα η Ασπασία θα ήθελε τη βοήθεια του Περικλή σε αυτά τα θέµατα. Εάν δεν την έχει, είναι πολύ πιθανό να αποτύχει να πείσει για το έργο και να απογοητευτεί στο να προτείνει κάτι νέο. Είναι πιθανόν έτσι η καλή της ιδέα να λειτουργήσει ως αντιπαράδειγµα δίνοντας την εντύπωση σε όλους ότι καλύτερη λογική είναι «να µην µπλέκεις µε πράγµατα που δεν είναι δουλειά σου». iii) Είναι το καλύτερο που έχει να κάνει ο Περικλής. Η Ασπασία θα µάθει από την πείρα του Περικλή και θα τον εκτιµήσει περισσότερο, βλέποντάς τον να διορθώνει τα λάθη της και να προβάλει την ιδέα της. Επίσης θα νιώσει χαρά όταν θα την παρουσιάσει µαζί µε τον Περικλή. Τέλος οι άλλοι υφιστάµενοι του Περικλή θα θελήσουν να µιµηθούν την Ασπασία και θα έχουν και οι ίδιοι αντίστοιχες ιδέες. Ίσως ο Περικλής για κάποιο διάστηµα να αρχίσει να βοµβαρδίζεται µε νέες ιδέες που θα απορρίπτει τις περισσότερες (στην προσπάθεια όλων να µιµηθούν την Ασπασία), αλλά σίγουρα αξίζει τον κόπο να τις ακούσει όλες. iv) Ίσως να σας προξενήσει κατάπληξη, αλλά και αυτό εµπεριέχει µία δόση αλήθειας! ∆εν µιλάµε για προσωπικές βλέψεις του Περικλή για την Ασπασία, αλλά όταν το έργο (η ιδέα της Ασπασίας) εγκρινόταν, ένας καλός υπεύθυνος έργου θα έβγαζε, όχι µόνο την Ασπασία, αλλά όλη την οµάδα των άµεσων συνεργατών του για δείπνο πιθανότατα πληρωµένο από την εταιρία. 1.3 i) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Μη συγχέετε τη διαδικασία που γίνεται στη φάση του προγραµµατισµού έργου µε τη σχεδίαση του έργου. ii) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Είναι ο ορισµός του χρονοπρογραµµατισµού. iii) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Αυτό που ισχύει είναι το αντίστροφο. Η επίτευξη ενός ορόσηµου θα πρέπει να οδηγεί σε τεκµηρίωση µε τη µορφή έκθεσης προόδου (progress report). iv) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Είναι βασική δουλειά του υπεύθυνου έργου. v) Η σωστή απάντηση είναι «ΣΩΣΤΟ». vi) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Αντίθετα τονίσαµε τη σηµασία της τεκµηρίωσης και το ότι –κακώς– µερικές φορές η τεκµηρίωση υποτιµάται για κάποια έργα. Μπράβο σας αν απαντήσατε σωστά σε όλες τις ερωτήσεις. Σε αντίθετη περίπτωση πρέπει οπωσδήποτε να ξαναδιαβάσετε την ενότητα 1.2.1 και να επαναλάβετε την

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

∞¶∞¡∆∏™∂π™ ∞™∫∏™∂ø¡ ∞À∆√∞•π√§√°∏™∏™

άσκηση, αφού φυσικά αφήσετε να περάσει λίγος χρόνος από την επανάληψη. Γενικά είναι καλό να δοκιµάσετε να ξαναλύσετε τις ασκήσεις µετά την πάροδο κάποιου χρόνου από την πρώτη φορά που τις λύσατε, ακόµα κι αν τις λύσατε σωστά την πρώτη φορά. 1.4 i) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Εάν απαντήσατε διαφορετικά καλύτερα αφιερώστε λίγο χρόνο για να διαβάσετε ξανά τις ενότητες 1.3.6 και 1.3.7. Προσωπικό µίας επιχείρησης είναι και άνθρωποι που δεν συµµετέχουν στην ανάπτυξη λογισµικού. Επίσης ο πελάτης αν και συµµετέχει στη διαδικασία ανάπτυξης λογισµικού δεν ανήκει στο προσωπικό της επιχείρησης. ii) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Αν και θα µπορούσε να συµµετέχει (π.χ να είναι µέλος του ∆ιοικητικού Συµβουλίου), αυτό δεν είναι κανόνας. Ο ρόλος του συνήθως είναι να συµβουλεύει τη διοίκηση. iii) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Ο υπεύθυνος έργου έχει πιο εύκολο ρόλο όταν µιλά µε τους ηγέτες οµάδων και αυτοί µε τη σειρά τους µεταβιβάζουν τις εντολές του στις οµάδες τους. iv) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Αυτό είναι δουλειά µηχανικού ανάπτυξης και ειδικότερα του σχεδιαστή. Προσέξτε: κάποιος προγραµµατιστής θα µπορούσε να εξελιχθεί σε µηχανικό ανάπτυξης και να αναλάβει τη σχεδίαση, αλλά η πρόταση δεν µιλάει για αυτό. v) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Σε περίπτωση αντίθετης απάντησης θα πρότεινα µία αρκετά καλή επανάληψη, όχι µόνο στην ενότητα 1.3.7, αλλά σε όλο το κεφάλαιο. Μπράβο σας αν απαντήσατε σωστά σε όλες τις ερωτήσεις. Μπορεί να µοιάζουν εύκολες, αλλά δεν είναι. Σε αντίθετη περίπτωση θα πρέπει να αφιερώσετε κάποιο χρόνο για επανάληψη της ενότητας 1.3, ίσως και διαβάζοντας ξανά τα σχετικά θέµατα της τεχνολογίας λογισµικού που αφορούν τους συµµετέχοντες στην ανάπτυξη λογισµικού. Ένα καλό βιβλίο να σας βοηθήσει είναι το βιβλίο του Ince [Inc95] που σας προτείνουµε στη βιβλιογραφία. 1.5 i) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Και οι τρεις τρόποι οργάνωσης έχουν πλεονεκτήµατα και µειονεκτήµατα και οι παράγοντες του προβλήµατος είναι αυτοί που καθορίζουν τον τρόπο επιλογής της οργάνωσης της οµάδας.

171

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

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

172

ii) Η σωστή απάντηση είναι «ΣΩΣΤΟ». ∆εν το αναλύσαµε στην ενότητα 1.4.1, αλλά προκύπτει από τον ορισµό των δηµοκρατικά διοικούµενων οµάδων. Μπράβο σας αν απαντήσατε σωστά. iii) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Οι οµάδες αυτές έχουν πρόβληµα για έργα που έχουν µεγάλη χρονική διάρκεια, αλλά είναι πιο αποδοτικές (λόγω της αµεσότητας των αποφάσεων και των καθορισµένων ρόλων) για σύντοµης διάρκειας έργα. iv) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Μιλήσαµε για αυτό στην ενότητα 1.4.2. Μπράβο σας αν απαντήσατε σωστά σε όλες τις ερωτήσεις. Σε αντίθετη περίπτωση πρέπει οπωσδήποτε να ξαναδιαβάσετε την ενότητα 1.4 και να επαναλάβετε την άσκηση, αφού φυσικά αφήσετε να περάσει λίγος χρόνος από την επανάληψη. 2.1 Οι σωστές επιλογές είναι: Μέγεθος του έργου, πολυπλοκότητα του έργου, ιστορικά δεδοµένα, λεπτοµερείς απαιτήσεις έργου και σταθερές απαιτήσεις έργου. Η ικανότητα του προσωπικού ανάπτυξης σχετίζεται µε το αποτέλεσµα της εκτίµησης, αλλά όχι µε την ακρίβειά της. Οι βάσεις δεδοµένων πιθανόν να σας µπέρδεψαν αφού σε βάσεις δεδοµένων θα µπορούσαν να αποθηκεύονται τα ιστορικά δεδοµένα, ενώ ο σχεδιασµός του έργου είναι φάση της ανάπτυξης και δεν σχετίζεται µε την εκτίµηση παραγόντων όπως οι ανάγκες σε ανθρώπινο δυναµικό, το κόστος και ο χρόνος. 2.2 Οι σωστές προτάσεις δίνονται παρακάτω. Μπράβο σας αν τις συµπληρώσατε µε επιτυχία. α) Η καθυστέρηση της εκτίµησης είναι συνήθως η λύση που έχει τα καλύτερα αποτελέσµατα, αλλά δεν είναι πρακτική. β) Το να βασιστεί η εκτίµηση σε παρόµοια έργα που έχουν ήδη ολοκληρωθεί, µπορεί να λειτουργήσει καλά, αν το συγκεκριµένο έργο το οποίο θέλουµε να εκτιµήσουµε είναι παρόµοιο µε εκείνο το οποίο συσχετίζουµε. γ) Τα εµπειρικά µοντέλα µπορούν να χρησιµοποιηθούν επικουρικά στις τεχνικές τµηµατοποίησης και να δώσουν πολύτιµες πληροφορίες σχετικά µε τα µεγέθη που εξετάζονται. 2.3 i) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Κάτι τέτοιο συνήθως είναι απαραίτητο για

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

∞¶∞¡∆∏™∂π™ ∞™∫∏™∂ø¡ ∞À∆√∞•π√§√°∏™∏™

173

καλύτερη εκτίµηση. ii) Η σωστή απάντηση είναι «ΣΩΣΤΟ». iii) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Το «από κάτω προς τα πάνω» αναφέρεται στον τρόπο τµηµατοποίησης του έργου και όχι στην ιεραρχία αυτών που θα συµµετάσχουν στη διαδικασία της εκτίµησης παραγόντων όπως οι ανάγκες σε ανθρώπινο δυναµικό, το κόστος και ο χρόνος. iv) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Στην πραγµατικότητα είναι η πιο διαδεδοµένη. v) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Σε περίπτωση αντίθετης απάντησης θα πρότεινα µία αρκετά καλή επανάληψη, όχι µόνο στην ενότητα 2.2.1.3, αλλά σε όλο το κεφάλαιο. vi) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Αυτή ήταν δύσκολη ερώτηση, αφού για τµηµατοποίηση µιλήσαµε σε διαφορετικό κεφάλαιο, αλλά αν προσέξετε τον τρόπο εφαρµογής των τεχνικών θα δείτε ότι είναι και οι δύο τεχνικές τµηµατοποίησης. Μπράβο σας αν απαντήσατε σωστά σε όλες τις ερωτήσεις. Σε αντίθετη περίπτωση θα πρέπει να αφιερώσετε κάποιο χρόνο για επανάληψη της ενότητας 2.2. 2.4 Η σωστή αντιστοίχηση είναι η παρακάτω: οργανική κατηγορία

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

ηµι – προσαρτηµένη κατηγορία

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

ενσωµατωµένη κατηγορία

αυστηρές απαιτήσεις έργων

3.1 Οι σωστές προτάσεις δίνονται παρακάτω. Μπράβο σας αν τις συµπληρώσατε µε επιτυχία. α) Ποιότητα είναι η συλλογή των χαρακτηριστικών και των ιδιοτήτων του προϊό-

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

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

174

ντος που σχετίζονται µε τη δυνατότητά του να εκπληρώνει τις ζητούµενες ανάγκες των πελατών. 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 ™ÂÏ›‰· 175

∞¶∞¡∆∏™∂π™ ∞™∫∏™∂ø¡ ∞À∆√∞•π√§√°∏™∏™

175

η διασφάλιση της ποιότητας ενός και µοναδικού πρωτότυπου του προϊόντος. vii) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Αυτό ακριβώς αναφέρεται και στην ενότητα 3.3. 4.1 Οι σωστές προτάσεις δίνονται παρακάτω. Μπράβο σας αν τις συµπληρώσατε µε επιτυχία. α) Παράγοντες ποιότητας είναι οµάδες χαρακτηριστικών τα οποία συνθέτουν την ποιότητα ενός προϊόντος, έχουν την ελάχιστη δυνατή επικάλυψη µεταξύ τους και είναι επαρκή για τη σύνθεση της ποιότητας. β) Η θεώρηση της ποιότητας από την πλευρά του χρήστη αντιµετωπίζει την ποιότητα ως καταλληλότητα για χρήση. γ) Αξιοπιστία είναι ένα σύνολο χαρακτηριστικών που είναι φορείς της δυνατότητας του λογισµικού να διατηρεί το επίπεδο απόδοσής του σε καθορισµένες συνθήκες και για προκαθορισµένη χρονική περίοδο. 4.2 ∆ίνεται η λίστα µε τις σωστές απαντήσεις. Μπράβο σας αν απαντήσατε σε όλα σωστά, αφού ήταν µία αρκετά δύσκολη άσκηση. Εάν δεν απαντήσατε σωστά, τουλάχιστον µελετήστε τους παράγοντες ποιότητας του ISO 9126 και φροντίστε να τους γνωρίζετε και –το κυριότερο– να µπορείτε να εξηγήσετε τι σηµαίνουν. Παράγοντας ποιότητας

FCM

Boehm

ISO 9126

ακεραιότητα

❏

αξιοπιστία

❏

αποδοτικότητα

❏

ασφάλεια

❏

ελεγξιµότητα

❏

διαλειτουργικότητα

❏

επαναχρησιµοποιησιµότητα

❏

ευελιξία

❏

ευχρηστία

❏

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

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

176

κατανοησιµότητα

❏

λειτουργικότητα

❏

µεταφερσιµότητα

❏

ορθότητα

❏

προσαρµοστικότητα

❏

συντηρησιµότητα

❏

ωριµότητα

❏

4.3 i) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Αυτή είναι η κωδικοποίηση των περισσότερων προτύπων του διεθνούς οργανισµού προτοτυποποίησης ISO, αλλά υπάρχουν και άλλα πρότυπα (όπως τα πρότυπα του IEEE) που δεν ακολουθούν αυτή την κωδικοποίηση. ii) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Προκύπτει από τον ορισµό της οδηγίας στην ενότητα 4.2. iii) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Προκύπτει από τον ορισµό της ανιχνευσιµότητας. iv) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Αυτό που ισχύει είναι το αντίστροφο, δηλαδή η διασφάλιση ποιότητας διαδικασιών και πόρων έµµεσα στοχεύει στη διασφάλιση ποιότητας του προϊόντος που είναι και ο απώτερος στόχος κάθε συστήµατος ποιότητας. v) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Το εγχειρίδιο ποιότητας είναι γενικό για την επιχείρηση και συµπεριλαµβάνει όλες τις διαδικασίες, µεθόδους, τεχνικές, κτλ. που µπορούν να χρησιµοποιηθούν σε κάθε έργο. Από το εγχειρίδιο αντλούνται κάποιες διαδικασίες –διαφορετικές για κάθε έργο– που συνθέτουν το πλάνο ποιότητας ενός έργου. vi) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Αυτό που εξελίσσεται δυναµικά είναι το εγχειρίδιο ποιότητας. Το πλάνο ποιότητας είναι σταθερό για κάθε έργο, αφού δεν είναι δυνατόν οι προδιαγραφές ποιότητας που έχουµε θέσει για ένα έργο να µεταβάλλονται στην πορεία του έργου. vii) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Αυτό αποτελεί εσφαλµένη άποψη που έγκειται στο γεγονός συχνά ότι κανείς δεν υποχρεώνει τους υπεύθυνους ενός

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

∞¶∞¡∆∏™∂π™ ∞™∫∏™∂ø¡ ∞À∆√∞•π√§√°∏™∏™

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

Τι παρέχει το σύστηµα ποιότητας

Υπεύθυνος έργου

Τυποποίηςη αναφορών δραστηριοτήτων έργου. ∆ιαδικασία καταγραφής βασικών δεδοµένων έργου.

Προγραµµατιστής

Πρότυπα που να ορίζουν τον τρόπο µε τον οποίο ένα πρόγραµµα πρέπει να αναπτυχθεί (κωδικοποιηθεί).

Σχεδιαστής

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

Αναλυτής

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

4.5 i) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Η επιλογή των καλύτερων προγραµµατιστών χωρίς να υπάρχει τυποποίηση των διαδικασιών ανάπτυξης και χρήση προγραµµατιστικών προτύπων, θα αναγκάσει την επιχείρηση να βασίζεται σε ad hoc διαδικασίες που θα εφευρίσκουν αυτοί οι µηχανικοί, αυξάνοντας την εξάρτησή της από τα άτοµα. ii) Η σωστή απάντηση είναι «ΣΩΣΤΟ». Το σύστηµα ποιότητας βοηθά σε αυτή την κατεύθυνση.

177

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

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

178

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 ™ÂÏ›‰· 179

∞¶∞¡∆∏™∂π™ ∞™∫∏™∂ø¡ ∞À∆√∞•π√§√°∏™∏™

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 σε µία επιχείρηση γίνεται από έναν εξωτερικό ελεγκτή την πρώτη φορά και ο

179

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

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

180

έλεγχος επαναλαµβάνεται περιοδικά. 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 ™ÂÏ›‰· 181

∞¶∞¡∆∏™∂π™ ∞™∫∏™∂ø¡ ∞À∆√∞•π√§√°∏™∏™

iv) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Αυτό ισχύει για όλα τα επίπεδα εκτός από το 1ο επίπεδο (το αρχικό επίπεδο) όπου δεν υπάρχουν βασικές περιοχές. v) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Η ικανότητα της διαδικασίας ανάπτυξης λογισµικού στους οργανισµούς του αρχικού επιπέδου µόνο πειθαρχηµένη δεν µπορεί να χαρακτηρίζεται. Αντίθετα είναι χαοτική. Ο ορισµός αναφέρεται στο 2ο επίπεδο. vi) Η σωστή απάντηση είναι «ΛΑΘΟΣ». Τυποποιηµένη και συνεπής χαρακτηρίζεται η ικανότητα στο 4ο επίπεδο και όχι στο 5ο. Μπράβο σας αν απαντήσατε όλες τις ερωτήσεις σωστά. Σε αντίθετη περίπτωση, είναι καλό να κάνετε µία καλή επανάληψη στην ενότητα 6.2.

181

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

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

°ÂÓÈÎ‹ ‚È‚ÏÈÔÁÚ·Ê›· ∂ÏÏËÓﬁÁÏˆÛÛË

Εδώ µπορείτε να βρείτε όλη τη βιβλιογραφία στην ελληνική γλώσσα που χρησιµοποιήθηκε στο βιβλίο, διαταγµένη ανάλογα µε την κωδικοποίηση και χωρίς σχόλια. [Abo00] Νικόλαος Αβούρης, «Εισαγωγή στην Επικοινωνία Ανθρώπου – Υπολογιστή», Εκδόσεις ∆ΙΑΥΛΟΣ, (2000). [Bar96] Γ. Βαρουφάκης, «Αρχαία Ελλάδα & Ποιότητα. Η ιστορία και ο έλεγχος των υλικών που σηµάδεψαν τον ελληνικό πολιτισµό», Εκδόσεις Αίολος, (1996). [Psy00] Ν. Ψύχας, «∆ιασφάλιση Ποιότητας: ∆ιοίκηση της Ποιότητας», Ελληνικό Ανοικτό Πανεπιστήµιο, ∆ΙΠ51/2, (2000). [Ste00] Σ. Στεφανάτος, «∆ιασφάλιση Ποιότητας: Ολική Ποιότητα», Ελληνικό Ανοικτό Πανεπιστήµιο, ∆ΙΠ51/3, (2000). [Ves00] Βασίλειος Βεσκούκης, «Τεχνολογία Λογισµικού Ι: Αρχές Τεχνολογίας Λογισµικού», Ελληνικό Ανοικτό Πανεπιστήµιο, ΠΛΗ20/1, (2000). [Xen94] Μιχάλης Ξένος και ∆ηµήτρης Χριστοδουλάκης, «Τεχνολογία Λογισµικού: Αρχές και Μεθοδολογίες», Εκδόσεις Πανεπιστηµίου Πατρών, (1994). [Xen96] Μιχάλης Ξένος, «Μεθοδολογία ελέγχου και εξασφάλισης της ποιότητας λογισµικού βασισµένη στις µετρικές προϊόντος και στα εξωτερικά ποιοτικά χαρακτηριστικά του λογισµικού», ∆ιδακτορική ∆ιατριβή, Πανεπιστήµιο Πατρών, (1996). •ÂÓﬁÁÏˆÛÛË

Εδώ µπορείτε να βρείτε όλη την ξενόγλωσση βιβλιογραφία που χρησιµοποιήθηκε στο βιβλίο, διαταγµένη ανάλογα µε την κωδικοποίηση. Για µερικές από τις αναφορές (κυρίως για τα βιβλία) που παρατίθενται εδώ, θα βρείτε σχολιασµό και οδηγίες µελέτης µετά το τέλος καθενός από τα κεφάλαια του βιβλίου. [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 ™ÂÏ›‰· 184

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

184

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). [Fen97] N. Fenton and S. Pfleeger, «Software Metrics A Rigorous & Practical Approach», Thomson Computer Press, (1997). [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 ™ÂÏ›‰· 185

° ∂ ¡ π ∫ ∏ µ π µ § π √ ° ƒ∞ º π ∞

[Gil87] Τ. Gilb, «Principles of Software Engineering Management», Addison Wesley, (1987). [Hal75] Μ. Η. Halstead, «Elements of Software Science», Elsevier Publications, N – Holland, (1975). [Ham96] Brian Hambling, «Managing Software Quality», McGraw–Hill, (1996). [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). [Inc95] Darrel Ince, «Software Quality Assurance: A Student Introduction», McGraw–Hill, (1995). [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).

185

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

186

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

[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). [Pre97] Roger S. Pressman, «Software Engineering: A Practitioner’s Approach», Forth edition, European Adaptation, McGraw–Hill, (1997). [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). [Yeh93] H. T. Yeh, «Software Process Quality», McGraw Hill, (1993). [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 ™ÂÏ›‰· 187

∞ÏÊ·‚ËÙÈÎﬁ Â˘ÚÂÙ‹ÚÈÔ ﬁÚˆÓ (ÂÏÏËÓÈÎ¿ – ·ÁÁÏÈÎ¿)

Ακεραιότητα

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 ™ÂÏ›‰· 188

188

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

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

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 ™ÂÏ›‰· 189

∞§º∞µ∏∆π∫√ ∂Àƒ∂∆∏ƒπ√ √ƒø¡ (∂§§∏¡π∫∞ – ∞°°§π∫∞)

189

Έλεγχος απόκλισης

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

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

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

190

Κατανοησιµότητα

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 ™ÂÏ›‰· 191

∞§º∞µ∏∆π∫√ ∂Àƒ∂∆∏ƒπ√ √ƒø¡ (∂§§∏¡π∫∞ – ∞°°§π∫∞)

191

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

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

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

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

192

Τεχνικές τµηµατοποίησης

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 ™ÂÏ›‰· 193

∞ÏÊ·‚ËÙÈÎﬁ Â˘ÚÂÙ‹ÚÈÔ ﬁÚˆÓ (·ÁÁÏÈÎ¿ – ÂÏÏËÓÈÎ¿)

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 ™ÂÏ›‰· 194

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

194

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 ™ÂÏ›‰· 195

∞§º∞µ∏∆π∫√ ∂Àƒ∂∆∏ƒπ√ √ƒø¡ (∞°°§π∫∞ – ∂§§∏¡π∫∞)

195

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

Οργανική κατηγορία έργων

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

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

196

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 ™ÂÏ›‰· 197

∞§º∞µ∏∆π∫√ ∂Àƒ∂∆∏ƒπ√ √ƒø¡ (∞°°§π∫∞ – ∂§§∏¡π∫∞)

197

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

Σταθερότητα

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

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

198

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 ™ÂÏ›‰· 199

°ÏˆÛÛ¿ÚÈ

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

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

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

200

∆ιαχείριση ανάπτυξης λογισµικού ∆ιαχείριση ανάπτυξης λογισµικού είναι η πράξη της παρακολούθησης των ανθρώπινων, οικονοµικών και τεχνικών παραγόντων που σχετίζονται µε την ανάπτυξη του λογισµικού (software). Υπενθυµίζουµε ότι µε τον όρο «αναπτύσσεται» αποδίδουµε τον αντίστοιχο αγγλικό όρο «engineered». ∆ιάγραµµα ανάθεσης έργου σε ανθρώπινο δυναµικό Το διάγραµµα ανάθεσης έργου σε ανθρώπινο δυναµικό σχετίζει το χρονοδιάγραµµα του έργου µε το προσωπικό που έχει την ευθύνη της υλοποίησης κάθε τµήµατος. Παρουσιάζει δηλαδή σε ένα διάγραµµα προσωπικό, τµήµατα, αλληλουχία τµηµάτων στο χρόνο και ποσοστό απασχόλησης κάθε εργαζοµένου σε κάθε τµήµα. ∆ιάγραµµα αξιολόγησης έργου To διάγραµµα αξιολόγησης έργου (PERT Chart) είναι µία γραφική αναπαράσταση των διαφόρων δραστηριοτήτων (activities ή tasks) που συνθέτουν ένα έργο, εµπλουτισµένη µε πληροφορίες όπως εκτιµήσεις διάρκειας και ορόσηµα. ∆ιαδικασία ∆ιαδικασία ενός συστήµατος ποιότητας είναι το κείµενο που περιγράφει πώς ένα συγκεκριµένο κοµµάτι λογισµικού θα αναπτυχθεί. ∆ιασφάλιση ποιότητας Η διασφάλιση ποιότητας είναι η διαδικασία που εµπεριέχει τη διαχείριση της ποιότητας, δηλαδή την πράξη που εξασφαλίζει ή υποδεικνύει ότι ένα πρόγραµµα παραγωγής είναι συµβατό και λειτουργικά αποδοτικό. ∆ιαχείριση ποιότητας ∆ιαχείριση ποιότητας είναι η κατηγορία (τοµέας) µιας επιχείρησης η οποία έχει την ευθύνη να ασκεί την ανώτατη διαχείριση και να ανατροφοδοτεί µε ακρίβεια και εγκυρότητα την παραγωγή. ∆ίκτυο δραστηριοτήτων έργου To δίκτυο δραστηριοτήτων έργου είναι µία γραφική αναπαράσταση των διαφόρων δραστηριοτήτων (activities ή tasks) που συνθέτουν ένα έργο.

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

°§ø™™∞ƒπ

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

201

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

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

202

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

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

°§ø™™∞ƒπ

Ερµηνεία µετρικής Ερµηνεία µετρικής είναι ο καθορισµός του βαθµού συσχέτισης της µετρικής αυτής µε κάποιο ή κάποια εξωτερικά χαρακτηριστικά του λογισµικού. Έργο λογισµικού Κάθε έργο ανάπτυξης λογισµικού σε µία επιχείρηση ή οργανισµό ονοµάζεται έργο λογισµικού. Την ευθύνη για τη διαχείριση αυτού του έργου την έχει ο υπεύθυνος διαχείρισης έργου λογισµικού. Εσωτερικά χαρακτηριστικά του λογισµικού Εσωτερικά χαρακτηριστικά λογισµικού είναι τα χαρακτηριστικά του λογισµικού για τα οποία υπάρχει απτή φυσική αντίληψη και άµεσος τρόπος µέτρησης. Εσωτερικές µετρικές Εσωτερικές µετρικές είναι οι µετρικές αυτές που χρησιµοποιούνται για τη µέτρηση χαρακτηριστικών του λογισµικού για τα οποία υπάρχει απτή αντίληψη για τη φυσική τους σηµασία και δυνατότητα άµεσης µέτρησης. Εσωτερικός περιοδικός έλεγχος Εσωτερικός περιοδικός έλεγχος είναι η επισκόπηση σε έναν οργανισµό, µε περιοδικότητα και επιµονή και έχοντας ως τελικό σκοπό την εγκαθίδρυση ενός προτύπου ποιότητας. Ευχρηστία Ευχρηστία, σύµφωνα µε το πρότυπο ISO 9241, ενός συστήµατος είναι η ικανότητά του να λειτουργεί αποτελεσµατικά και αποδοτικά ενώ παρέχει υποκειµενική ικανοποίηση στους χρήστες του. Κρίσιµο µονοπάτι Κρίσιµο µονοπάτι είναι µια αλληλουχία δραστηριοτήτων από τις οποίες αν καθυστερήσει κάποια από αυτές, αυτό θα έχει ως συνέπεια την καθυστέρηση όλου του έργου. Λειτουργικότητα Λειτουργικότητα είναι ένα σύνολο χαρακτηριστικών που είναι φορείς ενός συνό-

203

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

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

204

λου λειτουργιών και των καθορισµένων ιδιοτήτων τους. Οι λειτουργίες αυτές ικανοποιούν δηλωµένες ή συνεπαγόµενες ανάγκες. Μέγεθος έργου Μέγεθος στη γλώσσα του λογισµικού, ορίζουµε τη µετρήσιµη ποσότητα –που συνήθως µετριέται σε γραµµές κώδικα– του εξαγόµενου προϊόντος. Μεταφερσιµότητα Μεταφερσιµότητα είναι ένα σύνολο χαρακτηριστικών που σχετίζονται µε τη δυνατότητα του λογισµικού να µεταφέρεται από ένα περιβάλλον σε άλλο (αυτό περιλαµβάνει το υλικό, λογισµικό ή οργανωτικό περιβάλλον). Μέτρηση Μέτρηση είναι η διαδικασία µε την οποία αριθµοί ή σύµβολα αντιστοιχούνται σε ιδιότητες οντοτήτων του πραγµατικού κόσµου, έτσι ώστε να τις περιγράφουν σύµφωνα µε καθορισµένους κανόνες. Μετρική Μετρική είναι µια εµπειρική αντικειµενική αντιστοίχηση ενός αριθµού (ή συµβόλου) σε µια οντότητα µε στόχο να χαρακτηρίσει ένα συγκεκριµένο χαρακτηριστικό της οντότητας αυτής. Οδηγία Οδηγία στα πλαίσια ενός συστήµατος ποιότητας είναι περιγραφικό κείµενο που επεξηγεί την εφαρµογή ενός προτύπου. ∆ιαχείριση ολικής ποιότητας ∆ιαχείριση ολικής ποιότητας είναι τρόπος διοίκησης ενός οργανισµού που εστιάζει στην ποιότητα, ο οποίος βασίζεται στη συµµετοχή όλων των µελών του και στοχεύει στη µακροπρόθεσµη επιτυχία µέσω της ικανοποίησης του πελάτη και στην παροχή οφελών σε όλα τα µέλη του οργανισµού και στην κοινωνία. Οργανόγραµµα διαχείρισης έργου Το οργανόγραµµα διαχείρισης έργου παρουσιάζει σχηµατικά τη διοικητική δοµή του έργου, παρουσιάζει δηλαδή τις οµάδες ανάπτυξης, το προσωπικό που συµµετέ-

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

°§ø™™∞ƒπ

χει σε αυτές και τους ρόλους καθενός που συµµετέχει στην ανάπτυξη λογισµικού. Ορόσηµα Ένα ορόσηµο καθορίζει ένα σηµαντικό σηµείο του έργου που σχετίζεται µε την ολοκλήρωση ενός µετρήσιµου στόχου. Τα ορόσηµα πήραν το αγγλικό όνοµά τους «milestones» από τα πέτρινα κολωνάκια που ήταν τοποθετηµένα παλαιότερα στην άκρη των δρόµων και έδειχναν σε ποιο µίλι βρίσκεται ο οδηγός. Παράγοντες ποιότητας Παράγοντες ποιότητας είναι οµάδες χαρακτηριστικών τα οποία συνθέτουν την ποιότητα ενός προϊόντος, έχουν την ελάχιστη δυνατή επικάλυψη µεταξύ τους και είναι επαρκή για τη σύνθεση της ποιότητας. Πλάνο ποιότητας Το πλάνο ποιότητας είναι συγκεκριµένο για κάθε έργο και είναι το υποσύνολο του εγχειριδίου ποιότητας που έχει κριθεί ότι εξυπηρετεί τους στόχους ποιότητας του συγκεκριµένου έργου. Ποιότητα Ποιότητα είναι η συλλογή των χαρακτηριστικών και των ιδιοτήτων του προϊόντος που σχετίζονται µε τη δυνατότητά του να εκπληρώνει τις ζητούµενες ανάγκες των πελατών. (Ορισµός του American Society for Quality) Ποιότητα είναι η συµµόρφωση µε τις απαιτήσεις των χρηστών. (Ορισµός του Phillip Crosby) Ποιότητα είναι καταλληλότητα προς χρήση. (Ορισµός του Joseph Juran) Ποιότητα είναι η συλλογή των χαρακτηριστικών σχεδιασµού, κατασκευής και συντήρησης, διά µέσου των οποίων το προϊόν κατά τη χρήση του θα εκπληρώσει τις προσδοκίες των πελατών. (Ορισµός του Feigenbaum) Ποιότητα είναι η συµµόρφωση µε τυποποιηµένες προδιαγραφές που περιγράφουν τα βασικά χαρακτηριστικά του προϊόντος και έχουν βασιστεί στις ανάγκες και προσδοκίες των πελατών. (Ορισµός του Aubrey) Ποιότητα είναι το σύνολο των χαρακτηριστικών µιας οντότητας που της αποδίδουν την ικανότητα να ικανοποιεί εκφρασµένες και συνεπαγόµενες ανάγκες. (Ορισµός του προτύπου ISO 8402)

205

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

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

206

Πρόγραµµα ποιότητας Πρόγραµµα ποιότητας µίας επιχείρησης ορίζεται ως το σύνολο των διαδικασιών, εγχειριδίων, εργαλείων και ανθρώπων που έχουν την ευθύνη για την ποιότητα του παραγόµενου προϊόντος ή την ικανοποίηση των απαιτήσεων των πελατών. Προγραµµατισµός βασισµένος σε ψηφίδες Προγραµµατισµός βασισµένος σε ψηφίδες είναι η τεχνική ανάπτυξης τµηµάτων λογισµικού τα οποία µπορούν να χρησιµοποιηθούν αυτόνοµα σε κάθε έργο. Υλοποιείται µε συγκεκριµένες γλώσσες προγραµµατισµού που υποστηρίζουν τη δηµιουργία ψηφίδων (components). Προγραµµατισµός έργου Προγραµµατισµός έργου είναι η αρχική φάση της ανάπτυξης λογισµικού κατά την οποία καθορίζονται οι βασικές προδιαγραφές του λογισµικού, γίνεται η κοστολόγηση του έργου, η τιµολόγηση του έργου (εάν είναι έργο που αναπτύσσεται για συγκεκριµένο πελάτη), η εκτίµηση των µεγεθών του έργου, η µελέτη του εφικτού και η ανάλυση του κινδύνου και η αρχική τµηµατοποίηση και ο χρονοπρογραµµατισµός του έργου. Προσοχή: δεν πρέπει να συγχέουµε τον προγραµµατισµό του έργου (planning) µε τον προγραµµατισµό / κωδικοποίηση (programming) που γίνεται στη φάση της υλοποίησης του έργου. Προγραµµατιστής Ο προγραµµατιστής είναι αυτός που γνωρίζει µία γλώσσα προγραµµατισµού και του δίνονται προδιαγραφές ώστε να υλοποιήσει ένα τµήµα λογισµικού σε αυτή τη γλώσσα. Προσαρµοσµένο λογισµικό Το προσαρµοσµένο λογισµικό είναι λογισµικό το οποίο αναπτύσσεται για συγκεκριµένο πελάτη. Συνήθως αυτός ο πελάτης εντάσσεται τόσο στη διαδικασία ανάπτυξης, όσο και στο πρόγραµµα διασφάλισης ποιότητας. Προσωπικό Προσωπικό µίας επιχείρησης ή οργανισµού είναι το σύνολο των ανθρώπων που εργάζονται σε αυτή.

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

°§ø™™∞ƒπ

Πρότυπο Πρότυπο είναι µία τεκµηριωµένη σύµβαση που περιέχει τεχνικές προδιαγραφές, ή άλλα ακριβή κριτήρια χρησιµοποιούµενα ως κανόνες και κατευθυντήριες γραµµές για την εξασφάλιση της τυποποίησης των κατάλληλων υλικών, προϊόντων, διεργασιών και υπηρεσιών για τη διευκόλυνση της διεθνούς ανταλλαγής αγαθών και υπηρεσιών και της ανάπτυξης συνεργασίας στη σφαίρα των επιστηµονικών, τεχνολογικών και οικονοµικών ενεργειών. Συντήρηση Η συντήρηση είναι η φάση της ανάπτυξης λογισµικού κατά την οποία διορθώνουµε, αλλάζουµε ή βελτιώνουµε λογισµικό που έχει ήδη αναπτυχθεί και παραδοθεί στον πελάτη. Συντηρησιµότητα Συντηρησιµότητα είναι ένα σύνολο χαρακτηριστικών που σχετίζονται µε την απαιτούµενη προσπάθεια για να υλοποιηθούν συγκεκριµένες αλλαγές (που µπορεί να περιλαµβάνουν διορθώσεις, βελτιώσεις και προσαρµογές) στο λογισµικό, στο περιβάλλον, ή στις απαιτήσεις. Σύστηµα ποιότητας Βλέπε «πρόγραµµα ποιότητας». Τεκµηρίωση Τεκµηρίωση ονοµάζεται κάθε είδος κειµένου που παράγεται στα πλαίσια ενός έργου λογισµικού. Σε αυτή περιλαµβάνεται κάθε εσωτερικό κείµενο που θα διακινηθεί µόνο στα πλαίσια της επιχείρησης, αλλά και κάθε εξωτερικό κείµενο που θα κοινοποιηθεί ή θα παραδοθεί στον πελάτη. Τεχνολογία ποιότητας Τεχνολογία ποιότητας ονοµάζεται η κατηγορία (τοµέας) µιας επιχείρησης η οποία έχει την ευθύνη να αναλύει τα προβλήµατα που σχετίζονται µε την ποιότητα, να τα επιλύει, να εκπαιδεύει το προσωπικό και να εγκαθιδρύει προγράµµατα που βελτιώνουν την ποιότητα.

207

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

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

208

Υπεύθυνος διαχείρισης έργου λογισµικού Ο υπεύθυνος διαχείρισης έργου λογισµικού είναι αυτός που έχει την ευθύνη για την πορεία του έργου, δηλαδή την τεχνική, οικονοµική και διαχειριστική ευθύνη για το έργο. Συχνά ο υπεύθυνος διαχείρισης έργου λογισµικού αναφέρεται για λόγους συντοµίας και ως υπεύθυνος έργου. Υπεύθυνος έργων Βλέπε «Ανώτερος υπεύθυνος έργων». Υπεύθυνος έργου Βλέπε «Υπεύθυνος διαχείρισης έργου λογισµικού». Υπεύθυνος ποιότητας Υπεύθυνος ποιότητας είναι το µέλος του προσωπικού που έχει την ευθύνη διοίκησης του τµήµατος ποιότητας, δηλαδή την ευθύνη της καταγραφής, επίβλεψης και διαρκούς εξέλιξης όλων των δοµών, δραστηριοτήτων, αρµοδιοτήτων, διαδικασιών, πόρων, µετρικών και εργαλείων µέτρησης που µπορούν να χρησιµοποιηθούν για τη διασφάλιση ή τον έλεγχο της ποιότητας ενός έργου. Χρονοδιάγραµµα Το χρονοδιάγραµµα (Gantt chart) παρουσιάζει το χρόνο που εκτιµάται ότι θα χρειαστεί κάθε τµήµα του έργου, αλλά και χρησιµοποιείται από τον υπεύθυνο έργου για την επίβλεψη του έργου και την παρακολούθηση του ποσοστού ολοκλήρωσης κάθε τµήµατος.