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

Transcript

1 ΤΕΧΝΟΛΟΓΙΚΟ ΕΚΠΑΙΔΕΥΤΙΚΟ ΙΔΡΥΜΑ ΤΕΙ ΙΟΝΙΩΝ ΝΗΣΩΝ ΤΜΗΜΑ ΕΦΑΡΜΟΓΩΝ ΠΛΗΡΟΦΟΡΙΚΗΣ ΣΤΗ ΔΙΟΙΚΗΣΗ ΚΑΙ ΤΗΝ ΟΙΚΟΝΟΜΙΑ ΠΤΥΧΙΑΚΗ ΕΡΓΑΣΙΑ ΜΕΘΟΔΟΙ ΕΚΤΙΜΗΣΗΣ ΚΟΣΤΟΥΣ ΛΟΓΙΣΜΙΚΟΥ (SOFTWARE COST ESTIMATION METHODS) ΟΝΟΜΑΤΕΠΩΝΥΜΟ: ΜΠΟΝΟΥ ΚΑΛΛΙΟΠΗ ΑΡΙΘΜΟΣ ΜΗΤΡΩΟΥ: 538 ΕΠΙΒΛΕΠΩΝ ΚΑΘΗΓΗΤΗΣ: ΠΑΝΑΓΙΩΤΗΣ ΣΑΤΟΣ ΛΕΥΚΑΔΑ 2011

2 ΠΕΡΙΛΗΨΗ Στα πλαίσια αυτής της εργασίας αναπτύχθηκαν τα παρακάτω θέματα. Αρχικά γίνεται μία ιστορική αναφορά στην οικονομική του λογισμικού το οποίο είναι ένα πεδίο έρευνας στα οικονομικά που άρχισε να ενδιαφέρει τους οικονομολόγους τη δεκαετία του 60 και γίνεται μια εισαγωγή στην οικονομική του λογισμικού. Παρουσιάζεται ο σκοπός, η δήλωση του προβλήματος καθώς και η διαδικασία εκτίμησης του κόστους και ο κύκλος εκτίμησης κόστους λογισμικού. Έπειτα γίνεται μια εισαγωγή στις τεχνικές εκτίμησης κόστους όπου γίνεται διάκριση αυτών σε τεχνικές μη αλγοριθμικές όπως είναι η Top down, Bottom up, τεχνική κρίσης του ειδικού και η τεχνική των Δελφών, σε τεχνικές αλγοριθμικές μη παραμετρικές όπως είναι η εκτίμηση με αναλογίες, CBR (Case Based Reasoning), παλινδρόμηση και σε τεχνικές αλγοριθμικές παραμετρικές όπως είναι η SLIM, COCOMO, λειτουργικά σημεία (Function points) όπου και γίνεται αναφορά στα μοντέλα που αναφέρθηκαν. Στις τεχνικές COCOMO και λειτουργικά σημεία (Function points) γίνεται εκτενής αναφορά. Ακολουθεί μία μικρή αναφορά σε κάποιες άλλες τεχνικές εκτίμησης κόστους όπως είναι η μετρική Halstead s Complexity Metric, McCabe s Cyclomatic Complexity Metric v(g), Τεχνική Non Commenting Source Statements (NCSS) και η μετρική πολυπλοκότητας με την χρήση Maintainability Index. Τέλος παρουσιάζεται μία μελέτη περίπτωσης όπου γίνεται εφαρμογή του μοντέλου COCOMO και των λειτουργικών σημείων (Function points) για την εκτίμηση του κόστους μιας εφαρμογής διαχείρισης βιβλιοθηκών. 1

3 ΠΕΡΙΕΧΟΜΕΝΑ ΠΕΡΙΛΗΨΗ.σ. 1 ΠΕΡΙΕΧΟΜΕΝΑ.2 ΕΙΣΑΓΩΓΗ..8 ΚΕΦΑΛΑΙΟ 1: ΕΚΤΙΜΗΣΗ ΚΟΣΤΟΥΣ ΛΟΓΙΣΜΙΚΟΥ ΕΙΣΑΓΩΓΗ ΟΡΙΣΜΟΣ ΤΟΥ ΠΡΟΒΛΗΜΑΤΟΣ ΔΙΑΔΙΚΑΣΙΑ ΕΚΤΙΜΗΣΗΣ ΤΟΥ ΚΟΣΤΟΥΣ ΚΥΚΛΟΣ ΖΩΗΣ ΕΚΤΙΜΗΣΗΣ ΚΟΣΤΟΥΣ ΛΟΓΙΣΜΙΚΟΥ.14 ΚΕΦΑΛΑΙΟ 2: ΜΟΝΤΕΛΑ ΕΚΤΙΜΗΣΗΣ ΚΟΣΤΟΥΣ ΕΙΣΑΓΩΓΗ ΤΕΧΝΙΚΕΣ ΜΗ ΑΛΓΟΡΙΘΜΙΚΕΣ ΤΕΧΝΙΚΗ ΤΗΣ ΔΟΜΗΣ ΚΑΤΑΚΕΡΜΑΤΙΣΜΟΥ ΤΗΣ ΕΡΓΑΣΙΑΣ (TOP- DOWN) ΒΟΤΤΟΜ-UP ΤΕΧΝΙΚΗ ΤΗΣ ΚΡΙΣΗΣ ΤΟΥ ΕΙΔΙΚΟΥ ΤΕΧΝΙΚΗ DELFI (ΤΕΧΝΙΚΗ ΤΩΝ ΔΕΛΦΩΝ) ΤΕΧΝΙΚΕΣ ΑΛΓΟΡΙΘΜΙΚΕΣ ΜΗ ΠΑΡΑΜΕΤΡΙΚΕΣ ΕΚΤΙΜΗΣΗ ΜΕ ΑΝΑΛΟΓΙΕΣ CASE BASED REASONING ( CBR) ΠΑΛΙΝΔΡΟΜΗΣΗ ORDINARY LEAST SQUARES (OLS) ΤΕΧΝΙΚΕΣ ΑΛΓΟΡΙΘΜΙΚΕΣ ΠΑΡΑΜΕΤΡΙΚΕΣ SLIM ΟΡΙΣΜΟΣ ΤΗΣ SLOC COCOMO ( CONSTRUCTIVE COST MODEL) ΛΕΙΤΟΥΡΓΙΚΑ ΣΗΜΕΙΑ ( FUNCTION POINTS)..31 ΚΕΦΑΛΑΙΟ 3: ΜΟΝΤΕΛΟ COCOMO (CONSTRUCTIVE COST MODEL) ΙΣΤΟΡΙΚΗ ΑΝΑΔΡΟΜΗ ΟΡΙΣΜΟΣ ΤΟΥ COCOMO ΕΚΤΙΜΗΣΗ ΚΑΤΑ BOEHM ΒΑΣΙΚΟ ΜΟΝΤΕΛΟ COCOMO..37 2

4 3.3.2 ΕΝΔΙΑΜΕΣΟ ΜΟΝΤΕΛΟ COCOMO ΛΕΠΤΟΜΕΡΕΙΑΚΟ ΜΟΝΤΕΛΟ COCOMO COCOMO II ΣΥΝΑΡΤΗΣΗ ΕΚΤΙΜΗΣΗΣ ΠΡΟΣΠΑΘΕΙΑΣ ΣΥΝΑΡΤΗΣΗ ΕΚΤΙΜΗΣΗ ΧΡΟΝΟΠΡΟΓΡΑΜΜΑΤΙΣΜΟΥ ΣΥΣΧΕΤΙΣΜΟΣ ΤΩΝ ΣΤΑΔΙΩΝ EARLY DESIGN ΚΑΙ POST ARCHITECTURE ΠΑΡΑΓΟΝΤΕΣ ΚΛΙΜΑΚΩΣΗΣ ΜΟΝΤΕΛΟ ΩΡΙΜΑΝΣΗΣ ΙΚΑΝΟΤΗΤΑΣ ΔΙΕΡΓΑΣΙΩΝ ΠΑΡΑΓΟΝΤΕΣ ΚΟΣΤΟΥΣ ΚΑΘΟΡΙΣΜΟΣ ΜΕΓΕΘΟΥΣ ΜΗ ΠΡΟΣΑΡΜΟΣΜΕΝΑ ΛΕΙΤΟΥΡΓΙΚΑ ΣΗΜΕΙΑ ΜΕΤΑΤΡΟΠΗ ΤΩΝ UNADJUSTED FUNCTION POINTS ΣΕ ΓΡΑΜΜΕΣ ΚΩΔΙΚΑ..60 ΚΕΦΑΛΑΙΟ 4: ΛΕΙΤΟΥΡΓΙΚΑ ΣΗΜΕΙΑ ( FUNCTION POINTS) ΟΡΙΣΜΟΣ ΤΩΝ ΛΕΙΤΟΥΡΓΙΚΩΝ ΣΗΜΕΙΩΝ ΠΕΡΙΓΡΑΦΗ ΤΗΣ ΜΕΘΟΔΟΥ ΕΚΤΙΜΗΣΗΣ ΠΕΡΙΓΡΑΦΗ ΤΩΝ ΓΕΝΙΚΩΝ ΧΑΡΑΚΤΗΡΙΣΤΙΚΩΝ ΤΟΥ ΣΥΣΤΗΜΑΤΟΣ ΠΛΕΟΝΕΚΤΗΜΑ ΚΑΙ ΜΕΙΟΝΕΚΤΗΜΑ ΤΩΝ FUNCTION POINTS 69 ΚΕΦΑΛΑΙΟ 5: ΑΛΛΕΣ ΜΕΤΡΙΚΕΣ ΕΚΤΙΜΗΣΗΣ ΚΟΣΤΟΥΣ ΛΟΓΙΣΜΙΚΟΥ ΤΕΧΝΙΚΗ NON COMMENTING SOURCE STATEMENTS ( NCSS) MCCABE S CYCLOMATIC COMPLEXITY METRIC- V (G) ΜΕΤΡΙΚΗ HALSTEAD S COMPLEXITY METRIC ΜΕΤΡΙΚΗ ΠΟΛΥΠΛΟΚΟΤΗΤΑΣ ΜΕ ΤΗΝ ΧΡΗΣΗ MAINTAINABILITY INDEX.72 ΚΕΦΑΛΑΙΟ 6: ΜΕΛΕΤΗ ΠΕΡΙΠΤΩΣΗΣ ΠΑΡΟΥΣΙΑΣΗ ΤΟΥ ΣΥΣΤΗΜΑΤΟΣ ΚΑΡΤΕΛΑ ΧΕΙΡΙΣΜΟΥ ΒΙΒΛΙΩΝ ΚΑΡΤΕΛΑ ΧΕΙΡΙΣΜΟΥ ΔΑΝΕΙΖΟΜΕΝΩΝ ΚΑΙ ΔΑΝΕΙΣΜΩΝ ΚΑΡΤΕΛΑ ΕΝΕΡΓΕΙΩΝ ΔΙΑΧΕΙΡΙΣΤΗ

5 6.5 ΕΚΤΙΜΗΣΗ ΚΟΣΤΟΥΣ ΛΟΓΙΣΜΙΚΟΥ ΜΕ ΤΗ ΜΕΘΟΔΟ FUNCTION POINTS ΕΚΤΙΜΗΣΗ ΚΟΣΤΟΥΣ ΛΟΓΙΣΜΙΚΟΥ ΜΕ ΤΗ ΜΕΘΟΔΟ COCOMO II.97 ΣΥΜΠΕΡΑΣΜΑ..102 ΒΙΒΛΙΟΓΡΑΦΙΑ.104 ΚΑΤΑΛΟΓΟΣ ΔΙΑΓΡΑΜΜΑΤΩΝ ΔΙΑΓΡΑΜΜΑ 1: ΔΙΑΓΡΑΜΜΑ ΕΚΤΙΜΗΣΗΣ ΚΟΣΤΟΥΣ 14 ΔΙΑΓΡΑΜΜΑ 2: ΚΥΚΛΟΣ ΖΩΗΣ ΤΟΥ ΕΡΓΟΥ.15 ΔΙΑΓΡΑΜΜΑ 3: ΤΑΞΙΝΟΜΗΣΗ ΤΩΝ ΜΕΘΟΔΩΝ ΕΚΤΙΜΗΣΗΣ ΚΟΣΤΟΥΣ ΚΑΤΑ BRIANDT 16 ΔΙΑΓΡΑΜΜΑ 4: ΚΑΤΑΚΕΡΜΑΤΙΣΜΟΣ ΕΡΓΟΥ..17 ΔΙΑΓΡΑΜΜΑ 5: ΚΑΤΑΚΕΡΜΑΤΙΣΜΟΣ ΤΟΥ ΣΥΣΤΗΜΑΤΟΣ..18 ΔΙΑΓΡΑΜΜΑ 6: ΔΙΑΓΡΑΜΜΑ CBR ΜΟΝΤΕΛΟΥ...26 ΔΙΑΓΡΑΜΜΑ 7: COCOMO BLACK BOX...33 ΔΙΑΓΡΑΜΜΑ 8: ΚΑΜΠΥΛΗ RAYLEIGH ΚΑΤΑ ΒΟΕΗΜ...35 ΔΙΑΓΡΑΜΜΑ 9: ΠΡΟΣΑΡΜΟΓΗ COCOMO II ΣΤΑ ΜΟΝΤΕΛΑ ΑΝΑΠΤΥΞΗΣ.47 ΔΙΑΓΡΑΜΜΑ 10: ΛΙΣΤΑ ΟΡΙΣΜΟΥ ΓΙΑ ΜΕΤΡΗΣΕΙΣ ΠΗΓΑΙΩΝ ΔΗΛΩΣΕΩΝ ΚΩΔΙΚΑ..58 ΚΑΤΑΛΟΓΟΣ ΠΙΝΑΚΩΝ ΠΙΝΑΚΑΣ 1:ΦΟΡΜΑ ΕΚΤΙΜΗΣΗΣ ΜΕ ΒΑΣΗ ΤΗΝ ΤΕΧΝΙΚΗ ΤΩΝ ΔΕΛΦΩΝ.22 ΠΙΝΑΚΑΣ 2: ΚΑΤΑΝΟΜΗ ΠΡΟΣΠΑΘΕΙΑΣ ΧΡΟΝΟΠΡΟΓΡΑΜΜΑΤΙΣΜΟΥ..35 ΠΙΝΑΚΑΣ 3: ΚΑΤΑΝΟΜΗ ΠΡΟΣΠΑΘΕΙΑΣ, ΧΡΟΝΟΠΡΟΓΡΑΜΜΑΤΙΣΜΟΥ ΚΑΙ ΠΡΟΣΩΠΙΚΟΥ...36 ΠΙΝΑΚΑΣ 4: ΠΑΡΑΓΟΝΤΕΣ ΚΟΣΤΟΥΣ ΚΑΤΑ COCOMO.38 ΠΙΝΑΚΑΣ 5: ΕΞΙΣΩΣΕΙΣ ΟΝΟΜΑΣΤΙΚΗΣ ΠΡΟΣΠΑΘΕΙΑΣ ΚΑΙ ΔΙΑΡΚΕΙΑΣ ΑΝΑΠΤΥΞΗΣ.40 ΠΙΝΑΚΑΣ 6: ΚΑΤΗΓΟΡΙΕΣ ΕΡΓΩΝ ΛΟΓΙΣΜΙΚΟΥ ΚΑΤΑ COCOMO...41 ΠΙΝΑΚΑΣ 7:ΠΟΛΛΑΠΛΑΣΙΑΣΤΕΣ ΠΡΟΣΠΑΘΕΙΑΣ...42 ΠΙΝΑΚΑΣ 8: ΚΑΤΑΤΑΞΗ ΠΑΡΑΓΟΝΤΩΝ ΚΟΣΤΟΥΣ ΚΑΤΑ COCOMO..43 4

6 ΠΙΝΑΚΑΣ 9:ΚΑΤΑΤΑΞΗ ΤΟΥ ΠΑΡΑΓΟΝΤΑ ΚΟΣΤΟΥΣ ΠΟΛΥΠΛΟΚΟΤΗΤΑΣ..49 ΠΙΝΑΚΑΣ 10: ΕΠΕΞΗΓΗΣΗ ΣΥΜΒΟΛΩΝ ΕΞΙΣΩΣΗΣ ΕΚΤΙΜΗΣΗΣ ΠΡΟΣΠΑΘΕΙΑΣ 49 ΠΙΝΑΚΑΣ 11: ΕΠΕΞΗΓΗΣΗ ΤΩΝ ΣΥΜΒΟΛΩΝ ΤΗΣ ΕΞΙΣΩΣΗΣ ΕΚΤΙΜΗΣΗ ΧΡΟΝΟΠΡΟΓΡΑΜΜΑΤΙΣΜΟΥ..50 ΠΙΝΑΚΑΣ 12:ΧΑΡΑΚΤΗΡΙΣΤΙΚΑ ΣΤΑΔΙΩΝ ΑΝΑΠΤΥΞΗΣ...51 ΠΙΝΑΚΑΣ 13: ΠΑΡΑΓΟΝΤΕΣ ΚΛΙΜΑΚΩΣΗΣ ΤΟΥ COCOMO II..52 ΠΙΝΑΚΑΣ 14: ΠΟΛΛΑΠΛΑΣΙΑΣΤΕΣ ΠΡΟΣΠΑΘΕΙΑΣ 56 ΠΙΝΑΚΑΣ 15: ΜΕΤΑΤΡΟΠΗ ΛΕΙΤΟΥΡΓΙΚΩΝ ΣΗΜΕΙΩΝ ΣΕ ΓΡΑΜΜΕΣ ΚΩΔΙΚΑ..60 ΠΙΝΑΚΑΣ 16: ΠΑΡΑΔΕΙΓΜΑ ΠΟΛΥΠΛΟΚΟΤΗΤΑΣ ΕΙΣΟΔΩΝ 65 ΠΙΝΑΚΑΣ 17: ΠΟΛΥΠΛΟΚΟΤΗΤΑ ΑΡΧΕΙΩΝ ΚΑΙ ΔΙΕΠΑΦΩΝ...66 ΠΙΝΑΚΑΣ 18: ΚΑΤΗΓΟΡΙΟΠΟΙΗΣΗ ΠΟΛΥΠΛΟΚΟΤΗΤΑΣ...66 ΠΙΝΑΚΑΣ 19: ΣΥΝΤΕΛΕΣΤΕΣ ΣΤΑΘΜΙΣΗΣ ΜΕΤΡΗΣΕΩΝ..66 ΠΙΝΑΚΑΣ 20: ΠΙΝΑΚΑΣ ΠΟΛΥΠΛΟΚΟΤΗΤΑΣ ΚΑΤΑ HALSTEAD 72 ΚΑΤΑΛΟΓΟΣ ΕΞΙΣΩΣΕΩΝ ΕΞΙΣΩΣΗ 1: ΕΥΚΛΕΙΔΕΙΑ ΑΠΟΣΤΑΣΗ.24 ΕΞΙΣΩΣΗ 2: ΥΠΟΛΟΓΙΣΜΟΣ ΕΥΘΕΙΑΣ ΠΑΛΙΝΔΡΟΜΗΣΗΣ 26 ΕΞΙΣΩΣΗ 3:ΥΠΟΛΟΓΙΣΜΟΣ ΕΚΤΙΜΗΣΗΣ ΠΡΟΣΠΑΘΕΙΑΣ..26 ΕΞΙΣΩΣΗ 4: ΣΥΝΑΡΤΗΣΗ ΠΑΛΙΝΔΡΟΜΗΣΗΣ 27 ΕΞΙΣΩΣΗ 5:ΕΚΘΕΤΙΚΟ ΠΡΟΤΥΠΟ ΕΚΤΙΜΗΣΗΣ 28 ΕΞΙΣΩΣΗ 6: ΓΡΑΜΜΙΚΗ ΕΞΙΣΩΣΗ...28 ΕΞΙΣΩΣΗ 7: ΕΞΙΣΩΣΗ ΚΑΜΠΥΛΗΣ RAYLEIGH 33 ΕΞΙΣΩΣΗ 8: ΥΠΟΛΟΓΙΣΜΟΣ ΑΝΘΡΩΠΟΠΡΟΣΠΑΘΕΙΑΣ...37 ΕΞΙΣΩΣΗ 9: ΥΠΟΛΟΓΙΣΜΟΣ ΠΑΡΑΓΟΝΤΑ ΠΡΟΣΑΡΜΟΓΗΣ ΠΡΟΣΠΑΘΕΙΑΣ..39 ΕΞΙΣΩΣΗ 10:ΥΠΟΛΟΓΙΣΜΟΣ ΠΡΟΣΠΑΘΕΙΑΣ ΑΝΑΠΤΥΞΗΣ..39 ΕΞΙΣΩΣΗ 11: ΥΠΟΛΟΓΙΣΜΟΣ ΤΟΥ ΚΟΣΤΟΥΣ...39 ΕΞΙΣΩΣΗ 12: ΥΠΟΛΟΓΙΣΜΟΣ ΔΙΑΡΚΕΙΑΣ ΕΡΓΟΥ

7 ΕΞΙΣΩΣΗ 13: ΣΥΝΑΡΤΗΣΗ ΕΚΤΙΜΗΣΗΣ ΠΡΟΣΠΑΘΕΙΑΣ.49 ΕΞΙΣΩΣΗ 14: ΣΥΝΑΡΤΗΣΗ ΕΚΤΙΜΗΣΗΣ ΧΡΟΝΟΠΡΟΓΡΑΜΜΑΤΙΣΜΟΥ..50 ΕΞΙΣΩΣΗ 15: ΥΠΟΛΟΓΙΣΜΟΣ ΑΝΘΡΩΠΟΠΡΟΣΠΑΘΕΙΑΣ ΚΑΤΑ COCOMO II..51 ΕΞΙΣΩΣΗ 16: ΥΠΟΛΟΓΙΣΜΟΣ ΣΥΝΤΕΛΕΣΤΗΣ Β 51 ΕΞΙΣΩΣΗ 17: ΕΞΙΣΩΣΗ ΠΑΡΑΓΟΝΤΩΝ ΚΟΣΤΟΥΣ ΓΙΑ EARLY DESIGN 56 ΕΞΙΣΩΣΗ 18: ΕΞΙΣΩΣΗ ΠΑΡΑΓΟΝΤΩΝ ΚΟΣΤΟΥΣ ΓΙΑ POST ARCHITECTURE...56 ΕΞΙΣΩΣΗ 19: ΥΠΟΛΟΓΙΣΜΟΣ FUNCTION COUNTS..67 ΕΞΙΣΩΣΗ 20: ΙΣΟΤΗΤΑ ΠΡΟΣΑΡΜΟΓΗΣ ΤΙΜΩΝ 69 ΕΞΙΣΩΣΗ 21: ΥΠΟΛΟΓΙΣΜΟΣ ΛΕΙΤΟΥΡΓΙΚΩΝ ΣΗΜΕΙΩΝ..69 ΕΞΙΣΩΣΗ 22: ΥΠΟΛΟΓΙΣΜΟΣ ΑΡΙΘΜΟΥ ΜΟΝΟΠΑΤΙΩΝ ΚΑΤΑ McCABE..71 ΜΕΛΕΤΗ ΠΕΡΙΠΤΩΣΗΣ ΚΑΤΑΛΟΓΟΣ ΕΙΚΟΝΩΝ ΕΙΚΟΝΑ 1: ΚΑΡΤΕΛΑ ΧΕΙΡΙΣΜΟΥ ΒΙΒΛΙΩΝ..75 ΕΙΚΟΝΑ 2: ΚΑΡΤΕΛΑ ΧΕΙΡΙΣΜΟΥ ΔΑΝΕΙΖΟΜΕΝΩΝ ΚΑΙ ΔΑΝΕΙΣΜΩΝ.76 ΕΙΚΟΝΑ 3: ΚΑΡΤΕΛΑ ΕΝΕΡΓΕΙΩΝ ΔΙΑΧΕΙΡΙΣΤΗ..77 ΕΙΚΟΝΑ 4: ΟΘΟΝΗ ΕΙΣΑΓΩΓΗΣ ΒΙΒΛΙΟΥ...78 ΕΙΚΟΝΑ 5: ΟΘΟΝΗ ΑΝΑΖΗΤΗΣΗΣ ΒΙΒΛΙΟΥ.79 ΕΙΚΟΝΑ 6: ΟΘΟΝΗ ΔΙΑΓΡΑΦΗΣ ΒΙΒΛΙΟΥ..80 ΕΙΚΟΝΑ 7: ΟΘΟΝΗ ΕΙΣΑΓΩΓΗΣ ΝΕΟΥ ΑΝΤΙΤΥΠΟΥ 81 ΕΙΚΟΝΑ 8: ΟΘΟΝΗ ΠΡΟΒΟΛΗΣ ΔΙΑΘΕΣΙΜΩΝ ΒΙΒΛΙΩΝ 82 ΕΙΚΟΝΑ 9: ΟΘΟΝΗ ΕΙΣΑΓΩΓΗΣ ΔΑΝΕΙΖΟΜΕΝΟΥ...83 ΕΙΚΟΝΑ 10: ΟΘΟΝΗ ΔΙΑΓΡΑΦΗΣ ΔΑΝΕΙΖΟΜΕΝΟΥ.84 ΕΙΚΟΝΑ 11: ΟΘΟΝΗ ΠΡΟΒΟΛΗΣ ΔΑΝΕΙΖΟΜΕΝΩΝ.85 ΕΙΚΟΝΑ 12: ΟΘΟΝΗ ΕΠΙΣΤΡΟΦΗΣ ΒΙΒΛΙΟΥ..86 ΕΙΚΟΝΑ 13: ΟΘΟΝΗ ΔΑΝΕΙΣΜΟΥ ΒΙΒΛΙΟΥ...87 ΕΙΚΟΝΑ 14: ΟΘΟΝΗ ΔΗΜΟΦΙΛΕΣΤΕΡΩΝ ΒΙΒΛΙΩΝ.88 ΕΙΚΟΝΑ 15: ΟΘΟΝΗ ΚΑΘΥΣΤΕΡΗΜΕΝΩΝ ΕΠΙΣΤΡΟΦΩΝ ΒΙΒΛΙΩΝ.89 ΕΙΚΟΝΑ 16: ΟΘΟΝΗ ΕΠΙΛΟΓΩΝ ΕΞΩΤΕΡΙΚΩΝ ΑΡΧΕΙΩΝ..90 ΚΑΤΑΛΟΓΟΣ ΠΙΝΑΚΩΝ ΠΙΝΑΚΑΣ 1:ΥΠΟΛΟΓΙΣΜΟΣ ΕΞΩΤΕΡΙΚΩΝ ΕΙΣΟΔΩΝ.91 ΠΙΝΑΚΑΣ 2: ΥΠΟΛΟΓΙΣΜΟΣ ΕΞΩΤΕΡΙΚΩΝ ΕΞΟΔΩΝ..91 6

8 ΠΙΝΑΚΑΣ 3: ΥΠΟΛΟΓΙΣΜΟΣ ΕΞΩΤΕΡΙΚΩΝ ΕΡΩΤΗΜΑΤΩΝ...92 ΠΙΝΑΚΑΣ 4: ΥΠΟΛΟΓΙΣΜΟΣ ΕΣΩΤΕΡΙΚΩΝ ΑΡΧΕΙΩΝ.94 ΠΙΝΑΚΑΣ 5: ΥΠΟΛΟΓΙΣΜΟΣ UNADJUSTED FUNCTION POINT COUNT ΠΙΝΑΚΑΣ 6: ΥΠΟΛΟΓΙΣΜΟΣ VALUE ADJUSTMENT FACTOR...95 ΠΙΝΑΚΑΣ 7: ΠΑΡΑΓΟΝΤΕΣ ΚΛΙΜΑΚΩΣΗΣ 97 ΠΙΝΑΚΑΣ 8: ΣΥΝΤΕΛΕΣΤΕΣ ΚΛΙΜΑΚΩΣΗΣ..99 ΠΙΝΑΚΑΣ 9: ΠΑΡΑΓΟΝΤΕΣ ΚΟΣΤΟΥΣ...99 ΠΙΝΑΚΑΣ 10: ΣΥΝΤΕΛΕΣΤΕΣ ΚΟΣΤΟΥΣ

9 ΕΙΣΑΓΩΓΗ Η οικονομική του λογισμικού μπορεί να θεωρηθεί ένας κλάδος της οικονομικής της πληροφορικής που με τη σειρά της είναι ένα πεδίο έρευνας στα οικονομικά το οποίο άρχισε να ενδιαφέρει τους οικονομολόγους την δεκαετία του 60. Τα βασικά αντικείμενα έρευνας αναφέρονταν σε θέματα όπως η οικονομική της διαφήμισης, η αναζήτηση καλύτερων τιμών, η οικονομική των επενδύσεων σε έρευνα και τεχνολογία. Η πρώτη εκτεταμένη εφαρμογή των οικονομικών στον τομέα της πληροφορικής υπήρξε η εργασία του Sharpe <<The economics of Computer>>[28]. Η συγκεκριμένη εργασία κάλυπτε θέματα όπως: οι επιλογές ανάμεσα στην αγορά, ενοικίαση ή leasing υπολογιστικών συστημάτων, τιμολόγηση αυτών καθώς και οικονομίες κλίμακας για υπολογιστικά συστήματα. Επιπλέον, περιελάμβανε και μία μικρή αναφορά για το κόστος λογισμικού στηριγμένη στην μελέτη System Development Corporation (SCD) που είχε διεξάγει η Αμερικάνικη Αεροπορία το Ουσιαστικά η μελέτη SDC παρουσίαζε ένα μοντέλο γραμμικής παλινδρόμησης προκειμένου να εκτιμηθεί το κόστος λογισμικού μίας εφαρμογής. Παρόλο που δεν ήταν ακριβές μοντέλο έδωσε το κατάλληλο ερέθισμα και την απαραίτητη ώθηση για να πραγματοποιηθεί έρευνα για μοντέλα εκτίμησης κόστους στην δεκαετία του 70 και του 80. Αποτέλεσμα της έρευνας αυτής υπήρξαν κάποια μοντέλα εκτίμησης κόστους τα οποία χρησιμοποιούνται ακόμα και σήμερα όπως τα SLIM, COCOMO, PRICE, SEER, ESTIMACS, SPQR/ Checkpoint. Στόχος του καλού σχεδιασμού των έργων πληροφορικής είναι η δημιουργία αξίας για την συγκεκριμένη επένδυση. Η οικονομική του λογισμικού μπορεί να οριστεί ως ο τομέας έρευνας που σκοπεύει στην βελτιστοποίηση της σχεδίασης και της υλοποίησης έργων πληροφορικής. Το πεδίο έρευνας της οικονομικής του λογισμικού τοποθετείται στην τομή των οικονομικών της πληροφορίας (information economics) με τον σχεδιασμό και την ανάπτυξη του λογισμικού. Βασική επιδίωξη της οικονομικής του λογισμικού είναι να βελτιώσει την αξία που δημιουργείται από τις επενδύσεις σε λογισμικό. Αναζητά την ουσιαστικότερη κατανόηση των σχέσεων μεταξύ των οικονομικών στόχων, περιορισμών και υποθέσεων από την μία μεριά με θέματα σχεδίασης και υλοποίησης λογισμικού από την άλλη, με σκοπό την βελτίωση της αξίας της επένδυσης σε επίπεδα έργου, προγράμματος, επιχείρησης, βιομηχανίας και εθνικών πόρων. 8

10 Πολλά από τα μοντέλα εκτίμησης κόστους δεν είναι συνεπή, καθώς τα δεδομένα για την εκτίμηση του κόστους, προγραμματισμού και ποιότητας απέχουν πολύ από το να γίνουν ομοιόμορφα. Παρά το σημαντικό βήμα που έγινε με την ανάπτυξη των βασικών μετρικών λογισμικού παρατηρείται μία απόκλιση του % μεταξύ των έργων και οργανισμών ως προς τους κανόνες που διέπουν την εκτίμηση του κόστους. Για παράδειγμα, υπάρχει διαφορετική συσχέτιση ανά οργανισμό του τρόπου εκτίμησης της υπερωρίας σε σχέση με την κατηγοριοποίηση της θέσης εργασίας και σε συνδυασμό με την ανάπτυξη των χαρακτηριστικών της εφαρμογής ή της επίλυσης των προβλημάτων. Αυτό το γεγονός οδήγησε στη δημιουργία μοντέλων εκτίμησης κόστους διαμορφωμένα και προσαρμοσμένα στα χαρακτηριστικά των οργανισμών που τα ανέπτυξαν, τα οποία αποδείχθηκαν περισσότερο ακριβή στις εκτιμήσεις τους από τα προτυποποιημένα μοντέλα (COCOMO, Function Points,SLIM κ.α.). Τέτοια μοντέλα αναπτύχθηκαν από μεγάλους οργανισμούς πληροφορικής και τηλεπικοινωνιών όπως AT&T/Lucent, IBM, Hewlett Packard, NAS/CSC/ Univercity of Maryland Software Engineering Lab, Advanced Information Services. Ο πολλαπλασιασμός των νέων διαδικασιών και τεχνολογιών είναι μία ακόμη πηγή ποικιλίας που περιορίζει την ακρίβεια εκτίμησης των μοντέλων. Επιπλέον εναλλακτικές προσεγγίσεις εκτίμησης κόστους έχουν αναπτυχθεί από: expertisebased, dynamics-based, case-based καθώς και μοντέλα νευρωνικών δικτύων. Η μέτρηση της παραγωγικότητας σε κώδικα λογισμικού υπήρξε ένα δύσκολο αντικείμενο. Πολλές συζητήσεις υπήρξαν στο κατά πόσο οι πηγαίες γραμμές κώδικα ή τα λειτουργικά σημεία (function points) είναι καλύτερα για την μέτρηση της παραγωγικότητας ανά ανθρωπομήνα. Εάν ένας οργανισμός έχει την δυνατότητα να αναπτύσσει λογισμικό σε διαφορετικά επίπεδα γλωσσών προγραμματισμού (assembly, 3GL, 4GL) τα λειτουργικά σημεία είναι προτιμότερα για την εκτίμηση της παραγωγικότητας καθώς δεν λαμβάνουν υπόψιν την επιπλέον εργασία που ενδεχομένως να χρειάζεται για να παραχθεί το προϊόν σε μια γλώσσα χαμηλού επιπέδου. Εάν ο οργανισμός αναπτύσσει όλο το λογισμικό στο ίδιο επίπεδο γλώσσας προγραμματισμού οποιαδήποτε από τις παραπάνω μεθοδολογίες είναι ικανοποιητική. Παράγοντες που επηρεάζουν την παραγωγικότητα είναι οι εξής: o Εμπειρία σε συγκεκριμένο τομέα εφαρμογών: Η γνώση του τομέα εφαρμογών είναι ουσιαστική για την αποτελεσματική ανάπτυξη του λογισμικού. Οι μηχανικοί οι οποίοι ήδη γνωρίζουν το τομέα εφαρμογών είναι πιο πιθανό να είναι περισσότερο παραγωγικοί. 9

11 o Ποιότητα διαδικασιών: Η διαδικασία ανάπτυξης λογισμικού που χρησιμοποιείται μπορεί να έχει σημαντική επίδραση στην παραγωγικότητα. o Μέγεθος έργου: Όσο μεγαλύτερο είναι ένα έργο τόσο περισσότερος χρόνος απαιτείται για επικοινωνία μεταξύ των μελών της ομάδας. Επομένως λιγότερος χρόνος είναι διαθέσιμος για ανάπτυξη, άρα η ατομική παραγωγικότητα μειώνεται. o Τεχνολογική υποστήριξη: Καλή τεχνολογική υποστήριξη, όπως CASE εργαλεία, υποστηρικτικά διαχειριστικά συστήματα κ.ά. μπορούν να βελτιώσουν την παραγωγικότητα. o Περιβάλλον εργασίας: Ένα ήσυχο εργασιακό περιβάλλον με ατομικές περιοχές εργασίας συμβάλλουν στην βελτιστοποίηση της παραγωγικότητας. 10

12 ΚΕΦΑΛΑΙΟ 1 ΕΚΤΙΜΗΣΗ ΚΟΣΤΟΥΣ ΛΟΓΙΣΜΙΚΟΥ 1.1 ΕΙΣΑΓΩΓΗ Η μηχανική του λογισμικού όπως καθορίζεται από το ΙΕΕΕ πρότυπο είναι η εξής: << Η εφαρμογή μιας συστηματικής, πειθαρχημένης, ποσοτικοποιημένης προσέγγισης στην ανάπτυξη, λειτουργία και συντήρηση του λογισμικού>>. Οι μεθοδολογίες εκτίμησης κόστους χρησιμοποιούνται από την βιομηχανία λογισμικού για να ποσοτικοποιήσουν την ανάπτυξη, λειτουργία και συντήρηση του λογισμικού. Μας δίνουν την γνώση της κατάστασης ενός χαρακτηριστικού του λογισμικού και μας βοηθούν να το εκτιμήσουμε με ένα αντικειμενικό τρόπο. Η πρακτική της εφαρμογής μετρικών λογισμικού σε μία διαδικασία λογισμικού και σε ένα προϊόν λογισμικού είναι μια πολύπλοκη εργασία. Υπάρχει ένα εύρος τεχνικών εκτίμησης κόστους λογισμικού όπου εξαρτώνται από τα χαρακτηριστικά του λογισμικού των οποίων θέλουμε να μετρήσουμε, την ποσότητα και την ποιότητα. Οι τεχνικές εκτίμησης κόστους λογισμικού οργανώνονται σε δύο διαφορετικές κατηγορίες: 1. Mετρικές για την διαδικασία ανάπτυξης λογισμικού & 2. Mετρικές για το προϊόν λογισμικού. Οι μετρικές για την διαδικασία ανάπτυξης λογισμικού σχετίζονται με την προσπάθεια που απαιτείται για να ολοκληρωθεί ένα έργο, τα resources που ξοδεύονται και τη μεθοδολογία που ακολουθείται. Ένα τέτοιο παράδειγμα είναι ο χρόνος που απαιτείται για να ολοκληρωθεί ένα έργο, οι άνθρωποι που απαιτούνται για να αναπτύξουν το έργο, το συνολικό κόστος σε χρήμα και η μεθοδολογία ανάπτυξης του έργου (π.χ. μοντέλο καταρράκτη, spiral, mature μοντέλο) που χρησιμοποιείται. Η μετρική που κάποιος μπορεί να εφαρμόσει εξαρτάται από την φύση του έργου του λογισμικού, όπως για παράδειγμα για την καταγραφή των απαιτήσεων μπορεί να θέλουμε να μετρηθεί πόσες απαιτήσεις έχει ένα έργο, την σχετικότητας τους και την ολοκληρωσιμότητα τους. Για το προϊόν λογισμικού μπορεί να θέλουμε να γνωρίζουμε τον αριθμό των πιθανών σφαλμάτων και δυσλειτουργιών που μπορεί να έχουν, τον αριθμό των περιπτώσεων ελέγχου για να επιβεβαιωθεί ότι όλες οι λειτουργικές απαιτήσεις έχουν προβλεφθεί. Ακόμα μπορεί να μετρηθεί και η αξιοπιστία του λογισμικού που θα παραδοθεί στον πελάτη. Στο χώρο της ανάπτυξης λογισμικού δεν έχει συμφωνηθεί 11

13 μία μεθοδολογία μέτρησης και κοστολόγησης λογισμικού που να είναι αποδεκτή. Οι εταιρείες χρησιμοποιούν διαφορετικούς τρόπους για να μετρήσουν τα διαφορετικά χαρακτηριστικά του λογισμικού. 1.2 ΟΡΙΣΜΟΣ ΤΟΥ ΠΡΟΒΛΗΜΑΤΟΣ Η εκτίμηση του κόστους του λογισμικού αποτελεί ένα δύσκολο κομμάτι στη διαχείριση των έργων λογισμικού. Είναι υπευθυνότητα του project manager να κάνει ακριβής εκτίμηση για την προσπάθεια και το κόστος. Η κακή εκτίμηση του κόστους έχει σοβαρές συνέπειες σε ένα ανταγωνιστικό περιβάλλον για το λόγο ότι μία πιθανή υψηλή εκτίμηση του κόστους του λογισμικού μπορεί να επιφέρει απώλεια ενός έργου από ανταγωνιστές που θα το εκτιμήσουν χαμηλότερα, ενώ από την άλλη μεριά μια χαμηλή εκτίμηση του κόστους μπορεί να αποτελέσει απώλεια για τον οργανισμό για τον οποίον απευθύνεται το έργο. Έτσι πρέπει να υπάρχει η ορθή εκτίμηση της προσπάθειας και του μεγέθους του έργου σε ένα πρώιμο στάδιο προκειμένου η διεύθυνση να αποφασίσει στην υλοποίηση ή όχι του έργου, παρόλο που μια πρώιμη εκτίμηση του κόστους του έργου πριν από την διαδικασία της ανάπτυξης μπορεί να οδηγήσει σε λανθασμένες προδιαγραφές. Η διαδικασίας της εκτίμησης κόστους του λογισμικού είναι ένα σύνολο τεχνικών και διαδικασιών που χρησιμοποιούν οι οργανισμοί για να φτάσουν σε μία εκτίμηση του κόστους υλοποίησης και της προσπάθειας που θα χρειαστεί. Λόγοι δυσκολίας εκτίμησης του κόστους: Η εκτίμηση κόστους του λογισμικού απαιτεί αρκετή προσπάθεια προκειμένου να πραγματοποιηθεί σωστά. Η εκτίμηση κόστους λογισμικού είναι μία διαδικασία που δεν λαμβάνεται σοβαρά από τους managers και γίνεται συνήθως βιαστικά χωρίς καμία εκτίμηση της προσπάθειας που απαιτείται. Απαιτείται εμπειρία σε διαδικασίες εκτίμησης ειδικά για μεγάλα έργα. Ένας εκτιμητής είναι πιθανόν να εκτιμήσει τον χρόνο που θα πάρει να δημιουργηθεί ένα μέρος του συστήματος και να συνάγει τη συγκεκριμένη εκτίμηση και για το υπόλοιπο σύστημα αγνοώντας τους αστάθμητους παράγοντες και την ανελαστικότητα της ανάπτυξης του λογισμικού. Κόστος και προγραμματισμός συχνά προκαθορίζονται από μία εξωτερική πηγή. 12

14 Μία ανάλυση της διαδικασίας ανάπτυξης του λογισμικού δεν πραγματοποιείται ή δεν γίνεται απόλυτα κατανοητή. Υπάρχει μία έλλειψη αποδοχής ότι η ανάπτυξη του λογισμικού είναι ένας παράγοντας κόστους. 1.3 ΔΙΑΔΙΚΑΣΙΑ ΕΚΤΙΜΗΣΗΣ ΤΟΥ ΚΟΣΤΟΥΣ Ο υπολογισμός του κόστους λογισμικού έχει να κάνει με την πρόβλεψη των πόρων που απαιτούνται για την ανάπτυξη / συντήρηση ενός συστήματος λογισμικού. Η εκτίμηση του κόστους είναι μία συνεχής διαδικασία η οποία θα πρέπει να χρησιμοποιείται κατά τον κύκλο ζωής του έργου. Η διαδικασία εκτίμησης του κόστους αποτελείται από τις ακόλουθες διαδικασίες: Εκτίμηση του μεγέθους. Εκτίμηση κόστους και προσπάθειας. Εκτίμηση χρονοπρογραμματισμού του έργου. Εκτίμηση των κρίσιμων υπολογιστικών πηγών. Αποτίμηση κινδύνων. Έλεγχος και έγκριση. Εκτίμηση αναφορών. Μετρήσεις και βελτιώσεις των ιδίων διαδικασιών εκτίμησης του κόστους [24]. 13

15 Ανάλυση Απαιτήσεων Εκτίμηση μεγέθους έργου Βάση δεδομένων Εκτίμηση προσπάθειας και κόστους Εκτίμηση χρονοδιαγράμματος Εκτίμηση κρίσιμων υπολογίσιμων πηγών Εκτίμηση ρίσκου Έρευνα έγκριση των εκτιμήσεων Σύγκριση των εκτιμήσεων Διαβάθμιση και βελτίωση της διαδικασίας Διάγραμμα 1: Διάγραμμα εκτίμησης κόστους. 1.4 ΚΥΚΛΟΣ ΖΩΗΣ ΕΚΤΙΜΗΣΗΣ ΚΟΣΤΟΥΣ ΛΟΓΙΣΜΙΚΟΥ Η πρώτη κίνηση για τον υπολογισμό του κόστους ανάπτυξης ενός συγκεκριμένου έργου είναι να υπολογιστεί το μέγεθος της εφαρμογής που θα αναπτυχθεί. Υπάρχουν ποικίλες προσεγγίσεις στον υπολογισμό του μεγέθους της εφαρμογής, συμπεριλαμβανομένων παραμετρικών ή αλγοριθμικών και ευρεστικών ή μη 14

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

17 ΚΕΦΑΛΑΙΟ 2 ΜΟΝΤΕΛΑ ΕΚΤΙΜΗΣΗΣ ΚΟΣΤΟΥΣ 2.1 ΕΙΣΑΓΩΓΗ Οι τεχνικές για την εκτίμηση του κόστους χωρίζονται σε δύο κατηγορίες: τις αλγοριθμικές και τις μη αλγοριθμικές. Η βασική διαφορά ανάμεσα στα μοντέλα εκτίμησης κόστους είναι ανάμεσα στα μοντέλα που χρησιμοποιούν την μεθοδολογία των Γραμμών Κώδικα (Source Lines Of Code SLOC) σαν είσοδο στο μοντέλο σε σχέση με αυτά τα οποία δεν την χρησιμοποιούν. Η SLOC επιλέχθηκε σαν μετρική από τους ερευνητές λόγω της ποσοτικοποίησης και της φαινομενικής αντικειμενικότητας της. Αναπτύχθηκε μια ολόκληρη περιοχή έρευνας προκειμένου να καθοριστεί η καλύτερη μέθοδος υπολογισμού η SLOC. Δεδομένου όμως ενός εμφανές προβλήματος ότι δεν ήταν δυνατόν να εκτιμηθούν οι γραμμές του κώδικα πριν ένα έργο αναπτυχθεί, νέα μοντέλα υλοποιήθηκαν που δεν ελάμβαναν υπόψιν τις γραμμές κώδικα σαν βασική είσοδο. Μοντέλα που χρησιμοποιούν την SLOC σαν είσοδο είναι τα COCOMO και SLIM, ενώ μοντέλα που δεν χρησιμοποιούν γραμμές πηγαίου κώδικα σαν εισοδό τους είναι το Function Points που αναπτύχθηκε από τον Allan Albrecht στην IBM το 1979 και το ESTIMACS που αναπτύχθηκε από τον Howard Rubin στο Hunter College. Estimation Methods Model Based Methods Non-Model Methods Generic Model Based Specific Model Based Proprietary Non Proprietary Data Driven Composite Methods Διάγραμμα 3: Ταξινόμηση των μεθόδων εκτίμησης κόστους κατά Briandt [17]. 16

18 2.2 ΤΕΧΝΙΚΕΣ ΜΗ ΑΛΓΟΡΙΘΜΙΚΕΣ Οι τεχνικές αυτές δεν στηρίζονται σε κάποιο αλγόριθμο αλλά στην εμπειρία κάποιοι ατόμου την οποία απόκτησε στην πράξη. Στις μη αλγοριθμικές τεχνικές εντάσσονται και οι ευρεστικοί μέθοδοι. Υπάρχουν δύο ευρεστικοί μέθοδοι η top-down και η bottom-up. Τεχνικές μη αλγοριθμικές είναι και η τεχνική της κρίσης του κρίσης του ειδικού και η τεχνική των Δελφών που παρουσιάζονται παρακάτω ΤΕΧΝΙΚΗ ΤΗΣ ΔΟΜΗΣ ΚΑΤΑΚΕΡΜΑΤΙΣΜΟΥ ΤΗΣ ΕΡΓΑΣΙΑΣ (TOP DOWN) Η τεχνική της δομής κατακερματισμού της εργασίας (work breakdown structures technique) βασίζεται στην αρχή ότι το κόστος ενός συστήματος ισούται με το άθροισμα ορισμένων όρων που ο κάθε ένας όρος αντιπροσωπεύει το κόστος ενός επιμέρους κομματιού του αντίστοιχου συστήματος. Τα επιμέρους κομμάτια του συστήματος είναι αποτέλεσμα κατακερματισμού του συστήματος. Ο κατακερματισμός αυτός γίνεται χωρίζοντας το σύστημα σε επιμέρους κομμάτια, το κάθε κομμάτι καταμερίζεται σε άλλα κομμάτια κ.ο.κ. Το κατακερματισμένο σύστημα που προκύπτει με αυτόν τον τρόπο έχει μία ιεραρχική δομή και μπορεί να παρασταθεί με ένα ιεραρχικό διάγραμμα που λέγεται <<διάγραμμα δομής κατακερματισμού του συστήματος>>. Η τεχνική αυτή χρησιμοποιεί δύο διαφορετικές δομές κατακερματισμού του συστήματος. Στην πρώτη, ως σύστημα θεωρείται το έργο. Τα επιμέρους στοιχεία της δομής συμβολίζουν τα κομμάτια του έργου, δηλαδή τα υποέργα όπως φαίνεται στο διάγραμμα 4. ΕΡΓΟ Υποέργο 1 Υποέργο 2 Υποέργο Ν Διάγραμμα 4: Κατακερματισμός έργου. Στη δεύτερη ως σύστημα θεωρείται η διεργασία κατασκευής του συστήματος. Τα επιμέρους στοιχεία της δομής συμβολίζουν τα υποσυστήματα που πρέπει να γίνουν 17

19 και να ολοκληρωθεί το αντίστοιχο έργο όπως φαίνεται και στο διάγραμμα 5. Για κάθε στοιχείο του κατακερματισμού του συστήματος εκτιμάται ένα κόστος ξεκινώντας από τα φύλλα της δομής και προχωρώντας προς τους εσωτερικούς κόμβους. Το κόστος του πρωταρχικού στοιχείου της δομής δίνει το ολικό κόστος του συστήματος. Δηλαδή, η τεχνική αυτή χρησιμοποιεί μία στρατηγική από πάνω προς τα κάτω ( top down approach). Σε αυτή την τεχνική εκτίμησης του κόστους μπορεί να χρησιμοποιηθεί η δομή κατακερματισμού του έργου ή η δομή κατακερματισμού του συστήματος ή και οι δύο δομές. Υποσύστημα1 Υποσύστημα 2 Υποσύστημα Ν Διάγραμμα 5: Κατακερματισμός του συστήματος BOTTOM UP Στην bottom-up προσέγγιση, οι προγραμματιστές εκτιμούν την προσπάθεια που απαιτείται για την κωδικοποίηση κάθε τμήματος της εφαρμογής ξεχωριστά και με βάση αυτές τις εκτιμήσεις υπολογίζεται και η προσπάθεια για τις ενέργειες που δεν αφορούν την κωδικοποίηση. Ποιο συγκεκριμένα το έργο χωρίζεται σε μικρότερα κομμάτια (modules). Άμεση εκτίμηση της προσπάθειας και του χρονοπρογραμματισμού γίνεται για κάθε module. Το ποσοστό της προσπάθειας για κάθε δραστηριότητα στο πλάνο έργου (project plan) συγκρίνεται με προκαθορισμένα ποσοστά για να ελεγχθεί ότι η κατανομή της προσπάθειας στις δραστηριότητες είναι λογική ή όχι. Οι προσπάθειες για κάθε ξεχωριστή διαδικασία προστίθενται για να καθοριστεί το συνολικό κόστος ανάπτυξης. 18

20 Εάν τα ποσοστά προσπάθειας στο πλάνο έργου αποκλίνουν σημαντικά από τα προκαθορισμένα ποσοστά τότε πρέπει να γίνει επανεκτίμηση κάποιων δραστηριοτήτων ΤΕΧΝΙΚΗ ΤΗΣ ΚΡΙΣΗΣ ΤΟΥ ΕΙΔΙΚΟΥ Μία από τις μεθόδους που χρησιμοποιείται περισσότερο για εκτίμηση του κόστους λογισμικού είναι αυτή της κρίσης του ειδικού η οποία δεν στηρίζεται σε μαθηματικό υπόβαθρο αλλά στην εμπειρία, την προϋπηρεσία και την γνώση των εκτιμητών σε παρόμοια περιβάλλοντα ανάπτυξης και ιστορικές βάσεις δεδομένων με στοιχεία ολοκληρωμένων έργων, στη διαίσθηση ενός ή περισσοτέρων ατόμων. Ένας ειδικός κάνει μία εκτίμηση κόστους βασιζόμενος πάντα σε εμπειρίες από παρόμοιο σύστημα που είχε αναπτυχθεί νωρίτερα. Με βάση το πραγματικό κόστος του παλιού συστήματος γίνεται η εκτίμηση κόστους του καινούργιου συστήματος με κατάλληλες προσαρμογές. Το κόστος του παλιού συστήματος θεωρείται ως άθροισμα των όρων που κάθε ένας αντιπροσωπεύει το κόστος ενός επιμέρους κομματιού του συστήματος. Σε αυτό το άθροισμα ορισμένοι όροι παραλείπονται, νέοι προστίθενται και όσοι μένουν προσαρμόζονται με αποτέλεσμα ένα καινούργιο άθροισμα να αντιπροσωπεύει μία εκτίμηση κόστους για το καινούργιο σύστημα. Η διαδικασία αυτή εκτίμησης κόστους δεν είναι καθόλου εύκολη και δεν μπορεί να θεωρηθεί συνεπής. Δύο κίνδυνοι που μπορεί να οδηγήσουν σε λανθασμένα αποτελέσματα είναι οι ακόλουθοι: Πρώτον, ο ειδικός να θεωρήσει το καινούργιο σύστημα παρόμοιο με ένα παλιό και αυτό να μην ανταποκρίνεται στην αλήθεια οπότε ξεκινάει από μία λάθος βάση. Δεύτερον, ο ειδικός να μην έχει εμπειρία με παρόμοια συστήματα με αυτό που καλείται να κάνει εκτίμηση κόστους, οπότε του λείπει η βάση. Και στις δύο περιπτώσεις η εκτίμηση κόστους είναι λανθασμένη. Για να αποφευχθούν τέτοιοι κίνδυνοι μπορεί να χρησιμοποιηθεί μία ομάδα από ειδικούς, η οποία κάνει μία εκτίμηση κόστους με συναίνεση. Βέβαια, η συναίνεση συνεπάγεται τον κίνδυνο ένα μέλος της ομάδας που είναι ισχυρή προσωπικότητα ή έχει μεγάλη εξουσία να παρασύρει τα άλλα μέλη να συμφωνήσουν στη δική του προσέγγιση. Έρευνα που πραγματοποιήθηκε στη Δανία αποκάλυψε ότι το 62% των εκτιμητών και των οργανισμών χρησιμοποιούν αυτήν την τεχνική, άλλη έρευνα από τους Vidger 19

21 και Kark αποκάλυψε ότι η τεχνική αυτή είναι εξαιρετικά δημοφιλής. Πιο συγκεκριμένα η μελέτη που διεξήχθη από τους Vidger και Kark αποκάλυψε ότι εν γένει οι εκτιμητές δεν χρησιμοποιούν πληροφορίες από προηγούμενα έργα είτε διότι ήταν πολύ δύσκολο να έχουν πρόσβαση σε αυτά είτε διότι δεν μπορούσαν να βρουν κάποιο τρόπο με τον οποίο θα μπορούσε αυτή η πληροφορία να τους είναι χρήσιμη για την ακρίβεια των εκτιμήσεων τους. Η μελέτη αυτή υποστηρίζει ότι η πλειοψηφία των εκτιμητών τείνουν να χρησιμοποιούν τις αναμνήσεις από παλαιότερα έργα. Ένας ή περισσότεροι ειδικοί λαμβάνουν μέρος στην διαδικασία εκτίμησης και έτσι λαμβάνεται ένας σταθμισμένος μέσος όρος των αναμνήσεων ως εκτίμηση. Υπάρχουν σοβαροί κίνδυνοι με αυτήν την μέθοδο ιδιαίτερα αν το υπό σχεδιασμό έργο περιλαμβάνει χαρακτηριστικά γνωρίσματα που πριν δεν είχαν αντιμετωπιστεί στο παρελθόν. Παρά την εκτενή χρήση της μεθόδου αυτής, δεν έχει καλή φήμη και αρκετές εκτιμήσεις που στηρίζονται σε αυτήν την τεχνική έχουν θεωρηθεί υποκειμενικές και αδόμητες και τα αποτελέσματα τους θεωρούνται τρωτά σε σχέση με αυτά των δομημένων μεθόδων [11, 26] ΤΕΧΝΙΚΗ DELFI (ΤΕΧΝΙΚΗ ΤΩΝ ΔΕΛΦΩΝ) Η τεχνική Delfi (τεχνική των Δελφών) αναπτύχθηκε από την εταιρεία Rand Corporation το 1948 για να εξαλειφθούν οι δυσμενείς παράγοντες που δημιουργούνται αναπόφευκτα όταν μία ομάδα ειδικών προσπαθεί να λύσει συναινετικά ένα πρόβλημα στη διάρκεια διαδοχικών συναντήσεων. Η προσαρμογή της Τεχνικής των Δελφών για εκτιμήσεις του κόστους λογισμικού από μία ομάδα ειδικών παρουσιάσθηκε από τον Fairley με τον παρακάτω τρόπο. Στην ομάδα των εκτιμητών ένας από όλους παίζει τον ρόλο του <<συντονιστή>> και οι υπόλοιποι του <<εκτιμητή>> [9]. 1. Ο συντονιστής δίνει σε κάθε εκτιμητή το έγγραφο ορισμού του συστήματος και μία τυποποιημένη φόρμα (φόρμα εκτίμησης με βάση την Τεχνική των Δελφών) για να καταγράψει την δικιά του εκτίμηση για το κόστος του συστήματος. 2. Οι εκτιμητές μελετούν τον ορισμό του συστήματος και συμπληρώνουν στην αντίστοιχη φόρμα ανώνυμα την εκτίμηση τους και την δίνουν στον συντονιστή. Οι εκτιμητές δεν επιτρέπεται να σχολιάσουν μεταξύ τους τις εκτιμήσεις που έχουν κάνει αλλά μπορούν να κάνουν ερωτήσεις στο συντονιστή. 20

22 3. Ο συντονιστής προετοιμάζει και μοιράζει στους εκτιμητές μία περίληψη των εκτιμήσεων που έλαβε, μαζί με εκείνα τα σχόλια των εκτιμητών για την εκτίμηση που πιστεύει ότι είναι ασυνήθιστα. 4. Οι εκτιμητές συμπληρώνουν μία καινούργια φόρμα εκτίμησης, ανώνυμα, λαμβάνοντας υπόψιν τα αποτελέσματα της προηγούμενης εκτίμησης και τη δίνουν στο συντονιστή. Οι εκτιμήσεις των εκτιμητών που διαφέρουν αρκετά από των υπολοίπων μπορούν να ερωτηθούν από τον συντονιστή και να δικαιολογήσουν την εκτίμηση τους (ανώνυμα). 5. Η διαδικασία μπορεί να επαναλαμβάνεται από το βήμα 3 έως ότου απαλειφθούν οι διαφορές μεταξύ των εκτιμητών. Κατά τη διάρκεια αυτής της διεργασίας η ομάδα δεν επιτρέπεται να συναντηθεί. Ακολουθεί μία μικρή παραλλαγή της τεχνικής, η οποία αυξάνει την επικοινωνία και διατηρεί την ανωνυμία [9]. 1. Ο συντονιστής δίνει σε κάθε εκτιμητή το έγγραφο ορισμού του συστήματος και μία φόρμα για να καταγράψει τη δική του εκτίμηση για το κόστος του συστήματος. 2. Οι εκτιμητές μελετούν τον ορισμό του συστήματος και ο συντονιστής καλεί μία συνάντηση της ομάδας στην οποία όλοι μαζί μπορούν να κουβεντιάσουν τα ζητήματα που αφορούν την εκτίμηση του κόστους. 3. Οι εκτιμητές συμπληρώνουν ανώνυμα τις φόρμες εκτίμησης. 4. Ο συντονιστής προετοιμάζει μία περίληψη των εκτιμήσεων αλλά δε βάζει σχόλια. 5. Ο συντονιστής καλεί μία συνάντηση της ομάδας στην οποία η συζήτηση επικεντρώνεται σε εκτιμήσεις που διαφέρουν αρκετά. 6. Οι εκτιμητές κάνουν μία καινούργια εκτίμηση, τη βάζουν στη φόρμα εκτίμησης και τη δίνουν ανώνυμα στο συντονιστή. Η διαδικασία προετοιμάζεται από το βήμα 4 έως ότου απαλειφθούν οι διαφορές μεταξύ των εκτιμητών. Και στις δύο περιπτώσεις είναι δυνατόν ύστερα από πολλούς γύρους να μην καταστεί δυνατόν να φθάσουν οι ειδικοί σε μία εκτίμηση αποδεκτή από όλους. Σε αυτήν την περίπτωση ο συντονιστής πρέπει να κουβεντιάσει το ζήτημα με κάθε ένα εκτιμητή χωριστά για να ξεκαθαρίσουν οι λόγοι των διαφορών. Με αυτόν τον τρόπο ο συντονιστής συγκεντρώνει επιπρόσθετες πληροφορίες που απαιτούνται και τις παρουσιάζει στους εκτιμητές για να λυθεί το αδιέξοδο. Η τεκμηρίωση που απαιτείται για την τεχνική των Δελφών είναι η ακόλουθη: 21

23 Η διαδικασία εκτίμησης των Δελφών απαιτεί την χρήση της φόρμας εκτιμήσεων όπως παρουσιάζεται παρακάτω. Ο Αριθμός Ανάθεσης Εργασίας, το όνομα του Εκτιμητή και η ημερομηνία εκτίμησης πρέπει να εισαχθούν στα κατάλληλα πεδία στην φόρμα. Το πεδίο απαίτηση αναγνωρίζεται αριθμητικά από αναφορά της ανάλυσης των απαιτήσεων. Οι εκτιμητές παρέχουν εκτιμήσεις για κάθε απαίτηση (requirement) σε ξεχωριστή φόρμα εκτίμησης. Οι εκτιμητές στηρίζονται σε δύο μετρικές α) στα πηγαίες γραμμές κώδικα (Source Lines of Code SLOC) και β) στις γραμμές κειμένου τεκμηρίωσης (Lines of Documentation LOD) οι οποίες εισάγονται (Ins) και διαγράφονται (Del) με σκοπό να υλοποιηθούν οι διάφορες απαιτήσεις. Οι εκτιμήσεις για κάθε απαίτηση εισάγονται στις SLOC και LOD κολώνες της φόρμας. Οι εκτιμήσεις για τις ανθρωποώρες γίνονται για κάθε διαδικασία μπλοκ / κελί για την οποία θα πρέπει να πραγματοποιηθεί εργασία για την ανάπτυξη και έλεγχο (κελιά 601, 602, 603, 701 και 702). Οι εκτιμήσεις δίνονται σε ανθρωποώρες. Για κάθε μεταγενέστερο κύκλο εκτίμησης χρησιμοποιείται η ίδια φόρμα εκτίμησης. Στατιστικά για τον προηγούμενο κύκλο εκτιμήσεων παρέχονται για κάθε Λειτουργική Απαίτηση. Περιλαμβάνονται η προηγούμενη εκτίμηση του εκτιμητή, η μεγαλύτερη και μικρότερη εκτίμηση από τους άλλους εκτιμητές καθώς και η μέση εκτίμηση όλων των εκτιμητών. Φόρμα εκτίμησης για την τεχνική των Δελφών Όνομα Εκτιμητή: Αριθμός Ανάθεσης Εργασίας: Γύρος Εκτίμησης (κυκλική επιλογή):1 2 3 LOC LOD 601 (Σε Ins+Del Ins+Del ώρες) Υψηλότερη Εκτίμηση Μέση Εκτίμηση Χαμηλότερη Εκτίμηση 602 (Σε ώρες) Ημερομηνία: Λειτουργική Απαίτηση: 603 (Σε 701 (Σε 702 (Σε ώρες) ώρες) ώρες) 22

24 Προηγούμενη Εκτίμηση Εκτιμητή Νέα εκτίμηση Εκτιμητή Σχόλια Εκτιμητή: Πίνακας 1:Φόρμα Εκτίμησης με βάση την τεχνική των Δελφών. 2.3 ΤΕΧΝΙΚΕΣ ΑΛΓΟΡΙΘΜΙΚΕΣ _ΜΗ ΠΑΡΑΜΕΤΡΙΚΕΣ 2.3.1ΕΚΤΙΜΗΣΗ ΜΕ ΑΝΑΛΟΓΙΕΣ Η Εκτίμηση με Αναλογίες (Estimation by Analogy-EbA) είναι μία μορφή συλλογιστικής βασισμένη σε περιπτώσεις (Case Based Reasoning-CBR), η οποία στηρίζεται στην ακόλουθη θεμελιώδη αρχή (Leake, 1996) «Νέα προβλήματα επιλύονται καλύτερα με λύσεις παλαιότερων παρόμοιων προβλημάτων» και σχετίζεται άμεσα με τον τρόπο με τον οποίο ο άνθρωπος επιλύει σε καθημερινή βάση ατομικά προβλήματα, βασιζόμενος σε παρόμοια γεγονότα του παρελθόντος[16]. Τα κύρια χαρακτηριστικά της μεθόδου είναι: Η χρήση μίας βάσης δεδομένων που αποτελείται από ολοκληρωμένα έργα με γνωστό κόστος. Η περιγραφή του νέου έργου με χαρακτηριστικά παρόμοια των ολοκληρωμένων έργων (π.χ. μετρικές κώδικα, γλώσσα προγραμματισμού, εμπειρία των προγραμματιστών, πεδίο εφαρμογής). Ο ορισμός της έννοιας της απόστασης ανάμεσα σε δύο έργα και η χρήση μέτρων απόστασης και ανομοιότητας που υπολογίζονται από τα χαρακτηριστικά των έργων. Ο υπολογισμός της απόστασης του νέου έργου από κάθε έργο της βάσης. Ο εντοπισμός των κοντινότερων έργων (γειτονικά ή ανάλογα). Η πρόβλεψη του κόστους συνδυάζοντας τα κόστη των γειτονικών έργων (συνήθως παίρνουμε το μέσο όρο τους). 23

25 Αναγνωρίζοντας τα χαρακτηριστικά τα οποία πιστεύεται ότι είναι σημαντικά για το νέο έργο τα πλέον κοντινά αναλογικά ολοκληρωμένα έργα μπορούν να βρεθούν. Η ομοιότητα ανάμεσα στα έργα μπορεί να ληφθεί χρησιμοποιώντας κάποιον από τους άλλους αλγόριθμους του <<Κοντινότερου Γείτονα (Nearest Neighbor NN>>. Ένας από τους πιο κοινούς ΝΝ αλγόριθμους είναι η <<Ευκλείδεια Απόσταση>> (Euclidean Distance ED). Τα χαρακτηριστικά αναπαριστώνται σαν έναν διάστατο χώρο και η απόσταση ανάμεσα σε δύο έργα (p και q ) μπορεί να βρεθεί χρησιμοποιώντας το ED με βάση την παρακάτω συνάρτηση [4]: Εξίσωση 1: Ευκλείδεια απόσταση Όπου n ο αριθμός που κάθε έργο έχει. Στη πρόβλεψη του κόστους συνδυάζοντας τα κόστη των γειτονικών έργων συνήθως παίρνουμε το μέσο όρο τους, αλλά η επιλογή αυτή δεν είναι πάντα η καλύτερη δυνατή. Ένα σημαντικό θέμα στην εφαρμογή της μεθόδου είναι η ρύθμιση (calibration) των διαφόρων παραμέτρων (αριθμός γειτόνων, μέτρο απόστασης κλπ) στα τοπικά δεδομένα. Γενικά, η μέθοδος είναι πολύ δημοφιλής (Heemstra, 1992), γιατί συνδυάζει ποικίλα πλεονεκτήματα[11]: Είναι εύκολη στην εφαρμογή. Η διαδικασία και τα αποτελέσματά της ερμηνεύονται εύκολα αφού ουσιαστικά προσομοιώνει τη λήψη αποφάσεων με αναζήτηση όμοιων καταστάσεων. Είναι εφαρμόσιμη σε όλους τους τύπους δεδομένων. Δεν βασίζεται σε υποθέσεις για την κατανομή των δεδομένων. Το πρόβλημα της μεθόδου είναι ότι παρουσιάζει δυσκολίες στη θεωρητική μελέτη του σφάλματος πρόβλεψης (prediction error) CASE BASED REASONING (CBR) Η τεχνική Case Based Reasoning και Reasoning by Analogy είναι συνώνυμες τεχνικές αν και δεν είναι απόλυτα όμοιες. Η τεχνική reasoning by analogy σημαίνει να 24

26 εφαρμοστεί η λύση σε ένα πρόβλημα χρησιμοποιώντας πληροφορίες από έργα και άλλων πεδίων εφαρμογών. Η συλλογιστική βασισμένη σε περιπτώσεις (CBR) είναι η διαδικασία επίλυσης των νέων προβλημάτων που εμπνέεται από τις λύσεις παρόμοιων προβλημάτων του παρελθόντος. Ξεκινά με μια σειρά περιπτώσεων / παραδειγμάτων, εξάγει γενικεύσεις από τα παραδείγματα αυτά εντοπίζοντας ομοιότητες μεταξύ των περιπτώσεων / παραδειγμάτων και του συγκεκριμένου προβλήματος. Η μέθοδος συλλογιστικής βασισμένη σε περιπτώσεις (CBR) έχει χρησιμοποιηθεί στον τομέα των κατασκευών όπως για συστήματα εκτίμησης διάρκειας, κόστους, υποβολής προσφορών επιλογής μεθόδων και μεθόδων διαχείρισης. Το σημαντικότερο και δυσκολότερο στοιχείο της μεθόδου αυτής είναι η καταχώρηση και επιλογή παρόμοιων περιπτώσεων που θα βοηθήσουν στην λύση του νέου προβλήματος ή την εκτίμηση του κόστους της συγκεκριμένης κατασκευής. Ένα σύστημα/μοντέλο συλλογιστικής βασισμένη σε περιπτώσεις, εμπνευσμένο από την ανάμνηση των ομοιοτήτων στη συλλογιστική των εμπειρογνωμόνων, αποτελείται από τέσσερις επιμέρους διεργασίες: 1. Παλαιές υποθέσεις, οι οποίες αντιπροσωπεύουν εμπειρίες τις οποίες το σύστημα έχει αποκτήσει και αποθηκεύονται σε μια βάση περιπτώσεων. 2. Όταν μια νέα περίπτωση παρουσιάζεται στο σύστημα, το σύστημα CBR ανακτά μια ή περισσότερες αποθηκευμένες περιπτώσεις παρόμοιες με την νέα υπόθεση. Αυτό γίνεται σύμφωνα με κάποιο ποσοστό ομοιότητας που υπολογίζεται με βάση κάποια εξίσωση ομοιότητας καθορισμένη από το χρήστη. 3. Οι χρήστες προσπαθούν να επιλύσουν τη νέα περίπτωση με την προσαρμογή των ανακτηθέντων περιπτώσεων, και η προσαρμογή βασίζεται στις διαφορές μεταξύ των αποθηκευμένων υποθέσεων και τη νέα υπόθεση. 4. Η νέα λύση διατηρείται ως μέρος των αποθηκευμένων υποθέσεων καθ' όλη τη διάρκεια της εργασίας. 25

27 Διάγραμμα 6:διάγραμμα CBR μοντέλου ΠΑΛΙΝΔΡΟΜΗΣΗ Η παλινδρόμηση είναι μία ευρέως χρησιμοποιούμενη τεχνική για την εκτίμηση των recourses στην τεχνολογία λογισμικού. Είναι μία στατιστική όπου η εξαρτώμενη μεταβλητή λειτουργικά σχετίζεται με μία ή περισσότερες ανεξάρτητες μεταβλητές. Για να αποκτηθεί η σχέση μεταξύ αυτών των δύο τύπων των μεταβλητών ένας ικανοποιητικός αριθμός δεδομένων πρέπει να συλλεχθεί. Αναλύοντας αυτά τα δεδομένα παράγεται η ευθεία παλινδρόμησης που αποτελεί την καλύτερη προσέγγιση της σχέσης ανάμεσα στην εξαρτώμενη μεταβλητή (D) και στις ανεξάρτητες μεταβλητές (I1 In). Αυτή η ευθεία εκφράζεται με την παρακάτω συνάρτηση: D = α + β 1 * I β n * I n Εξίσωση 2: Υπολογισμός Ευθείας Παλινδρόμησης ή Estimate = α + β 1 (effort driver n ) +.. β n (effort driver n ) Εξίσωση 3: Υπολογισμός Εκτιμητή Προσπάθειας. Όπου a και b συντελεστές παλινδρόμησης. Όταν χρησιμοποιείται το μοντέλο παλινδρόμησης είναι σημαντικό να επιλέγονται οι μεταβλητές πολύ προσεκτικά. Δεδομένου ότι η εκτίμηση προσπάθειας (estimate effort) είναι αυτό που θέλουμε να εκτιμήσουμε, άρα η προσπάθεια αντιπροσωπεύει την D μεταβλητή. Οι ανεξάρτητες μεταβλητές είναι οι συντελεστές προσπάθειας 26

28 (effort drivers). Όπως για παράδειγμα, το μέγεθος του έργου και το μέγεθος του προσωπικού. Μία συνάρτηση παλινδρόμησης είναι η ακόλουθη: Effort = α + β 1 (size) Εξίσωση 4: Συνάρτηση Παλινδρόμησης. Όταν ένα απλό μοντέλο παλινδρόμησης δημιουργείται με δεδομένα από παλαιά έργα, η εκτίμηση της μελλοντικής προσπάθειας υπολογίζεται με ένα γνωστό μέγεθος έργου ORDINARY LEAST SQUARES (OLS) Η τεχνική OLS είναι η πιο κοινή μορφή παλινδρομικής ανάλυσης όπου γίνεται αναφορά στην κλασική στατιστική προσέγγιση της γενικής γραμμικής παλινδρόμησης χρησιμοποιώντας τη μέθοδο των ελάχιστων τετραγώνων. Με τη μέθοδο των ελάχιστων τετραγώνων έχουν ασχοληθεί αρκετοί συγγραφείς όπως οι (Judge et al. 1993, Weisberg 1985) [13, 27]. Σαν τεχνική είναι απλή και εύκολη στη χρήση. Η μέθοδος OLS προσαρμόζεται καλά όταν: 1. Είναι διαθέσιμα πολλά δεδομένα, όταν συμβαίνει αυτό υπάρχουν πολλοί βαθμοί ελευθερίας διαθέσιμοι και ο αριθμός των παρατηρήσεων είναι πολύ μεγαλύτερος από τον αριθμό των μεταβλητών που προβλέπονται. 2. Δεν λείπει κανένα στοιχείο στα δεδομένα. Τα σύνολα δεδομένων που παρουσιάζουν απώλεια πληροφορίας θα μπορούσαν να συμπεριληφθούν όταν υπάρχει περιορισμένος χρόνος και προϋπολογισμός κατά τη διαδικασία συλλογής δεδομένων ή λόγω της έλλειψης κατανόησης της υποβολής των εκθέσεων για τα δεδομένα. 3. Δεν υπάρχει κανένα outlier. Οι ακραίες περιπτώσεις παρουσιάζονται πολύ συχνά στα δεδομένα τεχνολογίας λογισμικού λόγω παρανοήσεων ή έλλειψης ακρίβειας στη διαδικασία συλλογής δεδομένων ή λόγω των διαφορετικών διαδικασιών ανάπτυξης. 4. Οι ανεξάρτητες μεταβλητές δεν συσχετίζονται. Τα περισσότερα από τα υπάρχοντα πρότυπα εκτίμησης λογισμικού έχουν παραμέτρους που συσχετίζονται μεταξύ τους. Αυτό παραβιάζει μία βασική υπόθεση εφαρμογής της OLS. 5. Οι ανεξάρτητες μεταβλητές έχουν εύκολη ερμηνεία όταν χρησιμοποιούνται στο πρότυπο. Αυτό είναι δύσκολο να επιτευχθεί καθώς υπάρχει αδυναμία στο 27

29 να γίνουν έγκυρες υποθέσεις τόσο για τη μορφή των συναρτησιακών σχέσεων μεταξύ των ανεξάρτητων μεταβλητών όσο και για καινοτομίες που αυτές ακολουθούν. 6. οι ανεξάρτητες μεταβλητές είναι είτε όλες συνεχείς είτε όλες διακριτές μεταβλητές. Υπάρχουν διάφορες στατιστικές τεχνικές για να εξεταστεί κάθε μία από τις ανεξάρτητες μεταβλητές. Κάθε ένα από αυτά αποτελεί πρόκληση στη διαμόρφωση των δεδομένων της τεχνολογίας λογισμικού έτσι ώστε να μπορέσει να αναπτυχθεί ένα κατανοητό και εποικοδομητικό πρότυπο εκτίμησης κόστους. Λαμβάνοντας υπόψη τα δεδομένα μας για τη περιγραφή της μεθόδου χρησιμοποιούμε μία γενική μεταφορά του εκθετικού προτύπου εκτίμησης. Effort = a * s b Εξίσωση 5: εκθετικό πρότυπο εκτίμησης. Λογαριθμώντας και τις δύο πλευρές έτσι ώστε Υ = log(effort), A = log(a) και Χ = log(s) η συνάρτηση μετασχηματίζεται σε μία γραμμική εξίσωση: Υ = Α + b * X Εξίσωση 6: γραμμική εξίσωση. Εάν στη συνέχεια εφαρμοστεί η κλασική μέθοδος των ελάχιστων τετραγώνων σε ένα σύνολο προηγούμενων δεδομένων {Υi, Xi: i = 1,, K}, προκύπτουν οι παράμετροι b και Α της εκθετικής συνάρτησης. Το μειονέκτημα της αυτής της μεθόδου είναι η υπόθεση ανυπαρξίας σφαλμάτων στη μεταβλητή S. Τα σφάλματα στην μέτρηση του μεγέθους του λογισμικού μπορεί να οφείλονται σε μία σειρά από παράγοντες οι οποίοι μπορεί να οφείλονται τόσο στο ανθρώπινο δυναμικό όσο και σε μικρές ή μεγάλες διαφοροποιήσεις στις τεχνικές μέτρησης του μεγέθους. 2.4 ΤΕΧΝΙΚΕΣ ΑΛΓΟΡΙΘΜΙΚΕΣ ΠΑΡΑΜΕΤΡΙΚΕΣ Οι τεχνικές αυτές στηρίζονται σε κάποιο αλγόριθμο ο οποίος χρησιμοποιεί δεδομένα από έργα λογισμικού που έχουν εκτελεστεί στο παρελθόν. Σύμφωνα με την μελέτη του Kemerer οι τεχνικές αυτές χωρίζονται σε δύο κατηγορίες[14]. Η πρώτη χρησιμοποιεί ανάμεσα στα άλλα δεδομένα και το μέγεθος του λογισμικού μετρημένου σε εντολές πηγαίου κώδικα. 28

30 Η δεύτερη κατηγορία δεν χρησιμοποιεί το στοιχείο αυτό, αλλά στοιχεία όπως είναι ο αριθμός των τύπων των δοσοληψιών του συστήματος (transactions) και ο αριθμός των αναφορών (reports) δηλαδή στοιχεία σχετικά με την είσοδο και την έξοδο. Οι αλγοριθμικές αυτές τεχνικές ονομάζονται και παραμετρικές προσεγγίσεις οι οποίες εκτιμούν το παραδοθέν μέγεθος του λογισμικού της εφαρμογής χρησιμοποιώντας έναν όρο εκτίμησης που ονομάζεται μετρική. Οι αποτελεσματικές μετρικές θα πρέπει να συσχετίζoνται στενά με την προσπάθεια που καταβάλλεται για την ανάπτυξη του έργου. Δύο μετρικές που χρησιμοποιούνται συχνά είναι οι : Source Line Of Code (SLOC) και τα Function Points) (FP). Έως τώρα έχει παρατηρηθεί είναι ότι καμία μετρική δεν έχει φανεί να είναι η ιδανική για όλους τους τύπους των έργων, κατά συνέπεια ο εκτιμητής θα πρέπει να επιλέξει την κατάλληλη μετρική για το έργο το οποίο θα θέλει να εκτιμήσει το κόστος του. Έτσι για παράδειγμα σε συστήματα τα οποία είναι data driven (εμπορικά πληροφοριακά συστήματα, MIS) κυριαρχεί η μετρική των Function Points, ενώ σε computation driven συστήματα κυριαρχεί η μετρική των SLOC. Η SLOC μετρική μετρά την εφαρμογή σε όρους <<γραμμών κώδικα>> περιλαμβανομένων δηλώσεων που αφορούν έλεγχο εργασιών αλλά δεν λαμβάνει υπόψιν της τα προγραμματιστικά σχόλια. Για εφαρμογές που είναι ισχυρά data driven αλλά επίσης περιλαμβάνουν και ισχυρά αλγοριθμικά δομικά στοιχεία έχει αναπτυχθεί η μετρική των Feature Points που ουσιαστικά επεκτείνει την υπάρχουσα μετρική των Function Points. Δύο ακόμα προσεγγίσεις αφορούν τις αντικειμενοστραφείς μετρικές και τις μετρικές Graphical User Interface (GUI). Οι αντικειμενοστραφείς μετρικές χρησιμοποιούν σαν είσοδο στους υπολογισμούς τους τον αριθμό των αντικειμένων που θα αναπτυχθούν προκειμένου να αποδώσουν την απαιτούμενη λειτουργικότητα της εφαρμογής, η μετρική αυτή αφορά κυρίως τις αντικειμενοστραφείς εφαρμογές. Οι Graphical User Interface μετρικές χρησιμοποιούν στοιχεία του GUI (παράθυρα, μενού) ως εισόδους SLIM Η μέθοδος εκτίμησης κόστους SLIM (Software Life Cycle Management) αναπτύχθηκε στα τέλη της δεκαετίας του 70 από τον Larry Putnam της εταιρείας Quantitative Software Management. Η μέθοδος SLIM εξαρτάται από τη χρήση της SLOC μεθόδου για εκτίμηση του γενικού μεγέθους του έργου και μετατρέπει το 29

31 εκτιμώμενο μέγεθος του έργου με την χρήση του μοντέλου εκτίμησης καμπύλης Rayleigh για υπολογισμό της εκτίμησης της ανθρωπο-προσπάθειας. Ο χρήστης μπορεί να επηρεάσει την μορφή της καμπύλης επηρεάζοντας δύο παραμέτρους: την αρχική κλίση της καμπύλης (manpower buildup index MBI) και έναν παράγοντα παραγωγικότητας (technology constant PF). Ο χρήστης του SLIM έχει δύο δυνατότητες για να επηρεάσει τις τιμές των δύο αυτών μεταβλητών: α) ο χρήστης μπορεί να επαληθεύσει το μοντέλο εισάγοντας δεδομένα από έργα που έχουν ολοκληρωθεί ή β) μπορεί να απαντήσει σε μία σειρά από 22 ερωτήσεις, από τις οποίες η μέθοδος SLIM θα εξάγει τα συνιστώμενα PF και MBI. Η μέθοδος του ερωτηματολογίου επιλέχθηκε λόγω της απουσίας προϋπάρχουσας βάσης δεδομένων σχετικών με έργα που έχουν ολοκληρωθεί και της αίσθησης ότι κάτι τέτοιο θα αντικατοπτρίζει περισσότερο τις εμπειρίες του μέσου χρήστη [23] ΟΡΙΣΜΟΣ ΤΗΣ SLOC Η μετρική SLOC εντοπίζει τον όγκο του κώδικα που απαιτείται για να αναπτυχθεί ένα έργο λογισμικού. Η εκτίμηση του μεγέθους γίνεται μέσω της αναλογίας ή της ύπαρξης μετρικών κώδικα. Η μετρική SLOC παρουσιάζει κάποιες δυσκολίες για το λόγο ότι δεν υπάρχει κάποιο πρότυπο για το τι μπορεί να θεωρείται μετρήσιμο σα γραμμή κώδικα και τι όχι. Η SLOC περιλαμβάνει μόνο τις γραμμές κώδικα οι οποίες παραδίδονται ως μέρος του προϊόντος που δίνεται στο πελάτη ενώ δεν περιλαμβάνει επιμέρους λογισμικό όπως το λογισμικό ελέγχου και το υποστηρικτικό λογισμικό. Πιο συγκεκριμένα περιλαμβάνονται οι γραμμές κώδικα που δημιουργούνται από το προσωπικό του έργου και αποκλείεται ο κώδικας που παράγεται από γεννήτριες εφαρμογών. Μία εντολή είναι μία γραμμή κώδικα, οι δηλώσεις λαμβάνονται ως εντολές και τα προγραμματιστικά σχόλια δεν λαμβάνονται ως εντολές. Πλεονεκτήματα και μειονεκτήματα της SLOC Πλεονεκτήματα: Εύκολα μπορεί να εκτιμηθεί το μέγεθος που αφορά ένα έργο. Υπάρχουν διαθέσιμα αρκετά ιστορικά δεδομένα. Μπορούν να αναπτυχθούν εύκολα εργαλεία αυτόματης μέτρησης γραμμών. Υποστηρίζεται από τις πλέον γνωστές μεθοδολογίες εκτίμησης κόστους. Μειονεκτήματα: 30

32 Δεν υπάρχει κάποιο παγκόσμιο πρότυπο με αποτέλεσμα να υπάρχουν αντιφατικές εκτιμήσεις. Εκτιμήσεις μεγέθους μεταξύ διαφορετικών γλωσσών για το ίδιο έργο είναι μη αξιόπιστες. Δεν υπάρχουν ολοκληρωμένα προϊόντα μέτρησης μεγέθους έργου. Η μετρική δεν είναι εύκολο να ερμηνευτεί. Είναι δυνατόν μία γλώσσα προγραμματισμού να έχει τις καλύτερες μετρικές παραγωγικότητας (προσπάθεια ανά SLOC) αλλά η χρήση της να παρουσιάζει υψηλότερο κόστος επειδή είναι λιγότερο αποτελεσματική από τις πιο σύγχρονες γλώσσες προγραμματισμού. Είναι απροσάρμοστη σε σύγχρονα προγραμματιστικά περιβάλλοντα COCOMO (CONSTRUCTIVE COST MODEL) Η COCOMO είναι αλγοριθμικό μοντέλο εκτίμησης κόστους που αναπτύχθηκε από τον Dr. Barry Boehm. Το μοντέλο αυτό χρησιμοποιεί ένα βασικό τύπο παλινδρόμησης με τις παραμέτρους που προκύπτουν από τα ιστορικά στοιχεία και τρέχοντα χαρακτηριστικά του έργου. Εκτενής αναφορά του μοντέλου ακολουθείται στο κεφάλαιο ΛΕΙΤΟΥΡΓΙΚΑ ΣΗΜΕΙΑ (FUNCTION POINTS) Η μέθοδος εκτίμησης και μέτρησης των λειτουργικών σημείων (Function Points) πρωτοδημοσιεύθηκε το 1979 από τον Allan Albrecht στην IBM, από τον οποίο αναπτύχθηκε και δημιουργήθηκε ως εναλλακτική μέθοδος εκτίμησης που χρησιμοποιεί πηγές γραμμές κώδικα (SLOC). Εκτενής αναφορά του μοντέλου γίνεται στο κεφάλαιο 4. 31

33 ΚΕΦΑΛΑΙΟ 3 ΜΟΝΤΕΛΟ COCOMO (CONSTRUCTIVE COST MODEL) 3.1 ΙΣΤΟΡΙΚΗ ΑΝΑΔΡΟΜΗ Η COCOMO δημοσιεύθηκε για πρώτη φορά το 1981, από το βιβλίο οικονομίας του Barry J. Boehm s με τίτλο Τεχνολογία Λογισμικού, ως μοντέλο για την εκτίμηση της αλιευτικής προσπάθειας, το κόστος και το χρονοδιάγραμμα για τα έργα λογισμικού. Επέσυρε την προσοχή σε μια μελέτη 63 έργων σε TRW Aerospace, όπου ο Barry Boehm ήταν διευθυντής της έρευνας και της Τεχνολογίας λογισμικού το Η μελέτη εξέτασε τα προγράμματα που κυμαίνονται σε μέγεθος από έως γραμμές κώδικα, και οι γλώσσες προγραμματισμού που κυμαίνονται από τη συναρμολόγηση σε PL/ I. Τα έργα αυτά βασίζονται στο μοντέλο καταρράκτη ανάπτυξης λογισμικού, όπου ήταν η κυρίαρχη διαδικασία ανάπτυξης λογισμικού το Οι αναφορές σε αυτό το μοντέλο συνήθως αποκαλούνται COCOMO 81. Το 1987 παρουσιάζονται τα Ada COCOMO και το Incremental (επαυξητικό) COCOMO (proceedings, Third COCOMO Users Group Meeting, Software Engineering Insitute). Το γίνεται βελτιστοποίηση του μοντέλου Ada COCOMO. Το 1997 αναπτύχθηκε το COCOMO II και τελικά δημοσιεύθηκε το 2000 στο βιβλίο Λογισμικό Κοστολόγησης. Το COCOMO II είναι ο διάδοχος του COCOMO 81 και είναι πιο κατάλληλο για την εκτίμηση των σύγχρονων έργων ανάπτυξης λογισμικού. 3.2 ΟΡΙΣΜΟΣ ΤΟΥ COCOMO Το μοντέλο εκτίμησης κόστους COCOMO χρησιμοποιείται από πολλούς διαχειριστές έργων λογισμικού και στηρίζεται στην μελέτη εκατοντάδων έργων πληροφορικής. Συγκριτικά με άλλα μοντέλα εκτίμησης κόστους το COCOMO είναι ένα ανοικτό μοντέλο. Κατά συνέπεια: Α) Όλες οι σχέσεις και οι αλγόριθμοι του είναι διαθέσιμοι. Β) Όλες οι διεπαφές είναι δημοσιευμένες, καλά προσδιορισμένες και παραμετροποιημένες. Το παρακάτω διάγραμμα παρουσιάζει μια υψηλού επιπέδου περιγραφή του COCOMO. 32

34 Software product size estimation Software product, process, platform and personnel attributes Software reuse, maintenance and increment parameters COCOMO Software development, maintenance cost and schedule estimates Cost, schedule distribution by phase, activity increment Software organization s project data COCOMO recalibrated to organization s data. Διάγραμμα 7: COCOMO Black Box. Ο βασικότερος υπολογισμός του μοντέλου του COCOMO είναι η χρήση της Συνάρτησης Προσπάθειας (Effort Equation) για την εκτίμηση του αριθμού των Ανθρωπομηνών που απαιτούνται για να αναπτυχθεί ένα έργο. Ο Boehm στηριγμένος στην ανάλυση 63 έργων λογισμικού ανέπτυξε ένα εύκολα κατανοητό μοντέλο το οποίο εκτιμά την προσπάθεια και την διάρκεια ενός έργου βασισμένου α) σε εισόδους σχετικές με το μέγεθος των συστημάτων που θα δημιουργηθούν και β) σε έναν αριθμό συντελεστών κόστους (Cost drivers) που πιστεύει ότι επηρεάζουν την παραγωγικότητα [2, 5]. 3.3 ΕΚΤΙΜΗΣΗ ΚΑΤΑ BOEHM Ο Boehm στο βιβλίο του Software Engineering Economics παρατηρεί ότι η καμπύλη Rayleigh είναι ένας λογικά ακριβής εκτιμητής των απαιτήσεων σε προσωπικό για τον κύκλο ανάπτυξης από την αρχιτεκτονική σχεδίαση μέχρι την κωδικοποίηση και τον έλεγχο του συστήματος εάν χρησιμοποιηθεί το διάστημα μεταξύ 0.3td και 1.7td [5]. Η καμπύλη Rayleigh έχει τότε την μορφή: FSP = PM * Q * R Εξίσωση 7: Εξίσωση καμπύλης Rayleigh 33

35 Όπου: FSP = Full Time Software Personnel. Q ένας συντελεστής που ισούται με: Όπου: S ένας συντελεστής που ισούται με: S= 0.15TDEV+0.7t T ένας συντελεστής που ισούται με: t= 0.25TDEV R ένας συντελεστής που ισούται με: Q= S / t -(M / t) R= e Όπου Μ είναι ένας συντελεστής που ισούτε με : Μ = S Και TDEV είναι ο εκτιμούμενος χρόνος ανάπτυξης. PM είναι ο εκτιμώμενος αριθμός μηνών προγραμματιστικής εργασίας που απαιτείται για την ανάπτυξη ενός προϊόντος (χωρίς τον σχεδιασμό και την ανάλυση). Ο ανθρωπομήνας είναι το ποσό του χρόνου που ένα άτομο ξοδεύει εργαζόμενο στην ανάπτυξη ενός έργου λογισμικού για ένα μήνα. Αυτός ο αριθμός δεν συμπεριλαμβάνει αργίες, εορτές και διακοπές. Ο αριθμός των ανθρωπομηνών είναι διαφορετικός από τον χρόνο που χρειάζεται το έργο για να ολοκληρωθεί. Αυτό αποκαλείται χρονοδιάγραμμα ανάπτυξης. Για παράδειγμα ένα έργο μπορεί να εκτιμάται ότι απαιτεί 50 Ανθρωπομήνες προσπάθειας αλλά να έχει και ένα χρονοδιάγραμμα 11 μηνών. Με δεδομένους αυτούς τους δύο παράγοντες, ο αριθμός του προσωπικού πλήρους απασχόλησης Full Time Software (ESP) που χρειάζεται σε οποιαδήποτε χρονική στιγμή t, όπου t είναι στο διάστημα από 0,3td ως 1,7td, μπορεί να υπολογιστεί. Σημειώνεται ότι το td εξακολουθεί να είναι η στιγμή της μέγιστης απαίτησης σε προσωπικό, αλλά δεν ερμηνεύεται πια σαν ο χρόνος ανάπτυξης που πέρασε. Μια γραφική παράσταση του απαιτούμενου προσωπικού πλήρους απασχόλησης ως συνάρτησης του χρόνου για ένα έργο 32 KDSI (Delivered Source Ιnstructions πηγαίες γραμμές κώδικα σε χιλιάδες), 91 PM, 14 μηνών φαίνεται στο διάγραμμα 8. 34

36 Φάση σχεδιασμού Φάση ανάπτυξης Έλεγχος συστήματος FSP Καμπύλη Rayleigh Μεθοδολογία COCOMO t i months FSP = PM (0.15 * TDEV + 0.7t/0.25 * TDEV 2 ) * e -(M/t) Διάγραμμα 8: Καμπύλη Rayleigh κατά Boehm Ο Boehm παρουσιάζει πίνακες που καθορίζουν την κατανομή της προσπάθειας και του χρονοδιαγράμματος σε ένα έργο λογισμικού. Όπως για παράδειγμα ένα έργο μεγέθους 32 KDSI και ένα έργο 128 KDSI έχουν την κατανομή προσπάθειας που παρουσιάζεται στον παρακάτω πίνακα 2. Προσπάθεια Χρονοπρογραμματισμός Δραστηριότητα 32 KDSI 128 KDSI 32 KDSI 128 KDSI Απαιτήσεις 6% 6% 12% 13% Αρχιτεκτονική 16% 16% 19% 19% σχεδίαση Λεπτομερής 24% 23% σχεδίαση Κωδικοποίηση 38% 36% 55% 51% Έλεγχος 22% 25% 26% 30% Πίνακας 2: Κατανομή προσπάθειας χρονοπρογραμματισμού. 35

37 Ο συνολικός αριθμός μηνών προγραμματιστή (PM) και ο συνολικός χρόνος ανάπτυξης μπορούν να χρησιμοποιηθούν για να γίνει μία εκτίμηση του πραγματικού αριθμού μηνών προγραμματιστή και του χρόνου που έχει προέλθει για κάθε δραστηριότητα. Μια εκτίμηση του αριθμού του προσωπικού πλήρους απασχόλησης που απαιτείται σε κάθε φάση της ανάπτυξης ενός έργου λογισμικού μπορεί να γίνει διαιρώντας τον αριθμό των ανθρωπομηνών του προγραμματιστή με το χρόνο που έχει παρέλθει. Ο πίνακας 3 δείχνει την κατανομή της προσπάθειας, χρονοδιαγράμματος και απαιτούμενου προσωπικού για ένα έργο 32 KDSI, 91PM, 14 μηνών και για ένα 128 KDSI, 292PM, 24 μηνών. Προσπάθεια Χρονοπρογραμματισμός Προσωπικό Δραστηριότητα 32 KDSI 128 KDSI 32 KDSI 128 KDSI 32 KDSI 128 KDSI Απαιτήσεις 5 PM 24 PM 1.2 MO 3.1 MO 2.9 FSP 8 FSP Αρχιτεκτονική 15 PM 63 PM 2.2 MO 4.6 MO 5.6 FSP 14 FSP σχεδίαση Λεπτομερής 22 PM 90 PM σχεδίαση Κωδικοποίηση 34 PM 141 PM 7.7 MO 12.2 MO 7.3 FSP 19 FSP Έλεγχος 20 PM 90 PM 3.6 MO 7.2 MO 5.6 FSP 14 FSP Πίνακας 3: Κατανομή προσπάθειας, χρονοπρογραμματισμού και προσωπικού. Όπως μπορεί να παρατηρηθεί, ο έλεγχος του συστήματος παίρνει αναλογικά περισσότερο χρόνο και προσπάθεια στο μεγαλύτερο έργο και η παραγωγικότητα του προγραμματιστή στο έργο 128 KDSI (μετρημένη σε KDSI/PM) πέφτει στα 93% της παραγωγικότητας του έργου των 32 KDSI. Το COCOMO διακρίνεται σε τρία μοντέλα: 1) το βασικό μοντέλο, 2) το ενδιάμεσο μοντέλο (Intermediate model) και 3) το λεπτομερειακό μοντέλο (detailed model). 36

38 3.3.1.ΒΑΣΙΚΟ ΜΟΝΤΕΛΟ COCOMO Η βασική εξίσωση στο μοντέλο COCOMO είναι η εξίσωση υπολογισμού απαιτούμενης ονομαστικής προσπάθειας (Effort Equation) που εκτιμά τον αριθμό των ανθρωπομηνών που απαιτείται για να αναπτυχθεί ένα έργο. Τα υπόλοιπα αποτελέσματα COCOMO όπως εκτιμήσεις των απαιτήσεων των εργαζομένων και χρονοπρογραμματισμός προκύπτουν από την κάτωθι εξίσωση: ΜΜ Nom = c (KSDI) k Εξίσωση 8: Υπολογισμός Ανθρωποπροσπάθειας Όπου: ΜΜ NOM είναι η ονομαστική προσπάθεια σε ανθρωπομήνες που απαιτείται για την εκτέλεση του έργου (π.χ. ένας ανθρωπομήνας = 152 εργάσιμες ώρες) C είναι μία σταθερά. KDSI είναι το μέγεθος χιλιάδες παραδιδόμενες γραμμές κώδικα (delivered source instructions DSI). K είναι μία σταθερά. O Boehm ορίζει τις παραδιδόμενες γραμμές κώδικα DSI σαν τον κώδικα της εφαρμογής που παραδίδεται στον πελάτη από το προσωπικό του έργου σαν μέρος του τελικού προϊόντος. Δεν περιλαμβάνονται τα σχόλια καθώς και το βοηθητικό λογισμικό (compilers), όμως μπορεί να περιλαμβάνονται εντολές σε γλώσσα ελέγχου εργασιών (Job control language). Το Βασικό μοντέλο COCOMO είναι κατάλληλο για πρώιμες, ακατέργαστες εκτιμήσεις της προσπάθειας, της διάρκειας και του κόστους του έργου ΕΝΔΙΑΜΕΣΟ ΜΟΝΤΕΛΟ COCOMΟ Ο Boehm σε μία προσπάθεια να βελτιώσει την ακρίβεια του μοντέλου, επανασχεδίασε την συνάρτηση εκτίμησης προσπάθειας (Effort Equation) και προσέθεσε τα αποτελέσματα 15 συντελεστών κόστους (cost drivers) οι οποίοι είναι χαρακτηριστικά του τελικού προϊόντος όπως η χρήση του υπολογιστή, η στελέχωση του προσωπικού και το περιβάλλον εργασίας. Ο Boehm θεωρεί ότι αυτοί οι δεκαπέντε παράγοντες επηρεάζουν την παραγωγικότητα του έργου και ονόμασε το μοντέλο αυτό Ενδιάμεσο. Σε κάθε παράγοντα κόστους αντιστοιχεί και μία παράμετρος, που λέγεται <<πολλαπλασιαστής προσπάθειας>> (effort multiplier). Στη συνέχεια θα 37

39 συμβολίσουμε τους πολλαπλασιαστές αυτούς ως q1, q2,,q15. Η σημασία των παραγόντων κόστους καθώς και η μνημονική ονομασία τους δίνεται στο πίνακας 4. α / α Ονομασία παράγοντα κόστους Περιγραφή Συσχέτιση 1 RELY Απαιτούμενη αξιοπιστία λογισμικού Παραδοτέο λογισμικό 2 DATA Μέγεθος βάσης δεδομένων Παραδοτέο λογισμικό 3 CPLX Πολυπλοκότητα λογισμικού Παραδοτέο λογισμικό 4 TIME Περιορισμός στο χρόνο εκτέλεσης Υπολογιστικό σύστημα 5 STOR Περιορισμός στη κύρια μνήμη Υπολογιστικό σύστημα 6 VIRT Διαθεσιμότητα βασικού λογισμικού Υπολογιστικό σύστημα και hardware (Λειτουργικό σύστημα, Βάση δεδομένων, επεξεργαστική ισχύς) 7 TURN Διάρκεια κύκλου εξυπηρέτησης Υπολογιστικό σύστημα 8 ACAP Ικανότητα αναλυτών Προσωπικό 9 AEXP Εμπειρία αναλυτών σε εφαρμογές Προσωπικό 10 PCAP Ικανότητα προγραμματιστών Προσωπικό 11 VEXP Εμπειρία με το σύστημα (λογισμικό Προσωπικό και hardware) 12 LEXP Εμπειρία με τη γλώσσα Έργο προγραμματισμού 13 MODP Χρησιμοποίηση μοντέρνων Έργο πρακτικών προγραμματισμού 14 TOOL Χρησιμοποίηση εργαλείων Έργο προγραμματισμού 15 SCED Απαιτούμενο χρονοδιάγραμμα ανάπτυξης Έργο Πίνακας 4: Παράγοντες κόστους κατά COCOMO. 38

40 Εκτός από την εξίσωση υπολογισμού απαιτούμενης ονομαστικής προσπάθειας για την εκτίμηση του κόστους χρησιμοποιούνται και οι ακόλουθες εξισώσεις: o Η εξίσωση η οποία λέγεται εξίσωση υπολογισμού παράγοντα προσαρμογής προσπάθειας και έχει τη μορφή: Q=q1*q2*q3* *q15 Εξίσωση 9: υπολογισμός παράγοντα προσαρμογής προσπάθειας. Όπου : q i είναι πολλαπλασιαστής προσπάθειας. q είναι ο παράγοντας προσαρμογής προσπάθειας. o Η εξίσωση που λέγεται <<εξίσωση υπολογισμού προσπάθειας ανάπτυξης>>, που έχει την μορφή: MM DEV = q*mm NOM Εξίσωση 10: υπολογισμός προσπάθειας ανάπτυξης Όπου: q είναι ο παράγοντας προσπάθειας. MM NOM είναι η ονομαστική προσπάθεια για την εκτέλεση του έργου σε ανθρωπομήνες. MM DEV είναι η προσπάθεια σε ανθρωπομήνες που απαιτείται για την εκτέλεση του έργου. o Η εξίσωση που ονομάζεται εξίσωση υπολογισμού του κόστους και έχει την μορφή: C t = p*mm DEV Εξίσωση 11: υπολογισμός του κόστους Όπου: p είναι η αξία σε χρήμα ενός ανθρωπομήνα. MM DEV είναι η προσπάθεια σε ανθρωπομήνες που απαιτείται για την εκτέλεση ενός έργου. C t είναι το κόστος σε χρήμα που απαιτείται για την εκτέλεση του έργου. o Η εξίσωση υπολογισμού διάρκειας του έργου που έχει την μορφή: T DEV = R*(MM DEV ) m Εξίσωση 12: υπολογισμός διάρκειας έργου Όπου: R είναι μία σταθερά και καθορίζεται με βάση την έκδοση του μοντέλου COCOMO. 39

41 MM DEV είναι η προσπάθεια σε ανθρωπομήνες που απαιτείται για την εκτέλεση του έργου m είναι μία παράμετρος. T DEV είναι η χρονική διάρκεια σε ανθρωπομήνες του έργου. Τα δεδομένα εισόδου σε αυτό το μοντέλο είναι το μέγεθος ενός έργου λογισμικού μετρημένο σε χιλιάδες εντολών πηγαίου κώδικα (KDSI), οι παράγοντες κόστους και η τιμή του ανθρωπομήνα εργασίας (p). Είναι φανερό ότι για να μπορεί να χρησιμοποιηθεί αυτό το μοντέλο στην πράξη, για την εκτίμηση του κόστους έργων λογισμικού, πρέπει να βαθμονομηθεί. Το αποτέλεσμα της βαθμονόμησης (calibration) θα είναι ένας τρόπος εκχώρησης τιμών στις παραμέτρους C, K, R, m, q1,q2,.,q15 με βάση το κάθε έργο λογισμικού. Χωρίς αυτές τις τιμές δεν μπορεί να εφαρμοστεί το μοντέλο. Ο Boehm βαθμονόμησε το μοντέλο του χρησιμοποιώντας δεδομένα από 63 διαφορετικά έργα λογισμικού [5, 9]. Σύμφωνα με τα αποτελέσματα της βαθμονόμησης αυτής υπολογίζονται τιμές για τις παραμέτρους C, K, R, m από τον πίνακα 5. Κατηγορία Ονομαστική Προσπάθεια Διάρκεια Ανάπτυξης Οργανική ΜΜ ΝΟΜ =3.2*(KDSI) 1.05 T DEV =2.5*(MM DEV ) 0.38 Ημιαποσπασμένη MM NOM =3.0*(KDSI) 1.12 T DEV =2.5*(MM DEV ) 0.35 Ενσωματωμένη ΜΜ ΝΟΜ =2.8*(KDSI) 1.20 T DEV =2.5*(MM DEV ) 0.32 Πίνακας 5: Εξισώσεις ονομαστικής προσπάθειας και διάρκειας ανάπτυξης. Ακολουθεί η κατάταξη ενός έργου λογισμικού σε μία από τις κατηγορίες: Οργανική (organic) Στην οργανική κατηγορία μικρές σχετικά ομάδες ανάπτυξης λογισμικού αναπτύσσουν το λογισμικό τους σε ένα φιλικό, γνωστό περιβάλλον εντός της επιχείρησης. Οι περισσότεροι εργαζόμενοι που σχετίζονται με το έργο έχουν εκτεταμένη εργασιακή εμπειρία σε παρόμοια συστήματα εντός του οργανισμού και έχουν μία εκτενή αντίληψη για το πώς το υπό ανάπτυξη σύστημα θα συμβάλει στους στόχους του οργανισμού. Σύμφωνα με την εκτίμηση του Boehm πολύ λίγα έργα αυτής της κατηγορίας έχουν ολοκληρώσει προϊόντα με περισσότερες από 50 KDSI [2, 5]. Ημιαποσπασμένη (semidetached) Η ημιαποσπασμένη κατηγορία ανάπτυξης λογισμικού παρουσιάζει ένα ενδιάμεσο στάδιο ανάμεσα στην οργανική και την Ενσωματωμένη. Λέγοντας ενδιάμεσο 40

42 θεωρούμε ότι είναι α) ένα ενδιάμεσο επίπεδο στον τρόπο ανάπτυξης του έργου είτε β) ένα μείγμα οργανικού και ενσωματωμένου μοντέλου ανάπτυξης. Το μέγεθος ενός προϊόντος ημιαποσπαμένης κατηγορίας γενικά επεκτείνεται έως και τα 300 KDSI. Ενσωματωμένη (embedded) Ο βασικός διαχωριστικός παράγοντας των ενσωματωμένης κατηγορίας έργων λογισμικού είναι η ανάγκη να λειτουργούν μέσα σε στενούς περιορισμούς. Το προϊόν λογισμικού πρέπει να λειτουργήσει μέσα σε ένα ισχυρά πολύπλοκο συνδυασμό hardware, software, περιορισμών / κανόνων και λειτουργικών διαδικασιών. Τέτοια συστήματα είναι: ηλεκτρονικό σύστημα μεταφοράς χρημάτων ή ένα σύστημα ελέγχου κυκλοφορίας αεροσκαφών. Χαρακτηριστικά Κατηγορία Οργανική Ημιαποσπασμένη Ενσωματωμένη Κατανόηση από όλους τους Λεπτομερής Λεπτομερής Γενική εμπλεκόμενους των αντικειμενικών σκοπών του έργου. Εμπειρία που να αποκτήθηκε σε Εκτενής Σημαντική Μέτρια σχετικά έργα λογισμικού. Ανάγκη για συμμόρφωση του Βασική Σημαντική Πλήρης λογισμικού με προκατασκευασμένες απαιτήσεις. Ανάγκη για διαμόρφωση του Βασική Σημαντική Πλήρης λογισμικού με προκατασκευασμένη εξωτερική διαπροσωπία (User Interface). Ταυτόχρονη ανάπτυξη νέων Μερική Μέτρια Πλήρης λειτουργικών διαδικασιών και υλικού. Ανάγκη για νεωτεριστικές Ελάχιστη Μερική Σημαντική αρχιτεκτονικές υπολογιστών, νέους αλγόριθμους. Δώρο από γρήγορη αποπεράτωση. Χαμηλό Μέτριο Υψηλό 41

43 Μέγεθος έργου. <50KDSI <300KDSI Όλα Παραδείγματα Μαζική ελάττωση δεδομένων, Επιστημονικά μοντέλα, Συμβατικά λειτουργικά, Συστήματα, Μεταγλωττιστές, Συστήματα ελέγχου παραγωγής. Απλά συστήματα δοσοληψιών, Καινούργια λειτουργικά συστήματα, Συστήματα βάσεων δεδομένων. Πίνακας 6: Κατηγορίες έργων λογισμικού κατά COCOMO. Μεγάλα σύνθετα συστήματα δοσοληψιών, Συστήματα ελέγχου. Για τις παραμέτρους q1,q2,,q15 ακολουθεί ο πίνακας 7. Κατάταξη Παράγοντας Κόστους Χαμηλότερη Χαμηλή Ονομαστική Υψηλή Υψηλότερη Υψηλότατη RELY DATA CPLX TIME STOR VIRT TURN ACAP AEXP PCAP VEXP

44 LEXP MODP TOOL SCED Πίνακας 7: Πολλαπλασιαστές Προσπάθειας. Όπου η κατάταξη όλων των παραγόντων κόστους λογισμικού στην κλίμακα χαμηλότερη, χαμηλή, ονομαστική, υψηλή, υψηλότερη, υψηλοτάτη γίνεται σύμφωνα με τον πίνακα 8. Κατάταξη Παράγοντες Χαμηλότερη Χαμηλή Ονομαστική Υψηλή Υψηλότερη Υψηλότατη κόστους RELY Αποτέλεσμα: μικρή ενόχληση. Μικρές, εύκολα ανακτήσιμες Μέτριες, ανακτήσιμες απώλειες. Μεγάλες οικονομικές απώλειες. Κίνδυνος για ανθρώπινες ζωές. απώλειες. DATA L<10 10<L< <L<10 00 L>1000 CPLX Πίνακας 9: Κατάταξη του παράγοντα κόστους Πολυπλοκότητα ΤΙΜΕ <50% ΧΔΧΕ 70% ΧΔΧΕ 85% ΧΔΧΕ 95% ΧΔΧΕ STOR <50% ΧΔΜ 70%ΧΔΜ 85% ΧΔΜ 95% ΧΔΜ VIRT Σημαντική αλλαγή κάθε 12 μήνες. Μηδαμινή 1 φορά το μήνα. Σημαντική αλλαγή κάθε 6 μήνες. Μηδαμινή 2 εβδομάδες. Σημαντική αλλαγή κάθε 2 μήνες. Μηδαμινή 1 εβδομάδα. Σημαντική αλλαγή κάθε 2 μήνες. Μηδαμινή 2 ημέρες. 43

45 TURN Διαλογική ΜΧΚΕ<4 4 έως 8 >12 ώρες ώρες ώρες ACAP 15 ET 35ET 55ET 75ET 90ET AEXP <4 μήνες 1 χρόνο 3 χρόνια 6 χρόνια 12 χρόνια PCAP 15 ET 35 ET 55 ET 75 ET 90 ET VEXP <1 μήνα 4 μήνες 1 χρόνο 3 χρόνια LEXP <1 μήνα 4 μήνες 1 χρόνο 3 χρόνια MODP Καμία χρήση. Αρχή χρήσης. Μερική Χρήση. Γενική Χρήση. Αποτελεσμα -τική χρήση. TOOL Βασικά εργαλεία υπολογιστή. Βασική εργαλεία μίνι υπολογιστή. Βασικά εργαλεία μεσαίου και μεγάλου υπολογιστή. Ισχυρά εργαλεία προγ/σμού και ελέγχου ορθότητας Επιπρόσθετα εργαλεία για προδιαγραφές απαιτήσεων και σχεδίου.. SCED 75% 85% 100% 130% 160% L= MBbytes/Prog. DSI, ΧΔΧΕ = Χρησιμοποίηση Διαθέσιμου Χρόνου Εκτέλεσης, ΧΔΜ= Χρησιμοποίηση Διαθέσιμης Μνήμης, ΜΧΚΕ = Μέση Διάρκεια Κύκλου Εξυπήρεσης, ΕΤ = Εκατοτόμος. Πίνακας 8: Κατάταξη παραγόντων κόστους κατά COCOMO Η κατάταξη του παράγοντα κόστους πολυπλοκότητα (CPLX) γίνεται σύμφωνα με τον πίνακα 9. Κατάτα Λειτουργίες Ελέγχου Λειτουργίες Λειτουργίες Λειτουργίες -ξη Υπολογισμού εξαρτημένες από Διαχείρισης συσκευές Δεδομένων Χαμηλό Ευθύς κώδικας με Αποτίμηση Απλές εντολές Απλά arrays -τερη λίγους φωλιασμένους απλών Εισόδου/ Εξόδου στην κύρια τελεστές του Δομημέ- εκφράσεων. με απλό format. μνήμη. νου Προγραμματισμού. 44

46 Χαμηλή Ομαλό φώλιασμα τελεστών ΔΠ κυρίως με απλά κατηγορήματα. Αποτίμηση μέτριου επιπέδου εκφράσεων. Δεν απαιτείται γνώση των χαρακτηριστικών του ιδιαίτερου επεξεργαστή ή συσκευής Εισόδου/ Εξόδου. Ονομαστική Κυρίως απλό Χρησιμοποίηση Η επεξεργασία φώλιασμα. Ελάχιστος πρότυπων Εισόδου/ Εξόδου έλεγχος στα δομικά μαθηματικών περιλαμβάνει επιλογή στοιχεία. και στατιστικών συσκευής, ρουτινών. έλεγχος κατάστασης και λαθών. Υψηλή Τελεστές Δομημένου Βασική Λειτουργίες στο Προγραμματισμού Αριθμητική φυσικό επίπεδο ΕΕ. πολύ φωλιασμένοι με Ανάλυση. πολλά σύνθετα κατηγορήματα. Υψηλότερη Επαναλαμβανόμενος Δύσκολες αλλά Εξυπηρέτηση γρα- και αναδρομικός δομημένες μμών επικοινωνίας. κώδικας. λειτουργίες Αριθμητικής Ανάλυσης. Υψηλότατσμός Χρονοπρογραμματι- Δύσκολες και Κώδικας πολλών πόρων με αδόμητες εξαρτημένος από προτεραιότητες που λειτουργίες τις δυνατότητες του αλλάζουν δυναμικά. Αριθμητικής υπολογιστή και από Έλεγχος σε επίπεδο Ανάλυσης. το χρόνο. μικροκώδικα. Πίνακα 9: Κατάταξη του παράγοντα κόστους Πολυπλοκότητα. Απλά Αρχεία χωρίς αλλαγές στις δομές δεδομένων. Πολλαπλά αρχεία και ένα αρχείο εξόδου. Πολύπλοκες Λειτουργίες σε επίπεδο εγγραφής. Παραμετροποιημένα αρχεία. Πολύ συζευγμένες δυναμικές σχεσιακές δομές. Για τα έργα λογισμικού που γίνονται σε εργασιακό περιβάλλον και περιβάλλον αγοράς διαφορετικό από εκείνα στα οποία στηρίχθηκε η βαθμονόμηση αυτή, τα 45

47 αποτελέσματα της δεν ισχύουν και μία νέα βαθμονόμηση πρέπει να γίνει από την αρχή ΛΕΠΤΟΜΕΡΕΙΑΚΟ ΜΟΝΤΕΛΟ COCOMO To λεπτομερειακό μοντέλο διαφέρει από το Ενδιάμεσο μοντέλο σε ένα βασικό χαρακτηριστικό: το λεπτομερειακό μοντέλο χρησιμοποιεί διαφορετικούς πολλαπλασιαστές προσπάθειας για κάθε φάση του έργου. Οι εξαρτώμενοι από την φάση πολλαπλασιαστές προσπάθειας παράγουν καλύτερες εκτιμήσεις από ότι το ενδιάμεσο μοντέλο. Οι φάσεις του Λεπτομερειακού COCOMO είναι: α) απαιτήσεις του χρήστη, β)σχεδιασμός του έργου, γ)λεπτομερειακός σχεδιασμός, δ)ανάπτυξη του έργου και έλεγχος εγκυρότητας, ε) ενοποίηση - τελικός έλεγχος και στ) συντήρηση. Οι φάσεις από τον σχεδιασμό του έργου μέχρι την ενοποίηση και τον τελικό έλεγχο αποκαλούνται και φάσεις ανάπτυξης του έργου. Οι εκτιμήσεις για τις φάσεις των απαιτήσεων χρήστη και της συντήρησης πραγματοποιούνται με διαφορετικό τρόπο από ότι για τις τέσσερις φάσεις ανάπτυξης του έργου. 3.4 COCOMO II Ο Boehm βελτιώνοντας την έκδοση του COCOMO παρουσίασε μία δεύτερη έκδοση του μοντέλου του με την οποία λύνει τα ήδη υπάρχοντα προβλήματα. Ο Boehm ενσωμάτωσε στο ήδη υπάρχον και προαναφερθέν COCOMO I δυνατότητες που παρέχονται από τα Function Points [6]. Οι πρωταρχικοί στόχοι του COCOMO II είναι: o Να καθιερώσει ένα μοντέλο εκτίμησης κόστους και χρονοπρογραμματισμού. o Να αναπτύξει μία βάση δεδομένων εκτίμησης κόστους και ένα εργαλείο που θα υποστηρίζει δυνατότητες για συνεχή βελτίωση του μοντέλου. 46

48 o Να παρέχει ένα πλαίσιο ποσοτικής ανάλυσης καθώς και ένα σύνολο εργαλείων και τεχνικών για την εκτίμηση του κόστους λογισμικού. Ουσιαστικά προτείνει την εισαγωγή του COCOMO II στις διάφορες φάσεις του κύκλου ζωής του λογισμικού όπως φαίνεται και στο διάγραμμα 9. COCOMO I I Estimation Inception Readiness Review Life cycle objectives Life cycle architecture Initial operational capability Product Release Review MBASE Inception Elaboration Construction Transition / waterfall Plans and requirements Preliminary design Detailed design Code and unit Integratio n and test Life cycle concept review Software requirements review Product design review Critical design review Unit test accept Software acceptance review Early Design Model Post - Architecture Model Διάγραμμα 9: Προσαρμογή COCOMO II στα μοντέλα ανάπτυξης. To COCOMO II αποτελείται από τρία ξεχωριστά στάδια. I. Το πρώτο στάδιο περιλαμβάνει την εκτίμηση της προσπάθειας της εφαρμογής που πρόκειται να αναπτυχθεί. Το μοντέλο Application Compositition αφορά τη προσπάθεια που καταβάλλεται για την κατασκευή του ενός πρωτοτύπου της εφαρμογής προκειμένου να αναδειχθούν και αναλυθούν τα πιθανά υψηλής επικινδυνότητας και ρίσκου θέματα όπως είναι το περιβάλλον ανάπτυξης, 47

49 θέματα απόδοσης και ωριμότητα των διαδικασιών. Το συγκεκριμένο μοντέλο χρησιμοποιεί object points που αφορούν μετρήσεις των οθονών, των αναφορών και των modules γλωσσών τρίτης γενιάς. Τα object points στηρίζονται στη χρήση του rapid-composition integrated Computer Aided Software Environment (ICASE) που παρέχει builders για διεπαφή χρήστη, εργαλεία ανάπτυξης λογισμικού καθώς και μεγάλα και σύνθετα components εφαρμογών. II. Το δεύτερο στάδιο περιλαμβάνει την εκτίμηση του μοντέλου Early Design όταν λίγα είναι γνωστά για τους συντελεστές κόστους του έργου. Το μοντέλο Early Design αφορά την αναζήτηση των εναλλακτικών αρχιτεκτονικών λογισμικού και συστημάτων καθώς και εννοιών λειτουργικότητας. Σε αυτό το στάδιο δεν είναι γνωστή αρκετή πληροφορία ώστε να υποστηριχθεί μια λεπτομερής εκτίμηση του κόστους λογισμικού. Το συγκεκριμένο μοντέλο χρησιμοποιεί τα function points και ένα μικρό αριθμό συντελεστών κόστους για τις εκτιμήσεις. III. Το τρίτο στάδιο περιλαμβάνει το μοντέλο του Post Architecture. Στο στάδιο αυτό έχουν αναπτυχθεί τύποι οι οποίοι υπολογίζουν την προσπάθεια, τον χρονοπρογραμματισμό και το κόστος που απαιτείται για την ανάπτυξη ενός προϊόντος λογισμικού. Επίσης περιλαμβάνεται μία κατάτμηση της προσπάθειας και του χρονοπρογραμματισμού στις διάφορες φάσεις του κύκλου ζωής του έργου και προσαρμόζεται κατάλληλα σε έργα λογισμικού που αναπτύσσονται με βάση το μοντέλο του καταρράκτη (waterfall model). Το post architecture μοντέλο αναφέρεται στην πραγματική ανάπτυξη και συντήρηση του προϊόντος λογισμικού. Το μοντέλο αυτό χρησιμοποιεί πηγαίες γραμμές κώδικα και λειτουργικά σημεία για τη μέτρηση του μεγέθους της εφαρμογής καθώς και συντελεστές για την επαναχρησιμοποίηση κώδικα και την τμηματοποίηση του λογισμικού ΣΥΝΑΡΤΗΣΗ ΕΚΤΙΜΗΣΗΣ ΠΡΟΣΠΑΘΕΙΑΣ Η συνάρτηση εκτίμησης προσπάθειας για το COCOMO II παρουσιάζεται παρακάτω. 48

50 Εξίσωση 13: Συνάρτηση εκτίμησης προσπάθειας. Όπου: Σύμβολο Περιγραφή A Σταθερά με τιμή 2.45 για την συγκεκριμένη έκδοση του μοντέλου. ΑΑ Εκτίμηση και εξομοίωση (assimilation). ADAPT Ποσοστό των components που υιοθετήθηκαν (παριστά την προσπάθεια που απαιτείται για την κατανόηση του λογισμικού). AT Ποσοστό των components τα οποία μεταφράσθηκαν και ενσωματώθηκαν. ATPROD Διαδικασία μετάφρασης. BRAK Ποσοστό κώδικα ο οποίος απορρίφθηκε λόγω μεταβολής των απαιτήσεων. CM Ποσοστό κώδικα που τροποποιήθηκε. DM Ποσοστό σχεδίασης που τροποποιήθηκε. ΕΜ Πολλαπλασιαστές προσπάθειας (RELY, DATA, CPLX, RUSE, DOCU, TIME, STOR, PVOL, ACAP, PCAP, PCON, AEXP, PEXP, LTEX, TOOL, SITE ). IM Ποσοστό τροποποίησης ολοκλήρωσης και ελέγχου. KASLOC Μέγεθος των component που υιοθετούνται εκφρασμένο σε χιλιάδες γραμμές κώδικα. 49

51 KNSLOC PM SF SU Μέγεθος των νέων component που δημιουργούνται εκφρασμένα σε χιλιάδες γραμμές νέου κώδικα. Ανθρωπομήνες της εκτιμούμενης προσπάθειας. Συντελεστές κλίμακας: PREC, FLEX, RESL, TEAM, PMAT. Κατανόηση λογισμικού (μηδέν εφόσον DM=0 και CM=0). Πίνακας 10: Επεξήγηση συμβόλων εξίσωσης εκτίμησης προσπάθειας ΣΥΝΑΡΤΗΣΗ ΕΚΤΙΜΗΣΗΣ ΧΡΟΝΟΠΡΟΓΡΑΜΜΑΤΙΣΜΟΥ Καθορισμός του χρόνου ανάπτυξης (TDEV) για μία εκτιμούμενη προσπάθεια, PM, που όμως δεν περιλαμβάνει το αποτέλεσμα του SCED πολλαπλασιαστή προσπάθειας: TDEV =[3.67 * (PM ) ( * (B 1.01)) ]* SCED% 100 where 5 B = Σ SF j j = 1 Εξίσωση 14: Συνάρτηση Εκτίμησης Χρονοπρογραμματισμού. Όπου: σύμβολο PM SF TDEV SCED SCED% περιγραφή Ανθρωπομήνες της εκτιμούμενης προσπάθειας για τα μοντέλα early Design ή Post Architecture. Παράγοντες κλίμακας (Scale Factors): PREC, FLEX, RESL, TEAM, PMAT. Χρόνος ανάπτυξης. Χρονοπρογραμματισμός. Το ποσοστό συμπίεσης ή επέκτασης που θα υπάρξει για τον SCED πολλαπλασιαστή προσπάθειας. Πίνακας 11: Επεξήγηση των συμβόλων της εξίσωσης εκτίμησης χρονοπρογραμματισμού. 50

52 3.4.3 ΣΥΣΧΕΤΙΣΜΟΣ ΤΩΝ ΣΤΑΔΙΩΝ EARLY DESIGN ΚΑΙ POST ARCHITECTURE. Τα στάδια που αντιπροσωπεύουν τα μοντέλα αυτά περιγράφονται στο πίνακα 12. Early Design Μοντέλο Post Architectural Μοντέλο Επαρκής γνώση του έργου. Λεπτομερής ανάλυση του έργου. Προσεγγιστικές εκτιμήσεις κόστους και χρόνου. Ακριβείς εκτιμήσεις κόστους και χρόνου. Επαρκής γνώση των προδιαγραφών. Καθορισμένες Απαιτήσεις. Επαρκής γνώση της αρχιτεκτονικής. Καθορισμένη Αρχιτεκτονική. Πίνακας 12: Χαρακτηριστικά Σταδίων Ανάπτυξης. Κάθε ένα από τα παρακάτω μοντέλα χρησιμοποιεί την ακόλουθη ισότητα: PM=2.45 * EAF * (size) B Εξίσωση 15: Υπολογισμός Ανθρωποπροσπάθειας κατά COCOMOII. Όπου EAF είναι ο Συντελεστής προσαρμογής Προσπάθειας (Effort Adjustment Factor). Ο EAF είναι το παραγόμενο επτά (7) πολλαπλασιαστών προσπάθειας στο Early Design μοντέλο και δεκαεπτά (17) στο Post Architecture μοντέλο. Οι πολλαπλασιαστές προσπάθειας διαβαθμίζονται στις εξής κατηγορίες: α) πολύ χαμηλό, β) χαμηλό, γ) μέσο, δ) υψηλό, ε) πολύ υψηλό και στ) εξαιρετικά υψηλό. Αριθμητικοί σταθμιστές ανατίθενται στους πολλαπλασιαστές προσπάθειας βασισμένοι στην επίδραση που έχουν οι πολλαπλασιαστές στην προσπάθεια ανάπτυξης του έργου ΠΑΡΑΓΟΝΤΕΣ ΚΛΙΜΑΚΩΣΗΣ Η εξίσωση 14: συνάρτηση εκτίμησης χρονοπρογραμματισμού καθορίζει τον συντελεστή Β που λαμβάνει τιμές στο διάστημα ( ) που δίνεται από τον τύπο: Β= *Σw i Εξίσωση 16: Υπολογισμός συντελεστή Β. Το Σw i είναι το άθροισμα 5 χαρακτηριστικών στοιχείων τα οποία αποκαλούνται παράγοντες κλιμάκωσης. Κάθε παράγωντας κλιμάκωσης έχει ένα εύρος τιμών που κατηγοριοποιούνται και σταθμίζονται σε ένα διάστημα (0, ) και σε μία 51

53 λεκτική κλιμάκωση από πολύ χαμηλό σε εξαιρετικά υψηλό και παρουσιάζονται στο πίνακα 13. Συντελεστές Συντο- Πολύ Χαμηλό Μέσο Υψηλό Πολύ Εξαιρετικά κλιμάκωσης μογρα- χαμηλό (0.01) (0.02) (0.03) Υψηλό υψηλό (0.05) (Σw i ) φία (0.00) (0.04) Γνώση του PREC Καμία Ελάχι- Σχετική Σχετική Μεγάλη Απόλυτη αντικειμένου γνώση στη γνώ- γνώση οικειό- οικειότητα οικειότητα με του έργου, του ση του του αντι- τητα με με το αντι- το αντικείμε- εργασιακή αντικει- αντικει- κειμένου το αντι- κείμενο. νο. εμπειρία σε μένου. μένου. κείμενο. ανάλογα συστήματα λογισμικού, ανάπτυξη συστημάτων που σχετίζονται με σύγχρονα περιβάλλοντα hardware και λογισμικού, χρήση πρωτοποριακών αρχιτεκτονικών λογισμικού και αλγορίθμων (precedentedness). Προσαρμο- FLEX Αυστη- Περιστα Σχετική Σχετική Ικανή Γενικοί στικότητα ρή -σιακή χαλάρω- προσα- προσαρμο Στόχοι. ανάπτυξης χαλάρω- ση της ρμοστι- στι- 52

54 ση εργασίας. εργασίας. κότητα. κότητα. Σχετική Μέτρια Ικανή Υψηλή (40%) (60%) (75%) (90%) Σχετική Βασικές Ικανοποιητικό Υψηλό δυσκολία σχέσεις επίπεδο στην συνεργα- επίπεδο συνε- συνεργα σίας. συνεργα ργασίας. -σία. -σίας. CMM CMM CMM CMM επίπεδο1 επίπεδο 2 επίπεδο3 επίπεδο4 (Development Flexibility). Αρχιτεκτονική/ RESL Μικρή εκτίμηση (20%) ρίσκου Risk Management Plan στο οποίο να αναγνωρίζονται τα κρίσιμης επικινδυνότη -τας σημεία (Architecture/ Risk Resolution) Συνάφεια TEAM Μεγάλη Ομάδας δυσκολία εμπειρία στην στην λειτουργία συνεργα ως ομά- -σία. δας (Team Cohesion) Ωρίμανση PMAT CMM 1 διαδικασιών (Capability (Process Ma- Maturity) turity Model) επίπεδο 1 Πίνακας 13: παράγοντες κλιμάκωσης του COCOMO II Πλήρης (100%) Εξαιρετικά υψηλό επίπεδο συνεργασίας CMM επίπεδο 5 53

55 ΜΟΝΤΕΛΟ ΩΡΙΜΑΝΣΗΣ ΙΚΑΝΟΤΗΤΑΣ ΔΙΕΡΓΑΣΙΩΝ Το Μοντέλο Ωρίμανσης Ικανότητας Διεργασιών (Capability Maturity Model CMM ή SW CMM) είναι ένα μοντέλο για τη κρίση της ωριμότητας των διαδικασιών ανάπτυξης και χρήσης λογισμικού σε έναν οργανισμό και για τον προσδιορισμό των βασικών πρακτικών που απαιτούνται για να αυξήσουν την ωριμότητα αυτών των διαδικασιών. Το λογισμικό CMM έχει γίνει πρότυπο για την αξιολόγηση και τη βελτίωση των διαδικασιών λογισμικού σε έναν οργανισμό [18]. Το μοντέλο ωρίμανσης ικανοτήτων διεργασιών για το λογισμικό περιγράφει τις αρχές και τις πρακτικές που κρύβονται κάτω από την διαδικασία ωρίμανσης του λογισμικού και προορίζεται να βοηθήσει τους οργανισμούς και τις εταιρείες ανάπτυξης λογισμικού να βελτιώσουν τις διαδικασίες ωρίμανσης λογισμικού από την άποψη ενός εξελικτικού μονοπατιού από τις ad hoc και ενδεχόμενες χαοτικές διαδικασίες που ακολουθούνται για την ωρίμανση ενός έργου, στις πειθαρχημένες διαδικασίες λογισμικού. Η CMM οργανώνεται σε πέντε επίπεδα ωριμότητας: 1) Αρχικό. Η διαδικασία ωρίμανσης του λογισμικού χαρακτηρίζεται ad hoc, και περιστασιακά και χαοτική. Λίγες διαδικασίες καθορίζονται και η επιτυχία εξαρτάται από τη μεμονωμένη προσπάθεια των εμπλεκόμενων ανθρώπων. 2) Επαναλαμβανόμενο. Οι βασικές διαδικασίες διαχείρισης έργου στηρίζονται στην καταγραφή του κόστους, του χρονοπρογραμματισμού και της λειτουργικότητας. Η απαραίτητες διαδικασίες πειθαρχίας είναι σε θέση να επαναλαμβάνονται σε ένα έργο με παρόμοιες εφαρμογές. Πιο συγκεκριμένα οι διαδικασίες εστιάζουν σε ανησυχίες συσχετιζόμενες με την καθιέρωση των βασικών μεθόδων ελέγχου διαχείρισης ενός έργου οι οποίες είναι: α) διαχείριση απαιτήσεων, β) προγραμματισμός και σχεδιασμός του έργου, γ) καταγραφή των διαδικασιών και των παραλείψεων κατά την ανάπτυξη του έργου λογισμικού, δ) διαχείριση υπεργολαβιών έργων λογισμικού, ε) εξασφάλιση ποιότητας λογισμικού και στ) διαχείριση διαμόρφωσης έργων λογισμικού. 3) Καθορισμένο. Η διαδικασία λογισμικού τόσο για τις δραστηριότητες διαχείρισης όσο και για τις δραστηριότητες ανάπτυξης λογισμικού είναι τεκμηριωμένες, τυποποιημένες και ενσωματωμένες σε μία προτυποποιημένη διαδικασία ανάπτυξης λογισμικού για τον οργανισμό. Οι διαδικασίες απευθύνονται τόσο σε θέματα έργων όσο και σε γενικότερα θέματα του οργανισμού, δεδομένου ότι ο οργανισμός καθιερώνει μια υποδομή που θεσμοποιεί τις αποτελεσματικές διαδικασίες ανάπτυξης 54

56 και διαχείρισης λογισμικού σε όλα τα έργα. Τέτοιες είναι α) η εστίαση στην διαδικασία οργάνωσης, β) ο καθορισμός διαδικασίας οργάνωσης, γ) επιμορφωτικό πρόγραμμα, δ) ολοκληρωμένη διαχείριση λογισμικού, ε) εφαρμοσμένη μηχανική προϊόντων λογισμικού, στ)συντονισμός ομάδων και ζ) αναθεωρήσεις. 4) Διοικούμενο. Λεπτομερείς μετρήσεις της διαδικασίας ανάπτυξης λογισμικού και της ποιότητας των προϊόντων που συλλέγονται. Τόσο η διαδικασία ανάπτυξης όσο και τα προϊόντα λογισμικού γίνονται κατανοητά και ελέγχονται. Οι διαδικασίες εστιάζουν στην καθιέρωση μιας ποσοτικής κατανόησης τόσο της διαδικασίας ανάπτυξης λογισμικού όσο και της εργασίας που απαιτείται για να αναπτυχθούν τα προϊόντα λογισμικού. Τέτοιες είναι α) η διαδικασία ποσοτικής διαχείρισης και β) η διαδικασία ποιοτικής διαχείρισης λογισμικού. 5) Βελτιστοποιημένο. Η συνεχής διαδικασία βελτιστοποίησης γίνεται εφικτή από μία ποσοτική ανατροφοδότηση από τις μετρήσεις των διαδικασιών ανάπτυξης λογισμικού σε συγκερασμό με την χρήση καινοτόμων ιδεών και τεχνολογιών. Οι διαδικασίες εδώ καλύπτουν τα ζητήματα που ο οργανισμός και τα έργα πρέπει να αντιμετωπίσουν για να εφαρμόσουν συνεχή, μετρήσιμη βελτίωση της διαδικασίας λογισμικού. Τέτοιες είναι α) η πρόληψη ατελειών, β) η διαχείριση αλλαγής τεχνολογίας και γ) η διαχείριση αλλαγής διαδικασίας ΠΑΡΑΓΟΝΤΕΣ ΚΟΣΤΟΥΣ Οι παράγοντες κόστους χρησιμοποιούνται για να αποτυπώσουν χαρακτηριστικά της διαδικασίας ανάπτυξης τα οποία επηρεάζουν την προσπάθεια ολοκλήρωσης του έργου. Οι παράγοντες κόστους έχουν πολλαπλασιαστική επίδραση στην εκτίμηση της προσπάθειας και για αυτό ονομάζονται πολλαπλασιαστές προσπάθειας (Effort Multiplier). Κάθε ΕΜ έχει ένα επίπεδο κλιμάκωσης το οποίο εκφράζει την επίδραση του πολλαπλασιαστή στην προσπάθεια ανάπτυξης. Αυτή η κλιμάκωση κυμαίνεται από εξαιρετικά χαμηλά σε εξαιρετικά υψηλά επίπεδα. Για τους λόγους ποσοτικής ανάλυσης κάθε επίπεδο κλιμάκωσης για κάθε ΕΜ έχει και μία συσχετισμένη στάθμιση. Στο Aerly Design μοντέλο, το οποίο χρησιμοποιείται στα αρχικά στάδια του έργου όπου λίγα είναι γνωστά για το μέγεθος του έργου που θα αναπτυχθεί, χρησιμοποιούνται επτά από τους συντελεστές κόστους και παρουσιάζεται στην εξίσωση 17: 55

57 7 PM adjusted = PM nomimal * (Π EM i ) i=1 Εξίσωση 17: εξίσωση παραγόντων κόστους για Early Design. Στο Post Architecture μοντέλο όπου η πληροφορία είναι πλεονάζουσα και θεωρείται ένα λεπτομερειακό μοντέλο εκτίμησης χρησιμοποιούνται 17 συντελεστές κόστους όπως παρουσιάζεται στην εξίσωση 18: 17 PM adjusted = PM nomimal * (Π EM i ) i=1 Εξίσωση 18: εξίσωση παραγόντων κόστους για Post Architecture. Ο συσχετισμός των δύο μοντέλων ως προς τους συντελεστές κόστους παρουσιάζεται στον πίνακα 14. Παράγοντες κόστους του Early Design μοντέλου. Αξιοπιστία προϊόντος και πολυπλοκότητα (Product Reliability and Complexity) RCPX. Απαιτούμενη Επαναχρησιμοποίηση Κώδικα (Required Reuse)-RUSE. Δυσκολία ανάπτυξης πλατφόρμας (platform difficulity) PDIF. Ικανότητα προσωπικού (Personnel Capability)-PERS. Αντίστοιχοι παράγοντες κόστους για το Post Architecture Μοντέλο. Απαιτούμενη αξιοπιστία λογισμικού (Required Software Reliability) RELY. Μέγεθος Βάσης Δεδομένων (Data Base Size) DATA. Πολυπλοκότητα προϊόντος (Product Complexity) CPLX. Τεκμηρίωση (Documentation)- DOCU. Απαιτούμενη επαναχρησιμοποίηση κώδικα (Required Reuse) RUSE. Περιορισμοί χρόνου εκτέλεσης (Execution Time Constraints) TIME. Περιορισμοί Αποθηκευτικού χώρου ( Main Storage Constraint) STOR. Μεταβλητότητα Πλατφόρμας (Platform Volatility) PVOL. Ικανότητα αναλυτών (Analyst Capability)- ACAP. 56

58 Ικανότητα Προγραμματιστών (Programmer Capability) - PCAP Μεταφορά τεχνογνωσίας κατά την αποχώρηση προσωπικού (Personnel Continuity) PCON. Εμπειρία προσωπικού (Personnel Εμπειρία στην ανάπτυξη εφαρμογών Experience) PREX. (Applications Experience) AEXP. Εμπειρία στην επιλεγόμενη πλατφόρμα ανάπτυξης (Platform Experience) PEXP. Εμπειρία στα επιλεγόμενα εργαλεία και στην γλώσσα ανάπτυξης (Language and Tool Experience)-LTEX. Διευκολύνσεις Περιβάλλοντος Χρήση εργαλείων ανάπτυξης (Use of Ανάπτυξης (Facilities) FCIL. software Tools)- TOOL Ανάπτυξη με σκοπό την εγκατάσταση σε πολλούς οργανισμούς (Multisided Development)-SITE. Χρονοπρογραμματισμός (Schedule) Απαιτούμενο Χρονοδιάγραμμα SCED. Ανάπτυξης (SCED). Πίνακας 14: πολλαπλασιαστές προσπάθειας ΚΑΘΟΡΙΣΜΟΣ ΜΕΓΕΘΟΥΣ Στη COCOMO II σαν μετρική για τις γραμμές κώδικα έχει επιλεγεί η λογική πηγαία γραμμή. Ο καθορισμός των γραμμών κώδικα αποτελεί μία δύσκολη διαδικασία λόγω των διαφορών που υπάρχουν ανάμεσα σε εντολές εκτέλεσης και δηλώσεις δεδομένων σε διαφορετικές γλώσσες. Ο στόχος είναι να μετρηθεί το ποσό της διαλογικής δουλειάς που εισάγεται στην ανάπτυξη του προγράμματος, αλλά οι δυσκολίες εμφανίζονται όταν γίνεται προσπάθεια να καθοριστούν συνεπείς μετρήσεις σε διαφορετικές γλώσσες. Για την ελαχιστοποίηση αυτών των προβλημάτων χρησιμοποιείται η λίστα ορισμού (definition checklist) για την λογική δήλωση, η οποία χρησιμοποιείται στον καθορισμό των μετρήσεων για τις γραμμές του κώδικα. Η 57

59 λίστα ορισμού αναπτύχθηκε από το software engineering institute σαν ένα τμήμα ενός συστήματος από λίστες ορισμού, φόρμες αναφορών και υποστηρικτικές φόρμες με σκοπό την υποστήριξη ορισμού μετρικών του συστήματος. Το παρακάτω διάγραμμα 10 δείχνει ένα τμήμα της λίστας ορισμού που έχει υιοθετηθεί για να υποστηρίξει την ανάπτυξη του COCOMO II. Κάθε σημείωση στην Includes κολώνα καθορίζει ένα συγκεκριμένο τύπο δήλωσης ή χαρακτηριστικό που περιλαμβάνεται στον ορισμό και το αντίθετο συμβαίνει για τα excludes. Άλλα τμήματα της λίστας ορισμού αποσαφηνίζουν χαρακτηριστικά που αφορούν την χρήση, την λειτουργικότητα, την επαναληπτικότητα κώδικα, τα παραδοτέα και την κατάσταση ανάπτυξης. Definition Checklist for Source Statements Counts Definition name:..logical Source Statements Date:..(basic definition) Originator: COCOMO II. Measurement unit Physical source lines Logical source statements B Statement type Definition B Data includes excludes When a line or statement contains more than array one type, classify it as the type with the highest precedence 1 Executable order of precedence 1 B 2 Nonexecutable 2 B 3 Declarations 3 B 4 Compiler directives 4 B 5 Comments 5 B 6 On their own lines 6 B 7 On lines with source code 7 B 8 How produced Definition B Data includes excludes 58

60 array 1 Programmed B 2 Generated with source code generators B 3 Converted with automated translators B 4 Copied or reused without change B Origin Definition B Data array includes 1 New work: no prior existence B 2 Prior work: taken or adapted from B 3 A previous version, build, or release B excludes 4 Commercial, off the shelf software (COTS) other than libraries B 5 Government furnished software (GFS), other than reuse libraries B 6 Another product B 7 A vendor-supplied language support library (unmodified) B 8 A vendor-supplied operating system or utility (unmodified) B Διάγραμμα 10: Λίστα ορισμού για μετρήσεις πηγαίων δηλώσεων κώδικα ΜΗ ΠΡΟΣΑΡΜΟΣΜΕΝΑ ΛΕΙΤΟΥΡΓΙΚΑ ΣΗΜΕΙΑ. Ο Boehm με το COCOMO II ενσωμάτωσε στο μοντέλο του την χρηστικότητα των λειτουργικών σημείων (function points). Η προσέγγιση εκτίμησης κόστους με λειτουργικά σημεία (function points) στηρίζεται στο ποσό της λειτουργικότητας που έχει ένα έργο λογισμικού καθώς και σε ανεξάρτητους παράγοντες που το επηρεάζουν. Τα λειτουργικά σημεία είναι χρήσιμοι εκτιμητές καθώς στηρίζονται σε πληροφορία η οποία είναι διαθέσιμη σε αρχικό στάδιο του κύκλου ζωής του έργου. 59

61 Το COCOMO II χρησιμοποιεί Unadjusted Function Points για την εκτίμηση του μεγέθους της εφαρμογής και εφαρμόζει τους δικούς του συντελεστές επαναχρησιμοποίησης, πολλαπλασιαστές προσπάθειας, συντελεστές κόστους και παράγοντες κλιμάκωσης ΜΕΤΑΤΡΟΠΗ ΤΩΝ UNADJUSTED FUNCTION POINTS ΣΕ ΓΡΑΜΜΕΣ ΚΩΔΙΚΑ. Προκειμένου να υπολογιστούν οι ανθρωπομήνες για το Early Design Μοντέλο πρέπει να μετατραπούν τα λειτουργικά σημεία σε πηγαίες γραμμές κώδικα στην γλώσσα ανάπτυξης που θα χρησιμοποιηθούν προκειμένου να υπάρξει μία σχετική συνέπεια στην ανάπτυξη σε κώδικα ανά λειτουργικό σημείο. Ο επόμενος πίνακας παρουσιάζει μία προσπάθεια που έγινε προκειμένου να συσχετισθούν τα λειτουργικά σημεία με γραμμές κώδικα που προκύπτουν με συγκεκριμένες σταθμίσεις για γλώσσες προγραμματισμού. Γλώσσα Προγραμματισμού SLOC/UFP Ada 71 AIShell 49 APL 32 Assembly 320 Assembly (Macro) 213 ANSI / Quick/ Turbo Basic 64 Basic - Compiled 91 Basic - Interpeted 128 C 128 C++ 29 ANSI Cobol Fortran Forth 64 Jowial 105 Lisp 64 60

62 Modula2 80 Pascal 91 Prolog 64 Report Generator 80 Spreadsheet 6 Πίνακας 15 : Μετατροπή λειτουργιών σημείων σε γραμμές κώδικα. Το απαιτούμενο προσωπικό για το έργο μπορεί να υπολογισθεί διαιρώντας τον χρόνο ανάπτυξης με τον απαιτούμενο προγραμματισμό. Συνέπεια του παραπάνω αποτελεί το γεγονός ότι ο χρόνος για την ολοκλήρωση του έργου δεν είναι ανάλογος του αριθμού των ανθρώπων που εργάζονται σε αυτό. 61

63 ΚΕΦΑΛΑΙΟ 4 ΛΕΙΤΟΥΡΓΙΚΑ ΣΗΜΕΙΑ (FUNCTION POINTS) 4.1 ΟΡΙΣΜΟΣ ΤΩΝ ΛΕΙΤΟΥΡΓΙΚΩΝ ΣΗΜΕΙΩΝ Η μέθοδος εκτίμησης και μέτρησης των λειτουργικών σημείων αναπτύχθηκε από τον Allan Albrecht στην ΙΒΜ και πρωτοδημοσιεύτηκε το Ο Albrecht ενδιαφερόταν για το γενικότερο πρόβλημα της μέτρησης παραγωγικότητας στην ανάπτυξη πληροφοριακών συστημάτων και δημιούργησε τη μέθοδο των Λειτουργικών σημείων ως εναλλακτική των μεθόδων εκτίμησης που χρησιμοποιούν πηγαίες γραμμές κώδικα (SLOC) [1]. O Albrecht όρισε τα λειτουργικά σημεία σε ένα πιο μακροοικονομικό επίπεδο σε σχέση με τη SLOC περιλαμβάνοντας στην θεώρηση του έννοιες όπως ο αριθμός των δοσοληψιών εισόδου και ο αριθμός των πρότυπων αναφορών. Ο Albrecht θεωρούσε ότι τα λειτουργικά σημεία προσφέρουν πολλά πλεονεκτήματα σε σχέση με τις SLOC μετρήσεις. Πρώτον είναι δυνατό να εκτιμηθούν νωρίς στο κύκλο ζωής του έργου κατά τη διάρκεια της φάσης ορισμού των απαιτήσεων των χρηστών. Αυτό είναι ένα σημαντικό πλεονέκτημα για οποιονδήποτε προσπαθεί να εκτιμήσει το επίπεδο προσπάθειας που θα απαιτηθεί στην ανάπτυξη του έργου. Δεύτερον είναι δυνατόν να πραγματοποιηθεί η εκτίμηση από ένα άλλο μέλος του έργου που δεν έχει τεχνική κατάρτιση. Τρίτον αποφεύγονται οι ιδιαιτερότητες της κάθε γλώσσας προγραμματισμού και οι διαφοροποιήσεις στην ανάπτυξη του έργου. Δεδομένου ότι τα function points μετρούν το σύστημα από μία λειτουργική προοπτική είναι ανεξάρτητα τεχνολογίας. Τα function points παραμένουν σταθερά ανεξαρτήτως γλώσσας, μεθόδου ανάπτυξης ή hardware πλατφόρμας που χρησιμοποιείται. Η μόνη μεταβλητή που χρησιμοποιείται είναι το ποσό προσπάθειας που χρειάζεται για να δοθεί το δεδομένο σύνολο των λειτουργικών σημείων. Κατά συνέπεια η ανάλυση των λειτουργικών σημείων (function point analysis) χρησιμοποιείται για να καθοριστεί εάν ένα εργαλείο, ένα περιβάλλον ανάπτυξης, μία γλώσσα ανάπτυξης είναι πιο παραγωγικό σε σχέση με άλλα αντίστοιχα μέσα στον ίδιο οργανισμό ή μεταξύ οργανισμών. Αυτό είναι ένα κρίσιμο σημείο και μία από τις πιο σημαντικές τιμές της ανάλυσης των λειτουργικών σημείων. 62

64 Η ανάλυση των λειτουργικών σημείων μπορεί να παρέχει ένα μηχανισμό που παρακολουθεί και καταγράφει τις διαδικασίες. Οι μετρήσεις λειτουργικών σημείων Function point counts συγκρίνονται στο τέλος των διάφορων φάσεων. Για παράδειγμα οι μετρήσεις λειτουργικών σημείων στο τέλος της καταγραφής των απαιτήσεων του χρήστη ή στο τέλος του σχεδιασμού της εφαρμογής συγκρίνονται με τα λειτουργικά σημεία που πραγματικά παραδίδονται. 4.2 ΠΕΡΙΓΡΑΦΗ ΤΗΣ ΜΕΘΟΔΟΥ ΕΚΤΙΜΗΣΗΣ Προκειμένου να μετρηθούν τα λειτουργικά σημεία θα πρέπει να χρησιμοποιηθούν τα τρέχοντα δεδομένα των υπαρχόντων εφαρμογών. Τέτοια δεδομένα μπορεί να είναι: οι διαμορφώσεις οθονών χρήστη, τα σχέδια (layouts) αναφορών, η λίστα εφαρμογών διεπαφής μεταξύ των υποσυστημάτων του ιδίου συστήματος ή και με άλλα συστήματα, λογικά και φυσικά μοντέλα δεδομένων τα οποία θα βοηθήσουν την ανάλυση των λειτουργικών σημείων. Η διαδικασία μέτρησης των λειτουργικών σημείων θα πρέπει να περιλαμβάνεται ως μέρος του όλου πλάνου του έργου. Κατά συνέπεια οι μετρήσεις των λειτουργικών σημείων θα πρέπει να προγραμματίζονται και να σχεδιάζονται. Δύο βήματα που πρέπει να ακολουθηθούν για τον υπολογισμό των λειτουργικών σημείων είναι τα εξής: (1) υπολογισμό των λειτουργιών χρήστη και (2) διευθετήσεις της πολυπλοκότητας των διαδικασιών. Υπάρχουν 5 κατηγορίες λειτουργιών χρηστών ή αλλιώς 5 βασικά συστατικά (components) του προτεινόμενου ή υπό ανάπτυξη συστήματος τα οποία θα μελετήσουμε: Α) Είσοδοι: αφορούν στοιχειώδη διαδικασία κατά την οποία τα δεδομένα εισέρχονται στο σύστημα από εξωτερικές πηγές. Αυτά τα δεδομένα μπορεί να λαμβάνονται από οθόνες καταχώρησης δεδομένων ή από άλλες εφαρμογές. Τα δεδομένα αυτά μπορεί να χρησιμοποιούνται για να ενημερώνονται ένα ή περισσότερα λογικά αρχεία. Τα δεδομένα αυτά μπορεί να είναι είτε πληροφορίες ελέγχου είτε επιχειρησιακή πληροφόρηση. Β) Έξοδοι: αφορούν στοιχειώδη διαδικασία κατά την οποία τα δεδομένα αποστέλλονται από το σύστημα προς εξωτερικούς προορισμούς. Τα δεδομένα αυτά συνθέτουν αναφορές ή αρχεία εξόδου που αποστέλλονται σε άλλες εφαρμογές. Αυτές 63

65 οι αναφορές και τα αρχεία εξόδου δημιουργούνται από ένα ή περισσότερα αρχεία ή διεπαφές. Γ) Επερωτήσεις (queries): αφορούν τη στοιχειώδη διαδικασία με components εισόδων και εξόδων τα οποία έχουν ως αποτέλεσμα την λήψη δεδομένων από ένα ή περισσότερα λογικά αρχεία στο δίσκο και τα αρχεία διεπαφής. Η διαδικασία εισόδου δεν ενημερώνει τα εσωτερικά λογικά αρχεία. Δ) Εσωτερικά λογικά αρχεία: αρχεία όπως τα αντιλαμβάνεται ο χρήστης και όχι οι φυσικές τους αναπαραστάσεις. Τα αρχεία αυτά περιλαμβάνουν ένα σύνολο λογικά συσχετιζόμενων δεδομένων τα οποία εμπεριέχονται στα όρια των εφαρμογών και ενημερώνονται από εξωτερικές εισόδους. Ε) Εξωτερικά αρχεία διεπαφής: αρχεία που περιλαμβάνουν ένα σύνολο λογικά συσχετιζόμενων δεδομένων τα οποία χρησιμοποιεί η εφαρμογή αλλά δεν ενημερώνονται από αυτήν. Είναι τα αρχεία που βρίσκονται εκτός των ορίων της εφαρμογής και συντηρούνται από άλλες εφαρμογές π.χ. αρχεία διαμόρφωσης (configuration files), αρχεία αρχικοποίησης (initialization files). Ο Albrecht αναγνώρισε ότι η προσπάθεια που απαιτείται για να δημιουργηθεί κάποιο επίπεδο λειτουργικότητας εξαρτάται σε μεγάλο βαθμό από το περιβάλλον στο οποίο θα αναπτυχθεί το έργο. Αφού τα βασικά components της εφαρμογής ταξινομηθούν σε μία από τις 5 βασικές κατηγορίες στοιχείων που αναφέραμε παραπάνω, κατηγοριοποιούμε την πολυπλοκότητα των βασικών αυτών χαρακτηριστικών ως: Α) χαμηλή, Β) μέση, Γ) υψηλή για κάθε ένα από τα χαρακτηριστικά αυτά. Για δοσοληψίες (trancactions) <έξοδοι, είσοδοι, επερωτήσεις> η κατηγοριοποίηση βασίζεται στον αριθμό των αρχείων που ενημερώνονται ή λαμβάνονται δεδομένα από αυτά (file types referenced F T R s) και στον αριθμό των τύπων δεδομένων (data element D E T s). Για τα εσωτερικά λογικά αρχεία και τα αρχεία διεπαφής η κατηγοριοποίηση βασίζεται στους τύπους εγγραφών (record element types RE T s) και στους τύπους δεδομένων (data element types DE Τ s). Ένας τύπος εγγραφής είναι ένα υποσύνολο δεδομένων όπως το αντιλαμβάνεται ο χρήστης μέσα σε ένα λογικό αρχείο (π.χ. μέσα στην βάση δεδομένων). Για παράδειγμα, μία εξωτερική είσοδος η οποία επιλέγει ή ενημερώνει δύο αρχεία αναφοράς (FTR) και έχει 7 64

66 στοιχεία δεδομένων (DET) θα της ανατεθεί μία διαβάθμιση μέση (average) και μία συσχετιζόμενη κατηγοριοποίηση 4. Όπου τα FTR είναι ο αριθμός των εσωτερικών αρχείων τα οποία ενημερώνονται ή από τα οποία γίνεται λήψη δεδομένων και αρχείων διεπαφής από τα οποία γίνεται λήψη δεδομένων. Κατά συνέπεια εάν θέλαμε να υπολογίσουμε την σχετική πολυπλοκότητα ενός από τα βασικά αυτά χαρακτηριστικά έστω μίας εξωτερικής εξόδου όπως μία αναφορά θα μπορούσαμε να καθορίσουμε α) τον αριθμό των αρχείων που χρησιμοποιούνται για να παραχθεί η αναφορά και β) τον αριθμό των πεδίων της αναφοράς. Καθορίζοντας αυτές τις τιμές θα μπορούσαμε να κατηγοριοποιήσουμε την πολυπλοκότητα της αναφοράς σε μία από τις τρεις προαναφερόμενες καταστάσεις (χαμηλή, μέση, υψηλή) όπως φαίνεται στο πίνακα 16. Αρχεία τα Αριθμός των τύπων δεδομένων (DE T s) οποία >15 ενημερώνονται ή από τα οποία λαμβάνονται δεδομένα. 0-1 χαμηλή χαμηλή μέση 2 χαμηλή μέση υψηλή 3 ή περισσότερα μέση υψηλή υψηλή Πίνακας 16:παράδειγμα πολυπλοκότητας εισόδων. Όπως όλα τα components, οι επερωτήσεις (queries) κατηγοριοποιούνται και βαθμολογούνται. Μία επερώτηση κατηγοριοποιείται σε χαμηλή, μέση, υψηλή όπως ακριβώς μία έξοδος αλλά της καθορίζεται μία τιμή όπως σε μία είσοδο. Η κατηγοριοποίηση βασίζεται στον συνολικό αριθμό των τύπων δεδομένων (DE T ) και των τύπων αρχείων (F T R ) τα οποία λαμβάνονται από την επερώτηση. Για τα εσωτερικά αρχεία και τις εξωτερικές διεπαφές ο αριθμός των τύπων εγγραφών (RE T ) και ο αριθμός των τύπων δεδομένων (DE T ) χρησιμοποιείται για την κατηγοριοποίηση τους όπως φαίνεται και στον πίνακα

67 Αριθμός τύπων Αριθμός των τύπων δεδομένων (DE T s) εγγραφών >50 (RE T s) 1 χαμηλή χαμηλή μέση 2-5 χαμηλή Μέση υψηλή >5 Μέση υψηλή Υψηλή Πίνακας 17:πολυπλοκότητα αρχείων και διεπαφών. Οι σταθμίσεις βαρών για ένα από τα 5 βασικά components παρουσιάζονται στον πίνακα 18. Κατηγοριοποίηση Στάθμιση πολυπλοκότητας έξοδοι είσοδοι επερωτήσεις αρχεία διεπαφές χαμηλή μέση υψηλή Πίνακας 18: κατηγοριοποίηση πολυπλοκότητας. Οι μετρήσεις για κάθε επίπεδο πολυπλοκότητας για κάθε τύπο component θα μπει στον πίνακα ως εξής: κάθε μέτρηση πολλαπλασιάζεται με την αριθμητική κατηγοριοποίηση του πίνακα 18 για να καθοριστεί η τιμή κατηγοριοποίησης. Οι τιμές κατηγοριοποίησης ανά γραμμή αθροίζονται δίνοντας την συνολική τιμή για κάθε τύπο component. Τα σύνολα αυτά ακολούθως αθροίζονται για να δώσουν τον συνολικό αριθμό των μη προσαρμοσμένων λειτουργικών σημείων (unadjusted function points). Τύπος component Εξωτερικοί τύποι εισόδων Εξωτερικοί τύποι εξόδων Πολυπλοκότητα των component χαμηλή μέση υψηλή _χ3= _χ4= _χ6= _χ4= _χ5= _χ7= Σύνολα 66

68 Εξωτερικοί _Χ3= _χ4= _χ6= τύποι επερωτήσεων Λογικοί _χ7= _χ10= _χ15= εσωτερικοί τύποι αρχείων Εξωτερικοί τύποι αρχείων διεπαφής _χ5= _χ7= _χ10= Συνολικός αριθμός μη προσαρμοσμένων λειτουργικών σημείων σημείων (UAF) Συντελεστής προσαρμογής Σύνολο προσαρμοσμένων Λειτουργικών σημείων (VAF) Πίνακας 19: συντελεστές στάθμισης μετρήσεων. Έπειτα ο συνολικός αριθμός των λειτουργικών μετρήσεων (function counts) υπολογίζεται όπως φαίνεται στη παρακάτω ισότητα: FC=ΣΣ w ij * x ij με 1<=i<=5 και 1<=j<=3 Εξίσωση 19: υπολογισμός Function counts Όπου w ij =στάθμιση για την γραμμή i και κολώνα j και x ij =τιμή στο κελί i,j Η τιμή του συντελεστή προσαρμογής (value adjustment factor VAF) βασίζεται στα 14 γενικά χαρακτηριστικά του συστήματος τα οποία μετρούν την γενικότερη λειτουργικότητα της εφαρμογής που πρόκειται να εκτιμηθεί το κόστος της. Κάθε χαρακτηριστικό ακολουθείται από την περιγραφή του, που βοηθά στον καθορισμό των βαθμών επίδρασης αυτών των χαρακτηριστικών. Οι βαθμοί επίδρασης εκτείνονται σε μία κλίμακα από το 0 (χωρίς επίδραση) έως το 5 (ισχυρή επίδραση). 67

69 4.2.1 ΠΕΡΙΓΡΑΦΗ ΤΩΝ ΓΕΝΙΚΩΝ ΧΑΡΑΚΤΗΡΙΣΤΙΚΩΝ ΤΟΥ ΣΥΣΤΗΜΑΤΟΣ. 1) Επικοινωνία δεδομένων (data communication): πόσες επικοινωνιακές συνδέσεις υπάρχουν για να βοηθήσουν την μεταφορά ή την ανταλλαγή πληροφοριών με την εφαρμογή ή το σύστημα. 2) Κατανεμημένη επεξεργασία δεδομένων: πως γίνεται ο χειρισμός της κατανομής των δεδομένων και της εκτέλεσης των διαφόρων λειτουργιών. 3) Απόδοση: οι χρόνοι απόκρισης ήταν οι απαιτούμενοι από τον χρήστη. 4) Υπερφορτωμένο σύστημα: πόσο πολυχρησιμοποιημένη είναι η τρέχουσα hardware πλατφόρμα όπου θα εγκατασταθεί και θα λειτουργήσει η εφαρμογή. 5) Ρυθμός δοσοληψιών: πόσο συχνά εκτελούνται δοσοληψίες (ημερήσια, εβδομαδιαία, μηνιαία κτλ.) 6) On-line καταχωρήσεις δεδομένων: τι ποσοστό της πληροφορίας εισάγεται online. 7) Αποδοτικότητα τελικού χρήστη: το σύστημα σχεδιάστηκε με σκοπό να αυξήσει την αποδοτικότητα του τελικού χρήστη. 8) On line ενημέρωση: πόσα εσωτερικά αρχεία ενημερώνονται από on-line καταχωρήσεις. 9) Πολυπλοκότητα επεξεργασία: η εφαρμογή έχει αυξημένη λογική και μαθηματική επεξεργασία. 10)Επαναχρησιμοποίηση: η εφαρμογή αναπτύχθηκε για έναν πελάτη ή θα χρησιμοποιηθεί και για άλλες εγκαταστάσεις. 11) Ευκολία εγκατάστασης: πόσο δύσκολη είναι η μετάβαση και η εγκατάσταση. 12) Ευκολία χρήσης: πόσο αποτελεσματικές και αυτοματοποιημένες είναι οι διαδικασίες εκκίνησης, λήψης εφεδρικών αντιγραφών (backup) και αποκατάστασης από αποτυχίες (recovery). 13) Πολλαπλοί χώροι εγκατάστασης: η εφαρμογή σχεδιάστηκε, αναπτύχθηκε και υποστηρίζει πολλαπλές εγκαταστάσεις σε οργανισμούς. 14) Διευκόλυνση Αλλαγών: η εφαρμογή σχεδιάστηκε, αναπτύχθηκε και υποστηρίχθηκε με τρόπο που προήγαγε την αλλαγή των διαδικασιών στον οργανισμό. 68

70 Όταν τα 14 γενικά χαρακτηριστικά απαντηθούν θα ταξινομηθούν χρησιμοποιώντας την εξίσωση 20 που ονομάζεται και ισότητα προσαρμογής τιμών (Value Adjustment Equation VAF). VAF= Σ ci Εξίσωση 20:ισότητα προσαρμογής τιμών. Όπου (0.65<=VAF<=1.35), Ci = βαθμοί πολυπλοκότητας για κάθε ένα από τα γενικά χαρακτηριστικά του συστήματος (0<=Ci <=5), (1<=i<=14). Η τελική μέτρηση των λειτουργικών σημείων αποκτάται από το γινόμενο των μη προσαρμοσμένων λειτουργικών σημείων (UAF) με το σύνολο προσαρμοσμένων λειτουργικών σημείων (VAF). FP = UAF * VAF Εξίσωση 21: Υπολογισμός λειτουργικών σημείων. Το τελικό αποτέλεσμα είναι το γεγονός ότι τα λειτουργικά σημεία μπορεί να βρίσκονται στο διάστημα εμπιστοσύνης = [-35%, +35%] από τις πραγματικές function counts. Εφόσον τα λειτουργικά σημεία υπολογιστούν μπορούν να χρησιμοποιηθούν για σύγκριση του προτεινόμενου έργου με παρελθόντα έργα σε όρους που αφορούν το μέγεθος τους. 4.3 ΠΛΕΟΝΕΚΤΗΜΑΤΑ ΚΑΙ ΜΕΙΟΝΕΚΤΗΜΑΤΑ ΤΩΝ FUNCTION POINTS Ένα από τα βασικά πλεονεκτήματα της χρήσης των function points σαν μετρική εκτίμησης μεγέθους ενός έργου αποτελεί το γεγονός ότι έχουν εδραιωθεί και συντηρούνται πρότυπα μετρήσεις για αυτήν την τεχνική. Ο οργανισμός IFPUG (International Function Point Users Group) διαχειρίζεται, ρυθμίζει και εισάγει ενημερώσεις των προτύπων αυτών που κάνουν τα function points πλήρως τεκμηριωμένα. Τα function points όπως και άλλες τεχνικές έχουν πλεονεκτήματα και μειονεκτήματα τα οποία και παρουσιάζονται παρακάτω. Πλεονεκτήματα : Τα λειτουργικά σημεία μπορούν να χρησιμοποιηθούν για ακριβείς εκτιμήσεις κόστους λογισμικού με σκοπό να καθοριστεί και η παραγωγικότητα. Διαφορετικοί άνθρωποι μπορούν να τα μετρήσουν διαφορετικές χρονικές στιγμές και θα πάρουν τις ίδιες μετρήσεις με λογικό εύρος λάθους. 69

71 Τα λειτουργικά σημεία γίνονται εύκολα αντιληπτά και κατανοητά από μη τεχνικό προσωπικό. Αυτό βοηθά την επικοινωνία μεταξύ πελάτη και προγραμματιστή. Τα λειτουργικά σημεία μπορούν να χρησιμοποιηθούν για να καθοριστεί κατά πόσο ένα εργαλείο, μία γλώσσα ή ένα περιβάλλον είναι πιο αποδοτικό και παραγωγικό συγκρινόμενο με άλλα. Έχουν καθιερωθεί πρότυπα και αναθεωρούνται συχνά. Τα αποτελέσματα των μετρήσεων είναι λογικά και συνεπή. Πηγές μέτρησης είναι διαθέσιμες από το στάδιο της <<ανάλυσης απαιτήσεων χρήστη>> και είναι εφαρμοσμένα σε όλο τον κύκλο ζωής της ανάλυσης. Είναι ανεξάρτητα τεχνολογίας, πλατφόρμας και γλώσσας προγραμματισμού. Μειονεκτήματα: Κατά κύριο λόγο είναι μία manual διαδικασία σε σχέση με την αυτοματοποίηση π.χ. της SLOC μετρικής. Επακριβής μέτρηση απαιτεί εις βάθος γνώση των προτύπων. Δεν γίνεται εκτενής χρήση ιστορικών δεδομένων όπως με την SLOC μετρική. 70

72 ΚΕΦΑΛΑΙΟ 5 ΑΛΛΕΣ ΜΕΡΙΚΕΣ ΕΚΤΙΜΗΣΗΣ ΚΟΣΤΟΥΣ ΛΟΓΙΣΜΙΚΟΥ 5.1 ΤΕΧΝΙΚΗ NON COMMENTING SOURCE STATEMENTS (NCSS) Αυτό που κάνει η μετρική NCSS είναι να μετράει μόνο τις εντολές που υπάρχουν σε ένα πρόγραμμα, καθώς ο αριθμός των γραμμών ενός προγράμματος δεν είναι ασφαλής μετρική επειδή μπορεί να υπάρχουν πολλές κενές γραμμές, σχόλια ή εντολές που εκτείνονται σε περισσότερες από μία γραμμές. Το NCSS ενός Java προγράμματος είναι περίπου αυτό που προκύπτει αν μετρήσουμε τις εμφανίσεις των χαρακτήρων ; και { στα αρχεία που ορίζουν τις κλάσεις του. 5.2 MCCABE S CYCLOMATIC COMPLEXITY METRIC V(G) Η μετρική λογισμικού που είναι γνωστή σα Cyclomatic Complexity προτάθηκε από τον Thomas J. McCabe το 1976 και χρησιμοποιείται για να δείξει την πολυπλοκότητα ενός προγράμματος. Ο McCabe θεωρεί ένα πρόγραμμα σαν γράφο και ακολούθως βρίσκει τον αριθμό των διαφόρων μονοπατιών διάμεσο του γράφου. Όταν τα προγράμματα γίνουν πολύ μεγάλα σε μέγεθος και πολυπλοκότητα, ο αριθμός των μονοπατιών δεν μπορεί να μετρηθεί σε μία μικρή περίοδο του χρόνου. Ο McCabe προτείνει την μέτρηση του αριθμού των βασικών μονοπατιών από ένα σημείο του γράφου στο άλλο [19]. Αυτό παρουσιάζεται στη παρακάτω συνάρτηση: V(G) = E N + 2P Εξίσωση 22: Υπολογισμός αριθμού μονοπατιών κατά McCabe. Όπου: V (G)= Cyclomatic Complexity E= αριθμός των ακμών Ν= αριθμός των κόμβων P= αριθμός των συνδεδεμένων συστατικών Η βασική αλγοριθμική λογική της παρουσιάζεται παρακάτω: 1. Ξεκινάς με 1 για κάθε απλή γραμμή μια ρουτίνας 2. προσθέτεις 1 για κάθε if, while, for ή? 3. προσθέτεις ένα boolean operators && και ΙΙ 4. προσθέσεις 1 σε κάθε switch, και 1 ακόμα αν δεν υπάρχει default 71

73 5.3 ΜΕΤΡΙΚΗ HALSTEAD S COMPLEXITY METRIC Ο Maurice Howard Halstead είναι ο πρώτος που έγραψε μία επιστημονική τυποποίηση μετρικής λογισμικού το Ο Halstead ανέφερε ότι κάθε πρόγραμμα λογισμικού μπορεί να μετρηθεί μετρώντας τον αριθμό των συντελεστών και από αυτούς καθόρισε μία σειρά τύπων προκειμένου να διαμορφώσει αυτά που ονόμασε λεξιλόγιο, μέγεθος και όγκο του προγράμματος [10]. Ο Halstead υπολογίζει τη λογική πολυπλοκότητα ενώ το McCabe τη πολυπλοκότητα στη δόμηση. Μετρική Σύμβολο Τύπος Μέγεθος Ν Ν = Ν1 + Ν2 Λεξιλόγιο N N = n1 + n2 Υπολογιζόμενη διάρκεια ^ N Του προγράμματος Όγκος V V = N * log2(n) Δυσκολία D D = (n1/2) * (N2/n2) Προσπάθεια E E = D * V Πίνακας 20: Πίνακας πολυπλοκότητας κατά Halstead. 5.4 ΜΕΤΡΙΚΗ ΠΟΛΥΠΛΟΚΟΤΗΤΑΣ ΜΕ ΤΗΝ ΧΡΗΣΗ MAINTAINABILITY INDEX Η μετρική Maintainability Index αναπτύχθηκε στο Πανεπιστήμιο Idaho, το 1991 από τον Ομάν και Hagemeister. Είναι η μετρική που συνδυάζει τη μετρική SLOC, McCabe μέτρα και Halstead μέτρα πολυπλοκότητας και χρησιμοποιείται κυρίως για να καθοριστεί εάν ένας κώδικας έχει υψηλό, μεσαίο ή χαμηλό βαθμό δυσκολίας να διατηρήσει. Είναι η τεχνική που προωθεί το SEI (Software Engineering Institute). Τύπος: * 1n (avev) 0.23 * avev (g ) 16.2 * 1n (aveloc) 50 * sin (sqrt (2.4 * percm)) avev: μέση τιμή του Halstead V ανά module. avev (g ): μέση τιμή του cyclomatic Complexity ανά module. 72

74 aveloc: μέση τιμή γραμμών εντολών ανά module. percm: μέση τιμή γραμμών σχολίων ανά module. 73

75 ΚΕΦΑΛΑΙΟ 6 ΜΕΛΕΤΗ ΠΕΡΙΠΤΩΣΗΣ 6.1 ΠΑΡΟΥΣΙΑΣΗ ΤΟΥ ΣΥΣΤΗΜΑΤΟΣ Το υπό εξέταση σύστημα είναι μια εφαρμογή διαχείρισης βιβλιοθηκών. Η εφαρμογή επιτρέπει την εισαγωγή / τροποποίηση / διαγραφή βιβλίων, καθώς και την εισαγωγή / τροποποίηση / διαγραφή μελών δανειζόμενων της βιβλιοθήκης. Η εφαρμογή διατίθεται δωρεάν και μπορεί να μεταφορτωθεί από τη σελίδα Η εφαρμογή έχει γραφεί σε γλώσσα προγραμματισμού και διατίθεται ως ένα εκτελέσιμο αρχείο (.jar) που το συνοδεύουν τρία εξωτερικά αρχεία: books.txt: περιέχει τα στοιχεία των βιβλίων (όνομα βιβλίου, συγγραφέας, εκδότης, ISBN, ημερομηνία έκδοσης, αντίτυπα, διαθέσιμα αντίτυπα και κατηγορία) members.txt: περιέχει τα στοιχεία των δανειζόμενων (όνομα, επώνυμο, διεύθυνση, αριθμός, πόλη, αριθμός τηλεφώνου, id, , ηλικία) και borrow.txt: περιέχει τα στοιχεία των δανεισμών (isbn βιβλίου, id δανειζόμενου, ημερομηνία δανεισμού, ημερομηνία επιστροφής) Η εφαρμογή αποτελείται από τρεις κύριες καρτέλες, όπως φαίνεται και στις παρακάτω εικόνες: Χειρισμός βιβλίων Χειρισμός δανειζόμενων και δανεισμών και Ενέργειες διαχειριστή 74

76 Εικόνα 1: Καρτέλα χειρισμού βιβλίων 75

77 Εικόνα 2: Καρτέλα χειρισμού δανειζόμενων και δανεισμών 76

78 Εικόνα 3: Καρτέλα ενεργειών διαχειριστή 6.2 ΚΑΡΤΕΛΑ ΧΕΙΡΙΣΜΟΥ ΒΙΒΛΙΩΝ Στην καρτέλα χειρισμού βιβλίων υπάρχουν πέντε επιμέρους οθόνες, όπως απεικονίζονται και στις παρακάτω εικόνες: Οθόνη εισαγωγής βιβλίου Οθόνη αναζήτησης βιβλίου Οθόνη διαγραφής βιβλίου Οθόνη εισαγωγής νέου αντίτυπου και 77

79 Οθόνη προβολής διαθέσιμων βιβλίων Εικόνα 4: Οθόνη εισαγωγής βιβλίου 78

80 Εικόνα 5: Οθόνη αναζήτησης βιβλίου 79

81 Εικόνα 6: Οθόνη διαγραφής βιβλίου 80

82 Εικόνα 7: Οθόνη εισαγωγής νέου αντιτύπου 81

83 Εικόνα 8: Οθόνη προβολής διαθέσιμων βιβλίων 6.3 ΚΑΡΤΕΛΑ ΧΕΙΡΙΣΜΟΥ ΔΑΝΕΙΖΟΜΕΝΩΝ ΚΑΙ ΔΑΝΕΙΣΜΩΝ Στην καρτέλα χειρισμού δανειζόμενων και δανεισμών υπάρχουν πέντε επιμέρους οθόνες, όπως απεικονίζονται και στις παρακάτω εικόνες: Οθόνη εισαγωγής δανειζόμενου Οθόνη διαγραφής δανειζόμενου Οθόνη προβολής δανειζόμενων Οθόνη επιστροφής βιβλίου και 82

84 Οθόνη δανεισμού βιβλίου Εικόνα 9: Οθόνη εισαγωγής δανειζόμενου 83

85 Εικόνα 10: Οθόνη διαγραφής δανειζόμενου 84

86 Εικόνα 11: Οθόνη προβολής δανειζόμενων 85

87 Εικόνα 12: Οθόνη επιστροφής βιβλίου 86