1 HMMY Τεχνολογία Λογισμικού Διδάσκων Κώστας Κοντογιάννης Αναπλ. Καθηγητής, Ε.Μ.Π.

Παρουσίαση με θέμα: "1 HMMY Τεχνολογία Λογισμικού Διδάσκων Κώστας Κοντογιάννης Αναπλ. Καθηγητής, Ε.Μ.Π."— Μεταγράφημα παρουσίασης:

1 1 HMMY Τεχνολογία Λογισμικού Διδάσκων Κώστας Κοντογιάννης Αναπλ. Καθηγητής, Ε.Μ.Π

2 2 Διαχείριση Έργων Λογισμικού Η διαχείριση έργων λογισμικού περιλαμβάνει διαφορετικά θέματα όπως: –Υπολογισμός κόστους και όγκου εργασίας για τη ανάπτυξη συστημάτων λογισμικού (Cost and Effort estimation) –Υπολογισμός απαιτούμενων πόρων ανθρώπινου δυναμικού (Staffing) –Επιλογή, και διαχείριση της διαδικασίας ανάπτυξης συστημάτων λογισμικού –Χρονικός προγραμματισμός των εργασιών που είναι σχετικές με τη ανάπτυξη συστημάτων λογισμικού (Scheduling activities) –Παρακολούθηση και έλεγχος ποιοτικών χαρακτηριστικών του έργου και του συστήματος υπό ανάπτυξη (Monitoring quality) –… Σε επίπεδο οργανισμού, τόσο οι διαδικασίες για τη διαχείριση έργων λογισμικού, όσο και η δομή του ίδιου του οργανισμού θα πρέπει συνεχώς να εξελίσσονται και να αναβαθμίζονται

3 3 Ενότητα-Α: Υπολογισμός Κόστους Ο υπολογισμός του κόστους έχει να κάνει με πρόβλεψη των πόρων που απαιτούνται για την ανάπτυξη (συντήρηση) ενός συστήματος λογισμικού Μερικά από τα θέματα που είναι σχετικά με τον υπολογισμό κόστους είναι: Ορισμός Παραγωγικότητας Υπολογιστικές / αλγοριθμικές τεχνικές για πρόβλεψη κόστους και όγκου εργασίας Υπολογισμός χρονοδιαγραμμάτων και διαχείριση ανθρώπινων πόρων

4 4 Κόστος Λογισμικού Το κόστος της ανάπτυξης ενός συστήματος λογισμικού επηρεάζεται κατά κύριο τρόπο από το κόστος εργασίας (Effort costs), καθώς και την σχετική υποδομή που απαιτείται για την παραγωγή αυτής της εργασίας Κόστος Ανθρώπινης Εργασίας (Effort costs) –Μισθοδοσία –Κόστος εισφορών –Κόστος μετακινήσεων και επιμόρφωσης Κόστος Υποδομής –Κόστος κτιριακής υποδομής –Κόστος υποστήριξης δικτύου και τηλεπικοινωνιών –Κόστος κοινών υπηρεσιών και κοινόχρηστων χώρων (βιβλιοθήκη, εστιατόρια κλπ.) –Κόστος Λογισμικού και Υπολογιστών –…

5 5 Κόστος και Τιμή Πώλησης Λογισμικού Συνήθως δεν υπάρχει απλή σχέση ανάμεσα στο κόστος ανάπτυξης ενός συστήματος λογισμικού και στη τιμή που θα πωληθεί Υπάρχουν διάφοροι παράγοντες που θα μπορούσαν να επηρεάσουν τη τιμή πώλησης, όπως: –Ευκαιρίες στην Αγορά – Το λογισμικό προσφέρεται σε χαμηλή τιμή για να γίνει ευρέως γνωστό στους αγοραστές (π.χ. Αρχικά “free software”) –Αβεβαιότητα σχετικά με τον υπολογισμό του τελικού κόστους –Όροι συμβολαίου –Μεταβλητότητα στις απαιτήσεις του συστήματος –Οικονομική ευρωστία του οργανισμού / εταιρίας –…

6 6 Μια μετρική του ρυθμού με το οποίο οι προγραμματιστές παράγουν λογισμικό και το συναφές με αυτό υλικό τεκμηρίωσης Η ποιότητα του παραγόμενου έργου θα πρέπει τελικά με κάποιο τρόπο να λαμβάνεται υπ’όψη στον υπολογισμό της παραγωγικότητας Επηρεάζεται και εξαρτάται από: –Την πολυπλοκότητα του προγράμματος, μοντέλων, αλγορίθμων –Το μέγεθος του προγράμματος / εφαρμογής –Την ευκολία συνεννόησης ανάμεσα στους προγραμματιστές –Χρονικούς περιορισμούς –Κοινωνικούς παράγοντες Ένας τρόπος μέτρησης της παραγωγικότητας των προγραμματιστών είναι η παραγόμενη προδιαγραμμένη λειτουργικότητα του συστήματος όπως αυτή υλοποιείται στην μονάδα του χρόνου και ανά προγραμματιστή Παραγωγικότητα Προγραμματιστών

7 7 Μια μετρική παραγωγικότητας που έχει χρησιμοποιηθεί είναι ο αριθμός γραμμών πηγαίου κώδικα (source lines of code SLOC) ανά ανθρωπομήνα - SLOC / person-month Αυτή η μετρική δεν είναι πολύ καλή διότι δεν λαμβάνει υπ’ όψη χρησιμοποιούμενες βιβλιοθήκες, κλωνοποιημένο κώδικα κλπ. Επιπλέον δεν δίνει κίνητρα στους προγραμματιστές να παράγουν ποιοτικό κώδικα Μια άλλη κατηγορία μετρικών παραγωγικότητας, και που είναι επίσης καλύτερη από αυτές που βασίζονται σε SLOC, είναι αυτές που βασίζονται σε μετρικές που ποσοτικοποιούν το «μέγεθος» της λειτουργικότητας που υλοποιεί ένα κομμάτι κώδικα. Μια τέτοια μετρική είναι η μετρική Function- points. Με αυτή τη λογική μια μετρική της παραγωγικότητας είναι πόσα Function Points υλοποιούνται ανά μονάδα χρόνου και ανά προγραμματιστή δηλαδή η μετρική FP / person-month Μετρικές Παραγωγικότητας

8 8 Στη βιβλιογραφία έχουν προταθεί αρκετοί διαφορετικοί τρόποι να μετρήσουμε τις γραμμές του πηγαίου κώδικα. Κάποιες τεχνικές μετρούν τις γραμμές κειμένου στο αρχείο του πηγαίου κώδικα. Άλλες τεχνικές μετρούν αριθμό εντολών ή αριθμό γραμμών με εντολές (NCLOC – Non-Commented Lines of Code). Άλλες τεχνικές μετρούν τις γραμμές πηγαίου κώδικα αφότου έχουν ήδη επεξεργαστεί από κάποιον formatter. Όταν χρησιμοποιούμε λοιπόν τη μετρική SLOC, θα πρέπει να γνωρίζουμε ποια απ’ όλες τις τεχνικές έχουμε επιλέξει για τον υπολογισμό αυτής της μετρικής. χρησιμοποιούμε. Επειδή θα πρέπει να έχουμε κάποια αναλογική σχέση ανάμεσα στον όγκο του «εκτελέσιμο» πηγαίου κώδικα (δηλ. εντολές) και τον όγκο της τεκμηρίωσης στο αρχείο του πηγαίου κώδικα, μια άλλη μετρική που χρησιμοποιείται είναι και η CLOC (Comment Lines of Code) η οποία ποσοτικοποιεί τον όγκο των σχολίων στον πηγαίο κώδικα. Τέλος μια χρήσιμη μετρική που συνδυάζει την NCLOC και τη CLOC είναι η comment density πού ορίζεται σαν ο λόγος του αριθμού των γραμμών τεκμηρίωσης προς το συνολικό αριθμό γραμμών του πηγαίου κώδικα. Η Μετρική SLOC

9 9 Μετρικές LOC LOC (Lines of Code): Συνολικός αριθμός γραμμών στο αρχείο πηγαίου κώδικα NCLOC (Non-Commented Lines of Code): Συνολικός αριθμός γραμμών στο αρχείο του πηγαίου κώδικα που δεν είναι τεκμηρίωση (δηλ. είναι κείμενο του προγράμματος – εφαρμογής) CLOC (Commented Lines of Code): Συνολικός αριθμός γραμμών στο αρχείο του πηγαίου κώδικα που έχουν να κάνουν με σχόλια - τεκμηρίωση CD (Comment Density): Ο λόγος που ποσοτικοποιεί τον όγκο των σχολίων σε σχέση με το μέγεθος του αρχείου του πηγαίου κώδικα ES (Executable Statements): Αριθμός εκτελέσιμων εντολών στο αρχείο του πηγαίου κώδικα – εξαιρούνται οι headers, και τα οι ορισμοί δομών δεδομένων DSI (Delivered Source Instructions): Ο αριθμός των εντολών που τελικά θα παραδοθούν / παραδόθηκαν στον πελάτη / χρήστη (π.χ. Δεν περιλαμβάνει κώδικα που γράφτηκε για έλεγχο, πρωτότυπα κλπ.) Οπότε οι μετρικές μας είναι: LOC = NCLOC + CLOC CD = CLOC/LOC

10 10 LOC & Γλώσσες Προγραμματισμού Γενικά μετρικές της παραγωγικότητας που βασίζονται στον όγκο παραγωγής πηγαίου κώδικα στη μονάδα του χρόνου δεν είναι οι καλύτερες διότι δεν λαμβάνουν υπ’ όψη τους την ποιότητα του παραγόμενου κώδικα

11 11 Συστήματα Πραγματικού Χρόνου – Embedded Systems, 40-160 LOC/P-month Εφαρμογές Συστημάτων (Systems applications), 150-400 LOC/P-month Εταιρικές Εφαρμογές (Commercial applications), 200-800 LOC/P-month Εκτίμηση Παραγωγικότητας – Εμπειρικά Στοιχεία

12 12 Οι Τέσσερις Παράμετροι ενός Έργου Λογισμικού Οι τέσσερις κύριες παράμετροι ενός έργου λογισμικού είναι: –Κόστος Ανάπτυξης της Εφαρμογής (Development cost) –Χρόνος Ανάπτυξης της Εφαρμογής (Development time) –Ποιότητα της Εφαρμογής (Product Quality) –Εμβέλεια της Εφαρμογής (Product Scope) Μόνο τρεις από αυτές τις παραμέτρους μπορούμε να ρυθμιστούν ανεξάρτητα Το Κόστος Ανάπτυξης, ο Χρόνος Ανάπτυξης, και η Ποιότητα είναι κακές παράμετροι για ρύθμιση –Το κόστος εξαρτάται από τον αριθμό των προγραμματιστών (περισσότεροι δεν δίνουν πάντα καλύτερα αποτελέσματα) –Το χρονοδιάγραμμα ανάπτυξης συνήθως καθορίζεται από εξωτερικούς παράγοντες (π.χ. market window, important presentation) –Χαμηλή ποιότητα αποθαρρύνει πελάτες και προγραμματιστές Η Εμβέλεια της εφαρμογής είναι η μόνη πραγματικά ελεγχόμενη παράμετρος. Γι’ αυτό είναι σημαντικό η εμβέλεια της εφαρμογής, δηλαδή οι προδιαγραφές (λειτουργικές – μη-λειτουργικές), να ορισθούν με σαφήνεια από την αρχή.

13 13 Παραγωγικότητα Το “Vicious Square” ++ -- -- ++ ΠοιότηταΕμβέλεια Χρόνος ΑνάπτυξηςΚόστος

14 14 Ακρίβεια – Ορθότητα Εκτίμησης Υπολογισμών Κόστους FeasibilityRequirementsDesignCodeDelivery x 2x 4x 0.25x 0.5x Καθώς το έργο προχωρά, περισσότερες πληροφορίες γίνονται Γνωστές και η ακρίβεια των εκτιμήσεων αυξάνει. x – Το τελικό κόστος ανάπτυξης Οι εκτιμήσεις του κόστους είναι ανάμεσα Στις δύο καμπύλες του παρακάτω διαγράμματος

15 15 Τεχνικές Εκτίμησης Κόστους Εμπειροτεχνικά (Expert judgement) Κατά αναλογία (Estimation by analogy) Με το νόμο του Parkinson (Parkinson's Law) Με σκοπό την κατοχύρωση του έργου (Pricing to win) Εκτίμηση Top-down (Top-down estimation) Εκτίμηση Bottom-up (Bottom-up estimation) Εκτίμηση με τη χρήση μετρικής Function Point (Function point estimation) Εκτίμηση με τη χρήση αλγοριθμικών μοντέλων κόστους (Algorithmic cost modelling)

16 16 Εμπειροτεχικά - Expert judgement Ένας ή περισσότεροι εμπειρογνώμονες στις περιοχές πεδίου εφαρμογής και στις περιοχές ανάπτυξης συστημάτων εκτιμούν το κόστος ανάπτυξης. Η διαδικασία επαναλαμβάνεται όσες φορές χρειάζεται μέχρι που να βρεθεί μια κοινή γνώμη και όλοι οι εμπειρογνώμονες είναι ικανοποιημένοι από το αποτέλεσμα. Κάθε εμπειρογνώμονας εκφράζει και μια διαφορετική σκοπιά για την τελική εκτίμηση του κόστους Πλεονεκτήματα της μεθόδου: Σχετικά ολιγοέξοδη μέθοδος υπολογισμού / εκτίμησης κόστους Relatively cheap estimation method. Μειονεκτήματα της μεθόδου: Αναξιόπιστη μέθοδος εάν δεν υπάρχουν καλοί εμπειρογνώμονες

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

18 18 Parkinson's Law Το έργο θα κοστίσει όσο κοστίζουν οι διαθέσιμοι πόροι Πλεονεκτήματα της μεθόδου: Ποτέ δεν βγαίνουμε εκτός προϋπολογισμού Μειονεκτήματα της μεθόδου: Η εφαρμογή συνήθως δεν παραδίδεται τελειωμένη ή ποτέ δεν τελειώνει

19 19 Κατοχύρωση του Έργου Pricing to win Το έργο θα κοστίσει όσο έχει να πληρώσει ο πελάτης / χρήστης Πλεονεκτήματα της μεθόδου: Κατοχυρώνουμε το έργο Μειονεκτήματα της μεθόδου: Η πιθανότητα ο πελάτης να παραλάβει τελικά την εφαρμογή έτσι όπως θα την ήθελε είναι χαμηλή. Σε αυτή τη μέθοδο το κόστος ανάπτυξης δεν αντικατοπτρίζει σωστά την εργασία που απαιτείται για την εκτέλεση του έργου.

20 20 Εκτίμηση Top-down Για την εκτίμηση του κόστους ανάπτυξης της εφαρμογής ξεκινάμε από το σύστημα σαν σύνολο και προσδιορίζουμε τα επιμέρους υποσυστήματα που πρέπει να υλοποιηθούν, και υπολογίζουμε τα επί μέρους κόστη. Καταλήγουμε τη διαδικασία όταν φτάσουμε σε απλές μονάδες που δεν απαιτούν άλλα υποσυστήματα ψηφίδες συστήματος για την υλοποίησή τους Η μέθοδος λαμβάνει υπ΄ όψη της το κόστος ενοποίησης των ψηφίδων / υποσυστημάτων Η μέθοδος υποφέρει από το πρόβλημα ότι μπορεί να υπο- εκτιμήσουμε το κόστος της ανάπτυξης των τελικών μονάδων της εφαρμογής

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

22 22 Εκτίμηση με τη Μετρική Function Points Η ιδέα παρουσιάστηκε από τον Albrecht το 1979 Η μετρική function point ενός συστήματος/υποσυστήματος/ψηφίδας έχει προταθεί με σκοπό να ποσοτικοποιήσει το «όγκο» της λειτουργίας που προσφέρει ένα συστήμα/υποσύστημα/ψηφίδα Βήματα της μεθόδου: –Υπολογισμός FPs – (information domain) –Εκτίμηση της πολυπλοκότητας της εφαρμογής – προσαρμογή της μετρικής FP –Χρήση εμπειρικής αναλογίας σχέσης της προσαρμοσμένης μετρικής FP με LOC και P-months για τη συγκεκριμένη γλώσσα προγραμματισμού που χρησιμοποιείται για τη ανάπτυξη της εφαρμογής

23 23 Παράμετροι Εκτίμησης της Μετρικής Function Points Ποσοτικοποίηση Δεδομένων Εισόδου από τον Χρήστη (application oriented data) Ποσοτικοποίηση Δεδομένων Εξόδου (application oriented information to the user) Ποσοτικοποίηση Αναζήτησης Δεδομένων από τον Χρήστη (ποσοτικοποίηση ερωτημάτων από τον χρήστη που ξεκινούν κάποια διαδικασία) Ποσοτικοποίηση Χρήσης Αρχείων (master files) Ποσοτικοποίηση Εξωτερικών Διαπροσωπειών

24 24 Παράδειγμα Εκτίμησης Μετρικής Function Points

25 25 Προσαρμογή της Μετρικής Function Points Η προσαρμογή της μετρικής με τη χρήση παραμέτρων προσαρμογής (F i ). και τιμή βάρους για κάθε παράμετρο, με εύρος τιμών [0-5]. Η τιμή 0 σημαίνει ότι η παράμετρος δεν είναι σημαντική, και η τιμή 5 σημαίνει ότι είναι απαραίτητη Οι παράμετροι είναι: 1. Does the system require reliable backup and recovery? 2. Are data communications required? 3. Are there distributed processing functions? 4. Is performance critical? 5. Will the system run in an existing, heavily utilized operational env.? 6. Does the system require on-line data entry?

26 26 Προσαρμογή της Μετρικής Function Points 7. Does the on-line data entry require the input transaction to be built over multiple screens or operations (user efficiency)? 8. Are the master files updated on-line? 9. Are the inputs, outputs, files, or inquiries complex? 10. Is the internal processing complex? 11. Is the code designed to be reusable? 12. Is installation included in the design? 13. Is the system designed for multiple installations? 14. Is the application designed to facilitate change and ease of use by the user?

27 27 Απεικόνιση FPs to LOC Χρήση εμπειρικής μεθόδου –Function point = count total  [0.65 + 0.01  (sum of the 14 F i )] –Companies may want to refine their own version Σύμφωνα με μια μελέτη για την υλοποίηση κάθε Function Point απαιτούνται οι παρακάτω γραμμές πηγαίου κώδικα ανά γλώσσα προγραμματισμού –Assembly320 –C128 –COBOL106 –C++64 –Visual Basic32 –SQL12 Βλ. www.ifpug.org για περισσότερες πληροφορίες για τη μετρική FP

28 28 Παράδειγμα

29 29 Παράδειγμα Συνολικά FPs = 25 F 4 = 4, F 10 = 4, άλλα F i ’s είναι 0. Σύνολο F i ’s = 8. FP = 25 x (0.65 + 0.01 x 8) = 18.25 Γραμμές πηγαίου κώδικα C = 18.25 x 128 LOC = 2336 LOC

30 30 Αλγοριθμικά Μοντέλα Εκτίμησης Κόστους Το κόστος υπολογίζεται με ένα αλγοριθμικό τρόπο σαν συνάρτηση του τύπου της εφαρμογής Ένα τέτοιο μοντέλο είναι το COCOMO Το μοντέλο COCOMO έχει τρεις εκδόσεις –Βασική –Ενδιάμεση –Προηγμένη

31 31 Κατηγορίες Έργων στο Μοντέλο COCOMO Οργανική κατηγορία (Organic mode): Μικρές ομάδες, γνωστό αντικείμενο, απλές απαιτήσεις Ημι-χωρισμένη κατηγορία (Semi-detached mode): Η ομάδα και ο οργανισμός που αναλαμβάνει το έργο έχουν σχετική εμπειρία αλλά όχι μεγάλη εμπειρία στο πεδίο εφαρμογής και στην υλοποίηση των προδιαγραφών του συστήματος Ενσωματωμένα: Η ομάδα έχει περιορισμένη εμπειρία, στις συγκεκριμένες εφαρμογλες συστήματα, και οι προδιαγρεφές είναι πολύπλοκες

32 32 Βασικό Μοντέλο COCOMO Οργανική κατηγορία: PM = 2.4 (KDSI) 1.05 Ημι-χωρισμένη: PM = 3 (KDSI) 1.12 Ενσωματωμένη : PM = 3.6 (KDSI) 1.2 KDSI = Kilo Delivered Source Instructions

33 33 Εκτιμήσεις Φόρτου Εργασίας

34 34 Organic mode, 32KLOC –PM = 2.4 (32) 1.05 = 91 person months –TDEV = 2.5 (91) 0.38 = 14 months –N = 91/15 = 6.5 people Embedded mode, 128KLOC –PM = 3.6 (128) 1.2 = 1216 person-months –TDEV = 2.5 (1216) 0.32 = 24 months –N = 1216/24 = 51 Παράδειγμα

35 35 Εκτίμηση παραγωγικότητας –Organic mode = 16 LOC/day –Embedded mode = 4 LOC/day Ο χρόνος ανάπτυξης είναι συνάρτηση του συνολικού φόρτου εργασίας και όχι του μεγέθους της ομάδας Υποθέσεις στο Μοντέλο COCOMO

36 36 Λαμβάνει το βασικό μοντέλο COCOMO σαν αρχή Θεωρεί παραμέτρους σχετικές με προσωπικό, το πεδίο εφαρμογής, και τα χαρακτηριστικά του συστήματος υπό ανάπτυξη Το μοντέλο πολλαπλασιάζει το βασικό κόστος με αυτές τις πολλαπλασιαστικές παραμέτρους Ενδιάμεσο Μοντέλο COCOMO

37 37 Personnel attributes –Analyst capability –Virtual machine experience –Programmer capability –Programming language experience –Application experience Product attributes –Reliability requirement –Database size –Product complexity Χαρακτηριστικά Προσωπικού

38 38 Computer attributes –Execution time constraints –Storage constraints –Virtual machine volatility –Computer turnaround time Project attributes –Modern programming practices –Software tools –Required development schedule Χαρακτηριστικά Υπολογιστών και Εφαρμογής

39 39 Cost Drivers Ratings Very LowLowNominalHighVery HighExtra High Product attributes Required software reliability0.750.881.001.151.40 Size of application database 0.941.001.081.16 Complexity of the product0.700.851.001.151.301.65 Hardware attributes Run-time performance constraints 1.001.111.301.66 Memory constraints 1.001.061.211.56 Volatility of the virtual machine envionment 0.871.001.151.30 Required turnabout time 0.871.001.071.15 Personnel attributes Analyst capability1.461.191.000.860.71 Applications experience1.291.131.000.910.82 Software engineer capability1.421.171.000.860.70 Virtual machine experience1.211.101.000.90 Programming language experience1.141.071.000.95 Project attributes Use of software tools1.241.101.000.910.82 Application of software engineering methods1.241.101.000.910.83 Required development schedule1.231.081.001.041.10

40 40 Predicted costs

41 41 Embedded system σε microcomputer Basic COCOMO predicts a 45 person-month effort requirement Attributes = RELY (1.15), STOR (1.21), TIME (1.10), TOOL (1.10) Intermediate COCOMO predicts –45*1.15*1.21.1.10*1.10 = 76 person-months. Total cost = 76*$7000 = $532, 000 Παράδειγμα

42 42 Οργανικό: TDEV = 2.5 (PM) 0.38 Ημι-χωρισμένο: TDEV = 2.5 (PM) 0.35 Ενσωματωμένο: TDEV = 2.5 (PM) 0.32 Απαιτήσεις για προσωπικό: N = PM/TDEV Εκτιμήσεις Χρόνου Ανάπτυξης Συστήματος

43 43 Μοντέλα Εκτίμησης – Συνοπτικά Function points –SRS -> LOC –SRS -> PM COCOMO –LOC -> PM –May use FP as a front-end to COCOMO COCOMO II –Refined version with different estimation models based on Requirements (FP->PM), Early design (FP->PM), and Architecture (FP or LOC->PM)

44 44 Διάγραμμα Ελέγχου Ροής (Control Flow Graph) Βασικά Μπλοκ FindMean (FILE ScoreFile) { float SumOfScores = 0.0; int NumberOfScores = 0; float Mean=0.0; float Score; Read(ScoreFile, Score); while (! EOF(ScoreFile) { if (Score > 0.0 ) { SumOfScores = SumOfScores + Score; NumberOfScores++; } Read(ScoreFile, Score); } /* Compute the mean and print the result */ if (NumberOfScores > 0) { Mean = SumOfScores / NumberOfScores; printf(“ The mean score is %f\n”, Mean); } else printf (“No scores found in file\n”); } 1 2 3 4 5 7 6 8 9

45 45 Κατασκευή Διαγράμματος Ελέγχου Ροής

46 46 Διαγράμματα Ελέγχου Ροής για Απλές Κατασκευές Assignment, I/O, call If c then S1 else S2 c~c S1S2 If c then S1 c S1 while c S1 c S1 ~c

47 47 Μετρική Κυκλοματικής Πολυπλοκότητας –(McCabe’s) Cyclomatic complexity V(G) = E – N + 2  E: # ακμές, N: # κόμβοι V(G) = p + 1  p # σημεία επιλογής ροής (T, F) V(G) = # κλειστές περιοχές –Παράδειγμα: –V(G) = E – N + 2 = 17 - 13 + 2 = 6 –V(G) = p + 1 = 5 + 1 –V(G) = 6

48 48 Παράδειγμα I = 1; TI = TV = 0; sum = 0; DO WHILE (value[I] <> -999 and TI < 100) TI++; if (value[I] >= min and value[I] <= max){ then {TV++; sum = sum + value[I];} } I++; ENDDO If TV > 0 av = sum/TV; Else av = -999; 1 2 3 4 56 7 8 9 10 11 12 13  final node 1 2 3 4 6 5 78 9 10 1112 13 R1 R2 R3 R4 R5 R6 Outer region F F F T T