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

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

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

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

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

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

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

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

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

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. Ανάλυση Σχεδίαση Υλοποίηση Έλεγχος Τεκμηρίωση Assembly code 3 weeks 5 weeks 8 weeks 10 weeks 2 weeks High-level language 3 weeks 5 weeks 8 weeks 6 weeks 2 weeks Μέγεθος LOC Φόρτος Παραγωγικότητα Assembly code 5000 lines 28 weeks 714 lines/month High-level language 1500 lines 20 weeks 300 lines/month LOC & Γλώσσες Προγραμματισμού Γενικά μετρικές της παραγωγικότητας που βασίζονται στον όγκο παραγωγής πηγαίου κώδικα στη μονάδα του χρόνου δεν είναι οι καλύτερες διότι δεν λαμβάνουν υπ’ όψη τους την ποιότητα του παραγόμενου κώδικα

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

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

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

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

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

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

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

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

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

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

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

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

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

25. Προσαρμογή της Μετρικής Function Points Η προσαρμογή της μετρικής με τη χρήση παραμέτρων προσαρμογής (Fi). και τιμή βάρους για κάθε παράμετρο, με εύρος τιμών [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. Προσαρμογή της Μετρικής 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. Απεικόνιση FPs to LOC • Χρήση εμπειρικής μεθόδου • Function point = count total  [0.65 + 0.01  (sum of the 14 Fi)] • Companies may want to refine their own version • Σύμφωνα με μια μελέτη για την υλοποίηση κάθε Function Point απαιτούνται οι παρακάτω γραμμές πηγαίου κώδικα ανά γλώσσα προγραμματισμού • Assembly 320 • C 128 • COBOL 106 • C++ 64 • Visual Basic 32 • SQL 12 • Βλ. www.ifpug.orgγια περισσότερες πληροφορίες για τη μετρική FP

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

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

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

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

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. Εκτιμήσεις Φόρτου Εργασίας

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. Υποθέσεις στο Μοντέλο COCOMO • Εκτίμηση παραγωγικότητας • Organic mode = 16 LOC/day • Embedded mode = 4 LOC/day • Ο χρόνος ανάπτυξης είναι συνάρτηση του συνολικού φόρτου εργασίας και όχι του μεγέθους της ομάδας

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

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

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

40. Predicted costs

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

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. 1 2 3 4 5 6 7 8 9 Διάγραμμα Ελέγχου Ροής (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”); • }

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

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

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. Παράδειγμα 1 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; 2 1 F 3 2 3 4 R1 4 5 6 F 7 R4 5 8 F 10 R2 T 6 9 T R5 12 11 10 R3 8 7 11 13 12 R6 9 13  final node Outer region