ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ. ΜΕΤΑΠΤΥΧΙΑΚΟ ΔΙΠΛΩΜΑ ΕΙΔΙΚΕΥΣΗΣ (MSc) στα ΠΛΗΡΟΦΟΡΙΑΚΑ ΣΥΣΤΗΜΑΤΑ ΔΙΠΛΩΜΑΤΙKH ΕΡΓΑΣΙΑ. Μετρικές Ευέλικτων Μεθόδων Διαχείρισης Έργων

Transcript

1 ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΜΕΤΑΠΤΥΧΙΑΚΟ ΔΙΠΛΩΜΑ ΕΙΔΙΚΕΥΣΗΣ (MSc) στα ΠΛΗΡΟΦΟΡΙΑΚΑ ΣΥΣΤΗΜΑΤΑ ΔΙΠΛΩΜΑΤΙKH ΕΡΓΑΣΙΑ Κουταβάς Θεόφιλος ΑΘΗΝΑ, ΣΕΠΤΕΜΒΡΙΟΣ 2016

2

3 Κουταβάς Θεόφιλος Δρ. Φιτσιλής Παναγιώτης Επιβλέπων Δρ. Γκρίτζαλης Δημήτριος Μέλος Δρ. Δρίτσας Στυλιανός Μέλος Περίληψη: Είναι αδιαμφισβήτητο γεγονός, το ότι υπάρχει ένα διαρκές αυξανόμενο ενδιαφέρον ως προς τη χρήση Agile μεθόδων. Αυτό το ενδιαφέρον, προέρχεται κυρίως λόγω της ευέλικτης διαχείρισης της μεταβλητότητας και της εκτεταμένης συνεργασίας μεταξύ πελατών και ομάδας ανάπτυξης, που αυτές οι μέθοδοι παρέχουν. Η βιβλιογραφία η σχετιζόμενη με αυτές τις μεθόδους και τις προτεινόμενες αντίστοιχες μετρικές, αυξάνεται με γεωμετρική πρόοδο. Ωστόσο, θα μπορούσε να χαρακτηριστεί ως έλλειψη, η συστηματική καταγραφή και σύνθεση των διαφόρων απόψεων και προσεγγίσεων. Η παρούσα πτυχιακή, αποτελεί μια προσπάθεια καταγραφής και σύνθεσης των προτεινόμενων μετρικών, οι οποίες κυρίως στοχεύουν στην πρόβλεψη της εξελικτικής πορείας του έργου. Η παρούσα ακολουθεί της εξής δομή: Στο πρώτο κεφάλαιο, γίνεται μια περιγραφή του χώρου των ευέλικτων μεθόδων. Επισημαίνονται οι σημαντικότερες διαφοροποιήσεις σε σχέση με τις παραδοσιακές μεθόδους, εξετάζεται η αποδοχή των ευέλικτων μεθοδολογιών από τη βιομηχανία λογισμικού και αναπτύσσονται τα κύρια χαρακτηριστικά των σημαντικότερων ευέλικτων μεθοδολογιών. Στο δεύτερο κεφάλαιο αναπτύσσεται η έννοια της μετρολογίας, με επισήμανση των διαφοροποιήσεων της φύσης των μετρικών στις ευέλικτες μεθοδολογίες. Στο τρίτο κεφάλαιο, περιγράφεται η Ερευνητική μεθοδολογία βιβλιογραφικής επισκόπησης που ακολουθήθηκε για τον εντοπισμό των πληροφοριών. Στο τέταρτο κεφάλαιο, γίνεται παρουσίαση των μετρικών που εντοπίστηκαν στη βιβλιογραφία, ταξινομημένων σύμφωνα με το είδος τους. Λέξεις-κλειδιά: agile, metrics, XP, scrum

4 Agile Project Management Metrics Theofilos Koutavas Dr. Fitsilis Panagiotis Director of research Dr. Gritzalis Dimitris Member Dr.Dritsas Stelios Member Αbstract: It is an undeniable fact that there is a growing interest in the use of agile methods. This interest, mainly due to the flexible management of volatility and extensive cooperation between customers and development team, which these methods provide. The literature associated with these methods and the proposed corresponding metrics increases exponentially. However, it could be described as a lack, the systematic recording and synthesis of views and approaches. This study is an attempt to capture and composition the proposed measures, which mainly aim to predict the evolution of a project. This study follows the structure: The first chapter is a description of the area of agile methods. It indicates significant differences compared to traditional methods, examines the acceptance of agile methodologies from the software industry and explicates the main features of the main agile methods. The second chapter describes the concept of metrology, indicating the variations of metrics on agile methodologies. The third chapter describes the research literature review methodology used for identifying information.

5 Περιεχόμενα Κεφάλαιο 1ο. Περιγραφή χώρου ευέλικτων μεθόδων Αρχικές μεθοδολογίες Ευέλικτες μεθοδολογίες (agile methods) Βιομηχανία λογισμικού και ευέλικτες μεθοδολογίες Οι σημαντικότερες ευέλικτες μέθοδοι Adaptive software development Crystal Family Dynamic Systems Development Method (DSDM) Extreme Programming (XP) Feature-driven development (FDD) Lean software development (LSD) Μέθοδος Scrum Κεφάλαιο 2ο. Η έννοια της μετρολογίας Εισαγωγή Η έννοια της μετρικής Οι μετρικές στο λογισμικό Επικύρωση μετρικών Φύση μετρικών στις ευέλικτες μεθοδολογίες Κεφάλαιο 3ο. Ερευνητική μεθοδολογία βιβλιογραφικής επισκόπησης Systematic Literature Review (SLR) Ερευνητική προσέγγιση Πιλοτική μελέτη Εξόρυξη δεδομένων Σύνθεση δεδομένων Κεφάλαιο 4ο. Αναλυτική παρουσίαση μετρικών Εισαγωγή Ταξινόμηση μετρικών Μετρικές διαδικασιών Μετρικές διαχείρισης Μετρικές κύκλου ζωής Μετρικές προϊόντων Μετρικές πόρων Συμπεράσματα Αναφορές

6 Κεφάλαιο 1ο. Περιγραφή χώρου ευέλικτων μεθόδων 1.1 Αρχικές μεθοδολογίες Μια από τις πρώτες - και σίγουρα η πιο αποδεκτή μεταξύ τους- προσπάθειες δομημένης περιγραφής των βημάτων που πρέπει να ακολουθηθούν για την παραγωγή επιτυχημένου λογισμικού, αποτέλεσε το μοντέλο του καταρράκτη (Waterfall Model) [1]. Το συγκεκριμένο μοντέλο χρησιμοποιήθηκε ευρέως. Παρουσιάζει γραμμικά την πορεία ανάπτυξης του έργου, είναι άμεσα κατανοητό από όσους συμμετέχουν στην ανάπτυξη του λογισμικού, περιέχει την ανάλυση και το σχεδιασμό των απαιτήσεων στα αρχικά στάδια και δρα βοηθητικά στον επιμερισμό των εργασιών. Ωστόσο, αυτή η γραμμικότητα σπάνια συναντάται και απεικονίζει τις πραγματικές ανάγκες ανάπτυξης ενός έργου και ο προκαθορισμός των απαιτήσεων στερεύει κάθε δυνατότητα επαναπροσδιορισμού. Επιπρόσθετα, μεσολαβεί μεγάλο χρονικό διάστημα μέχρι την πρώτη παραδοτέα έκδοση του συστήματος και οι πελάτες καθυστερούν σημαντικά να λάβουν μια πρώτη εικόνα. Στα τέλη της δεκαετίας του 1980, ο Boehm πρότεινε τη χρήση του σπειροειδούς μοντέλου (Spiral Model) [2]. Στόχος, ήταν η παροχή ενός μοντέλου που θα λάμβανε σοβαρά υπόψη την αλληλεπίδραση με τον ανθρώπινο παράγοντα και την αναγνώριση των κινδύνων κατά την ανάπτυξη. Η υλοποίηση του έργου επιτυγχάνεται μέσω της υλοποίησης μιας σειράς υποέργων, συμπεριλαμβανομένης μιας ομάδας αρχετύπων. Παράλληλα, εμφανίστηκαν μεθοδολογίες με κύριο χαρακτηριστικό την επαναλαμβανόμενη ανάπτυξη λειτουργικών τμημάτων του έργου. Χαρακτηριστικά παραδείγματα, οι μέθοδοι evolutionary delivery [3] και rapid application development [4]. Σε αυτές, υπάρχει παραδοτέο λειτουργικό λογισμικό ανά τακτά χρονικά διαστήματα και ο πελάτης έχει τη δυνατότητα να παρακολουθεί την ανάπτυξη του συστήματος και να αλληλεπιδρά με την ομάδα ανάπτυξης. Σημαντική εξέλιξη αποτέλεσε και η εμφάνιση της μεθοδολογίας Rational Unified Process (RUP) [5], κατάλληλη για αντικειμενοστραφή ανάλυση και σχεδιασμό, με σημαντικό χαρακτηριστικό τη χρήση σεναρίων χρήσης, μέσω των οποίων προσεγγίζονταν οι απαιτήσεις του χρήστη. 6

7 Ωστόσο, η παραγωγή έργων λογισμικού παρέμεινε μια προβληματική προσπάθεια υψηλού ρίσκου. Συστατικά αυτής της προβληματικής προσπάθειας, οι σημαντικές υπερβάσεις σε προκαθορισμένα χρονοδιαγράμματα και οικονομικούς προϋπολογισμούς και οι αποκλίσεις όσον αφορά την τελική ποιότητα και την εξυπηρέτηση των πραγματικών αναγκών του πελάτη. Η αναφορά Chaos του Standish Group [6], αναφέρει ως κύριους παράγοντες αποκλίσεων και αποτυχιών τα ακόλουθα. Παράγοντας Έλλειψη δεδομένων από πλευράς χρήστη - πελάτη Παράγοντες αποκλίσεων Ποσοστό 12.8% Ελλιπείς απαιτήσεις και προδιαγραφές 12.3% Διαφοροποιήσεις απαιτήσεων και προδιαγραφών 11.8% Έλλειψη ανώτερης διοικητικής υποστήριξης 7.5% Τεχνολογικές ελλείψεις 7% Ελλείψεις πόρων 6.4% Μη ρεαλιστικές προσδοκίες 5.9% Ασαφείς στόχοι 5.3% Μη ρεαλιστικά χρονοδιαγράμματα 4.3% Χρήση νέας τεχνολογίας 3.7% Άλλο 23% Πίνακας 1. Κύριοι παράγοντες αποκλίσεων από τις επιθυμητές προδιαγραφές έργων [6] 7

8 Παράγοντας Παράγοντες ακυρώσεων Ποσοστό Ελλιπείς απαιτήσεις 13.1% Έλλειψη εμπλοκής χρήστη 12.4% Ελλείψεις πόρων 10.6% Μη ρεαλιστικές προσδοκίες 9.9% Έλλειψη ανώτερης διοικητικής υποστήριξης 9.3% Διαφοροποιήσεις απαιτήσεων και προδιαγραφών 8.7% Ελλιπής σχεδιασμός 8.1% Δεν ήταν πλέον χρήσιμο για τον πελάτη 7.5% Έλλειψη ΙΤ Manager 6.2% Έλλειψη τεχνολογικών γνώσεων 4.3% Άλλο 9.9% Πίνακας 2. Κύριοι παράγοντες ακυρώσεων έργων [6] 8

9 1.2 Ευέλικτες μεθοδολογίες (agile methods) Στις αρχές του 21ου αιώνα, μια νέα ομάδα μεθοδολογιών, γνωστές ως ευέλικτες μέθοδοι (Agile methods) [7], αναδύθηκαν στο προσκήνιο, με στόχο την επίλυση των προβληματικών καταστάσεων. Οι ευέλικτες μεθοδολογίες πρότειναν μια εντελώς νέα προσέγγιση στην ανάπτυξη έργων λογισμικού. Σε αυτήν τη νέα προσέγγιση, ο ανθρώπινος παράγοντας τοποθετείται στο επίκεντρο. Η φιλοσοφία τους, περιλαμβάνει επαναληπτική ανάπτυξη, με την παραγωγή μικρών εκδόσεων πλήρους λειτουργικότητας κάθε φορά, διαρκή και άμεση επικοινωνία με τους πελάτες και μελλοντικούς χρήστες, και πλήρη προσαρμοστικότητα, καθώς οι αλλαγές στις απαιτήσεις κατά την ανάπτυξη είναι αποδεκτές. Ο Jim Highsmith [8], υποστηρίζει πως αυτές οι μεθοδολογίες, ήρθαν να καλύψουν τις ανάγκες ενός ευμετάβλητου περιβάλλοντος ανάπτυξης λογισμικού. Οι ευέλικτες μέθοδοι είναι [9]: -Επαναληπτικές (iterative) Παραδίδεται αρχικά ένα πλήρες σύστημα, το οποίο αποτελείται από επιμέρους υποσυστήματα. Σε κάθε επόμενη έκδοση, γίνονται αλλαγές στη λειτουργία κάθε υποσυστήματος. -Αυξητικές (incremental) Σε κάθε νέα έκδοση, προστίθενται νέες λειτουργίες στις ήδη υπάρχουσες. -Προκύπτουσες (emergent) Οι αποφάσεις σχετικά με τις απαιτήσεις και την τεχνολογία που θα χρησιμοποιηθεί, λαμβάνονται κατά τη διάρκεια του κύκλου ανάπτυξης. -Αυτό-διοργανωμένες (self organizing) Η ομάδα έχει την ελευθερία της αυτό-οργάνωσης. Στο Manifesto for Agile Software Development [10], έργο 17 συγγραφέων του χώρου, περιγράφονται οι ακόλουθες βασικές αρχές αυτών των μεθοδολογιών: Ύψιστη προτεραιότητα είναι η ικανοποίηση του πελάτη. Γι αυτό το λόγο, λειτουργικά τμήματα του συστήματος θα πρέπει να παραδίδονται τακτικά, ώστε ο πελάτης να έχει επαφή με τη μορφή του υπό ανάπτυξη συστήματος και να μπορεί να τροφοδοτεί με παρατηρήσεις και ιδέες την ομάδα ανάπτυξης. 9

10 Οι αλλαγές στις απαιτήσεις είναι αποδεκτές σε οποιοδήποτε στάδιο της ανάπτυξης, ακόμη και στα τελικά στάδια. Στόχος, το ανταγωνιστικό πλεονέκτημα του πελάτη. Συχνά παραδοτέα τα οποία αποτελούνται από μικρά τμήματα λογισμικού. Η παράδοση γίνεται τακτικά, σε διαστήματα μερικών εβδομάδων ή μηνών, με προτίμηση στη συντομότερη χρονική κλίμακα. Καθημερινή συνεργασία ομάδας ανάπτυξης και πελατών, σε όλη τη διάρκεια ανάπτυξης του έργου. Είναι σημαντικό τα έργα να υλοποιούνται από άτομα με πάθος και ενδιαφέρον. Θα πρέπει να παρέχεται η αναγκαία υποστήριξη, η διαμόρφωση του κατάλληλου περιβάλλοντος και η εμπιστοσύνη στις δημιουργικές δυνάμεις του κάθε ατόμου ξεχωριστά. Η αποτελεσματικότερη μέθοδος μετάδοσης πληροφοριών προς και εντός της ομάδας ανάπτυξης, είναι η πρόσωπο με πρόσωπο συνομιλία. Το σημαντικότερο μέτρο προόδου του έργου, είναι το λογισμικό που λειτουργεί. Οι ευέλικτες διαδικασίες προάγουν την αειφόρο ανάπτυξη. Οι χορηγοί, η ομάδα ανάπτυξης λογισμικού και οι χρήστες θα πρέπει να είναι σε θέση να διατηρούν ένα σταθερό ρυθμό επ' αόριστον. Η τεχνική αρτιότητα και ο καλός σχεδιασμός αυξάνουν την ευελιξία. Η υλοποίηση γίνεται με απλό τρόπο είναι σημαντική παράμετρος η μεγιστοποίηση του όγκου των εργασιών που δεν είναι απαραίτητο να γίνουν. Η ομάδα θα πρέπει να αυτοοργανώνεται και σε τακτά χρονικά διαστήματα να αυτοαξιολογείται, ρυθμίζοντας και προσαρμόζοντας τη συμπεριφορά της αναλόγως, με κύριο στόχο την αύξηση της αποτελεσματικότητάς της. Βασικός στόχος των ευέλικτων μεθοδολογιών, είναι η τακτική παραγωγή λογισμικού -ακόμη και σε εβδομαδιαία βάση- το οποίο πρέπει να λειτουργεί. Για να καταστεί αυτό εφικτό, θα πρέπει να παράγεται όσο το δυνατόν απλούστερο λογισμικό, το οποίο απαιτεί μικρής έκτασης τεκμηρίωση. Η παράδοση εκτενών αναλυτικών τεχνικών εγγράφων, καταναλώνει αρκετό χρόνο και συνεπώς αυξάνει σημαντικά και το κόστος ανάπτυξης. Εξάλλου, η προσπάθεια εξαντλητικής τεκμηρίωσης ενός συστήματος το οποίο διαρκώς μεταβάλλεται, μοιάζει σαν μια προσπάθεια δίχως 10

11 ουσία. Η στόχευση λοιπόν στις ευέλικτες μεθοδολογίες αντιστοιχεί στην παραγωγή λογισμικού, με την τεκμηρίωση να περιορίζεται στο απαραίτητο μέγεθος, ώστε να υποστηρίζει την επικοινωνία και την καταγραφή ιστορικών πληροφοριών. Επιπλέον, ο ανθρώπινος παράγοντας τίθενται στο επίκεντρο και δίνεται το περιθώριο στα μέλη της ομάδας να αναπτύξουν ελεύθερα όλο το εύρος των δυνατοτήτων τους. Οι διαδικασίες και τα εργαλεία συνεχίζουν και υπάρχουν, ως δευτερεύοντες όμως παράγοντες, πίσω από τη σημασία της συνεργασίας και της δημιουργικότητας. Υποστηρικτικές πρακτικές αυτής της φιλοσοφίας, είναι ο προγραμματισμός σε ζεύγη (pair programming)[11], κατά την οποία δύο προγραμματιστές δουλεύουν μαζί γράφοντας κώδικα στον ίδιο υπολογιστή, η ύπαρξη μικρών ομάδων ανάπτυξης που συνεργάζονται σε κοινούς χώρους και η διαρκής ενεργή συμμετοχή του πελάτη. Η ύπαρξη συμβολαίων στις ευέλικτες μεθοδολογίες, έχει περισσότερο την έννοια της ανάπτυξης της εμπιστοσύνης και λιγότερο της νομικής κάλυψης. Τα συμβόλαια που θέτουν αυστηρούς όρους ως προς τα χρονοδιαγράμματα και το κόστος και προκαθορίζουν την απαιτούμενη λειτουργικότητα του υπό ανάπτυξη συστήματος, μειώνουν τη δυνατότητα ευελιξίας του έργου. Τα συμβαλλόμενα λοιπόν μέρη, θα πρέπει να κατανοήσουν ότι ένα σημαντικό μέρος της γνώσης σχετικά με το έργο, θα επέλθει κατά τη διαδικασία ανάπτυξης. Και αυτό συμβαίνει, είτε γιατί η ομάδα ανάπτυξης αποκτά περισσότερη εμπειρία καθώς το έργο προχωρά, είτε γιατί διαφοροποιούνται οι ανάγκες και οι απαιτήσεις των χρηστών, είτε γιατί μια σειρά τεχνολογικών εξελίξεων αναγκάζουν την ομάδα ανάπτυξης να τροποποιήσει την υλοποίηση του έργου. 1.3 Βιομηχανία λογισμικού και ευέλικτες μεθοδολογίες Στη βιομηχανία παραγωγής λογισμικού, υπάρχει μια διαρκώς αυξανόμενη χρήση και αποδοχή των ευέλικτων μεθόδων. Σε πρόσφατη έρευνα της HP με συμμετοχή 601 προγραμματιστών και επαγγελματιών της πληροφορικής[12], συμπεραίνεται ότι η πλειοψηφία αυτών χρησιμοποιεί πλέον τις ευέλικτες μεθοδολογίες. Στο ακόλουθο διάγραμμα καταγράφονται τα ποσοστά, σχετικά με την κύρια μέθοδο ανάπτυξης που χρησιμοποιούν οι συμμετέχοντες στην έρευνα. Στην πραγματικότητα, τα 2/3 περιγράφουν την εταιρεία στην οποία συμμετέχουν είτε ως pure agile είτε ως learning towards agile. 11

12 7% 24% 51% Learning towards agile Pure agile Pure waterfall Learning towards Waterfall Hybrid 2% 16% Εικόνα 1. Κύρια μέθοδος ανάπτυξης που χρησιμοποιείται στους οργανισμούς κατά την υλοποίηση έργων πληροφορικής [12]. Ταυτόχρονα, το σημαντικότερο ποσοστό από το 1/3 που δεν περιγράφει με αυτόν τον τρόπο την εταιρεία, δίνει το χαρακτηρισμό hybrid, πράγμα που σημαίνει ότι έχει ενσωματώσει κάποια χαρακτηριστικά των ευέλικτων μεθόδων στη διαχείριση των έργων ανάπτυξης λογισμικού. Παρόλο που οι ευέλικτες μεθοδολογίες εισήχθησαν εδώ και μία δεκαετία, οι περισσότεροι οργανισμοί που τις χρησιμοποιούν, τις υιοθέτησαν τα 5 τελευταία χρόνια [12]. Όπως φαίνεται και στο ακόλουθο διάγραμμα, τα πρώτα χρόνια υπήρχε μια αργή σταδιακή αποδοχή, με την απότομη επιτάχυνση να συμβαίνει από το 2009 και ύστερα. Η εξέλιξη αυτή εξηγείται μέσω της θεωρίας διάχυσης της καινοτομίας (Diffusion of Innovations theory), η οποία ερευνά το πως μια καινοτομία επιδρά σε έναν πληθυσμό [13]. 12

13 120% 100% 90% 100% 80% 67% 60% 40% 37% 46% 20% 4% 8% 8% 11% 13% 17% 0% Εικόνα 2. Αποδοχή ευέλικτων μεθοδολογιών ανά έτος Όπως είναι αναμενόμενο, η αποδοχή των ευέλικτων μεθοδολογιών στις νεώτερες ηλικίες προγραμματιστών και επαγγελματιών της πληροφορικής είναι πιο ευρεία. Ενδεικτικά, τα 3/4 της ηλικιακής ομάδας 24-34, χαρακτηρίζουν τη μεθοδολογία που χρησιμοποιούν είτε ως pure agile, είτε ως learning towards agile. Αυτό δε σημαίνει ότι η χρήση των ευέλικτων μεθοδολογιών περιορίζεται αυστηρά μεταξύ των νέων στελεχών, καθώς στην ηλικιακή ομάδα 50+, το αντίστοιχο αθροιστικό κλάσμα ισούται με 1/2 [12] yrs 22% Learning towards agile Pure agile 0% 5% 55% Pure waterfall Learning towards Waterfall 18% Hybrid Εικόνα 3. Μέθοδοι ανάπτυξης που χρησιμοποιούνται από την ηλικιακή ομάδα [12]. 13

14 35-49 yrs 24% Learning towards agile Pure agile 8% 50% Pure waterfall Learning towards Waterfall 2% 16% Hybrid Εικόνα 4. Μέθοδοι ανάπτυξης που χρησιμοποιούνται από την ηλικιακή ομάδα [12]. 50+ yrs 36% 41% Learning towards agile Pure agile Pure waterfall Learning towards Waterfall 11% 4% 8% Hybrid Εικόνα 5. Μέθοδοι ανάπτυξης που χρησιμοποιούνται από την ηλικιακή ομάδα [12]. Όσον αφορά τα κίνητρα για την αποδοχή των ευέλικτων μεθοδολογιών, οι συμμετέχοντες στην έρευνα ερωτήθηκαν ως προς τις θετικές συνέπειες που επέφερε η χρήση τους. Ως κύριες θετικές συνέπειες, καταγράφονται η βελτίωση της συνεργασίας της ομάδας, η αύξηση της ποιότητας του λογισμικού και η ικανοποίηση των πελατών [12]. 14

15 60% 50% 40% 30% 20% 10% 0% Ενίσχυση της συνεργασίας μεταξύ των μελών της ομάδας Αύξηση της ποιότητας του λογισμικού Αύξηση της ικανοποίησης των πελατών Συντομότερος χρόνος υλοποίησης Μείωση κόστους ανάπτυξης Εικόνα 6. Θετικές συνέπειες από τη χρήση ευέλικτων μεθοδολογιών [12]. 1.4 Οι σημαντικότερες ευέλικτες μέθοδοι Υπάρχει μια πλειάδα μεθόδων, των οποίων η φιλοσοφία που ακολουθούν στην αντιμετώπιση ενός έργου πληροφορικής, τις κατατάσσει στην ομάδα των ευέλικτων μεθοδολογιών. Οι κυριότερες ευέλικτες μεθοδολογίες κατά αύξουσα αλφαβητική σειρά είναι οι εξής: Adaptive software development Ο Jim Highsmith, εμπνεόμενος από τη θεωρία Complex Adaptive Systems (CAS theory [14]) και από μια προσομοίωση του Craig Reynolds με την ονομασία Boids [15], σχετικά με το συντονισμό των κινήσεων που λαμβάνει χώρα σε ένα σμήνος πουλιών, κι έχοντας ως στόχο την αντιμετώπιση της διαρκώς αυξανόμενης πολυπλοκότητας του παραγόμενου λογισμικού, πρότεινε τη μέθοδο ανάπτυξης λογισμικού Adaptive software development (ASD), η οποία ενσαρκώνει την αρχή ότι η συνεχής προσαρμογή των διαδικασιών είναι μία φυσιολογική κατάσταση [16]. Στη μέθοδο ASD, τροποποιείται ο κύκλος ζωής του μοντέλου του καταρράκτη ο οποίος χαρακτηρίζεται από τη γραμμικότητα και την προβλεψιμότητα, με έναν κύκλο ο οποίος αντανακλά την απρόβλεπτη φύση των πολύπλοκων συστημάτων [16]. 15

16 Εικόνα 7. Ο κύκλος ζωής στη μέθοδο ASD [17]. Το επίκεντρο στη μέθοδο ASD βρίσκεται στην ανάπτυξη κώδικα. Έχοντας μια βασική ιδέα σχετικά με το υπό ανάπτυξη σύστημα, ξεκινά η παραγωγή κώδικα. Είναι σχεδόν σίγουρο ότι αυτή η αρχική προσέγγιση θα χρειαστεί πολλαπλές προσαρμογές και αυτό συμβαίνει κάθε φορά που απαιτείται στους πολλαπλούς επαναληπτικούς κύκλους ανάπτυξης. Στη φάση Speculate, γίνεται μια αδρή περιγραφή του έργου: ποιοι είναι οι στόχοι, ποιες οι αρχικές εκτιμήσεις της διάρκειάς του, ποιοι είναι οι πιθανοί κίνδυνοι. Γίνεται επίσης προσπάθεια να προσεγγιστεί ο βέλτιστος αριθμός επαναλήψεων στις οποίες αναμένεται να ολοκληρωθεί το έργο, καθώς και ο καθορισμός των αντικειμενικών στόχων κάθε επανάληψης. Στη φάση Collaborate, αναπτύσσονται παράλληλα πολλαπλά συστατικά του έργου. Εάν κάποιο συστατικό δεν ολοκληρωθεί στα πλαίσια της τρέχουσας επανάληψης, μεταφέρεται σε επόμενο κύκλο. Στη φάση Learn, γίνεται ανασκόπηση της ποιότητας των παραγόμενων. Στην αξιολόγηση ενεργό ρόλο διαδραματίζει ο πελάτης, ο οποίος εκφράζει το βαθμό ικανοποίησής του. Επίσης, επιθεωρείται το παραγόμενο λογισμικό, ως προς πιθανά τεχνικά προβλήματα. Τέλος, τα μέλη της ομάδας ανάπτυξης αυτοαξιολογούνται, ως προς τις διαδικασίες που ακολούθησαν και ως προς την πρόοδο του έργου σε σχέση με τον αρχικό προγραμματισμό. Η παραγόμενη γνώση, επηρεάζει το σχεδιασμό της επόμενης επανάληψης. 16

17 1.4.2 Crystal Family Οικονομικό Πανεπιστήμιο Αθηνών, Π.Μ.Σ Πληροφοριακά Συστήματα Περιλαμβάνει μια ομάδα μεθόδων, οι οποίες σχεδιάστηκαν από τον Alistair Cockburn στα μέσα της δεκαετίας του 1990 [18]. Από αυτήν την ομάδα, επιλέγεται κάθε φορά η κατάλληλη μέθοδος, ανάλογα με τα χαρακτηριστικά και τις απαιτήσεις του έργου. Κάθε μέλος της ομάδας, χαρακτηρίζεται από ένα χρώμα, το οποίο ορίζει την αυστηρότητα της μεθοδολογίας (όσο σκουρότερο το χρώμα, τόσο πιο αυστηρή είναι η μεθοδολογία). Η επιλογή, εξαρτάται από το μέγεθος και την κρισιμότητα του έργου. Εικόνα 8. Η χρωματική απεικόνιση των μεθόδων μελών της ομάδας Crystal family[18]. Η κρισιμότητα ενός έργου, είναι συνδεδεμένη με τις πιθανές επιπτώσεις που θα έχει η αποτυχημένη λειτουργία του συστήματος στο χρήστη. Ο βαθμός κρισιμότητας καθορίζεται από τα αρχικά: C (Comfort): πιθανές επιπτώσεις στην άνεση του χρήστη. D (Discretionary money): πιθανή απώλεια ενός όχι σημαντικού χρηματικού ποσού. E (Essential Money): πιθανή απώλεια σημαντικού χρηματικού ποσού. L (Life): πιθανός σοβαρός κίνδυνος για τη ζωή του χρήστη. Οι αριθμοί, δείχνουν το μέγεθος του έργου, σε όρους αριθμού προγραμματιστών που συμμετέχουν στην υλοποίηση του έργου. Η ονομασία μιας μεθόδου προκύπτει από το βαθμό κρισιμότητας και από το μέγεθος του έργου. Για παράδειγμα, η μέθοδος Ε20, θα επιλεχθεί για ένα έργο, στην υλοποίηση του οποίου συμμετέχουν 20 προγραμματιστές και πιθανή αποτυχημένη λειτουργία του οποίου, πιθανώς να επιφέρει την απώλεια σημαντικού χρηματικού ποσού. 17

18 Κοινά χαρακτηριστικά μεταξύ των μεθόδων της ομάδας, είναι η υλοποίηση μέσω επαναληπτικών κύκλων με μέγιστη χρονική διάρκεια τους 4 μήνες, η έμφαση στη συνεργασία και στην επικοινωνία μεταξύ των μελών της ομάδας έργου και του πελάτη, και η ευχέρεια στη χρήση πρακτικών και μεθόδων που χρησιμοποιούνται σε άλλες ευέλικτες μεθοδολογίες Dynamic Systems Development Method (DSDM) Η μέθοδος DSDM, εμφανίστηκε για πρώτη φορά στο Ηνωμένο Βασίλειο στα μέσα της δεκαετίας του 1990 [19]. Η κεντρική φιλοσοφία, αφορά την ευθυγράμμιση του έργου με συγκεκριμένους στρατηγικούς στόχους και τη σημασία της έγκαιρης παράδοσης στον πελάτη [20]. Αντί λοιπόν να ορίζεται το σύνολο των λειτουργιών και στη συνέχεια να προσαρμόζεται ο χρόνος και οι πόροι για την επίτευξή τους, ορίζονται αρχικά ο χρόνος και οι πόροι και έπειτα η ποσότητα λειτουργιών που μπορεί να υλοποιηθούν με βάση αυτά. Η DSDM αποτελείται από 5 φάσεις [21]. Εικόνα 9. Οι φάσεις ανάπτυξης κατά την DSDM [21] Οι δύο πρώτες φάσεις, εκτελούνται σειριακά και από μία φορά η κάθε μία. Οι υπόλοιπες, είναι επαναληπτικές και αυξητικές. Οι επαναλήψεις, εντάσσονται μέσα σε αυστηρά χρονικά περιθώρια, μέσα στα οποία η επανάληψη επιβάλλεται να ολοκληρωθεί. Κάθε επανάληψη, μπορεί να διαρκέσει από λίγες μέρες έως και μερικές εβδομάδες. 18

19 Feasibility Σε αυτήν την αρχική φάση, λαμβάνεται η απόφαση σχετικά με το εάν χρησιμοποιηθεί η μέθοδος για την ανάπτυξη του έργου. Η απόφαση, λαμβάνει υπόψη το είδος του έργου, τυχόν χρονικά περιθώρια και τους ανθρώπινους πόρους. Εάν αποφασιστεί η χρήση της μεθόδου, παράγονται μια έκθεση σκοπιμότητας και ένα σχέδιο ανάπτυξης. Business study Σκοπός της φάσης αυτής, είναι η κατανόηση του έργου και η ανάλυση των βασικών χαρακτηριστικών και της τεχνολογίας που θα χρησιμοποιηθεί. Τα βασικά παράγωγα είναι ο καθορισμός της αρχιτεκτονικής του συστήματος και η παραγωγή πρότυπου σχεδίου. Functional model iteration Πρόκειται για την πρώτη βηματική και επαναληπτική φάση. Περιλαμβάνει τα στάδια της ανάλυσης, της κωδικοποίησης και της προτυποποίησης. Η ανάλυση αφορά το σχεδιασμό και την προσέγγιση της τρέχουσας επανάληψης, η κωδικοποίηση τη συγγραφή λειτουργικού κώδικα και η προτυποποίηση τη δημιουργία βελτιωμένου προτύπου, βάση της τεχνογνωσίας που έχει αποκτηθεί. Design and build iteration Είναι η φάση κατασκευής του συστήματος. Κατά τη φάση αυτή λαμβάνονται υπόψη τα σχόλια του πελάτη και των χρηστών ως προς το πρότυπο. Το τελικό παραδοτέο της φάσης, είναι ένα ελεγμένο και ολοκληρωμένο σύστημα, το οποίο έχει λάβει υπόψη τα σχόλια αυτά και ικανοποιεί τις λειτουργικές απαιτήσεις. Implementation Το σύστημα τίθεται σε λειτουργία στο πραγματικό του περιβάλλον. Στη συγκεκριμένη φάση περιλαμβάνονται η εκπαίδευση των χρηστών, η παράδοση των εγχειριδίων χρήσης και μία έκθεση ανασκόπησης του έργου. Εάν κριθεί ότι ένα σημαντικό μέρος των απαιτήσεων δεν ικανοποιήθηκε, τότε η διαδικασία ανάπτυξης των 5 φάσεων πρέπει να εκτελεστεί ξανά. 19

20 1.4.4 Extreme Programming (XP) Ο ακραίος προγραμματισμός (Extreme Programming, XP) παρουσιάστηκε από τον Kent Beck το 1999 [22]. Βασίζεται σε μια σειρά αρχών, που έχουν ως στόχο την όσο το δυνατόν ταχύτερη ολοκλήρωση του έργου σε μικρούς επαναληπτικούς κύκλους και την αποτελεσματική αποδοχή αλλαγών σε όλα τα στάδια ανάπτυξης. Η αποδοχή των αρχών σε απόλυτο ακραίο βαθμό, προσδίδει και το συνθετικό extreme στην ονομασία της μεθόδου. Οι αρχές αυτές είναι: -Επικοινωνία (Communication) Η αντιμετώπιση των προβλημάτων απαιτεί υψηλό επίπεδο επικοινωνίας. Εξάλλου, τα περισσότερα προβλήματα κατά τη διαδικασία υλοποίησης ενός έργου, προκύπτουν από την έλλειψη ικανοποιητικού επιπέδου επικοινωνίας, είτε μεταξύ των μελών της ομάδας ανάπτυξης, είτε μεταξύ της ομάδας και του πελάτη. -Απλότητα (Simplicity) Όταν ο κώδικας είναι απλός, είναι περισσότερο κατανοητός, και απαιτεί μικρότερο όγκο τεκμηρίωσης. Επίσης, η τήρηση της απλότητας σε όλα τα στάδια ανάπτυξης του έργου, επιτρέπει την ευελιξία σε τυχόν αλλαγές, την ταχύτητα ανάπτυξης και την απλοποίηση κατά τη μελλοντική διαδικασία συντήρησης και υποστήριξης του έργου. -Ανατροφοδότηση (Feedback) Μέσω της τακτικής παράδοσης τμημάτων του έργου στον πελάτη, λαμβάνεται η απαραίτητη πληροφορία ώστε να αντιμετωπιστούν εγκαίρως προβλήματα ως προς την ικανοποίηση των απαιτήσεων. -Θάρρος (Courage) Το θάρρος και η καλή ψυχολογία που πηγάζει από αυτό, είναι σημαντικοί παράγοντες ώστε να λαμβάνονται γρήγορα αποφάσεις και η ομάδα να ανακτά την απαραίτητη αυτοπεποίθηση μετά από αποτυχημένες προσπάθειες. -Σεβασμός Απαραίτητη προϋπόθεση, ο σεβασμός και η αλληλοεκτίμηση μεταξύ των μελών της ομάδας. Η ισότιμη μεταχείριση προς όλους και η ισότιμη συμμετοχή στην ανάπτυξη, απελευθερώνει τις ατομικές δυνατότητες, και συνεπώς δρα θετικά στο άθροισμα δυνατοτήτων του όλου. 20

21 Διαδικασία ανάπτυξης στον ακραίο προγραμματισμό Στον κύκλο ζωής της μεθόδου XP περιλαμβάνονται οι ακόλουθες φάσεις [23]: Φάση διερεύνησης Πρόκειται για την αρχική προσέγγιση, όσον αφορά τις απαιτήσεις του χρήστη και την πρώτη μορφή της αρχιτεκτονικής του συστήματος. Ως προς τη μοντελοποίηση των απαιτήσεων, στην XP χρησιμοποιείται η έννοια των ιστοριών χρήστη (user stories), στις οποίες ο χρήστης περιγράφει την επιθυμητή λειτουργικότητα της πρώτης μορφής του έργου υπό μορφή γραπτού κειμένου. Η ομάδα του έργου προσεγγίζει τα εργαλεία και τις τεχνολογίες που θα χρησιμοποιήσει για την υλοποίηση. Αυτή η προσέγγιση δεν είναι στατική, αλλά έχει έντονο δυναμικό χαρακτήρα και μπορεί να τροποποιηθεί κάθε φορά που θα υπάρξει λόγος. Σε κάποιες περιπτώσεις, αυτά τα εργαλεία και οι τεχνολογίες μπορούν να δοκιμαστούν με τη δημιουργία ενός αρχετύπου, το οποίο περιλαμβάνει μικρής έκτασης λειτουργικότητα. Η φάση της διερεύνησης, μπορεί να διαρκέσει από μερικές εβδομάδες έως και λίγους μήνες. Είναι κάτι το οποίο εξαρτάται από την έκταση του έργου και την εξοικείωση της ομάδας με παρόμοια εργαλεία και τεχνολογίες. Φάση προγραμματισμού Σε άμεση συνεργασία με τον πελάτη, τίθεται σειρά προτεραιότητας στις ιστορίες χρήστη. Επίσης, αποφασίζεται το τι θα περιέχει η πρώτη έκδοση του συστήματος, καθώς και η ημερομηνία παράδοσής της. Για να αποφασιστεί η προτεραιότητα, κάθε ιστορία χρήστη, χωρίζεται σε επιμέρους εργασίες που θα πρέπει να γίνουν ώστε να ολοκληρωθεί. Κάθε επιμέρους εργασία εκτιμάται ως προς το χρόνο που θα χρειαστεί και ακολούθως γίνεται αντίστοιχη χρονική εκτίμηση για την κάθε ιστορία χρήστη. Έχοντας συγκεκριμενοποιήσει την επιθυμητή ημερομηνία παράδοσης της πρώτης έκδοσης, την υφή και σημασία των ιστοριών χρήστη και την χρονική εκτίμηση της κάθε μιας, συναποφασίζεται το τι θα περιέχει η πρώτη έκδοση. Φάση επαναλήψεων Η πρώτη έκδοση του συστήματος υλοποιείται μέσω μιας σειράς επαναλήψεων. Στην αρχή της κάθε επανάληψης, πάντα με τη συμμετοχή του πελάτη, αποφασίζεται το τι θα υλοποιηθεί. Οι λειτουργικότητες που προκύπτουν σε κάθε επανάληψη προστίθενται στις προηγούμενες. Κάθε επανάληψη, εμπεριέχει τις έννοιες της ανάλυσης, του σχεδιασμού, του προγραμματισμού και της δοκιμής και διαρκεί από μία έως τέσσερεις εβδομάδες. 21

22 Φάση προϊοντοποίησης Οικονομικό Πανεπιστήμιο Αθηνών, Π.Μ.Σ Πληροφοριακά Συστήματα Αντιστοιχεί σε όλους τους ελέγχους, ώστε να διασφαλιστεί ότι το παραγόμενο είναι έτοιμο για παράδοση στον πελάτη. Η προσπάθεια σε αυτήν τη φάση αφορά κυρίως την τεχνική τελειοποίηση και όχι την αύξηση της λειτουργικότητας. Τυχόν ένδειξη για απαιτούμενη αύξηση της λειτουργικότητας αφήνεται συνήθως προς υλοποίηση σε επόμενη έκδοση. Η έννοια των επαναλήψεων συναντάται και στη φάση της προϊοντοποίησης. Φάση συντήρησης Αφορά την αντιμετώπιση τυχόν προβλημάτων καθώς και τις ανάγκες για νέες εκδόσεις του συστήματος. Αν απαιτείται νέα έκδοση του συστήματος, η φάση της συντήρησης περιλαμβάνει τις τέσσερεις προηγούμενες φάσεις. 22

23 Ακολουθεί μια σχηματική αναπαράσταση της διαδικασίας ανάπτυξης στον ακραίο προγραμματισμό. Φάση διερεύνησης Φάση προγ/σμου Φάση επαναλήψεων Φάση πρ/ποίησης Φάση συντήρησης Εικόνα 10. Σχηματική αναπαράσταση της διαδικασίας ανάπτυξης στον ακραίο προγραμματισμό Ρόλοι και υπευθυνότητες στον ακραίο προγραμματισμό Ο Beck [22], καθορίζει τους ρόλους και τις αντίστοιχες υπευθυνότητες στα πλαίσια του ακραίου προγραμματισμού. Προγραμματιστής (programmer) Γράφει τόσο λειτουργικό κώδικα, όσο και κώδικα ελέγχου. Η προσπάθεια του έγκειται στη συγγραφή όσο το δυνατόν απλούστερου κώδικα και στη διαρκή διάθεση συνεργασίας. Πελάτης (customer) Συγγράφει τις ιστορίες χρήστη, αποφασίζει την προτεραιότητα και καθορίζει το εάν μία απαίτηση έχει ικανοποιηθεί. 23

24 Ελεγκτής (tester) απαιτήσεων. Οικονομικό Πανεπιστήμιο Αθηνών, Π.Μ.Σ Πληροφοριακά Συστήματα Εκτελεί τακτικά ελέγχους και βοηθά τον πελάτη ως προς τον έλεγχο ικανοποίησης των Καταγραφέας (tracker) Καταγράφει στοιχεία που έχουν να κάνουν με τις αρχικές εκτιμήσεις και την πρόοδο που επιτυγχάνεται. Επίσης, στηριζόμενος στην καταγραφή της προόδου, εκτιμά αν είναι εφικτοί οι αρχικοί στόχοι. Καθοδηγητής (Coach) Για το ρόλο επιλέγεται άτομο έμπειρο στις μεθοδολογίες και τις πρακτικές του ακραίου προγραμματισμού, καθώς ο κύριος ρόλος του είναι η καθοδήγηση ώστε να τηρούνται αυτές οι πρακτικές. Διευθυντής (manager) Λαμβάνει τις αποφάσεις. Για τη λήψη σωστών αποφάσεων, είναι απαραίτητη η συνεχής επικοινωνία με τα υπόλοιπα μέλη ώστε να έχει κατά νου τυχόν δυσκολίες και προβλήματα Πρακτικές ακραίου προγραμματισμού [22]: Σε όλες τις φάσεις ανάπτυξης στην XP μέθοδο, ακολουθούνται οι εξής βασικές πρακτικές Το παιχνίδι του σχεδιασμού (planning game) Αντιστοιχεί στις συναντήσεις μεταξύ πελάτη και ομάδας ανάπτυξης, στις οποίες καταγράφονται οι ιστορίες χρήστη, αποφασίζεται η προτεραιότητα μεταξύ αυτών, γίνεται μια εκτίμηση της χρονικής διάρκειας που απαιτεί κάθε μια, και τέλος αποφασίζεται το τι θα περιλαμβάνει η επικείμενη έκδοση του συστήματος. Προγραμματισμός σε ζεύγη (pair programming) Όπως προειπώθηκε, αντιστοιχεί στην πρακτική του να παράγεται κώδικας από δύο προγραμματιστές που κάθονται μαζί στον ίδιο υπολογιστή. Ο ρόλος του ενός είναι να γράφει κώδικα και του άλλου να αξιολογεί και να επανεξετάζει τη δομή. Οι ρόλοι μεταξύ των δύο εναλλάσσονται. 24

25 Έλεγχοι πριν την κωδικοποίηση (test-first-design) Πριν την ανάπτυξη του οποιουδήποτε προγραμματιστικού τμήματος, σχεδιάζεται και υλοποιείται το τμήμα που θα το ελέγξει. Οι έλεγχοι γίνονται συνήθως με τη χρήση αυτοματοποιημένων εργαλείων. Πρότυπα κωδικοποίησης (coding standards) Τηρούνται προγραμματιστικά πρότυπα, τα οποία προσδίδουν ταχύτητα ανάπτυξης και βοηθούν στην επικοινωνία μεταξύ των μελών της ομάδας. Απλός σχεδιασμός (simple design) Η απλοποιημένη προσέγγιση βοηθά στην ταχύτητα παραγωγής και στην ευελιξία ως προς τυχόν μελλοντικές τροποποιήσεις. Ανακατασκευή (refactoring) Ο κώδικας είναι υπό διαρκή επανεξέταση. Αν παρατηρηθεί προβληματική συμπεριφορά ή θεωρηθεί ότι μπορεί να απλοποιηθεί περαιτέρω, ανακατασκευάζεται. Διαρκείς ενσωματώσεις (continuous integration) Οποιαδήποτε χρονική στιγμή, οι αλλαγές θα πρέπει να υλοποιούνται, να ενσωματώνονται και να ελέγχονται. Αν παρατηρηθεί ότι υποβιβάζουν τη συνοχή και ποιότητα του όλου, είτε τροποποιούνται είτε απορρίπτονται. Συλλογική ιδιοκτησία του κώδικα (collective code ownership) Υπό πνεύμα ισότιμης συμμετοχής και ολοκληρωτικής συνεργασίας, κάθε μέλος έχει το δικαίωμα να τροποποιήσει τμήμα του κώδικα. Διαρκής παρουσία πελάτη (on-site customer) Είναι σημαντικό το να μην υλοποιηθεί οτιδήποτε, δίχως την ενεργή συμμετοχή του πελάτη. Ο πελάτης θα πρέπει να είναι διαθέσιμος και να μπορεί να επιλύσει οποτεδήποτε χρειαστεί απορίες που έχουν μέλη της ομάδας ανάπτυξης. Μικρές εκδόσεις (small releases) Λειτουργικά συστήματα του κώδικα παραδίδονται τακτικά. Ο σκοπός είναι να αποφευχθεί ο κίνδυνος να προχωρήσει αρκετά η υλοποίηση ενός συστήματος σε λάθος προσανατολισμό. 25

26 Υποφερτός ρυθμός εργασίας (sustainable pace) Η ύπαρξη αναγκαστικών υπερωριών, θεωρείται σημάδι λανθασμένου σχεδιασμού και αρχικών εκτιμήσεων. Συμβολισμός συστήματος (system metaphor) Το σύστημα προσεγγίζεται αφαιρετικά με τη βοήθεια ενός συνόλου συμβολισμών το οποίο επιλέγεται συνεργατικά. Απλοί κανόνες (just rules) Ως προς τη συνεργασία της ομάδας, λειτουργεί υποβοηθητικά ένα σύνολο κανόνων που η ίδια ομάδα έχει αποφασίσει και αποδεχθεί. Σε καμία περίπτωση αυτό το σύνολο δεν είναι στατικό. Κοινός χώρος εργασίας (common workspace) Η φιλοσοφία του ακραίου προγραμματισμού απαιτεί υψηλό επίπεδο επικοινωνίας, κάτι το οποίο πραγματώνεται σε κοινό χώρο εργασίας. Στον ίδιο χώρο γίνονται και οι τακτικές συναντήσεις με τον πελάτη. 26

27 1.4.5 Feature-driven development (FDD) Η μέθοδος FDD αναφέρθηκε για πρώτη φορά από τον Peter Coad [24] και αναπτύχθηκε από τους Felsing και Palmer [25]. H FDD επικεντρώνεται στις φάσεις σχεδιασμού και κατασκευής, υποστηρίζει την επαναληπτική και αυξητική ανάπτυξη, δίνει ιδιαίτερη βαρύτητα σε θέματα ποιότητας και περιλαμβάνει διαρκείς ελέγχους της προόδου ως προς την εξέλιξη του έργου. Η μέθοδος FDD περιλαμβάνει 5 κύριες δραστηριότητες, οι οποίες εκτελούνται επαναληπτικά [26]. Εικόνα 11. Οι 5 δραστηριότητες που περιλαμβάνει η μέθοδος FDD [25]. Develop an overall model [27] Η φάση ξεκινά με την απόκτηση της απαραίτητης γνώσης -όσον αφορά τις απαιτήσεις του προς ανάπτυξη συστήματος- από την ομάδα ατόμων με το χαρακτηριστικό τίτλο domain experts. Στη συνέχεια η ομάδα αυτή αναλαμβάνει να παρουσιάσει στα μέλη ανάπτυξης του έργου τη γενική απεικόνιση του υπό ανάπτυξη συστήματος. Ακολουθεί η διάσπαση της γενικής απεικόνισης σε επιμέρους τομείς γνωστικών περιοχών. Κάθε επιμέρους τομέα αναλαμβάνει ειδική ομάδα η οποία φροντίζει για την παραγωγή ενός μοντέλου αντικειμένων. Τελικός στόχος, είναι η συνένωση των μοντέλων αντικειμένων των επιμέρους ομάδων, για την κατασκευή του γενικότερου μοντέλου του συνολικού συστήματος. 27

28 Build a features list [27] Οικονομικό Πανεπιστήμιο Αθηνών, Π.Μ.Σ Πληροφοριακά Συστήματα Σκοπός της συγκεκριμένης φάσης, είναι η λεπτομερής καταγραφή των χαρακτηριστικών του υπό ανάπτυξη συστήματος. Τα χαρακτηριστικά αυτά διαμερίζονται στους επιμέρους τομείς γνωστικών περιοχών που έχουν προκύψει από την προηγούμενη φάση. Η λίστα των χαρακτηριστικών, αξιολογείται, εμπλουτίζεται και τροποποιείται, σύμφωνα με τις απόψεις του πελάτη και των χρηστών. Plan by feature [27] Οι ομάδες χαρακτηριστικών που έχουν προκύψει από την προηγούμενη φάση, τίθενται σε σειρά προτεραιότητας ανάλογα με τη σημαντικότητά τους και τις αλληλεξαρτήσεις. Κατόπιν, δίνονται στους επικεφαλείς των ομάδων προγραμματιστών και καθορίζονται βασικά χρονικά ορόσημα ως προς την υλοποίησή τους. Design by feature και Build by feature[27] Η υλοποίηση των χαρακτηριστικών γίνεται επαναληπτικά, με κάθε επανάληψη να διαρκεί έως και 2 εβδομάδες. Η υλοποίηση γίνεται παράλληλα, με κάθε επιμέρους ομάδα ανάπτυξης να υλοποιεί το δικό της σύνολο χαρακτηριστικών. Σε αυτές της φάσεις περιλαμβάνονται και οι εργασίες του ελέγχου και της ενσωμάτωσης στο συνολικό σύστημα Lean software development (LSD) Η μέθοδος LSD, είναι η εφαρμογή των αρχών του συστήματος παραγωγής της Toyota στην ανάπτυξη λογισμικού [28]. Η μέθοδος εξετάζει την ιδιαίτερα επιτυχημένη ανάπτυξη της Toyota, με κύριο χαρακτηριστικό επιτυχίας την παραγωγή νέων μοντέλων σε πολύ σύντομα χρονικά διαστήματα, και προσπαθεί να την προσαρμόσει στην διαδικασία παραγωγής λογισμικού. Η LSD προτείνει επτά αρχές, που πρέπει να ακολουθούνται κατά την ανάπτυξη του λογισμικού [28]: Eliminate Waste Σπατάλη, είναι το οτιδήποτε δεν προσθέτει αξία στο παραγόμενο προϊόν, με την έννοια τις αξίας να είναι άμεσα συνυφασμένη με τις απαιτήσεις του χρήστη. Συνεπώς, η μέθοδος κρίνει ως ιδιαίτερα σημαντική τη διαδικασία ακριβούς καθορισμού των απαιτήσεων του πελάτη. 28

29 Build Quality In Οικονομικό Πανεπιστήμιο Αθηνών, Π.Μ.Σ Πληροφοριακά Συστήματα Η έννοια της ποιότητας έχει να κάνει με τη διαχρονική αξία του παραγόμενου προϊόντος. Για να επιτευχθεί αυτό, θα πρέπει το λογισμικό να διαθέτει ευχρηστία και να είναι προσαρμόσιμο και επεκτάσιμο. Create Knowledge Η αρχή τονίζει την αξία της γνώσης. Η γνώση ενισχύεται μέσω τεχνικών ελέγχων και συχνής επικοινωνίας με τον πελάτη. Η προστιθέμενη γνώση, βελτιώνει τα παραγόμενα, μέσα από σύντομους επαναληπτικούς κύκλους ανάπτυξης, μέσω των οποίων τα παραγόμενα ανακατασκευάζονται κάθε φορά που απαιτείται. Defer Commitment Σε έργα με υψηλό επίπεδο απροσδιοριστίας, είναι καλή πρακτική το να λαμβάνονται οι σημαντικές αποφάσεις όσο το δυνατόν πιο αργά. Αυτό έχει ως αποτέλεσμα οι αποφάσεις να βασίζονται σε γεγονότα και προστιθέμενη γνώση, και όχι σε προβλέψεις και εικασίες. Deliver Fast Όσο γρηγορότερα τελειώνει μια επανάληψη και παραδίδονται τμήματα του έργου στον πελάτη, τόσο γρηγορότερα λαμβάνεται η ανάδραση από αυτόν. Αυτό έχει ως συνέπεια την αύξηση της γνώσης σχετικά με τις απαιτήσεις του έργου και τη βελτιωμένη ανακατασκευή όπου απαιτείται. Respect People Έχει ιδιαίτερη σημασία το να υπάρχει σεβασμός στις ιδέες, τις απόψεις και τις δημιουργικές δυνάμεις κάθε ενός από τα μέλη της ομάδας παραγωγής. Τα στελέχη αυτά, έχουν την απαραίτητη εξειδίκευση και γνώση μέσω της καθημερινής επαφής με την ανάπτυξη του έργου, ώστε να λάβουν σωστές αποφάσεις σε σύντομο χρόνο. Optimize the Whole Πολλές φορές, σε σύνθετα έργα πολύπλοκης δομής, ο εντοπισμός της προσοχής σε ένα εξειδικευμένο τμήμα του όλου (για παράδειγμα, στο σχεδιασμό της βάσης δεδομένων) δρα αρνητικά στη συνολική αρτιότητα του συστήματος. Συνεπώς, θα πρέπει κάθε απόφαση σχετικά με την υλοποίηση του κάθε τμήματος, να γίνεται με σκοπό τη βελτίωση της συνολικής λειτουργία του συστήματος, ώστε να αποφευχθεί ο κίνδυνος να παραχθεί ένα προϊόν με επιμέρους τμήματα 29

30 υψηλής ποιότητας, τα οποία όμως δε συνεργάζονται άρτια μεταξύ τους, με συνέπεια τη μέτρια λειτουργία του συνολικού συστήματος Μέθοδος Scrum Η ύπαρξη της μεθόδου, οφείλεται σε ένα άρθρο των Nonaka και Takeuchi [29], όπου πραγματεύονταν την αύξηση της ταχύτητας και της ευελιξίας στην ανάπτυξη εμπορικών προϊόντων. Το 2001, στο βιβλίο με τίτλο Agile Software Development with Scrum, οι Schwaber και Beedle περιέγραψαν αναλυτικά τη μέθοδο. Πρόκειται για μια μέθοδο, η οποία δεν ορίζει κάποια συγκεκριμένη στρατηγική για τη φάση υλοποίησης. Αντιθέτως, δίνει έμφαση στο πως θα πρέπει να λειτουργήσει η ομάδα, ώστε να κατορθώσει την παραγωγή ενός επιτυχημένου προϊόντος, λαμβάνοντας υπόψη την ύπαρξη ενός διαρκώς μεταβαλλόμενου περιβάλλοντος Διαδικασία ανάπτυξης στην Scrum Ο κύκλος ζωής στην Scrum αποτελείται από τις εξής φάσεις [31]: Φάση αρχικής διερεύνησης Χωρίζεται σε δύο υπο-φάσεις: στον προγραμματισμό και στο σχεδιασμό υψηλού επιπέδου. Κατά τον προγραμματισμό, δημιουργείται η λίστα εκκρεμοτήτων προϊόντος (backlog list), στην οποία περιλαμβάνονται όλες οι εντοπισμένες έως εκείνο το σημείο απαιτήσεις του συστήματος. Οι απαιτήσεις αυτές, προέρχονται τόσο από τον πελάτη, όσο και από την ομάδα ανάπτυξης. Οι απαιτήσεις αυτές τίθενται σε σειρά προτεραιότητας και εκτιμάται η προσπάθεια που απαιτείται για την υλοποίησή τους, σε όρους συνήθως ανθρωποημερών (staff days). Η backlog list, ενημερώνεται και επικαιροποιείται τακτικά. Ταυτόχρονα, λαμβάνονται αποφάσεις σχετικά με τη δομή της ομάδας ανάπτυξης, αποφασίζονται τα εργαλεία και οι πόροι που θα χρησιμοποιηθούν και εκτιμώνται οι πιθανοί κίνδυνοι που ίσως προκύψουν. Στην υπο-φάση του σχεδιασμού υψηλού επιπέδου, αφαιρετικά προσεγγίζεται το όλο σύστημα, λαμβάνονται αποφάσεις σχετικά με την αρχιτεκτονική του και σε σχέση με το τι θα περιέχει η τελική έκδοση του συστήματος. 30

31 Φάση ανάπτυξης Οικονομικό Πανεπιστήμιο Αθηνών, Π.Μ.Σ Πληροφοριακά Συστήματα Η κρίσιμη αυτή φάση χαρακτηρίζει την ευελιξία της μεθόδου, καθότι η ομάδα ανάπτυξης πρέπει να λάβει υπόψη πολλές παραμέτρους, όπως χρόνος παράδοσης, ποιότητα, απαιτήσεις, πηγές, ενσωμάτωση επιπλέον τεχνογνωσίας κ.α., που ίσως διαφοροποιηθούν κατά τη διάρκεια της ανάπτυξης, αλλά και να είναι ικανή στο να αντιμετωπίσει πολλούς αστάθμητους παράγοντες και κινδύνους. Έτσι η ομάδα ανάπτυξης θα πρέπει να λάβει τα κατάλληλα μέτρα και να προβεί στους απαραίτητους ελέγχους ώστε να μπορέσει να αποφύγει τους πιθανούς κινδύνους που παραμονεύουν και να αντιμετωπίσει τα προβλήματα που ίσως προκύψουν. Οι διάφορες τεχνικές παράμετροι και οι παράμετροι του εξωτερικού περιβάλλοντος παρακολουθούνται και ελέγχονται διαρκώς, κατά τη διάρκεια των sprints. Τα sprints είναι επαναληπτικού κύκλου ανάπτυξης, που περιλαμβάνουν όλες τις κλασικές φάσεις ανάπτυξης του λογισμικού: καταγραφή απαιτήσεων, ανάλυση, σχεδιασμό, ανάπτυξη, παράδοση, έλεγχο. Φάση ολοκλήρωσης Αφού συναποφασιστεί με τον πελάτη ότι η συγκεκριμένη έκδοση έχει ολοκληρώσει τις απαιτήσεις, γίνονται όλες οι ενέργειες ώστε η έκδοση να παραδοθεί στον πελάτη: τεχνικοί έλεγχοι, ενσωμάτωση σε προηγούμενο υλικό, τεκμηρίωση συστήματος. Εικόνα 12. Κύκλος ζωής μεθόδου Scrum [32] 31

32 Ρόλοι και υπευθυνότητες στην Scrum [33], [34]: Στην ανάπτυξη έργων κατά τη μέθοδο Scrum, εμπλέκονται οι εξής ρόλοι και αρμοδιότητες Scrum master Είναι υπεύθυνος ώστε να διασφαλίσει ότι ακολουθούνται οι πρακτικές της Scrum κατά την ανάπτυξη του προϊόντος. Λειτουργεί σαν συνδεκτικός κρίκος μεταξύ ομάδας ανάπτυξης, πελάτη και διοίκησης και είναι υπεύθυνος ως προς το να διασφαλίσει πως θα ξεπεραστούν τυχόν εμπόδια που θα παρουσιαστούν, ώστε να παραμείνει η παραγωγικότητα της ομάδας σε υψηλά επίπεδα. Product owner Είναι υπεύθυνος του έργου και επιλέγεται από τον scrum master, τη διοίκηση και τον πελάτη. Αλληλεπιδρά με την ομάδα ανάπτυξης και αποφασίζει την προτεραιότητα των απαιτήσεων και συνεκτιμά την προσπάθεια που απαιτεί κάθε μία από αυτές. Παράλληλα, συμβάλλει αποφασιστικά στην εξέυρεση λύσεων ως προς τα προβλήματα διαφόρων φύσεων που προκύπτουν. Scrum team Μπορούν να υπάρχουν περισσότερες της μιας ομάδες, οι οποίες εργάζονται παράλληλα για την υλοποίηση του έργου. Η ομάδα scrum είναι επιφορτισμένη με την ανάπτυξη του έργου και με όλες τις δράσεις που πρέπει να λάβουν χώρα ως προς αυτό. Τα μέλη της έχουν λόγο ως προς τον καθορισμό των προτεραιοτήτων των απαιτήσεων και ως προς την εκτίμηση για το χρόνο που η υλοποίηση κάθε μιας από αυτές απαιτεί. Η ομάδα είναι επίσης υπεύθυνη για την εξέταση όσων τμημάτων έχουν καθυστερήσει και για την υποβολή αναφορών ως προς τα προκύπτοντα προβλήματα. Customer Ο πελάτης, έχει ενεργή συμμετοχή κατά την ανάπτυξη του έργου. Καθορίζει τις απαιτήσεις, έχει λόγο ως προς την προτεραιότητα αυτών και ελέγχει τη λειτουργία των παραδοθέντων τμημάτων. Βρίσκεται διαρκώςστη διάθεση της ομάδας ανάπτυξης για τυχόν απορίες. 32

33 Management Είναι υπεύθυνη για τις τελικές αποφάσεις, καθώς και για τον καθορισμό των στόχων και των απαιτήσεων του έργου Πρακτικές μεθόδου Scrum Σύμφωνα με τους Schwaber and Beedle, κατά τη μέθοδο Scrum ακολουθούνται οι ακόλουθες πρακτικές [30]: Λίστα εκκρεμοτήτων (backlog list) Αποτελείται από μια λίστα των όσων θα πρέπει να περιέχει και να υλοποιεί το τελικό προϊόν και βασίζεται στην μέχρι εκείνο το σήμείο γνώση. Η λίστα είναι διαρκώς ανανεούμενη. Υπεύθυνος για τη λίστα εκκρεμοτήτων, είναι ο product owner. Εκτίμηση προσπάθειας (effort estimation) Για κάθε περιεχόμενο της λίστας εκκρεμοτήτων, γίνεται επαναληπτική εκτίμση του χρόνου που απαιτεί. Στην εκτίμηση συμμετέχει ο scrum master και η scrum team. Επανάληψη (sprint) Είναι ένας πλήρης κύκλος ανάπτυξης, ο οποίος διαρκεί έως τέσσερεις εβδομάδες και στα πλαίσια του οποίου παράγεται προσαυξητικά λειτουργικότητα στο σύστημα. Στα πλαίσια του κάθε sprint λαμβάνουν χώρα η συνεδρίαση για τον καθορισμό του sprint και οι καθημερινές συναντήσεις scrum. Η συνεδρίαση για τον καθορισμό του sprint είναι η συνεδρίαση για τον σχεδιασμό και την υλοποίηση μιας επανάληψης που οργανώνεται από τον ειδικό της Scrum και υλοποιείται σε δύο φάσεις. Στην πρώτη φάση της συνεδρίασης συμμετέχουν οι πελάτες, οι χρήστες, η διοίκηση, ο ιδιοκτήτης του προϊόντος και η ομάδα ανάπτυξης για να καθορίσουν τους στόχους και την λειτουργικότητα της επόμενης επανάληψης. Στη δεύτερη φάση της συνεδρίασης, όπου συμμετέχουν μόνο ο ειδικός της Scrum και η ομάδα ανάπτυξης, καθορίζεται ο τρόπος με τον οποίο θα υλοποιηθεί η αυξητική ανάπτυξη του προϊόντος κατά την διάρκεια της επανάληψης. 33

34 Καθημερινή συνάντηση scrum (daily scrum meeting) Καθημερινή συνάντηση εντός κάθε sprint μικρής διάρκειας, στην οποια συμμετέχουν η scrum team, ο scrum master και αν θεωρηθεί απαραίτητο μέλη διοίκησης. Σε αυτές τις συναντήσεις, θέματα συζήτησης είναι το τι έχει υλοποιηθεί και το τι πρόκειται να προχωρήσει ως τη διάρκεια της ημέρας, καθώς και τυχόν προβλήματα που έχουν εντοπιστεί. Λίστα εκκρεμοτήτων sprint (sprint backlog) Αποφασίζεται από τον scrum master, την scrum team και τον scrum owner και περιέχει τις απαιτήσεις που θα πρέπει να ολοκληρώσει το τρέχον sprint. Αυτός ο κατάλογος των απαιτήσεων παραμένει αμετάβλητος στα όρια του τρέχοντος sprint. 34

35 Συνεδρίαση επανεξέτασης επανάληψης (sprint review meeting) Την τελευταία ημέρα κάθε sprint, η ομάδα scrum και ο scrum master παρουσιάζουν τα αποτελέσματα στον πελάτη, τη διoίκηση και τον product owner. Τα αποτελέσματα αξιολογούνται και αυτή η αξιολόγηση, μπορεί να οδηγήσει σε δημιουργία νέων απαιτήσεων και σε επανακαθορισμό της συνολικής στόχευσης του έργου Τροποποίηση μεθόδου scrum Μια από τις μεγαλύτερες ανησυχίες κατά την ανάπτυξη έργων λογισμικού, είναι η πιθανή απώλεια του ελέγχου της διαχείρισης. Ως εκ τούτου, η παρακολούθηση της πορείας προόδου του έργου είναι ένα θέμα υψίστης σημασίας. Έρευνα του 2009 [35], υποδεικνύει ως κύριο παράγοντα απώλειας του ελέγχου, τη χρήση του μοντέλου του καταρράκτη. Το μοντέλο του καταρράκτη, αποδεικνύεται επαρκές σε έργα μικρής διάρκειας με υψηλό το ποσοστό των εκ των προτέρων γνωστών απαιτήσεων. Ωστόσο, σε μεγαλύτερης διάρκειας έργα υψηλότερης αστάθειας, το μοντέλο του καταρράκτη αποδεικνύεται ανεπαρκές. Σε αυτές τις περιπτώσεις, η χρήση των Agile μεθοδολογιών προκρίνεται. Μια από τις πιο δημοφιλείς Agile μεθοδολογίες, είναι η μέθοδος Scrum. Διακρίνεται για την εύκολη εφαρμογή, έχοντας όμως συγκεκριμένες αδυναμίες. Μια από αυτές, είναι η θολή πολλές φορές εικόνα σχετικά με τους ρόλους και τις υπευθυνότητες. Μια δεύτερη, εξίσου σημαντική, είναι ότι στην αυθεντική έκδοση της μεθόδου, γίνεται εστίαση στα αυξητικά sprints, με αποτέλεσμα να μην παρέχεται μια ξεκάθαρη εικόνα του καθολικού χρονοδιαγράμματος του έργου. Ο περιορισμός αυτός, καθιστά δύσκολη την παραγωγή ορθών προβλέψεων ως προς τις κρίσιμες προθεσμίες, κάτι που τελικά επηρεάζει αρνητικά πολλαπλές διαδικασίες στον κύκλο ανάπτυξης του έργου. Επιπλέον, κατά τις εκθέσεις προόδου, η χρήση των διαγραμμάτων burndown στηριζόμενη στα σημεία εκτίμησης, πολλές φορές χαρακτηρίζεται ενοχλητική, λόγω της ανάγκης επανεξέτασης των σημείων εκτίμησης στο τέλος κάθε sprint. Ως εκ τούτου και με στόχο την αντιμετώπιση αυτών των προβλημάτων, θα πρέπει να λάβουν χώρα τροποποιήσεις. Κατά πρώτο λόγο, οι ρόλοι και οι υπευθυνότητες θα πρέπει να παρουσιάζονται με σαφήνεια, με υποβοηθητικό το ρόλο μιας βήμα προς βήμα λίστας δραστηριοτήτων. Κατά δεύτερο λόγο, θα πρέπει να ενσωματωθεί ένα επιπλέον στάδιο σχεδιασμού, με στόχο την περιγραφή της ολότητας του έργου. Αυτό το επιπλέον στάδιο, θα πρέπει με κάποιον τρόπο να συνδυάζει τα σχέδια των sprints, κάτι το οποίο έχει σημαντικό βαθμό πολυπλοκότητας, λόγω των πολλαπλών αλληλοεξαρτώμενων ενεργειών. Αυτή η πολυπλοκότητα 35

36 θα μπορούσε να αντιμετωπιστεί με τη χρήση δελτίων κατάστασης, στα οποία θα ενσωματώνονται ημερομηνίες έναρξης και λήψης δραστηριοτήτων Αυθεντική και τροποποιημένη έκδοση της μεθόδου Scrum Η Scrum, είναι μια σταδιακή, επαναληπτική, ευέλικτη μέθοδος, που χρησιμοποιείται για τη διαχείριση της ανάπτυξης λογισμικού. Το όραμα των εμπνευστών της 1, ήταν η δημιουργία μιας ολιστικής μεθόδου, η οποία θα αύξανε την ταχύτητα ανάπτυξης και θα παρείχε υψηλό επίπεδο ευελιξίας κατά την παραγωγική διαδικασία. Κάθε επαναληπτικό sprint, αντιστοιχεί κανονικά σε ένα χρονικό πλαίσιο διάρκειας από μία έως και τέσσερεις εβδομάδες. Κάθε sprint, ξεκινά με μια συνάντηση σχεδιασμού, η οποία ιεραρχεί τις απαιτήσεις του έργου, με την ενσωμάτωση συγκεκριμένων απαιτήσεων σε κάθε sprint. Κατόπιν, η ομάδα scrum προσπαθεί να υλοποιήσει τις απαιτήσεις του τρέχοντος sprint. Καθημερινές συναντήσεις λαμβάνουν χώρα, για την εξέταση της προόδου με τη χρήση απλών διαγραμμάτων. Στο τέλος ενός sprint, μια απολογιστική συνάντηση, όπου εξετάζονται οι ολοκληρωμένες εργασίες σε σχέση με αυτές που είχαν προγραμματιστεί να ολοκληρωθούν. Επίσης, παρουσιάζεται ένα demo του προϊόντος. Όπως προειπώθηκε, η παραπάνω διαδικασία δε ρέει απροβλημάτιστα. Η σύγχυση ως προς τους ρόλους και τις υπευθυνότητες, καθώς και η δυσκολία καθολικής εξέτασης του όλου έργου κρίνονται ως ιδιαίτερα σημαντικά. Η ύπαρξη βελτιώσεων λοιπόν κρίνεται ιδιαίτερης αξίας. Κατά τη φάση της οργάνωσης του έργου, οι ρόλοι και οι υπευθυνότητες πρέπει να οριστούν με ξεκάθαρο τρόπο. Αυτό θα βοηθήσει τα μέλη της ομάδας να έχουν επίγνωση των καθηκόντων που φέρουν σε κάθε φάση. Κατά τη φάση σχεδιασμού του έργου, η προσθήκη μιας master sprint φάσης σχεδιασμού, μπορεί να βοηθήσει στον καθορισμό οροσήμων για την ολότητα του έργου, πριν την έναρξη των επιμέρους sprints. Επίσης, κατά τη φάση αναθεώρησης ενός sprint, ο αριθμός των ολοκληρωμένων υποεργασιών μπορεί να χρησιμοποιηθεί ως δείκτης της συνολικής προόδου του έργου. 1 Hirotaka Takeuchi and Ikujiro Nonaka, 1986, Japan 36

37 Στην ακόλουθη εικόνα, παριστάνονται οι διαφοροποιήσεις μεταξύ της αυθεντικής και τροποποιημένης μεθόδου scrum. Εικόνα 13 Αυθεντική και τροποποιημένη μέθοδος Scrum [35] Καθορισμός ρόλων και υπευθυνοτήτων Μια ομάδα scrum, αποτελείται από πολλαπλές οντότητες με διαφορετικούς ρόλους. Μια τυπική ομάδα scrum, εμπεριέχει τρεις κύριους ρόλους: τον ιδιοκτήτη του προϊόντος, τον scrum master και τα υπόλοιπα μέλη της ομάδας. Σε κάθε έργο, θα πρέπει να υπάρχει πλήρης κατανόηση των ρόλων και των υπευθυνοτήτων. Ο ιδιοκτήτης του προϊόντος, είναι το άτομο που έχει την κύρια ευθύνη του έργου. Αντιπροσωπεύει τον πελάτη και λειτουργεί ως σύνδεσμος με την ομάδα ανάπτυξης. Είναι υπεύθυνος για την ιεράρχηση των λειτουργιών του έργου και θα πρέπει να είναι σε θέση να επανακαθορίζει αυτήν την ιεράρχηση, ανάλογα με τις προκύπτουσες ανάγκες και με στόχο την μεγιστοποίηση της απόδοσης της επένδυσης. Το τμήμα σχεδιασμού, θα μπορούσε να χειριστεί αυτόν το ρόλο. Ο scrum master, φροντίζει για την εξοικείωση της ομάδας, και τη σωστή προετοιμασία της για την αποτελεσματική εκτέλεση της scrum διαδικασίας. Είναι υπεύθυνος για την αντιμετώπιση των επιπλοκών που προκύπτουν κατά τη διάρκεια των sprints και παρακωλύουν την εξέλιξη του όλου έργου. Εξασφαλίζει ότι όσα περιγράφονται σε κάθε sprint, ολοκληρώνονται έγκαιρα και έγκυρα. Ο project manager, θα μπορούσε να αναλάβει τη διεκπεραίωση αυτού του ρόλου. Τα υπόλοιπα μέλη της ομάδας, είναι αυτοί που αναλαμβάνουν την πραγματική ανάπτυξη του προϊόντος. Περιλαμβάνει τους σχεδιαστές, τους προγραμματιστές, την ομάδα διασφάλισης ποιότητας. 37

38 έργου. Στον ακόλουθο πίνακα, επιχειρείται μια κατανομή των ρόλων ανά φάση ανάπτυξης του Product Master sprint Individual Daily meeting Sprint review backlog planning sprint review planning Στόχος Ανασκόπηση -Μέτρηση -Καθορισμός Διαμοιρασμός -Επίδειξη και εκτιμώμενης των στόχων καθημερινής παραδοτέων διαμοιρασμός product backlog βαθμολόγησης για το product backlog -Καθορισμός για τα μεμονωμένα sprints planning προόδου και ενημερώσεων -Έλεγχος και επίλυση -Ενημέρωση προόδου του αριθμού -Παραγωγή θεμάτων των sprints πίνακα -Καθορισμός προόδου έργου ορόσημου Scrum master Ανασκόπηση -Χειρισμός -Χειρισμός -Διαχείριση -Διαχείριση product συναντήσεων συναντήσεων προόδου προόδου backlog -Ανασκόπηση -Ανασκόπηση -Διαχείριση -Διαχείριση ολικού product προόδου έργου θεμάτων θεμάτων backlog -Διαχείριση -Διαχείριση -Καθορισμός χρονοδιαγραμ χρονοδιαγραμ του αριθμού μάτων μάτων των sprints -Ανασκόπηση του οροσήμου 38

39 Product Master sprint Individual Daily meeting Sprint review backlog planning sprint review planning Product Διαμοιρασμός -Μέτρηση -Συλλογή -Υποστήριξη -Έλεγχος owner product εκτιμώμενης backlog προς στην ανάλυση προϊόντος backlog βαθμολόγησης για το product backlog εκτέλεση για το τρέχον sprint θεμάτων -Έλεγχος απαιτήσεων που δεν -Καθορισμός -Ανασκόπηση ικανοποιούντα στόχων για το διαγράμματος ι από την ολικό sprint προόδου υλοποίηση εργασίας Scrum team Αναθεώρηση -Μέτρηση -Καθορισμός - Επίδειξη product εκτιμώμενης των στόχων Ολοκληρωμέν παραδοτέων backlog βαθμολόγησης για το τρέχον ες και για το product sprint ανά σχεδιαζόμενες backlog επιμέρους εργασίες -Καθορισμός λειτουργία -Θέματα στόχων για το -Παραγωγή ολικό sprint διαγράμματος προόδου εργασίας Πίνακας 3. Κατανομή ρόλων στην τροποποιημένη scrum [35]. 39

40 Master sprint planning Κύριος στόχος αυτής της φάσης, είναι ο προγραμματισμός του στόχου για την ολότητα του έργου. Αντιστοιχεί σε μια συνάντηση, όπου οι ρόλοι scrum master και product owner εκτιμούν το χρόνο και τον αριθμό των sprints ου θα χρειαστούν για την ολοκλήρωση του έργου. Η συνάντηση αυτή, δεν απαιτεί το να παραβρίσκονται όλα τα μέλη των ομάδων scrum. Αρκεί η συμμετοχή των ηγετών της κάθε επιμέρους ομάδας, ώστε να καθοριστούν οι στόχοι του κάθε sprint και τα ορόσημα του όλου έργου. Ο product owner παράγει το product backlog πριν από τη συνάντηση για το master sprint planning. Το product backlog, περιέχει μια λίστα απαιτήσεων σε προτεραιότητα. Δεν αποτελεί μια στατική έννοια, καθώς μπορεί να τροποποιηθεί με νέες προτεραιότητες, αν οι επιχειρηματικές ανάγκες το απαιτήσουν. Για κάθε επιμέρους υποέργο μπορεί να προκύψει ένα product backlog. Κάθε ένα χαρακτηρίζεται μοναδικά από κωδικό ταυτοποίησης, που επιτρέπει την εύκολη και γρήγορη πρόσβαση και αναφορά σε αυτό. Αν ένα υποέργο απαιτεί πολλές λειτουργίες για να εκτελεστεί, το αντίστοιχο product backlog μπορεί να αναπτύσσεται σε πολλαπλά βάθη - επίπεδα. Οι ηγέτες της κάθε επιμέρους ομάδας, προβαίνουν σε χρονικές εκτιμήσεις για κάθε backlog, οι οποίες στηρίζονται στην εμπειρία τους. Αυτή η διαδικασία, καλείται estimating scoring. Αυτό το estimating scoring, δε θα πρέπει να υπερβαίνει τις 40 ώρες. Αν τις υπερβαίνει, αυτό σημαίνει πως η εργασία θα πρέπει να διασπασθεί σε υποεργασίες. Όταν οι εκτιμήσεις ολοκληρωθούν, ακολουθεί έλεγχος, σχετικά με το εάν ακολουθούνται οι επιταγές του δεδομένου χρονοδιαγράμματος. Καθώς η ημερομηνία παράδοσης του προϊόντος είναι καθορισμένη, μπορούν να υπάρχουν εργασίες οι οποίες μπορεί να μην δύναται να ολοκληρωθούν εντός χρονοδιαγράμματος. Τέτοιες εργασίες, μπορεί να εξαιρεθούν από το δεδομένο backlog. Όταν η master spring planning συνάντηση ολοκληρωθεί, οι ηγέτες της κάθε ομάδας ενημερώνουν τα μέλη της, σχετικά με τον αριθμό των sprints και τους αναμενόμενους στόχους καθενός από αυτά. 40

41 Κεφάλαιο 2ο. Η έννοια της μετρολογίας 2.1 Εισαγωγή Οι μετρήσεις, είναι ένα αναπόσπαστο τμήμα της διαδικασίας παραγωγής λογισμικού, καθώς αποτελούν έναν αντικειμενικό τρόπο θεώρησης της ποιότητας, των δυνατοτήτων καθώς και των αδυναμιών του λογισμικού [36]. Οι μετρήσεις χρησιμεύουν στη διεύθυνση ενός έργου, ώστε να εξαχθούν συμπεράσματα σε σχέση με την πορεία του έργου, όσον αφορά χρηματικούς προϋπολογισμούς και χρονοδιαγράμματα. Παράλληλα, χρησιμεύουν στην ομάδα ανάπτυξης, ώστε να αξιολογήσει την πρόοδο του έργου και το βαθμό επίτευξης των απαιτήσεων των πελατών. Οι μετρήσεις επίσης χρησιμεύουν στους πελάτες, σαν μέσο προσδιορισμού της ποιότητας των προϊόντων. Τέλος, χρησιμεύουν στην ομάδα συντήρησης, ώστε να παρθεί η απόφαση του εάν πρέπει ένα τμήμα του λογισμικού να τροποποιηθεί [36]. Ο βασικότερος στόχος των μετρήσεων, είναι η βελτίωση της ποιότητας του λογισμικού. Για να είναι όμως η διαδικασία των μετρήσεων αποδοτική, θα πρέπει να ακολουθηθεί μια μεθοδολογία στη διεξαγωγή τους. Κάθε μεθοδολογία θα πρέπει να λαμβάνει υπόψη τρία χαρακτηριστικά: το είδος των οντοτήτων που θα μετρηθούν, το βασικό στόχο των μετρήσεων και το επίπεδο ωριμότητας του οργανισμού [36]. Μια οντότητα μπορεί να αντιστοιχεί σε διαδικασία, σε προϊόν ή σε πόρο. Τα χαρακτηριστικά των οντοτήτων που υπόκεινται σε μέτρηση, μπορεί να είναι είτε εσωτερικά είτε εξωτερικά. Η μέτρηση των εσωτερικών χαρακτηριστικών, για παράδειγμα το μέγεθος του κώδικα, γίνεται συνήθως άμεσα και με αυτοματοποιημένο τρόπο. Σε αντίθεση, τα εξωτερικά χαρακτηριστικά, όπως για παράδειγμα η αξιοπιστία ενός προϊόντος, δεν μπορεί να μετρηθεί με την ίδια αμεσότητα [36]. Ο βασικός στόχος μιας μέτρησης, καθορίζει και το είδος της μετρικής που θα χρησιμοποιηθεί. Ο πιο διαδεδομένος τρόπος γι αυτόν τον καθορισμό, είναι η μέθοδος Goal, Question, Metric (GQM) [37]. Σε αυτήν, ένα μοντέλο μέτρησης ορίζεται σε τρία επίπεδα. Στο πρώτο, το εννοιολογικό επίπεδο (Goal), ορίζεται ένας στόχος για μία οντότητα. Ο στόχος αυτός ορίζεται για συγκεκριμένους λόγους, έχει ως σημείο αναφοράς συγκεκριμένα ποιοτικά πρότυπα, έχει να κάνει με συγκεκριμένες απόψεις και είναι σχετικός με ένα συγκεκριμένο περιβάλλον στο οποίο η οντότητα υπάρχει. Στο δεύτερο, το επιχειρησιακό επίπεδο (Question), για το στόχο που έχει καθοριστεί στο πρώτο επίπεδο, παράγεται ένα σύνολο ερωτήσεων, οι απαντήσεις στις οποίες 41

42 θα καθορίζουν το βαθμό επίτευξης του στόχου. Στο τρίτο, το ποσοτικό επίπεδο (Metric), συγκεκριμένες μετρήσεις συνδέονται με κάθε ερώτηση του δεύτερου επιπέδου, ώστε να δοθούν απαντήσεις με μετρήσιμο τρόπο. Το επίπεδο ωριμότητας του οργανισμού, αναφέρεται στο επίπεδο ωριμότητας και ποιότητας των διαδικασιών που ο οργανισμός χρησιμοποιεί. Η ποιότητα των διαδικασιών, είναι έννοια άμεσα συνυφασμένη με την ποιότητα του παραγόμενου προϊόντος. Το πιο διαδεδομένο μοντέλο καθορισμού αυτού του επιπέδου, είναι το Capability Maturity Model (CMM) [38], καθώς και η επέκταση του στο Capability Maturity Model Integration (CMMI) [39]. 2.2 Η έννοια της μετρικής Η μέτρηση, σύμφωνα με τον Fenton είναι Η εμπειρική διαδικασία με την οποία αποδίδονται αριθμοί ή σύμβολα σε χαρακτηριστικά γνωρίσματα οντοτήτων του πραγματικού κόσμου, κατά τέτοιο τρόπο, ώστε να τα περιγράφουν σύμφωνα με καθαρά διατυπωμένους κανόνες [40]. Μια οντότητα είναι ένα αντικείμενο, ενώ ένα χαρακτηριστικό γνώρισμα είναι ένα γνώρισμα ή μία ιδιότητα της οντότητας. Η αντιστοίχιση των αριθμών ή συμβόλων στα χαρακτηριστικά θα πρέπει να είναι όσο το δυνατόν πιο ακριβής και να μην αφήνει περιθώρια διφορούμενων ερμηνειών. Για την αντιστοίχιση, επιλέγεται ένας τύπος κλίμακας. Οι πιο γνωστοί τύποι κλίμακας είναι οι ακόλουθοι: Ονομαστική κλίμακα Η μέτρηση ονομαστικής κλίμακας (nominal ή categorical scale) εμπλέκει δεδομένα που σχετίζονται με μεταβλητές των οποίων οι τιμές απεικονίζουν κατηγορίες που δεν διέπονται από την ιδιότητα της διάταξης ούτε από εκείνη της απόστασης, οπότε δεν μπορεί να γίνει κάποια σύγκριση, αριθμητική πράξη ή υπολογισμός στατιστικών μέτρων. Παραδείγματα τέτοιων μεταβλητών είναι το φύλο, το επάγγελμα, η οικογενειακή κατάσταση. 42

43 Τακτική κλίμακα Οικονομικό Πανεπιστήμιο Αθηνών, Π.Μ.Σ Πληροφοριακά Συστήματα Η μέτρηση τακτικής κλίμακας (ordinal scale) εμπλέκει δεδομένα που σχετίζονται με μεταβλητές των οποίων οι τιμές απεικονίζουν κατηγορίες οι οποίες μπορούν να μπουν σε μία διάταξη-σειρά, από μία κατώτερη σε μία ανώτερη. Δεν υπάρχει η ιδιότητα της απόστασης οπότε δεν μπορούμε να υπολογίσουμε το βαθμό διαφοράς ή το σχετικό μέγεθος μεταξύ δύο κατηγοριών. Παραδείγματα τέτοιων μεταβλητών είναι το επίπεδο γνώσης κάποιου θέματος, το επίπεδο εκπαίδευσης, η θέση σε μία εταιρεία. Κλίμακα με διαστήματα Η κλίμακα με διαστήματα (interval scale) αναφέρεται στη μέτρηση αριθμητικών δεδομένων, τα οποία ικανοποιούν την ιδιότητα της διάταξης αλλά και της απόστασης μεταξύ τους. Το 0, όμως, επιλέγεται αυθαίρετα, δεν δηλώνει δηλαδή την απουσία του μετρούμενου χαρακτηριστικού. Αποτέλεσμα είναι να μπορούμε να μελετήσουμε διαφορές όχι όμως και αναλογικές σχέσεις μεταξύ των τιμών των μεταβλητών. Χαρακτηριστικότερο παράδειγμα εδώ είναι η θερμοκρασία. Αναλογική κλίμακα Η αναλογική κλίμακα (ratio scale) αναφέρεται στη μέτρηση αριθμητικών δεδομένων τα οποία ικανοποιούν τις ιδιότητες της διάταξης και της απόστασης και ταυτόχρονα έχουν και ορισμένο 0 που αντιπροσωπεύει την απουσία του χαρακτηριστικού που μελετάται. Έτσι, εδώ μπορούν να μελετηθούν και αναλογικές σχέσεις μεταξύ των μεταβλητών. Παραδείγματα είναι η ηλικία, το σωματικό βάρος, εμβαδό οικοπέδων, κ.λ.π.. Απόλυτη κλίμακα Αντιστοιχεί στην απόλυτη μέτρηση της ποσότητας ενός συγκεκριμένου χαρακτηριστικού, πχ μέτρηση γραμμών κώδικα. 43

44 2.3 Οι μετρικές στο λογισμικό Η χρήση μετρικών, θεωρείται ο τρόπος για τη βελτίωση μιας παραγωγικής διαδικασίας. Στις μεγάλες εταιρείες παραγωγής λογισμικού, η χρήση των μετρικών είναι κοινή πρακτική και ο μεγαλύτερος όγκος παραγόμενης πληροφορίες έχει να κάνει με αυτές. Τα κυριότερα κίνητρα χρήσης των μετρικών σύμφωνα με τον Pluford, είναι τα ακόλουθα: -σχεδιασμός και σχετικές εκτιμήσεις για το έργο -διαχείριση έργου και παρακολούθηση -κατανόηση επιχειρηματικών στόχων και της ποιότητας -βελτιωμένη επικοινωνία κατά την ανάπτυξη του λογισμικού -ταχύτερη και ακριβέστερη διαδικασία λήψης αποφάσεων από την ηγεσία του έργου Η χρήση των μετρικών παράγει οφέλη, όπως η ικανότητα πρόβλεψης και βελτίωσης των επιμέρους συστατικών ενός λογισμικού. Θεωρείται όμως βασική παράμετρος, η μελέτη και η χρήση των μετρικών, να λαμβάνει υπόψη το πλαίσιο - χώρο στο οποίο καλούνται να εφαρμοστούν. Σε έρευνα του 2009, σχετικά με τους παράγοντες που επιδρούν στην ποιότητα του λογισμικού κατά τη χρήση ευέλικτων μεθοδολογιών, σημειώνεται η θετική επίδραση που έχει η χρήση μετρικών σε αυτήν την ποιότητα. Συγκεκριμένα, εντοπίζεται σημαντική θετική επίδραση των μετρικών που έχουν να κάνουν με την ταχύτητα ανάπτυξης, με την παραδιδόμενη αξία, με την καταμέτρηση σφαλμάτων και τον αριθμό των δοκιμών. Ταυτόχρονα, το 64% των συμμετεχόντων θεωρούν ως σημαντικό παράγοντα επιτυχίας τη χρήση μετρικών [42]. 44

45 Στο λογισμικό, σύμφωνα με τον Fenton [40], υπάρχουν τρεις κατηγορίες οντοτήτων: Διαδικασίες Κάθε δραστηριότητα που συνδέεται με την ανάπτυξη λογισμικού, ανεξαρτήτως της φάσης του κύκλου ζωής. Προϊόντα Κάθε παραδοτέο, έγγραφο ή τεχνούργημα προκύπτει από τη διαδικασία παραγωγής. Πόροι Κάθε τι που χρησιμοποιείται φγγια την παραγωγή των προϊόντων. Τα χαρακτηριστικά των οντοτήτων διακρίνονται σε εσωτερικά και εξωτερικά. Εσωτερικά χαρακτηριστικά, είναι αυτά που πηγάζουν άμεσα από τη φύση των οντοτήτων, όπως για παράδειγμα ο αριθμός γραμμών κώδικα. Εξωτερικά, είναι χαρακτηριστικά τα οποία πηγάζουν συνδυαστικά με το περιβάλλον στο οποίο αναπτύσσεται η οντότητα, για παράδειγμα ο αριθμός των αποτυχημένων προσπαθειών ολοκλήρωσης μιας συγκεκριμένης ενέργειας από το χρήστη. Η μέτρηση των εξωτερικών χαρακτηριστικών είναι μια πιο πολύπλοκη διαδικασία από την αντίστοιχη των εσωτερικών και έχει μεγαλύτερη αξία ως προς τα συμπεράσματα που μπορούν να εξαχθούν [36]. Μία κατηγοριοποίηση των μετρήσεων, είναι αυτή που τις διακρίνει σε άμεσες και έμμεσες. Άμεση μέτρηση, είναι αυτή που δεν προϋποθέτει τη χρήση άλλων μετρήσεων, αντίθετα από τις έμμεσες. Οι μετρήσεις επίσης μπορούν να κατηγοριοποιηθούν στις αντικειμενικές και υποκειμενικές. Αντικειμενικές, είναι οι μετρήσεις που δίνουν το ίδιο αποτέλεσμα, ανεξάρτητα από το άτομο που τη διεξάγει. Χαρακτηριστικό παράδειγμα, ο αριθμός των γραμμών κώδικα. Οι αντικειμενικές μετρήσεις γίνονται συνήθως με τη χρήση αυτοματοποιημένων μεθόδων. Οι υποκειμενικές μετρήσεις, αντιστοιχούν σε προσωπικές εκτιμήσεις ατόμων. Χαρακτηριστικό παράδειγμα, ο βαθμός ικανοποίησης του πελάτη από το παραγόμενο προϊόν. Παρά τη σχετική ασάφεια της υποκειμενικής άποψης, είναι μετρήσεις οι οποίες γίνονται τακτικά καθώς συλλέγουν χρήσιμα δεδομένα [36]. 45

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

47 2.4 Επικύρωση μετρικών Οικονομικό Πανεπιστήμιο Αθηνών, Π.Μ.Σ Πληροφοριακά Συστήματα Η χρήση μιας προβληματικής και μη ενδεδειγμένης μέτρησης, μπορεί να οδηγήσει σε λάθος συμπεράσματα και λανθασμένες στρατηγικές, που μπορούν να έχουν σημαντικά αρνητική επίδραση στην ποιότητα του παραγόμενου έργου. Γι αυτό το λόγο, είναι σημαντική η επικύρωση ενός μέτρου. Η επικύρωση ενός μέτρου, σύμφωνα με τον Fenton [36], έχει να κάνει με την επιβεβαίωση ότι η αναπαράσταση που χρησιμοποιείται εκφράζει με επιτυχία το χαρακτηριστικό. Με πιο απλά λόγια, είναι η επιβεβαίωση ότι η μέτρηση που χρησιμοποιείται αποδίδει σωστά αποτελέσματα. Υπάρχουν τρεις διαδικασίες, ως προς την επικύρωση των μετρήσεων: Θεωρητική επικύρωση Η θεωρητική επικύρωση βασίζεται σε μοντέλα, τα οποία επικυρώνουν με στατιστικό τρόπο τις μετρικές. Απαραίτητη προϋπόθεση, οι αριθμοί ή τα σύμβολα που αποδίδονται σε χαρακτηριστικά γνωρίσματα οντοτήτων του πραγματικού κόσμου, να αποδίδονται με τέτοιον τρόπο, ώστε να αντανακλούν την πραγματικότητα και να έχουν ξεκάθαρους κανόνες διατύπωσης [36]. Επίσης, η μετρική θα πρέπει να μην παρουσιάζει μη αναμενόμενες ασυνέχειες και θα πρέπει να έχει επιλεχθεί η κατάλληλη κλίμακα μέτρησης [43]. Πειραματική επικύρωση Η πειραματική επικύρωση, αποδεικνύει το εάν μια μετρική είναι εφαρμόσιμη στην πράξη και χρήσιμη. Απαιτείται η συλλογή δεδομένων, τα οποία αφορούν της εγκυρότητα και την αποτελεσματικότητα της μετρικής. Τα δεδομένα αυτά, συνήθως συλλέγονται μέσω έρευνας στη βιομηχανία παραγωγής λογισμικού. Σε περιπτώσεις που η πρόσβαση σε δεδομένα της βιομηχανίας κρίνεται αδύνατη, μπορεί να γίνει συλλογή δεδομένων μέσω πειραμάτων με τη βοήθεια πανεπιστημιακών ιδρυμάτων. Αξιωματική επικύρωση Ορίζεται ένα σύνολο αξιωμάτων μαθηματικής φύσεως, ως ιδιότητες που ιδανικά πρέπει να τηρεί η μετρική. Κατόπιν, η μετρική αξιολογείται βάση αυτών των αξιωμάτων. Είναι μια μέθοδος που δεν απαιτεί τη συγκέντρωση δεδομένων, αλλά απαιτεί ιδιαίτερη προσοχή ως προς την αξιοπιστία των αξιωμάτων. 47

48 2.5 Φύση μετρικών στις ευέλικτες μεθοδολογίες Στις ευέλικτες μεθοδολογίες, η χρήση παλαιότερα δοκιμασμένων μετρικών δεν εκλείπει. Ωστόσο, αυτές οι μετρικές χρησιμοποιούνται με διαφορετικό τρόπο απ' ότι στις παραδοσιακές μεθόδους. Για παράδειγμα, η μετρική team velocity, στις παραδοσιακές μεθόδους χρησιμοποιείται για να προκαθοριστεί ένας παραγωγικός στόχος και να μετρηθεί η απόδοση της ομάδας βάση αυτού του στατικού στόχου. Στην XP μέθοδο, η ίδια μετρική χρησιμοποιείται, ώστε να μπορεί να αποδοθεί σε κάθε ομάδα ένας λογικός φόρτος εργασίας στον οποίο θα μπορεί να ανταπεξέλθει, καθώς και για τον καθορισμό του περιεχομένου των επαναλήψεων αντίστοιχα [44]. Η χρήση των μετρικών στις ευέλικτες μεθοδολογίες έχει διαφορετική πολλές φορές στόχευση απ ότι στις παραδοσιακές. Στις παραδοσιακές μεθόδους, οι εκτιμήσεις χρησιμοποιούνται ως σημαντικοί στόχοι των οποίων η υλοποίηση πρέπει να προσεγγιστεί όσο το δυνατόν εγγύτερα - στο κύριο πλάνο υπάρχουν οι στόχοι. Στις ευέλικτες μεθοδολογίες, οι εκτιμήσεις χρησιμοποιούνται σαν ένας τρόπος πρόβλεψης του πόσα μπορεί μια ομάδα να πετύχει και η πρόοδος μετριέται σε όρους παραγωγής τμημάτων λογισμικού τα οποία είναι πλήρως λειτουργικά - στο κύριο πλάνο βρίσκεται ο ανθρώπινος παράγοντας, είτε με τη μορφή της ομάδας παραγωγής είτε με μορφή των πελατών ή χρηστών του υπό παραγωγή λογισμικού [44]. Η ευέλικτη προσέγγιση εν τέλει συγκρούεται με δύο θεμελιώδεις αρχές του τρόπου δόμησης των μετρικών των παραδοσιακών τεχνικών. Πρώτον, με την αρχή του να παρακολουθείται η πρόοδος του έργου, βάση προκαθορισμένων στόχων. Ενάντια σε αυτή την αρχή, η ευέλικτη προσέγγιση θεωρεί ως ευπρόσδεκτες τις διαρκείς αλλαγές. Δεύτερον, με την αρχή των αυστηρά καθορισμένων και ίσως πολύπλοκων μετρικών ποιότητας, καθώς η ευέλικτη προσέγγιση πρεσβεύει την αξία της απλότητας. 48

49 Στον ακόλουθο πίνακα αναγράφονται κάποιες σημαντικές διαφορές μεταξύ των δύο προσεγγίσεων. Παραδοσιακές μέθοδοι Ευέλικτες μέθοδοι Δίνει έμφαση στην παρακολούθηση παραδοτέων, στους προκαθορισμένους μετρήσιμους στόχους, στην προδιαγεγραμμένη πορεία βάση του αρχικού σχεδιασμού, στην παράδοση μεγάλων τμημάτων του λογισμικού. Στο επίκεντρο βρίσκεται ο ανθρώπινος παράγοντας, η απλότητα, η γρήγορη ανατροφοδότηση, η άμεση ανταπόκριση σε αλλαγές Πίνακας 4 Διαφορές μεταξύ παραδοσιακών και Agile μεθόδων [44]. Σε αντίθεση με τις παραδοσιακές μεθόδους, στις ευέλικτες μεθόδους, η εικόνα δεν είναι απόλυτα σαφής ως προς το είδος, τον τρόπο και τη χρονική στιγμή που εφαρμόζονται οι μετρικές. Τα οφέλη όμως της χρήσης μετρικών είναι αδιαμφισβήτητα, συνεπώς η ανάγκη του να ερευνηθεί η χρήση μετρικών στην πραγματική παραγωγή έργων λογισμικού, θεωρείται ιδιαίτερα σημαντική και σαφώς υπαρκτή. 49

50 Κεφάλαιο 3ο. Ερευνητική μεθοδολογία βιβλιογραφικής επισκόπησης 3.1 Systematic Literature Review (SLR) Η SLR, είναι μια διαδικασία για τον εντοπισμό, την αξιολόγηση και την ερμηνεία όλων των διαθέσιμων ερευνητικών δεδομένων, ώστε να δοθούν απαντήσεις σε μια συγκεκριμένη ερευνητική ερώτηση [45]. Σύμφωνα με την Patricia Cronin [46], σκοπός της SLR είναι το να παρέχει μία όσο το δυνατόν πληρέστερη λίστα δημοσιευμένων και αδημοσίευτων μελετών που σχετίζονται με μία συγκεκριμένη θεματική ενότητα. Σε αντίθεση με άλλους τύπους έρευνας που προσπαθούν απλά να συνοψίζουν τα αποτελέσματα μιας σειράς ερευνών, στην SLR χρησιμοποιούνται σαφή και αυστηρά κριτήρια για την κριτική αξιολόγηση και σύνθεση όλης της βιβλιογραφίας ενός συγκεκριμένου θέματος. Με σκοπό να μπορεί ο αναγνώστης να αξιολογήσει την αξιοπιστία και την εγκυρότητα της έρευνας, θα πρέπει να παρουσιάζονται τα κριτήρια που έχουν να κάνουν με τη διαμόρφωση των ερευνητικών ερωτημάτων, με τον ορισμό κριτηρίων ένταξης ή αποκλεισμού, με την επιλογή και την πρόσβαση στη βιβλιογραφία, με την αξιολόγηση της ποιότητας της βιβλιογραφίας, καθώς και με την ανάλυση και σύνθεση των ευρημάτων [47]. Εικόνα 14. Κριτήρια που χρησιμοποιούνται στην SLR [47]. Τα βήματα για τη διεξαγωγή έρευνας με τη διαδικασία SLR, είναι τα εξής [45]: 50

51 Planning Καθορίζεται το σύνολο των ερευνητικών ερωτημάτων για τα οποία θα συλλεχθεί πληροφορία. Conducting Περιλαμβάνει την αναζήτηση στη σχετική βιβλιογραφία, την επιλογή των κύριων μελετών, την εξαγωγή δεδομένων, την εκτίμηση της ποιότητας των μελετών, τη σύνθεση των ευρημάτων. Reporting Αντιστοιχεί στη συγγραφή της έρευνας. Εικόνα 15. Τα βήματα για τη διεξαγωγή SLR [45]. 51

52 3.2 Ερευνητική προσέγγιση Η έρευνα θεμελιώθηκε και επεκτάθηκε με τη βοήθεια πηγών - κυρίως πρόσφατων εργασιών -,οι οποίες είναι διαθέσιμες στο διαδίκτυο και έχουν ως γλώσσα γραφής την αγγλική. Η αναζήτηση έγινε με τη βοήθεια του εργαλείου Google scholar, μιας υπηρεσίας της Google που προσφέρει τη δυνατότητα αναζήτησης και πλήρους πρόσβασης σε ακαδημαϊκή βιβλιογραφία και της ScienceDirect, της βιβλιογραφικής βάσης δεδομένων που περιλαμβάνει περιλήψεις και παραπομπές για ακαδημαϊκά άρθρα περιοδικών. Η αναζήτηση περιείχε δημοφιλείς ευέλικτες μεθοδολογίες και λέξεις συνώνυμες της metric και το κλειδί αναζήτησης είχε ως εξής: (agile OR agile metrics OR crystal method OR crystal clear OR dsdm OR dynamic systems development method OR agile unified process OR AUP OR agile modeling OR scrum OR extreme programming OR xp OR kanban OR adaptive software development OR ASD OR feature driven development OR FDD OR lean software development OR LSD) AND (measure* OR metric OR diagnostic OR monitor*) AND (LIMIT-TO(LANGUAGE, English )) Επιπλέον, έγινε γενικότερη αναζήτηση στο διαδίκτυο, με λέξεις και όρους σχετικούς, με τις λέξεις κλειδιά και φράσεις να περιγράφονται στον ακόλουθο πίνακα. Θέμα αναζήτησης Keywords - Agile XP DSDM Agile μεθοδολογίες AUP ASD FDD Scrum Kanban 52

53 Agile Methods Agile practices Extreme Programming Crystal Method Dynamic Systems Development Method Agile Unified Process Adaptive Software Development Feature Driven Development Lean Software Development Software Development Approaches Traditional Development Approaches Using metrics in agile methods Effects of metrics in agile methods Agile metrics Metrics in software development Velocity, Work in progress Remaining task effort Πίνακας 5 Χρήση λέξεων κλειδιών και φράσεων 53

54 Οι πηγές κατόπιν, αξιολογήθηκαν ως προς την τήρηση των ακόλουθων φίλτρων - κριτηρίων: -Είναι κύριο θέμα ανάπτυξης της πηγής, η χρήση μετρικών στις Agile μεθοδολογίες; -Η εμπεριεχόμενη πληροφορία, θεωρείται ως ακριβής δίχως διφορούμενες έννοιες; -Περιέχονται πέρα από περιγραφές για μετρικές, πληροφορίες για λόγους και αποτελέσματα χρήσης; -Εμπεριέχονται πληροφορίες ως προς το είδος των μετρικών οι οποίες ασχολούνται κύρια με την πρόβλεψη της πορείας του έργου; Φίλτρο 1 Κύριο θέμα η χρήση μετρικών σε Agile μεθοδολογίες Φίλτρο 2 Ακριβής Πληροφόρηση Φίλτρο 3 Αναφορά σε λόγους και αποτελέσματα χρήσης μετρικών Φίλτρο 4 Αναφορά σε μετρικές που ασχολούνται με διαδικασίες πρόβλεψης Εικόνα 16 Σχηματική αναπαράσταση της μεθόδου επιλογής των πηγών 54

55 Οι εργασίες αρχικά προσεγγίστηκαν βάση τη σχετικότητα του τίτλου και της περίληψής τους. Εάν ο τίτλος και η περίληψη δεν ικανοποιούσαν τα φίλτρα κριτήρια, οι εργασίες αποκλείονταν. Σε περιπτώσεις όπου ο τίτλος και η περίληψη δεν επαρκούσαν, έγινε ένας πρόχειρος έλεγχος του κειμένου τους. Κατόπιν, όσα έγγραφα θεωρήθηκαν βάση τίτλου και περίληψης ότι ικανοποιούν τα κριτήρια, εξετάστηκαν ως προς το περιεχόμενο, ως προς τη σχετικότητα και τη δυνατότητα κατανόησης του περιεχομένου τους. Το επόμενο βήμα αφορούσε την περαιτέρω μελέτη όσων εργασιών ικανοποίησαν τα προηγούμενα φίλτρα. Για την τελική επιλογή και πρόκριση μιας μελέτης, τέθηκε το κριτήριο του να ικανοποιούν οι μετρικές που αναφέρονται στην εκάστοτε εργασία τα εξής: -να έχουν ένα γενικό πλαίσιο εφαρμογής και να μην περιορίζονται σε εξειδικευμένα έργα και σε εσωτερικές εξειδικευμένες διεργασίες συγκεκριμένων εταιρειών. -να έχουν πληροφορία σχετικά με τον τρόπο υπολογισμού των μετρικών. Η τελική επιλογή περιέλαβε τις εξής πηγές και εργασίες: Τίτλος εργασίας Συγγραφείς Περίληψη Λόγος επιλογής Η εργασία περιέχει σημαντικό πλήθος πληροφοριών για μετρικές ευέλικτων μεθόδων, Progress Monitoring of Agile Contractors. Software Engineering Institute, Will Hayes, Suzanne Miller, Mary Ann Lapham, Eileen Wrubel, Timothy Chick. Agile Metrics: Έρευνα σε σχέση με τη χρήση των ευέλικτων μεθοδολογιών και προτεινόμενες μετρικές. δίνοντας ταυτόχρονα πληροφορίες για τον τρόπο υπολογισμού. Πολλές από τις μετρικές που παρουσιάζονται σχετίζονται με προβλέψεις σχετικά με την εξέλιξη ενός έργου. Η εργασία εστιάζει κυρίως σε μετρικές που έχουν να 55

56 Τίτλος εργασίας Συγγραφείς Περίληψη Λόγος επιλογής Agile Metrics at the Will Hayes, Suzanne Μελέτη για μετρικές, στα κάνουν με τον Israeli Air Force,2005 Miller, Mary Ann πλαίσια της χρήσης της χρονοπρογραμματισμό και Lapham, Eileen Wrubel, μεθόδου XP σε έργα που την ποιότητα επικοινωνίας Timothy Chick αναπτύσσονται από τον πελατών και ομάδας ισραηλινό στρατό. ανάπτυξης. Οι μετρικές που παρουσιάζονται έχουν τέτοια μορφή, ώστε να μπορούν να εφαρμοστούν σε γενικότερο πλαίσιο. Παρουσιάζονται τρόποι υπολογισμού. Πολλές από τις μετρικές της εργασίας σχετίζονται με προβλέψεις σχετικά με την εξέλιξη ενός έργου. Ο βαθμός συμμετοχής των επιμέρους διαφορετικών ρόλων σε ένα έργο, είναι σημαντικός παράγοντας επιτυχίας του έργου. Adding Stakeholder Έρευνα σχετικά με τη Συνεπώς αποκτούν αξία Metrics to Agile Project, Tom Gilb χρήση μετρικών και οι μετρικές που 2006 συμμετεχόντων. σχετίζονται με τους συμμετέχοντες. Στα πλαίσια της εργασίας παρουσιάζεται και η μέθοδος συνολικής διαχείρισης έργου EVO. Toward a framework for evaluating extreme programming, presented at 8th conference on evaluation & assessment Williams, L., Krebs, W., Layman, L., Antón, A. I. and Abrahamsson, P. Έρευνα σε σχέση με τη χρήση της μεθόδου XP στη βιομηχανία παραγωγής λογισμικού. Στην έρευνα μελετάται ο τρόπος χρήσης μετρικών που σχετίζονται με το βαθμό ικανοποίησης του πελάτη σχετικά με την τρέχουσα έκδοση του 56

57 Τίτλος εργασίας Συγγραφείς Περίληψη Λόγος επιλογής in software engineering, συστήματος. Η μέτρηση 2004 της ικανοποίησης του πελάτη είναι ένας σημαντικός προγνωστικός δείκτης της ποιότητας του έργου, καθώς και παράγοντας επαναπρογραμματισμού του. Σε κάθε περίπτωση, σχετίζεται με την πρόβλεψη της εξέλιξης ενός έργου. Επίσης παρουσιάζονται μετρικές που έχουν να κάνουν με την πολυπλοκότητα του προϊόντος, τον έλεγχο λαθών και τα user stories. Στην εργασία εντοπίστηκε προτεινόμενη μετρική για τον καθορισμό της Customization of Scrum Methodology for Outsourced E-commerce Projects, 2010 Nayoung Hong, Junbeom Yoo, Sungdeok Cha Έρευνα που μελετά τροποποιήσεις της μεθόδου Scrum. συνολικής προόδου ενός έργου. Για τη μετρική δίνεται τρόπος υπολογισμού και έχει μορφή κατάλληλη για γενική εφαρμογή στις ευέλικτες μεθόδους. Στο βιβλίο εντοπίστηκαν Software Project Effort Estimation, Foundations and Best Practice Guidelines for Success, 2014 Adam Trendowicz, Ross Jeffery Βιβλίο στο οποίο ερευνώνται θέματα που έχουν να κάνουν με τις εκτιμήσεις κόστους και πληροφορίες σχετικά με τη χρήση μετρικών όσον αφορά τα user stories τα οποία υλοποιούνται στα πλαίσια επαναλήψεων. Οι μετρικές αυτές αποτελούν 57

58 Τίτλος εργασίας Συγγραφείς Περίληψη Λόγος επιλογής προσπάθειας για έργα σημαντικό δείκτη λογισμικού. καθορισμού της παραγωγικότητας της ομάδας ανάπτυξης και ένδειξη της πορείας του έργου όσον αφορά την τήρηση των χρονοδιαγραμμάτων. Η εργασία παρουσιάζει σημαντικές πληροφορίες για μετρικές που έχουν να κάνουν με τα user stories. Παρουσιάζει μετρική για την καταγραφή της μεταβλητότητας των Motivations and measurements in an Agile case study, 2004 Layman, L., Williams, L., Cunningham, L. Εργασία που αφορά εμπειρικές μελέτες σχετικά με τη χρήση μετρικών. απαιτήσεων, ώστε να βγουν χρήσιμα συμπεράσματα τόσο όσον αφορά το επίπεδο αλληλεπίδρασης με τον πελάτη, όσο και για προβλέψεις της πιθανής μεταβλητότητας των απαιτήσεων σε μελλοντικές επαναλήψεις ή εκδόσεις. Στην εργασία Motivations and Measurements in an Agile Case Study, 2006 Lucas Layman, Laurie Williams, Lynn Cunningham Εργασία που αφορά εμπειρικές μελέτες σχετικά με τη χρήση μετρικών. εντοπίστηκαν πληροφορίες που έχουν να κάνουν με μετρικές σχετικές με τους ελέγχους στον κώδικα. Τα αποτελέσματά τους αποτελούν προγνωστικό 58

59 Τίτλος εργασίας Συγγραφείς Περίληψη Λόγος επιλογής δείκτη της ποιότητας του έργου. Εμπεριέχει συστηματική Η εργασία αποτέλεσε Using metrics in Agile καταγραφή της σημαντικό σημείο and Lean Software σχετιζόμενης αναφοράς, καθώς Development A Eetu Kupiainen, Mika V. βιβλιογραφίας και εμπεριέχει ταξινομημένη systematic literature Mantyla, Juha Itkonen. αντιστοίχιση των λίστα με εργασίες που review of industrial μετρικών στις διάφορες αφορούν το θέμα των studies, 2015 φάσης ανάπτυξης του μετρικών στις ευέλικτες έργου μεθοδολογίες. Οι μετρικές earned value, αποτελούν σημαντικούς δείκτες ως προς την Making Agile Development Work in a Government Contracting Environment, Measuring velocity with Earned Value, 2003 Alleman, G. B., Henderson, M., Seggelke R. Παρουσίαση των μετρικών earned value. εκτίμηση του μελλοντικού χρονοπρογραμματισμού και των μεταβολών του κόστους. Οι μετρικές παρουσιάζονται αναλυτικά και περιγράφονται οι τύποι υπολογισμού. Η εργασία παρουσιάζει Exploring Extreme Programming in Context: An Industrial Case Study, 2004 Lucas Layman1, Laurie Williams1, Lynn Cunningham. Εργασία που αφορά τη χρήση της μεθόδου XP. αναλυτικά τον τρόπο υπολογισμού της μετρικής pre-release quality, που αποτελεί ένα δείκτη ποιότητας του έργου. Quality Practices and Problems in Free Software Projects, Martin Michlmayr, Francis Hunt, David Probert. Εργασία που αφορά θέματα σχετικά με τη διασφάλιση της Στην εργασία καταγράφεται η λειτουργία και ο τρόπος υπολογισμού μετρικών που έχουν να κάνουν με 59

60 Τίτλος εργασίας Συγγραφείς Περίληψη Λόγος επιλογής ποιότητας σε έργα το χρόνο που απαιτεί η ελεύθερου λογισμικού. διόρθωση των σφαλμάτων. Στην εργασία παρουσιάζεται η λειτουργία και ο τρόπος Exploring the Transient Nature of Agile Project Management Practices, 2010 Lech Krzanik, Pilar Rodriguez, Jouni Similä. Εργασία που ασχολείται με τη φύση των ευέλικτων μεθόδων. υπολογισμού μετρικών που έχουν να κάνουν με την εκτίμηση της επίδρασης των σχεδιαστικών ιδεών στον προϋπολογισμό του έργου. 60

61 3.3 Πιλοτική μελέτη Οικονομικό Πανεπιστήμιο Αθηνών, Π.Μ.Σ Πληροφοριακά Συστήματα Με στόχο την εξοικείωση με την ερευνητική μέθοδο και το θέμα, πραγματοποιήθηκε πιλοτική μελέτη σε τρία papers τα οποία ικανοποίησαν τα φίλτρα κριτήρια που περιγράφηκαν πιο πάνω. Τα έγγραφα αυτά επιλέχθηκαν με κριτήριο το ενδιαφέρον που προκάλεσε η πρώτη προσέγγιση στο περιεχόμενό τους και τον αριθμό αναφορών. Τα papers είναι τα εξής: Using metrics in Agile and Lean Software Development A systematic literature review of industrial studies των: Eetu Kupiainen, Mika V. Mantyla, Juha Itkonen. Αντικειμενικός στόχος του προαναφερθέντος paper, είναι η αύξηση της γνώσης, όσον αφορά τη χρήση και την επίδραση των μετρικών στις Agile μεθοδολογίες. Εμπεριέχει συστηματική καταγραφή της σχετιζόμενης βιβλιογραφίας και αντιστοίχιση των μετρικών στις διάφορες φάσης ανάπτυξης του έργου. Agile Metrics: Progress Monitoring of Agile Contractors των: Will Hayes, Suzanne Miller, Mary Ann Lapham, Eileen Wrubel, Timothy Chick Η συγκεκριμένη μελέτη, εστιάζει σε μετρικές οι οποίες χρησιμοποιούνται στα πλαίσια των ευέλικτων μεθόδων. Η μελέτη έχει στηριχθεί στην πρακτική εμπειρία και σε διδάγματα από επαγγελματίες του χώρου. Εμπεριέχει αρκετές προτάσεις και ιδέες ως προς την εξέλιξη και τροποποίηση μετρικών, ώστε να παρέχουν εγγύτερα αποτελέσματα. Agile Metrics at the Israeli Air Force, των: Yael Dubinsky, David Talby, Orit Hazzan, and Arie Keren Περιγράφει μια έρευνα, η οποία αφορά τη χρήση της ευέλικτης μεθόδου του ακραίου προγραμματισμού στα πλαίσια εφαρμογών λογισμικού οι οποίες αναπτύσσονται από ομάδες ανάπτυξης του ισραηλινού στρατού. Εμπεριέχει μελέτη για μετρικές, με στόχο τη μελέτη του χρόνου παράδοσης και την αύξηση της συνεργασίας και επικοινωνίας με τους πελάτες. 3.4 Εξόρυξη δεδομένων Η εξόρυξη των δεδομένων, πραγματοποιήθηκε με βάση το πλήρες κείμενο όλων των επιλεγμένων papers. Για κάθε εντοπισμένη μετρική, ακολουθήθηκε η εξής καταγραφή πληροφοριών: 61

62 Αύξον αριθμός μετρικής Οικονομικό Πανεπιστήμιο Αθηνών, Π.Μ.Σ Πληροφοριακά Συστήματα Πραγματοποιήθηκε με απλή αύξουσα ακέραια αρίθμηση ανά ένα και εκκίνηση από τον αριθμό 1. Βοήθησε ως προς το να ερευνηθεί η επαναληπτικότητα αναφοράς στην ίδια μετρική. Ορισμός μετρικής Για κάθε εντοπισμένη νέα μετρική, αναζητήθηκε η ύπαρξη ορισμού στα πλαίσια του εγγράφου. Αν η μετρική είχε ήδη καταγραφεί, αναζητήθηκε η ύπαρξη εναλλακτικού ορισμού. Συζήτηση επί της μετρικής Για κάθε μετρική που εντοπίζονταν, γίνονταν στα περιεχόμενα της εργασίας η αναζήτηση του λόγου για τους οποίους χρησιμοποιείται η εξής μετρική. Μία μετρική απορρίπτονταν από την καταγραφή εάν: -ο λόγος / λόγοι χρήσης δεν είχαν καμία άμεση ή έμμεση σχέση με την πρόβλεψη της πορείας του έργου. -ο λόγος / λόγοι χρήσης είχαν να κάνουν με εσωτερικές εξειδικευμένες διαδικασίες της εταιρείας και δεν είχαν εφαρμογή και αντίκτυπο σε γενικό πλαίσιο 62

63 Αποτελέσματα χρήσης μετρικής Για κάθε εντοπισμένη μετρική, έγινε αναζήτηση στο έγγραφο αποτελεσμάτων και συμπερασμάτων από τη χρήση της 3.5 Σύνθεση δεδομένων Ακολούθησε προσπάθεια ομαδοποίησης των δεδομένων. Για παράδειγμα, τα διαγράμματα burndown ομαδοποιήθηκαν κάτω από τη μετρική της ταχύτητας και οι αστοχίες ανά επανάληψη κάτω από την καταμέτρηση ελαττωμάτων. Οι ομαδοποιήσεις έγιναν βάση της προσπάθειας να βρεθούν εναλλακτικοί τρόποι και μετρικές οι οποίες έχουν παρόμοια στόχευση. Ως προς την κατηγοριοποίηση των μετρικών, ο προβληματισμός υπήρξε ανάμεσα σε δύο εναλλακτικές. Η πρώτη, αφορούσε την ομαδοποίηση με βάση τα συστατικά τα οποία τυπικά χρησιμοποιούνται από μια ομάδα που εργάζεται σε ευέλικτη μεθοδολογία: project tracking, source control, continuous integration, deployment tools και application monitoring [69]. Η δεύτερη, αφορούσε την προσέγγιση του Metrics Educational Toolkit [48]. Επιλέχθηκε η δεύτερη προσέγγιση για τρεις κυρίως λόγους: πρώτον, γιατί προσφέρει έναν ξεκάθαρο και απλό στην προσέγγιση τρόπο ομαδοποίησης, δεύτερον γιατί είναι μια δοκιμασμένη μέθοδος ταξινόμησης και τρίτον γιατί παρόλο που ξεκίνησε σαν ένας τρόπος ομαδοποίησης μετρικών παραδοσιακών μεθόδων, μπορεί να χρησιμοποιηθεί δίχως προβλήματα και ασάφειες και για την κατηγοριοποίηση μετρικών ευέλικτων μεθόδων. 63

64 Κεφάλαιο 4ο. Αναλυτική παρουσίαση μετρικών 4.1 Εισαγωγή Στις παραδοσιακές μεθόδους ανάπτυξης λογισμικού, υπάρχει ένα σημαντικό πλήθος ερευνών που εξετάζουν, προτείνουν, εφαρμόζουν κι επικυρώνουν μετρικές. Στις ευέλικτες μεθοδολογίες, η κατάσταση είναι διαφορετική, καθώς η εμπειρική επικύρωση πολλές φορές εκλείπει. Η ανασκόπηση της βιβλιογραφίας έγινε με τη βοήθεια του Google scholar και της ScienceDirect, μέσω γενικής αναζήτησης στο διαδίκτυο και από δικτυακούς τόπους προσωπικοτήτων του χώρου. Ένας αριθμός άρθρων εξ αυτών, επιλέχθηκε για ενδελεχή έρευνα και ανασκόπηση. Οι μετρικές που χρησιμοποιούνται στις ευέλικτες μεθοδολογίες, παρουσιάζουν ομοιότητες συγκριτικά με αυτές που χρησιμοποιούνται στις παραδοσιακές, αλλά και διαφορές. Οι διαφορές προκύπτουν λόγω της διαφορετικής μεθοδολογίας των ευέλικτων, κυρίως όσον αφορά τους επαναληπτικούς κύκλους ανάπτυξης και τη συχνή παράδοση τμημάτων λογισμικού που λειτουργεί, από τη συμμετοχή των πελατών κατά τη διαδικασία ανάπτυξης, από την έλλειψη μεγάλου όγκου τεκμηριωτικού υλικού και από τις συχνές αλλαγές στις απαιτήσεις. Η διαφοροποίηση αυτή επέφερε ένα βαθμό δυσκολίας ως προς την κατηγοριοποίηση των μετρικών, ακολουθώντας κανόνες ταξινόμησης που είναι ήδη γνωστοί από τις παραδοσιακές μεθόδους. Μια δεύτερη δυσκολία επήλθε στην προσπάθεια να προσεγγιστούν μετρικές οι οποίες έχουν ισχυρό θεωρητικό υπόβαθρο. Έτσι, όσες μετρικές δεν είχαν ξεκάθαρο ορισμό και αναφορά σε σκοπούς και χρήσεις, αποκλείστηκαν. Τέλος, υπήρξε ένα τρίτο επίπεδο δυσκολίας, ως προς την επιλογή αυτών των μετρικών, οι οποίες έχουν άμεσα ή έμμεσα σχέση με την πρόβλεψη της πορείας του έργου. 64

65 4.2 Ταξινόμηση μετρικών Οικονομικό Πανεπιστήμιο Αθηνών, Π.Μ.Σ Πληροφοριακά Συστήματα Η ταξινόμηση και κατηγοριοποίηση των μετρικών έγινε με τη βοήθεια της προσέγγισης του Metrics Educational Toolkit [48]. Ο προτεινόμενος τρόπος κατηγοριοποίησης περιγράφεται στον ακόλουθο πίνακα [48]. Μετρικές προϊόντων Μετρικές διαδικασιών Μετρικές πόρων Μετρικές αρχιτεκτονικής Μετρικές Δομών Μετρικές ποιότητας Μετρικές μεγέθους Μετρικές κύκλου ζωής Μετρικές διαχείρισης Μετρικές ωριμότητας Μετρικές software Μετρικές προσωπικού Μετρικές πολυπλοκότητας Πίνακας 6. Κατηγοριοποίηση μετρικών σύμφωνα με την προσέγγιση Metrics Educational Toolkit. 65

66 4.3 Μετρικές διαδικασιών Μετρικές διαχείρισης Μετρικές velocity Με απλά λόγια, η ταχύτητα αντιστοιχεί στον πραγματοποιούμενο όγκο εργασίας, σε καθορισμένο χρονικό διάστημα και για μια δεδομένη ομάδα. Στη γενικότερη περίπτωση, μπορεί να θεωρηθεί ως ο λόγος της παραδοτέας λειτουργικότητας σε σχέση με την προσχεδιασμένη λειτουργικότητα. Στη βιβλιογραφία υπάρχει ένα σημαντικό πλήθος διαφορετικών ορισμών της μετρικής της ταχύτητας. Ενδεικτικά: -Με δεδομένο ότι η διάρκεια μιας επανάληψης είναι προκαθορισμένη, είναι η μετρική που υπολογίζει την υλοποίηση ενός προσχεδιασμένου χρονοδιαγράμματος [49]. -Είναι η μετρική που υπολογίζει το πλήθος των ιστοριών χρήστη που περιέχει μια συγκεκριμένη έκδοση [50]. -Είναι η μετρική υπολογισμού της ποσότητας εργασίας που απαιτεί ο προγραμματισμός των βασικών τομέων του έργου, σύμφωνα με τις προτεραιότητες της επιχείρησης [51]. Ένας αποτελεσματικός τρόπος υπολογισμού της ταχύτητας ενός έργου, είναι οι προτεινόμενοι από τον Cohn βαθμοί των ιστοριών χρήστη (story points) [49]. Ο υπολογισμός των βαθμών ιστοριών χρήστη υλοποιείται ως εξής: -Οι προγραμματιστές την ομάδας ταξινομούν τα story points με κριτήριο ταξινόμησης το βαθμό δυσκολίας. Ο μικρότερος βαθμός δυσκολίας αντιστοιχεί στο 1, ο μεγαλύτερος στο 5. Δεν αποκλείεται η χρήση διαφορετικής αριθμητικής κλίμακας. -Με αυτόν τον τρόπο δημιουργούνται 5 ομάδες. Οι ομάδες αυτές, έχουν ως αναγνωριστικό τους αριθμούς 1, 2, 3, 4 και 5. Οι βαθμοί των story points, συνδυαστικά με την έννοια του ιδανικού χρόνου μπορούν να αποτελέσουν έναν τρόπο προσδιορισμού της ταχύτητας. Ιδανικός χρόνος, είναι ο χρόνος που απαιτείται για την προγραμματιστική υλοποίηση ενός story point, χωρίς να περιλαμβάνονται οι 66

67 χρόνοι για άλλες δραστηριότητες πέρα του προγραμματισμού. Ένα σαφές μειονέκτημα της διαδικασίας, όπως επισημαίνει και ο Alleman, είναι πως οι μονάδες μέτρησης παραμένουν στατικές, δίχως να απεικονίζουν τη δυναμική φύση τους στην πραγματικότητα, οι μονάδες μέτρησης αλλάζουν κατά την πρόοδο του έργου [52]. Το ακόλουθο διάγραμμα απεικονίζει υπό μορφή στηλών μια μορφή μετρικής ταχύτητας. Εικόνα 17. Κλασική μορφή διαγράμματος στηλών για την μετρική της ταχύτητας[53]. Το ύψος της κάθε στήλης, αντιστοιχεί στην ταχύτητα του κάθε sprint. Η συγκεκριμένη μετρική προσδίδει σημαντικές πληροφορίες για την περαιτέρω εξέλιξη του έργου. Για παράδειγμα, το να αναμένεται στο αμέσως επόμενο sprint η υπό παρακολούθηση ομάδα να παραδώσει 60 story points, μπορεί να θεωρηθεί κρίνοντας τη μέχρι τώρα απόδοσή της, μη ρεαλιστικός στόχος. Επίσης, το να αποδοθεί στην ίδια ομάδα και στα πλαίσια του επόμενου sprint, ένας όγκος εργασίας 10 story points, είναι κάτι που υποτιμά τις πραγματικές δυνατότητες αυτής της ομάδας [53]. 67

68 Η μετρική της ταχύτητας είναι λογικά συνδεδεμένη και με το sprint burn-down chart. Πρόκειται για κλασική τεχνική, η οποία παρέχει ένα μέσο για την προβολή της προόδου μιας ομάδας ανάπτυξης κατά τη διάρκεια ενός sprint. Καθώς τα θέματα που περιέχονται στο backlog ολοκληρώνονται, το διάγραμμα απεικονίζει το ρυθμό και το ποσό της προόδου. Είναι έκδηλο το γεγονός, ότι αυτός ο ρυθμός, πέρα από την καταγραφή της μέχρι τώρα πορείας, εμπεριέχει και γνώση για την μελλοντική εξέλιξη της πορείας του έργου [53]. Εικόνα 18. Παράδειγμα διαγράμματος burn - down ταχύτητας [53]. Στον κατακόρυφο άξονα καταγράφεται ο φόρτος εργασίας που έχει επιλεγεί για το συγκεκριμένο sprint. Από τα αριστερά προς τα δεξιά, αναπτύσσεται η μπλε γραμμή, η πορεία της οποίας καθορίζεται από το πλήθος των υποεργασιών που έχουν ολοκληρωθεί. Ο χρόνος, απεικονίζεται σε ημέρες στον οριζόντιο άξονα. Η διακεκομμένη γραμμή, αντιστοιχεί στην ιδανική γραμμή, με την οποία μπορεί να συγκριθεί η πραγματική έντονη γραμμή. Όταν η έντονη γραμμή αναπτύσσεται κάτω από την ιδανική, σημαίνει ότι ο ρυθμός της ομάδας είναι ταχύτερος από τον ιδανικό. Το αντίθετο συμβαίνει, όταν η έντονη γραμμή αναπτύσσεται πάνω από την ιδανική. Μία συμπληρωματική τεχνική της burn - down ταχύτητας, που καταγράφει τη συνολική πρόοδο του έργου, είναι και η μετρική release burn - up. Μπορεί να χρησιμοποιηθεί για να 68

69 υποδηλώσει το εάν μπορεί να θεωρηθεί εφικτός στόχος, η παράδοση του συνολικού έργου εντός καθορισμένων χρονοδιαγραμμάτων, ή το εάν πρέπει να βελτιωθεί ο ρυθμός απόδοσης για να καταστεί αυτό εφικτό [53]. Εικόνα 19. Παράδειγμα μετρικής release burn up [53]. Στο διάγραμμα αυτό, απεικονίζεται από τα αριστερά προς τα δεξιά και από κάτω προς τα πάνω, η συσσωρευτική αξία της παραδοτέας εργασίας. Η μπλε γραμμή καταγράφει το συνολικό πλήθος των story points που συνθέτουν το όλο έργο και η πράσινη το συσσωρευτικό πλήθος των παραδοτέων. Η διακεκομμένη γραμμή λειτουργεί εκ νέου ως ιδανική, η οποία συγκρινόμενη με την πραγματική πράσινη έντονη γραμμή προσδίδει τον χαρακτηρισμό στον ρυθμό με τον οποίο το έργο αναπτύσσεται. Ως κύρια μειονεκτήματα των κλασικών μεθόδων μετρικής της ταχύτητας, μπορούν να αναφερθούν τα ακόλουθα [53]: -είναι ευαίσθητες σε τοπικές συνθήκες και εποχιακές τάσεις -δε λαμβάνουν υπόψη την πολυπλοκότητα και δυσκολία υλοποίησης των διαφόρων story points. 69

70 Πιθανές τροποποιήσεις και χρήση βοηθητικών μετρικών για την μετρική της ταχύτητας Ο κύριος σκοπός της μετρικής velocity, είναι να βοηθήσει την ομάδα ώστε με ρεαλισμό να συνειδητοποιήσει και να καθορίσει τις δυνατότητές της. Άμεση συνέπεια αυτής της γνώσης, είναι η ανάληψη εκ μέρους της ομάδας μελλοντικών δεσμεύσεων, τις οποίες θα είναι σε θέση να τηρήσει. Κατά τα αρχικά στάδια ενός έργου, είναι αναμενόμενο να παρατηρηθούν διακυμάνσεις στην ταχύτητα. Σε αυτό συντελεί ένα πλήθος παραγόντων, όπως η απειρία στις ακριβείς εκτιμήσεις και το στάδιο προσαρμογής, ώστε να αποκτηθεί η απαραίτητη εμπειρία που απαιτείται σε κάθε νέο έργο. Επίσης, μια πλήρως λειτουργική ομάδα ανάπτυξης στα πλαίσια των ευέλικτων μεθοδολογιών, αναλαμβάνει όλο το εύρος καθηκόντων - ανάλυση απαιτήσεων, αρχιτεκτονική, σχεδιασμός, υλοποίηση, δοκιμή-, κάτι που έρχεται σε αντίθεση με προηγούμενες πρακτικές, όπου μέρος αυτών των καθηκόντων αναλάμβαναν εξωτερικές ομάδες. Είναι ένας επιπλέον παράγοντας που μπορεί να έχει ορατές συνέπειες στην ταχύτητα της ομάδας. Διαφοροποίηση στις agile μεθοδολογίες, υπάρχει και στη διαδικασία της ανακάλυψης και διόρθωσης σφαλμάτων. Σκοπός είναι στο τέλος κάθε sprint να παραδοθεί λειτουργικό τμήμα του έργου. Επομένως, η διαδικασία αυτή μπορεί να υλοποιηθεί με δύο τρόπους: -η ανακάλυψη και η διόρθωση των σφαλμάτων είναι αποκλειστική ευθύνη της ομάδας ανάπτυξης -η ανακάλυψη και η διόρθωση είναι ευθύνη της ομάδας δοκιμών, η οποία δουλεύει παράλληλα με την ομάδα παραγωγής. Και στις δύο περιπτώσεις, αυτό το στάδιο θα πρέπει να ενσωματωθεί στα πλαίσια ενός sprint και είναι κάτι το οποίο επίσης θα πρέπει να ληφθεί υπόψη ώστε να καθοριστεί με μεγαλύτερη ακρίβεια η μετρική της ταχύτητας. 70

71 Μετρική Defect burn - up chart Ο έλεγχος των παραδοτέων κάθε επανάληψης, θεωρείται τμήμα της επανάληψης. Η ομάδα ανάπτυξης στο τέλος κάθε sprint οφείλει να παραδώσει κώδικα ο οποίος λειτουργεί, καθώς και να προσπαθήσει να αντιμετωπίζει προβληματικές καταστάσεις που προέκυψαν από προηγούμενες επαναλήψεις. Σε πολλές περιπτώσεις, υπάρχουν test stories τα οποία συμπεριλαμβάνει ένα sprint, ώστε να ληφθεί υπόψη ο χρόνος που αυτή η διαδικασία απαιτεί. Σε άλλες περιπτώσεις, οι ομάδες προϋπολογίζουν την προσπάθεια για έλεγχο, ως ποσοστό του συνολικού χρόνου που θα απαιτήσει η επανάληψη (για παράδειγμα, 15% του συνολικού χρόνου την επανάληψης, προϋπολογίζεται ως χρόνος για την αντιμετώπιση ελαττωμάτων προηγούμενων επαναλήψεων) [53]. Είναι ιδιαίτερα σημαντικό, το να παρακολουθείται συσσωρευτικά το πλήθος των ελαττωμάτων που έχουν ανακαλυφθεί, καθώς και το πλήθος των ελαττωμάτων που έχουν επιτυχώς αντιμετωπιστεί. Το να υπάρχει μεγάλη διαφορά μεταξύ αυτών των καταμετρητών, σημαίνει πως επιβαρύνονται μεταγενέστερα sprint. Επίσης, όσο αυξάνει η διαφορά των δύο καταμετρητών, τόσο τίθεται σε κίνδυνο η επίτευξη της τελικής ποιότητας του προϊόντος. Η ανάγκη για παρακολούθηση των δύο καταμετρητών, γίνεται πιο επιτακτική στις περιπτώσεις όπου εργάζονται δύο ομάδες: η μία είναι η ομάδα ανάπτυξης, και η άλλη η ομάδα ελέγχου, με τις ομάδες αυτές να εργάζονται παράλληλα. Οι δύο ομάδες θα πρέπει όσο το δυνατόν να συγκλίνουν, ώστε να αποδώσουν βέλτιστα αποτελέσματα. Εάν η ομάδα ελέγχου μείνει πίσω, η ομάδα ανάπτυξης θα χρειαστεί είτε να περιμένει, είτε να προχωρήσει με ρίσκο, δίχως τον έλεγχο των προηγούμενων τμημάτων του κώδικα. Καμία από τις δύο περιπτώσεις δε θεωρείται ιδανική, υπάρχει λοιπόν η ανάγκη για χρήση μετρικής, η οποία θα παρακολουθεί τα δύο πλήθη ελαττωμάτων που περιγράφηκαν πριν. Η μετρική Defect burn - up chart, καταγράφει το πλήθος των ελαττωμάτων που έχουν προκύψει καθώς και αυτά που έχουν αντιμετωπιστεί, κι έχει ως κύριο στόχο το να ειδοποιήσει έγκαιρα ώστε να ληφθούν διορθωτικά μέτρα, σε περιπτώσεις που οι δύο δείκτες αποκλίνουν [53]. Για την καταγραφή της μετρικής, θα μπορούσε να χρησιμοποιηθεί μια μορφή μετρικής διαγράμματος burn - up. 71

72 Εικόνα 20. Παράδειγμα μετρικής διαγράμματος burn - up ελαττωμάτων [53]. Σε αυτό το διάγραμμα, η κόκκινη γραμμή παρακολουθεί συσσωρευτικά το πλήθος των ελαττωμάτων που έχουν προκύψει και η μπλε γραμμή το αντίστοιχο πλήθος αυτών που έχουν αντιμετωπιστεί. Ιδανικά, οι δύο γραμμές θα πρέπει να συμπίπτουν στη διακεκομμένη. 72

73 Μετρικές χειρισμού spikes Οικονομικό Πανεπιστήμιο Αθηνών, Π.Μ.Σ Πληροφοριακά Συστήματα Ο Cohn [49], ορίζει την έννοια spike ως μία εργασία, η οποία εμπεριέχεται σε μια επανάληψη ώστε να αποκτηθεί μια γνώση ή να απαντηθεί μια ερώτηση. Ένα spike, με απλά λόγια, είναι μια σύντομη εργασία η οποία επιλύει ένα θέμα. Σε κάθε περίπτωση, κάθε spike θα πρέπει να είναι χρονικά ορισμένο. Βασική προϋπόθεση θετικής επίδρασης των spikes, είναι το να υπάρχει μέτρο στη χρήση τους. Εάν υπάρχουν πάρα πολλά, θα επιδράσουν αρνητικά στην μετρική της ταχύτητας. Εάν ολοκληρωτικά εκλείπουν, θα υπονομευθεί η ικανότητα της ομάδας να συναντάται με τις απαιτήσεις των πελατών, συνεπώς να επηρεάζονται αρνητικά μετρικές που έχουν να κάνουν με την ικανοποίηση των πελατών. Σε κάθε περίπτωση, η χρήση μετρικών για το χειρισμό των spikes, έχει ιδιαίτερη αξία. Η μετρικές αυτές, πέρα από την απλή καταμέτρηση των spikes που περιλαμβάνει κάθε επανάληψη, μπορούν να αντιστοιχούν στην καταγραφή του χρόνου που αυτά απαιτούν. Αυτό θα έχει ως αποτέλεσμα, το να μπορεί να προϋπολογιστεί το κόστος ενσωμάτωσης των spikes σε μελλοντικές επαναλήψεις, ώστε είτε να γίνει καλύτερη προεκτίμηση του απαιτούμενου χρόνου ολοκλήρωσης, είτε να οδηγήσει στην αφαίρεση από την επανάληψη κάποιων επιμέρους εργασιών, ώστε να ενσωματωθούν τα spikes δίχως να επεκταθεί ο χρόνος ολοκλήρωσης [53]. Μετρική Velocity lag Οι ομάδες, συνεργάζονται καλύτερα και επιτυγχάνουν την απόδοση που αντιστοιχεί στις πραγματικές αθροιστικές δυνατότητες των μελών τους, όταν έχει περάσει ένα αρχικό προσαρμοστικό στάδιο. Έχει παρατηρηθεί, ότι αυτή η απόδοση επιτυγχάνεται από το τρίτο sprint και μετά. Αυτή η παράμετρος, γνωστή στη βιβλιογραφία ως velocity lag, θα πρέπει να λαμβάνεται υπόψη στην εκτίμηση της αναμενόμενης ταχύτητας της ομάδας [53]. Επίσης, είναι σημαντικό να λαμβάνεται υπόψη η επίδραση στην ταχύτητα, που θα έχει η προσθήκη νέων μελών στην ομάδα. Ο προσανατολισμός των νέων μελών, η εξοικείωση με το ρόλο τους και η ανάγκη παλαιότερα μέλη να καταναλώσουν μέρος του χρόνου τους ως βοήθεια στα νέα μέλη, είναι παράγοντες που αν δεν ληφθούν υπόψη θα οδηγήσουν σε λανθασμένες εκτιμήσεις. Αυτή η επίδραση, είναι λογικό να είναι μικρότερης κλίμακας, αν λαμβάνει χώρα κατά τις αρχικές επαναλήψεις, όπου ούτως ή άλλως όλη η ομάδα βρίσκεται σε στάδιο προσαρμογής [53]. 73

74 Μετρική συντελεστή διακύμανσης Ο συντελεστής διακύμανσης, θα μπορούσε να παρέχει μια ένδειξη ως προς τη σταθερότητα στην ταχύτητα μιας ομάδας, η οποία έχει ένα ικανοποιητικό χρονικό διάστημα συνεργασίας. Θα μπορούσε να υπολογιστεί ως εξής [53]: Τυπικήαπόκλιση Σ υντελεστήςδιακύµανσης = *100 Μέση Ο υπολογισμός αυτής της μετρικής για τα σχετικά πρόσφατα sprint, μπορεί να υποδείξει το κατά πόσο μπορεί να χρησιμοποιηθεί η μέση ταχύτητα ως αξιόπιστη μετρική για τα ερχόμενα sprint. Υψηλός συντελεστής διακύμανσης, σημαίνει πως η μέση ταχύτητα ως μέσο πρόβλεψης της απόδοσης της ομάδας κρίνεται ως εξαιρετικά αβέβαιο προγνωστικό μέσο. Αντιθέτως, χαμηλός συντελεστής διακύμανσης, σημαίνει πως με ικανοποιητική ακρίβεια, μπορεί να χρησιμοποιηθεί η μέση ταχύτητα προβλεπτικά. 74

75 Μετρική flow analysis Οικονομικό Πανεπιστήμιο Αθηνών, Π.Μ.Σ Πληροφοριακά Συστήματα Η συγκεκριμένη μετρική, μπορεί να χρησιμοποιηθεί ως ένας αποτελεσματικός τρόπος παρακολούθησης των θεμάτων που βρίσκονται σε διάφορα στάδια, ώστε να αποφευχθούν επικίνδυνες καταστάσεις, όπως το φαινόμενο της συμφόρησης [53]. 1. Ready Κάθε θέμα μπορεί να βρίσκεται σε μία από τις ακόλουθες καταστάσεις: Ο πελάτης έχει ορίσει το user story, η ομάδα ανάπτυξης έχει προβεί στις απαραίτητες εκτιμήσεις και το θέμα είναι έτοιμο να εισέλθει σε επόμενη κατάσταση. 2. Coding Το θέμα έχει τεθεί σε προτεραιότητα, έχει συμπεριληφθεί σε τρέχον sprint και η ομάδα είναι εργάζεται για την υλοποίησή του 3. Testing Το θέμα βρίσκεται στο στάδιο του ελέγχου. 4. Done Το θέμα έχει περάσει με επιτυχία τους ελέγχους και είναι πλέον έτοιμο προς παράδοση 75

76 Στο ακόλουθο διάγραμμα απεικονίζεται αυτή η μετρική, σε καθορισμένο χρονικό σημείο ανάπτυξης του έργου. Εικόνα 21. Παράδειγμα γραφήματος σωρευμένων στηλών 76

77 Στο ακόλουθο διάγραμμα, απεικονίζεται η καταγραφή για τρία sprint διάρκειας δύο εβδομάδων το καθένα, για 30 συνολικά story points. Εικόνα 22. Παράδειγμα σωρευτικού flow diagram Το διάγραμμα αυτό εμπεριέχει αρκετές μετρήσεις που έχουν να κάνουν με την απόδοση. Υπάρχει κατά τη διάρκεια του διαστήματος σχετικά μικρός και άρα ελεγχόμενος αριθμός θεμάτων που βρίσκονται στο στάδιο testing και coding. Η διατήρηση μικρού αριθμού θεμάτων που βρίσκονται σε αυτά τα στάδια, είναι βασική αρχή των agile μεθοδολογιών, καθώς ένας μεγάλος αριθμός τέτοιων θεμάτων μπορεί να σημαίνει πως η ομάδα τείνει να εισέλθει σε κατάσταση συμφόρησης, με αρνητική επίδραση σε ότι έχει ανατεθεί για το μέλλον. Επίσης, διαφαίνεται ο ρυθμός με τον οποίο ολοκληρώνονται θέματα κατά τη διάρκεια αυτών των έξι εβδομάδων, κάτι που μπορεί να βοηθήσει σε εκτιμήσεις σχετικά με τη μελλοντική απόδοση της ομάδας. 77

78 Μετρική καθορισμού απόδοσης ομάδας Μια παραγόμενη από την μετρική της ταχύτητας, θα μπορούσε να είναι και η μετρική που δείχνει τις αλλαγές στην απόδοση της ομάδας καθώς ο χρόνος περνά και ολοκληρώνονται τα sprints. Για παράδειγμα, θα μπορούσε να οριστεί μια μετρική, η οποία αρχίζει και λειτουργεί από ένα συγκεκριμένο sprint και μετά, έστω το τρίτο. Η συγκεκριμένη μετρική, αθροίζει τον αριθμό των story points που παρέδωσε η ομάδα, στα πλαίσια των τριών πιο πρόσφατων sprints. Στηριζόμενοι σε αυτήν τη λογική, μπορεί να παραχθεί πίνακας της ακόλουθης μορφής. Ομάδες sprints Πλήθος παραδοτέων story points Σύγκριση με προηγούμενη ομάδα sprints Πίνακας 7. Η χρήση της προτεινόμενης μετρικής για την παρακολούθηση των αλλαγών στην απόδοση της ομάδας. Αυτό που διαφαίνεται από την πληροφορία που ο πίνακας φέρει, είναι η σταδιακή βελτίωση στην απόδοση της ομάδας, καθώς ο χρόνος περνά. Η μετρική θα μπορούσε να τροποποιηθεί ώστε να λαμβάνει περισσότερο υπόψη τα πιο πρόσφατα sprint, με χρήση διαφορετικών βαρών. 78

79 Stakeholder Metrics Οικονομικό Πανεπιστήμιο Αθηνών, Π.Μ.Σ Πληροφοριακά Συστήματα Ο Tom Gilb, προτείνει τη χρήση μετρικών συμμετεχόντων (stakeholder metrics), για να παρακολουθείται ο βαθμός συμμετοχής, που διαδραματίζει σημαντικό ρόλο ώστε το έργο να είναι επιτυχές, ικανοποιώντας τις απαιτήσεις [54]. Γι αυτό το σκοπό, προτείνει μια μέθοδο διαχείρισης εξέλιξης των έργων, η οποία βασίζεται σε ποσοτικές μετρικές. Η μέθοδος καλείται EVO και περιγράφεται στον ακόλουθο πίνακα. Μέθοδος διαχείρισης εξέλιξης έργων EVO 1. Καταγραφή των stakeholders, που διαδραματίζουν τον πιο κρίσιμο ρόλο στο έργο. Σε κάθε έναν, απόδοση ενός ονόματος. 2. Καθορισμός στόχων, ορισμός μιας κλίμακας μέτρησης για κάθε έναν από αυτούς. 3. Ορισμός προϋπολογισμού για τους πιο περιορισμένους πόρους (για παράδειγμα: χρόνος, άνθρωποι, χρήματα, εξοπλισμός). 4. Σύντομη καταγραφή των στόχων και των προϋπολογισμών, έκτασης το πολύ μιας σελίδας. 5. Επικοινωνία και διαπραγμάτευση με τους καταγεγραμμένους stakeholders, για την επίτευξη συμφωνίας για στόχους και προϋπολογισμούς. 6. Σχεδιασμός προόδου που θα επιτυγχάνεται σε σύντομα χρονικά διαστήματα (evo steps, διάρκειας μιας εβδομάδας ή και μικρότερα). 7. Υλοποίηση του έργου μέσω υλοποίησης των evo steps. Αναφορά στον πελάτη με την ολοκλήρωση κάθε evo step, όσον αφορά την πορεία των στόχων και των προϋπολογισμών. Βάση της ανατροφοδότησης, αλλαγές σε οτιδήποτε απαιτείται. 8. Επίτευξη όλων των στόχων. Πίνακας 8. Τα βήματα της μεθόδου διαχείρισης της εξέλιξης έργων EVO [54] Όσον αφορά την πολιτική έργου, ο Gilb προτείνει την κρίση της ποιότητας και της επιτυχίας του έργου, με βάση τους παράγοντες της επίτευξης των στόχων και της επιτυχούς προσέγγιση των προϋπολογισμών. Οι απολαβές της ομάδας ανάπτυξης θα πρέπει να σχετίζονται με αυτούς τους δύο παράγοντες. Η ομάδα θα πρέπει να βρει το δικό της ρυθμό εργασίας και να είναι ελεύθερη να προτείνει ιδέες και προσαρμογές [54]. 79

80 Μετρική ικανοποίησης πελάτη Η μετρική ικανοποίησης πελάτη (customer satisfaction) καταγράφει την ικανοποίηση του πελάτη ως προς μία συγκεκριμένη έκδοση του προϊόντος. Η συγκεκριμένη μετρική, μπορεί να επηρεάσει άμεσα τη σχεδίαση και τον επαναπρογραμματισμό του έργου, και αποτελεί έναν προγνωστικό δείκτη της ποιότητας του προϊόντος που σταδιακά επιτυγχάνεται. Η πιο συνηθισμένη μορφή της μετρικής, δίνεται ως απάντηση του πελάτη σε ερώτημα της μορφής του πόσο ικανοποιημένος είναι. Οι δυνατές απαντήσεις είναι προκαθορισμένες και αντιστοιχούν σε συγκεκριμένη κλίμακα, π.χ.. από το 1-έως το 5 (1 ελάχιστος βαθμός ικανοποίησης, 5 μέγιστος βαθμός ικανοποίησης) [55] Μετρική προόδου συνολικού έργου Στη μέθοδο scrum και στο τέλος κάθε sprint, λαμβάνει χώρα η συνάντηση ανασκόπησης του sprint. Σε αυτήν τη συνάντηση, ο scrum master υπενθυμίζει τους στόχους που περιελάμβανε το τρέχον sprint και το κάθε μέλος της ομάδας επιδεικνύει το τι παρήγαγε. Ο product owner, καθορίζει το εάν μια εργασία έχει ολοκληρωθεί ή όχι. Εάν υπάρχουν μη ολοκληρωμένες εργασίες, τοποθετούνται σε επόμενο κύκλο sprint. Με το τέλος της συνάντησης ανασκόπησης του sprint, θα πρέπει να ενημερωθεί η κατάσταση της προόδου ολόκληρου του έργου. Στην αυθεντική μέθοδο scrum, η πρόοδος αναπαρίσταται με ένα διάγραμμα burn down. Αυτή η πρόοδος, θα μπορούσε να απεικονιστεί με το πλήθος των υποέργων που έχουν ολοκληρωθεί. Για παράδειγμα, σε ένα έργο κατασκευής ενός δικτυακού τόπου, η πρόοδος θα μπορούσε να καθορίζεται με τον αριθμό των ιστοσελίδων που έχουν ολοκληρωθεί. Σε αυτό το παράδειγμα, η πολυπλοκότητα των υποέργων είναι παρόμοια, συνεπώς το κάθε ένα από αυτά θα έχει τον ίδιο δείκτη βαρύτητας. Σε περιπτώσεις υποέργων διαφορετικής πολυπλοκότητας με διαφορετικούς αναμενόμενους χρόνους ολοκλήρωσης, κάθε υποέργο θα μπορούσε να αντιστοιχεί σε διαφορετικό βάρος. Στον τύπο που ακολουθεί, παρουσιάζεται ο τρόπος με τον οποίο θα μπορούσε να καθοριστεί μετρική για την παρακολούθηση της πραγματικής προόδου του έργου [35]. 80

81 Πραγµατικόποσοστόπροόδου = ολοκληρωµ ένων _ υποέργων *100 συνολικών _ υποέργων Μετρική Burn - down παρουσίασης εργασιών που απομένουν και διαθέσιμων πόρων Η συγκεκριμένη μετρική burn - down, παρουσιάζει τις εργασίες που απομένουν να ολοκληρωθούν, σε συνάρτηση με το διαθέσιμο ανθρώπινο δυναμικό. Αυτή η μετρική, υποστηρίζεται από έναν κύριο πίνακα σχεδιασμού του έργου, ο οποίος εμπεριέχει πληροφορίες για κάθε εργασία και είδος δραστηριότητας (π.χ. κώδικας, δοκιμές,...), ημερομηνίες έναρξης και ολοκλήρωσης, εκτιμώμενους και πραγματικούς χρόνος ολοκλήρωσης κ.α.. Επίσης, η μετρική αυτή υποστηρίζεται από έναν πίνακα ανθρώπινων πόρων [62]. Με τη χρήση αυτών των δεδομένων, η μετρική burn - down μπορεί να απεικονίσει τις εργασίες που απομένουν σε ημέρες, λαμβάνοντας πάντα υπόψη τους διαθέσιμους ανθρώπινους πόρους. Αυτή η πληροφορία θα μπορούσε να παράγεται σε συγκεκριμένα χρονικά διαστήματα, είτε συνολικά για όλη την ομάδα, είτε μεμονωμένα για επιμέρους ομάδες. Η κύρια αξία της μετρικής burn - down είναι η απάντηση στο καίριο ερώτημα: πρόκειται να επιτευχθούν οι στόχοι, και εάν όχι, τι μπορεί να γίνει γι αυτό; Μπορούν να φανούν ιδιαίτερα χρήσιμα, τόσο στους ηγέτες των ομάδων ώστε να επιμερίσουν αρμοδιότητες, όσο και σε στελέχη ανώτερης ιεραρχίας, ώστε να παρακολουθούν το εάν η πρόοδος είναι ικανοποιητική. Ο καθορισμός των στόχων θα μπορούσε να γίνει από τους χρήστες και κάθε στόχος μπορεί αν αντιστοιχεί σε ένα χαρακτηριστικό υψηλής αφαιρετικής προσέγγισης. Σε κάθε στόχο, αντιστοιχεί ένα ποσό εκτιμώμενης προσπάθειας, σε ημέρες και ανθρώπινους πόρους. Με το που καθορίζεται ένας στόχος και αντιστοιχεί σε ποσά εκτιμώμενης προσπάθειας, τα υπόλοιπα εργασίας στηρίζονται σε αυτήν την αρχική προσέγγιση. Καθώς το έργο προχωρά, υπάρχουν επανεκτιμήσεις, για την αποκατάσταση αρχικών τυχόν λανθασμένων εκτιμήσεων. 81

82 Εικόνα 23Διάγραμμα burn - down απεικόνισης εργασιών που απομένουν και διαθέσιμων πόρων για την ολότητα του έργου [62]. Εικόνα 24. Διάγραμμα burn - down απεικόνισης εργασιών συγκεκριμένης επανάληψης, κατηγοριοποιημένης ανά τομέα έργου [62]. 82

83 Συνοπτική παρουσίαση μετρικών διαχείρισης Ο ακόλουθος πίνακας, συνοψίζει τις μετρικές διαχείρισης που αναπτύχθηκαν στην προηγούμενη ανάλυση. Μετρική Περιγραφή Αναφορές Story points και ιδανικός χρόνος Εκτίμηση ταχύτητας, διάρκειας έργου [49] Release burn - up Καθορισμός ταχύτητας και απόδοσης, πρόβλεψη επίτευξης χρονοδιαγραμμάτων [53] Sprint burn-down chart Καταγραφή ολοκληρωμένων εργασιών, καθορισμός ταχύτητας και απόδοσης, πρόβλεψη επίτευξης χρονοδιαγραμμάτων [53] Defect burn - up chart Καταγραφή συνολικού πλήθους ελαττωμάτων και ελαττωμάτων που έχουν αντιμετωπιστεί [53] Spikes Καταμέτρηση spikes, υπολογισμός χρόνου που απαιτούν [49] Velocity lag Velocity lag και επίδραση στην ταχύτητα ομάδας στα διαδοχικά sprints[53] [53] 83

84 Μετρική Περιγραφή Αναφορές Συντελεστής διακύμανσης Υπολογισμός διακυμάνσεων στην απόδοση ομάδας [53] Flow analysis Παρακολούθηση κατάστασης στην οποία βρίσκονται τα υπό ανάπτυξη θέματα [53] Απόδοση ομάδας Παρακολούθηση αλλαγών στην απόδοση ομάδας Stakeholder Παρακολούθηση βαθμού συμμετοχής stakeholders [54] Customer satisfaction Καταγραφή ικανοποίησης πελάτη [55] Πρόοδος συνολικού έργου Παρακολούθηση προόδου έργου [35] Burn down of remaining work and remaining resources Καταγραφή εργασιών που απομένουν, λαμβάνοντας υπόψη τους διαθέσιμους πόρους [62] Πίνακας 9. Συνοπτική παρουσίαση μετρικών διαχείρισης 84

85 4.3.2 Μετρικές κύκλου ζωής Μετρικές που σχετίζονται με user stories Number of user stories per iteration, number of user stories per person month Η μετρική Number of user stories per iteration, καταγράφει το πλήθος των user stories οι οποίες υλοποιήθηκαν στα πλαίσια μιας επανάληψης συγκεκριμένης χρονικής διάρκειας. Με τη βοήθεια της συγκεκριμένης μετρικής, μπορεί να εκτιμηθεί η παραγωγικότητα της ομάδας, και συγκρινόμενη αυτή η παραγωγικότητα με το μέγεθος του έργου, να εκτιμηθεί το εάν είναι εφικτή η τήρηση των χρονοδιαγραμμάτων [56]. Εναλλακτικά και για παρόμοιους σκοπούς, χρησιμοποιείται η μετρική number of user stories per person month, η οποία καταγράφει το πλήθος των user stories που παραδίδονται στον πελάτη σε ένα ανθρωπομήνα [55]. Number of new and changed user stories per release-or per iteration Η μετρική number of new and changed user stories per release-or per iteration, αναφέρεται στο πλήθος των stories που έχουν υλοποιηθεί σε μία επανάληψη ή έκδοση του έργου. Η διαφοροποίηση από την μετρική number of user stories per iteration, έγκειται στο γεγονός ότι λαμβάνει υπόψη τυχόν τροποποιήσεις σε user stories προηγούμενων επαναλήψεων, ως νέα user stories της επανάληψης η οποία υλοποιεί αυτές τις τροποποιήσεις. Το αποτέλεσμα, είναι μια βελτιστοποιημένη προσέγγιση όσον αφορά την εκτίμηση της παραγωγικότητας της ομάδας και του μεγέθους του έργου [55]. Number of user stories postponed for next release Η μετρική number of user stories postponed for next release, καταγράφει τα user stories τα οποία για διάφορους λόγους μετακινούνται προς υλοποίηση σε μεταγενέστερες επαναλήψεις. Μεγάλη τιμή σε αυτήν τη μετρική, μπορεί να υποδηλώνει σημαντικό πρόβλημα ως προς την παραγωγικότητα της ομάδας και ως προς τη δυνατότητα επίτευξης των χρονοδιαγραμμάτων [57]. 85

86 Requirements Dynamism Οικονομικό Πανεπιστήμιο Αθηνών, Π.Μ.Σ Πληροφοριακά Συστήματα Η μετρική requirements dynamism, ορίζεται σαν το άθροισμα των user stories τα οποία διαγράφονται ή προστίθενται διά του πλήθους των user stories που παραδίδονται στο τέλος μιας επανάληψης ή μιας έκδοσης του λογισμικού. Σαν κύριο σκοπό, έχει την καταγραφή της μεταβλητότητας των απαιτήσεων, ώστε να βγουν χρήσιμα συμπεράσματα τόσο όσον αφορά το επίπεδο αλληλεπίδρασης με τον πελάτη, όσο και για προβλέψεις της πιθανής μεταβλητότητας των απαιτήσεων σε μελλοντικές επαναλήψεις ή εκδόσεις [58]. Ο τύπος υπολογισμού της μετρικής ορίζεται ως εξής: Add _ user _ stories + Remove _ user _ stories Requirements _ Dynamism = Total _ user _ stories _ per _ iteration _ or _ edition Μετρικές που σχετίζονται με ελέγχους Test coverage Η μετρική test coverage, καταγράφει το ποσοστό του κώδικα που εξετάζεται σε μια σειρά ελέγχων. Χρησιμοποιείται ως ένδειξη για το ποσοστό του έργου που έχει ελεγχθεί. Η μετρική δεν μπορεί να καταγράψει την ποιότητα των ελέγχων, ωστόσο υψηλές τιμές στην τιμή της μετρικής, σημαίνουν μεγάλη πιθανότητα εύρεσης σφαλμάτων και συνεπώς αυξημένη πιθανότητα υψηλής ποιότητας λογισμικού. Ο υπολογισμός της μετρικής, γίνεται με τη διαίρεση του πλήθους των νέων και τροποποιημένων γραμμών κώδικα που εκτελούνται σε έναν έλεγχο (run lines), δια το συνολικό αριθμό νέων και τροποποιημένων γραμμών κώδικα (total lines). run _ lines Test _ coverage = [59] total _ lines 86

87 Test run frequency Οικονομικό Πανεπιστήμιο Αθηνών, Π.Μ.Σ Πληροφοριακά Συστήματα Η μετρική test run frequency καταγράφει τη συχνότητα εκτέλεσης των ελέγχων. Για να υπολογιστεί, διαιρείται το πλήθος εκτέλεσης των αυτόματων ελέγχων (num1) με τις ημέρες εργασίας της ομάδας ανάπτυξης (num2), στα πλαίσια μιας επανάληψης. Μεγάλες τιμές στη μετρική, υποδηλώνουν ενδελεχή έλεγχο, και συνεπώς μεγάλη πιθανότητα ανακάλυψης των υφιστάμενων σφαλμάτων και ως εκ τούτου, αυξημένη πιθανότητα υψηλής ποιότητας λογισμικού. num1 Test _ run _ frequency = [55] num Μετρικές που σχετίζονται με το σχεδιασμό Μodule breakdown structure Η μετρική module breakdown structure, καταγράφει το πλήθος των διεργασιών που εκτελούνται ταυτόχρονα. Η μετρική μπορεί να φανεί ιδιαίτερα χρήσιμη ως προς τον ορισμό των χρονοδιαγραμμάτων με μεγαλύτερη ακρίβεια. Επίσης, αν έχει εκτιμηθεί ο μέγιστος αριθμός διεργασιών που μπορεί να αναλάβει ταυτόχρονα μια ομάδα ανάπτυξης, αν απαιτηθεί μεγαλύτερη τιμή της μετρικής module breakdown structure, σημαίνει πιθανότατα την ανάγκη ένταξης και νέων μελών στην ομάδα ανάπτυξης. [60] 87

88 Μετρικές earned value Οι μετρικές earned value, βοηθούν στην εκτίμηση του μελλοντικού χρονοπρογραμματισμού και στην εκτίμηση των μεταβολών του κόστους. Στηρίζονται σε τρεις μετρήσεις: το προϋπολογισμένο κόστος για την προγραμματισμένη εργασία (budgeted cost for work scheduled), το προϋπολογισμένο κόστος για την εργασία που υλοποιήθηκε (budgeted cost for work performed) και το πραγματικό κόστος για την εργασία που υλοποιήθηκε (actual cost for work performed) [61]. Το Budgeted Cost For Work Scheduled (BCWS), μετρά το συνολικό προϋπολογισμένο κόστος. Το Budgeted Cost For Work Performed (BCWP) μετρά το προϋπολογισμένο κόστος για την εργασία που έχει ολοκληρωθεί. Τέλος, το Actual Cost For Work Performed (ACWP) μετρά το πραγματικό κόστος για την εργασία που υλοποιήθηκε. Από αυτές τις τρεις μετρήσεις, προκύπτουν οι ακόλουθες μετρικές: Cost Variance CV Καθορίζει τη διαφορά μεταξύ πραγματικού και προϋπολογισμένου κόστους. CV = ACWP BSWS Cost And Schedule Performance Indices (CPI, SPI) Είναι οι ακόλουθοι δείκτες: BCWP CPI = ACWP BCWP SPI = BCWS 88

89 Estimate At Completion (EAC) Εκτιμά το συνολικό κόστος για την υλοποίηση και αντιστοιχεί στο άθροισμα του πραγματικού κόστους της εργασίας που έχει ολοκληρωθεί (ACWP) και του προϋπολογισμένου για την εργασία που απομένει (BCWR). EAC = ACWP + BCWR 89

90 Συνοπτική παρουσίαση μετρικών κύκλου ζωής Ο ακόλουθος πίνακας, συνοψίζει τις μετρικές κύκλου ζωής που αναπτύχθηκαν στην προηγούμενη ανάλυση. Μετρική Περιγραφή Αναφορές Number of user stories per iteration Καταγράφει το πλήθος των user stories που υλοποιήθηκαν σε μια επανάληψη [56] Number of user stories per person month Καταγράφει το πλήθος των user stories που υλοποιήθηκαν σε ένα ανθρωπομήνα [55] Number of new and changed user stories per release-or per iteration Καταγράφει το πλήθος των user stories που υλοποιήθηκαν σε μια επανάληψη ή έκδοση, θεωρώντας τα τροποποιημένα user stories ως νέα user stories. [55] Number of user stories postponed for next release Καταγράφει το πλήθος των user stories που αναβάλλονται για μεταγενέστερη επανάληψη [57] Requirements Dynamism Καταγράφει τη μεταβλητότητα των απαιτήσεων [58] 90

91 Μετρική Περιγραφή Αναφορές Test coverage Καταγράφει το ποσοστό του κώδικα που εξετάζεται σε μια σειρά ελέγχων [59] Test run frequency Καταγράφει τη συχνότητα εκτέλεσης ελέγχων [55] Μodule breakdown structure Καταγράφει το πλήθος των διεργασιών που εκτελούνται ταυτόχρονα [60] Earned Value Εκτίμηση μελλοντικού χρονοπρογραμματισμού και μεταβολών κόστους [61] Πίνακας 10. Συνοπτική παρουσίαση μετρικών κύκλου ζωής. 91

92 4.3.3 Μετρικές προϊόντων Μετρική Product size Οικονομικό Πανεπιστήμιο Αθηνών, Π.Μ.Σ Πληροφοριακά Συστήματα Στόχος της συγκεκριμένης μετρικής, είναι ο καθορισμός της ποσότητας του έργου που έχει ολοκληρωθεί. Πρόκειται για μια μετρική ιδιαίτερης σημασίας, καθώς το να καθοριστεί η ποσότητα αυτή, έχει ως συνέπεια την εξαγωγή συμπερασμάτων ως προς την τήρηση κρίσιμων χρονοπρογραμμάτων του ολικού έργου, καθώς και τυχόν τροποποιήσεις που πρέπει να ενσωματωθούν στην παραγωγική διαδικασία ώστε αυτά τα χρονοδιαγράμματα εν τέλει να τηρηθούν. Ο μηχανισμός που θα μπορούσε να βοηθήσει στον καθορισμό της ποσότητας του έργου που έχει ολοκληρωθεί, είναι σημεία ελέγχου (test points), τα οποία ενσωματώνονται σε κάθε συστατικό και κάθε επανάληψη. Ο αριθμός των test points που θα αντιστοιχούν σε κάθε επιμέρους συστατικό, θα πρέπει να είναι ανάλογος του μεγέθους και της πολυπλοκότητάς του. Η καταμέτρηση των test points που ολοκληρώθηκαν επιτυχώς, που εκτελέστηκαν προβληματικά, καθώς και αυτών που απέτυχαν πλήρως, θα προσδώσει σημαντικές πληροφορίες για την κατάσταση στην οποία βρίσκεται η πρόοδος του έργου [62]. Η μετρική product size, έρχεται να αντιμετωπίσει δύο σημαντικές προβληματικές καταστάσεις. Η μία, είναι η πολλές φορές παρατηρούμενη αδυναμία, να μετρηθεί η πρόοδος του έργου κατά τη μεθοδολογία XP. Η επιλογή των test points που εμπεριέχουν την έννοια της πολυπλοκότητας, και όχι για παράδειγμα του αριθμού των γραμμών του κώδικα που έχει γραφεί, συντελεί σε αυτήν την αντιμετώπιση [62]. Η δεύτερη προβληματική κατάσταση που αντιμετωπίζεται, είναι η συνήθεια του να μη γράφονται ή να μην εκτελούνται αρκετοί έλεγχοι. Έχει παρατηρηθεί η συνήθεια, να προχωρά η παραγωγή και ο συνολικός έλεγχος να αφήνεται σε ένα μεταγενέστερο στάδιο. Αυτό έχει πολλές φορές ως δυσάρεστη συνέπεια, να εντοπίζεται το πρόβλημα καθυστερημένα [62]. Η απεικόνιση της μετρικής, θα μπορούσε να γίνει με τη βοήθεια διαγραμμάτων, σαν αυτά που παρουσιάζονται ακολούθως. 92

93 Εικόνα 25. Καταγραφή επιτυχημένων και αποτυχημένων test points, σε ανάπτυξη τριών επαναλήψεων [62] Εικόνα 26. Καταγραφή επιτυχημένων και αποτυχημένων test points ανά τομέα έργου (5 διαφορετικοί τομείς, πχ ο τομέας 3 θα μπορούσε να αντιστοιχεί στη λειτουργία της βάσης δεδομένων) [62] Software size Η συγκεκριμένη μετρική μπορεί να χρησιμοποιηθεί για να γίνει εκτίμηση το κόστους και του χρονοδιαγράμματος του έργου. Αυτό που έχει σημασία, είναι η μεγιστοποίηση του λειτουργικού 93

94 τμήματος του έργου που παραδίδεται επιτυχώς στον πελάτη κατά τα sprints. Χρησιμοποιώντας την ιεράρχηση του πελάτη, κάθε user story μπορεί να εκτιμηθεί ως προς το μέγεθος του, και αυτά τα μεγέθη να παρουσιαστούν σχετικά [53]. Εικόνα 27. Εκτιμώμενος φόρτος εργασίας για ένα sprint [53]. Το σχετικό μέγεθος του κάθε user story, μπορεί να αποτελέσει μια πηγή πληροφοριών που μπορεί να χρησιμοποιηθεί από την ομάδα ανάπτυξης και τον πελάτη για να εξετασθούν πιθανές αλληλουχίες, όπως: -την υλοποίηση των πιο ορατών χαρακτηριστικών, ώστε οι χρήστες να λάβουν μια εικόνα της λειτουργικότητας -υλοποίηση αρχικά των πιο βασικών και πιεστικών αναγκών -υλοποίηση θεμάτων που λειτουργούν ως υποδομή σε άλλα Σε αυτήν την εξέταση, σημαντικό ρόλο ως προς τις αποφάσεις θα διαδραματίσει και το σχετικό μέγεθος του κάθε θέματος. Η μετρική για το μέγεθος του λογισμικού, μπορεί να χρησιμοποιηθεί ως ένα διαγνωστικό για την απόδοση της ομάδας. Όταν πολλαπλές ομάδες συνεργάζονται για την παράδοση ενός έργου μεγάλης κλίμακας, θα πρέπει να χρησιμοποιούνται ξεχωριστές μετρικές μεγέθους λογισμικού για κάθε ομάδα. Αυτό θα υποδείξει τις προβληματικές καταστάσεις για κάθε ομάδα και θα υποδείξει τα μέτρα βελτίωσης που πρέπει να ληφθούν. 94

95 Putnam Productivity Parameter - PPP Η μετρική PPP αποτιμά την πολυπλοκότητα του προϊόντος και υπολογίζεται από την ακόλουθη σχέση [55]: 9SLOC * B PPP = 4Time* Effort όπου: SLOC: πλήθος γραμμών πηγαίου κώδικα. Β: παράμετρος που σχετίζεται με το μέγεθος του συστήματος και λαμβάνει τιμές σύμφωνα με τον ακόλουθο πίνακα [63]: Μέγεθος SLOC B 5 15K K K K K 0.37 >70K 0.39 Πίνακας 11. Τιμές του Β ανάλογα με το μέγεθος του SLOC. 95

96 Μετρικές ποιότητας Quality and customer satisfaction Η έμφαση στην ποιότητα του έργου, είναι κάτι το οποίο τίθεται σε προτεραιότητα από τα αρχικά στάδια των agile μεθοδολογιών. Ο πελάτης, διαδραματίζει έναν εξέχοντα ρόλο στην ιεράρχηση των user stories, καθώς και στην έγκαιρη ανατροφοδότηση σχετικά με την ικανοποίησή του στο τέλος του κάθε sprint. Το ακόλουθο σχήμα παρουσιάζει μια πιθανή σχετική μετρική [53]. Εικόνα 28. Παρουσίαση touch points ποιότητας [53]. Η επιλογή χρήσης agile μεθοδολογιών, δεν εξαλείφει την ανάγκη χρήσης παραδοσιακών δραστηριοτήτων, όπως οι τυπικές δοκιμές αξιολόγησης και ο εντοπισμός των λαθών. Στις agile μεθοδολογίες, αυτές οι παραδοσιακές όψεις της ποιότητας μπορούν να συμπληρωθούν με πιο άμεσες μετρικές που έχουν να κάνουν με την ικανοποίηση του πελάτη και την αντιληπτή αξία των παραδιδόμενων, χρησιμοποιώντας την ανατροφοδότηση του πελάτη που συλλέγεται κατά τα στάδια που απεικονίζει η Εικόνα 29. Καθώς ο χειρισμός των ελαττωμάτων έχει άμεση επίδραση στην ποιότητα του έργου, θα μπορούσε να χρησιμοποιηθεί επιπλέον μετρική, η οποία να περιγράφει το φόρτο εργασίας που σχετίζεται με τα ελαττώματα. 96

97 Εικόνα 29. Μετρική ανάλυσης ελαττωμάτων με χρήση ενός σωρευτικού flow diagram [53]. Για παράδειγμα, η μοβ απεικόνιση αντιστοιχεί στα ελαττώματα των οποίων η αντιμετώπιση έχει αναβληθεί. Η αύξηση της μοβ περιοχής, μπορεί να υποδεικνύει προβληματική κατάσταση ως προς την έγκαιρη αντιμετώπιση των ελαττωμάτων, με πιθανή αρνητική επίδραση στην ποιότητα του έργου. Pre-release quality Η μετρική pre-release quality, αποτελεί ένα δείκτη ποιότητας των έργων [64]. Ο τρόπος υπολογισμού είναι ο εξής: -Υπολογίζεται το άθροισμα των λαθών που εντοπίζονται στο νέο και τον τροποποιημένο κώδικα. Τα λάθη αυτά εντοπίζονται κατά τον έλεγχο πριν την παράδοση της τρέχουσας έκδοσης στον πελάτη (TE). -Υπολογίζεται το πλήθος των νέων και τροποποιημένων γραμμών του κώδικα(tl). -Υπολογίζεται το ΤΕ δια το TL. Pr e ReleaseQuality = TE TL 97

98 Μετρική Faults Οικονομικό Πανεπιστήμιο Αθηνών, Π.Μ.Σ Πληροφοριακά Συστήματα Η συγκεκριμένη μετρική, αντιστοιχεί στην καταμέτρηση των ελαττωμάτων ανά επανάληψη και μπορεί να διαδραματίσει σημαντικό ρόλο στην πρόβλεψη και τον καθορισμό της ποιότητας του ολικού έργου. Πέρα από το πλήθος των ελαττωμάτων, είναι καθοριστικό να εξακριβωθεί και το είδος τους [62]. Εικόνα 30. Πλήθος και κατηγοριοποίηση λαθών ανά επανάληψη [62] 98