Transcript

1 ΑΡΙΣΤΟΤΕΛΕΙΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΘΕΣΣΑΛΟΝΙΚΗΣ ΣΧΟΛΗ ΘΕΤΙΚΩΝ ΕΠΙΣΤΗΜΩΝ - ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ Μοντέλα Αποτίµησης και Βελτιστοποίησης στον Ακραίο Προγραµµατισµό Πτυχιακή Εργασία του Πολυχρονιάδη Κίµων ΑΕΜ: 798 Επιβλέπων Καθηγητής: ΣΤΑΜΕΛΟΣ ΙΩΑΝΝΗΣ ΘΕΣΣΑΛΟΝΙΚΗ ΦΕΒΡΟΥΑΡΙΟΣ 2007 i

2

3 Πρόλογος Η παρούσα εργασία είναι µία προσπάθεια εξέτασης της «ανθρώπινης» πλευράς των Ευέλικτων Μεθόδων (Agile Methods) και πιο συγκεκριµένα του Ακραίου Προγραµµατισµού (Extreme Programming, XP). Πιο συγκεκριµένα, σκοπός είναι να εξεταστούν, να αναλυθούν και να αξιολογηθούν οι επικοινωνιακές διεργασίες οι οποίες λαµβάνουν χώρα σε περιπτώσεις εφαρµογής των παραπάνω µεθοδολογιών. Κατόπιν, να δοθεί έµφαση στην πλευρά της προσωπικότητας και της ιδιοσυγκρασίας του κάθε µέλους της οµάδας που εφάρµοσε τον Ακραίο Προγραµµατισµό και στο πώς αυτό επηρεάζει την επικοινωνία. Τα αποτελέσµατα και οι αναλύσεις προέκυψαν ύστερα από µια σειρά συνεδριών Προγραµµατισµού σε Ζευγάρια (Pair Programming, PP), και την διαρκή καταγραφή τόσο της προόδου του έργου, αλλά κυρίως των ανθρώπινων αλληλεπιδράσεων και χαρακτηριστικών της προσωπικότητας του κάθε µέλους του ζευγαριού που διαφάνηκαν σε κάθε συνεδρία. Προϊόν της διαδικασίας έρευνας και εφαρµογής των θεωρητικών αναλύσεων ήταν και η εφαρµογή XPortofolio, τα χαρακτηριστικά και ενδελεχής ανάλυση της οποία γίνεται σε µετέπειτα κεφάλαια της παρούσας εργασίας. Οι ρόλοι, οι ικανότητες, οι δεξιότητες του κάθε ατόµου και ο χειρισµός των χαρακτηριστικών αυτών από το ίδιο το άτοµο είναι επίσης ζητήµατα που θέτονται επί τάπητος και ενσωµατώνονται στην ευρύτερη έρευνα και συνεισφέρουν στην παραγωγή των µοντέλων αποτίµησης. i

4

5 Ευχαριστίες Η παρούσα πτυχιακή εργασία εκπονήθηκε στην οµάδα Τεχνολογίας Λογισµικού (Software Engineering Group) του Εργαστήριο Γλωσσών Προγραµµατισµού & Τεχνολογίας Λογισµικού (Programming Languages & Software Engineering, PLASE) του τµήµατος Πληροφορικής του Αριστοτελείου Πανεπιστηµίου Θεσσαλονίκης στα πλαίσια του προγράµµατος προπτυχιακών σπουδών υπό την επίβλεψη του καθηγητή Ι. Σταµέλου. Θα ήθελα να τον ευχαριστήσω για την συνεργασία µας και την εµπιστοσύνη που επέδειξε στο πρόσωπό µου, καθώς και για το ενδιαφέρον που έδειξε στην εκπόνηση της παρούσας εργασίας. Επίσης θα ήθελα να ευχαριστήσω ιδιαίτερα τον καθηγητή Π. Σφέτσο για την πολύτιµη βοήθειά του, την διαρκή παροχή συµβουλών και υποστήριξης και την αµέριστη συµπαράστασή του. Ακόµα, ένα θερµό ευχαριστώ στον συµφοιτητή και άµεσο συνεργάτη κατά την εκπόνηση της πτυχιακής εργασίας Σ. Σκαλιστή για την πολύτιµη βοήθεια και την άριστη συνεργασία που είχαµε. Τέλος, θα ήθελα να ευχαριστήσω την οικογένειά και τους φίλους µου για την υποµονή και στήριξή τους και να τους αφιερώσω αυτή την εργασία. Πολυχρονιάδης Κίµων 17/02/2007 iii

6

7 Περιεχόµενα ΠΡΟΛΟΓΟΣ... I ΕΥΧΑΡΙΣΤΙΕΣ... III ΠΕΡΙΕΧΟΜΕΝΑ... I 1 ΕΙΣΑΓΩΓΗ ΟΜΗ ΕΡΓΑΣΙΑΣ ΒΑΣΙΚΕΣ ΕΝΝΟΙΕΣ ΕΥΕΛΙΚΤΕΣ ΜΕΘΟ ΟΙ (AGILE METHODS) ΑΚΡΑΙΟΣ ΠΡΟΓΡΑΜΜΑΤΙΣΜΟΣ (EXTREME PROGRAMMING) ΠΡΟΓΡΑΜΜΑΤΙΣΜΟΣ ΣΕ ΖΕΥΓΑΡΙΑ (PAIR PROGRAMMING) ΤΟ ΕΡΓΟ ΠΡΟΣ ΑΝΑΠΤΥΞΗ ΟΝΟΜΑΣΙΑ ΓΕΝΙΚΟΣ ΣΚΟΠΟΣ ΡΟΛΟΙ ΠΟΥ ΕΠΙΛΕΧΘΗΚΑΝ ΣΥΝΘΕΣΗ ΟΜΑ ΑΣ Σύσταση µικρής οµάδας Τα οφέλη ΙΚΑΝΟΤΗΤΕΣ ΚΑΙ ΕΞΙΟΤΗΤΕΣ Agile Software Development Ecosystems ASDE Συνδυασµός και αξιολόγηση δεξιοτήτων και ικανοτήτων ΕΡΓΑΛΕΙΑ ΠΟΥ ΧΡΗΣΙΜΟΠΟΙΗΘΗΚΑΝ ΤΟ «ΠΑΙΧΝΙ Ι» ΤΟ ΣΥΝΕΡΓΑΤΙΚΟ ΚΟΜΜΑΤΙ ΤΟΥ ΠΑΙΧΝΙ ΙΟΥ Παράγοντες επιρροής στην συνεργασία Η ΕΠΙΝΟΗΤΙΚΟΤΗΤΑ ΩΣ ΜΕΡΟΣ ΤΟΥ ΠΑΙΧΝΙ ΙΟΥ ΤΟ ΕΠΙΚΟΙΝΩΝΙΑΚΟ ΠΑΙΧΝΙ Ι Η φάσεις της διαπροσωπικής επικοινωνίας i

8 4.4 Ο ΣΥΝ ΥΑΣΜΟΣ ΤΩΝ ΜΕΡΩΝ ΤΟΥ ΠΑΙΧΝΙ ΙΟΥ ΑΤΟΜΙΚΕΣ ΙΚΑΝΟΤΗΤΕΣ ΚΑΙ ΟΜΑ ΙΚΟ ΠΑΙΧΝΙ Ι ΕΜΠΙΣΤΟΣΥΝΗ Εµπιστοσύνη και ικανότητες ΜΕΤΑ ΟΣΗ ΓΝΩΣΗΣ «Σιωπηρή» γνώση «Ρητή» VS «Σιωπηρή» γνώση ΠΡΟΣΩΠΙΚΟΤΗΤΕΣ ΚΑΙ Ι ΙΟΣΥΓΚΡΑΣΙΕΣ Η ΕΠΙΡΡΟΕΣ ΣΤΗΝ ΣΥΝΕΡΓΑΣΙΑ ΚΑΙ ΤΗΝ ΕΠΙΚΟΙΝΩΝΙΑ ιαφωνία στον προγραµµατισµό Εξωγενείς παράγοντες επιρροής ΛΗΨΕΙΣ ΑΠΟΦΑΣΕΩΝ Σηµασία της διαδικασίας λήψης αποφάσεων Ο ανθρώπινος παράγοντας στην διαδικασία λήψης αποφάσεων ΓΕΝΙΚΟΤΕΡΕΣ ΕΠΙ ΡΑΣΕΙΣ ΤΟΥ ΑΝΘΡΩΠΙΝΟΥ ΠΑΡΑΓΟΝΤΑ ΑΝΘΡΩΠΙΝΗ ΜΝΗΜΗ Η ΑΝΘΡΩΠΙΝΗ ΦΥΣΗ ΩΣ ΠΑΡΑΓΟΝΤΑΣ ΕΠΙΤΥΧΙΑΣ «ΈΛΛΕΙΨΗ» ΙΑΓΡΑΜΜΑΤΩΝ ΚΑΙ ΛΟΙΠΩΝ ΑΝΑΠΑΡΑΣΤΑΣΕΩΝ ΑΠΛΑ «ΣΚΑΡΙΦΗΜΑΤΑ» ΑΝΤΙ ΙΑΓΡΑΜΜΑΤΩΝ ΈΛΕΓΧΟΙ ΕΙ Η ΕΛΕΓΧΩΝ ΚΑΙ ΧΡΗΣΙΜΟΤΗΤΑ Έλεγχοι Μονάδων (Unit Tests) Έλεγχοι Ενσωµάτωσης (Integration Tests) Έλεγχοι Λειτουργικότητας (Functionality Tests) Έλεγχοι Αποδοχής (Acceptance Tests) ΠΕΡΙΠΤΩΣΗ ΜΕΛΕΤΗΣ ΑΝΑΠΤΥΞΗ (CASE STUDY) ΠΕΡΙΛΗΨΗ ΣΤΟΧΟΙ / ΣΚΟΠΟΙ ΤΟΠΟΘΕΣΙΑ ii

9 9.4 ΕΜΠΛΕΚΟΜΕΝΑ ΑΤΟΜΑ Σύσταση οµάδας Οι ρόλοι στην οµάδα ανάπτυξης ΑΝΑΠΤΥΞΗ Γενική θεώρηση του Ακραίου Προγραµµατισµού ΟΙ ΠΡΑΚΤΙΚΕΣ ΤΟΥ ΑΚΡΑΙΟΥ ΠΡΟΓΡΑΜΜΑΤΙΣΜΟΥ ΣΤΗΝ ΑΝΑΠΤΥΞΗ ΤΟΥ XPORTOFOLIO Γενική θεώρηση των 12 πρακτικών του XP Οι 12 πρακτικές και η εφαρµογή τους στην ανάπτυξη του XPortofolio Εργαλεία Τεχνολογία Ανάπτυξης ΣΥΜΠΕΡΑΣΜΑΤΑ Ο Ανθρώπινος Παράγοντας Προδιαγραφές κώδικα και Αρχιτεκτονική εικόνα Αναθεώρηση κώδικα Απλή σχεδίαση Έλεγχοι Προγραµµατισµός σε ζευγάρι Συλλογική ιδιοκτησία κώδικα ιαρκής ενσωµάτωση, απλός σχεδιασµός και µικρές εκδόσεις ιαρκής παρουσία πελάτη Το «παιχνίδι» του σχεδιασµού Υποφερτός ρυθµός εργασίας Χρησιµότητα των φορµών ΒΙΒΛΙΟΓΡΑΦΙΑ ΠΗΓΕΣ ΠΑΡΑΡΤΗΜΑ Α ΠΑΡΑΡΤΗΜΑ Β ΠΑΡΑΡΤΗΜΑ Γ ΟΙ ΦΟΡΜΕΣ ΠΡΟΓΡΑΜΜΑΤΙΣΤΩΝ iii

10

11 1 Εισαγωγή Η ανάπτυξη λογισµικού οποιασδήποτε κλίµακας αποτελεί µία διαδικασία η οποία δεν µπορεί να αναλυθεί µε αυστηρά τυπολατρικές µεθόδους. Η σχετικά πιο πρόσφατες µέθοδοι ανάπτυξης, γνωστές ως Ευέλικτες Μέθοδοι εκφράζουν αυτή ακριβώς την τάση και προσπαθούν να βελτιώσουν τις ήδη υπάρχουσες θεωρίες στον τοµέα της ανάπτυξης έργων λογισµικού και όχι να τις εξαλείψουν. Η προσπάθεια αποτύπωσης των βασικών χαρακτηριστικών και δη του Ακραίου Προγραµµατισµού, καθώς και του ρόλου του ανθρώπινου παράγοντα στην όλη διαδικασία, είναι η γενεσιουργός αιτία της παρούσας εργασίας. 1.1 οµή Εργασίας Στο Κεφάλαιο 2 παρουσιάζονται κάποιες βασικές έννοιες του τοµέα της ευέλικτης ανάπτυξης λογισµικού και ανάλυση των χαρακτηριστικών τους. Στο Κεφάλαιο 3 γίνεται µια συνοπτική παρουσίαση του έργου προς ανάπτυξη κατά την εκπόνηση της παρούσας εργασίας. Στο Κεφάλαιο 4 παρουσιάζονται αναλυτικά οι έννοιες και αναλυτική περιγραφή των εννοιών της επικοινωνίας, της συνεργασίας και της επινοητικότητας και του πώς αυτά τα τρία χαρακτηριστικά συνθέτουν ένα «παιχνίδι» όπως συχνά αναφέρεται.. Στο Κεφάλαιο 5 περιγράφονται οι επιδράσεις της προσωπικότητας και των ιδιοσυγκρασιών του κάθε ατόµου κατά την ανάπτυξη ενός έργου λογισµικού και αναφέρονται οι παρατηρήσεις σχετικά µε αυτό το θέµα στην ανάπτυξη του XPortofolio. Στο Κεφάλαιο 6 περιγράφεται ένα γενικότερο πλαίσιο επιδράσεων του ανθρώπινου παράγοντα στην ανάπτυξη λογισµικού και πιο ειδικά στην ανάπτυξη του XPortofolio

12 Στο Κεφάλαιο 7 αναλύονται οι τεχνικές αναπαραστάσεων που χρησιµοποιήθηκαν από την οµάδα ανάπτυξης του XPortofolio και εξηγείται η απουσία κλασσικών διαγραµµατικών τεχνικών και γενικότερων αναπαραστάσεων. Στο Κεφάλαιο 8 γίνεται γενική περιγραφή των ελέγχων και των διαφόρων ειδών τους και ο συνήθης ρόλος τους στην ανάπτυξη έργων λογισµικού. Τέλος, στο Κεφάλαιο 9 παρουσιάζεται η περίπτωση µελέτης (case study) του XPortofolio όπου γίνεται πλήρης ανάλυση της διαδικασίας ανάπτυξης της εφαρµογής, σύνδεση µε το θεωρητικό υπόβαθρο από τα προηγούµενα κεφάλαια και παρουσίαση των συµπερασµάτων και γενικότερων παρατηρήσεων που προέκυψαν από την εκπόνηση της παρούσας εργασίας

13 2 Βασικές έννοιες Για την καλύτερη κατανόηση και σύνδεση των εννοιών που θα ακολουθήσουν στα επόµενα κεφάλαια, είναι θεµιτή µία σύντοµη αλλά περιεκτική περιγραφή (ή υπενθύµιση, για όσους έχουν κάποια εµπειρία µε το θέµα που πραγµατεύεται η εργασία) των εννοιών των Ευέλικτων Μεθόδων, του Ακραίου Προγραµµατισµού και του Προγραµµατισµού σε Ζευγάρια. 2.1 Ευέλικτες Μέθοδοι (Agile Methods) Οι Ευέλικτες Μέθοδοι (Agile Methods), αποτελούν ένα γενικότερο πλαίσιο για την ανάπτυξη έργων λογισµικού. Αναπτύχθηκαν κυρίως στα µέσα τις δεκαετίας του 1990, ως αντίδραση στις «βαριές» µεθοδολογίες (heavyweight) της παραδοσιακής ανάπτυξης λογισµικού. Το 2001, 17 εξέχουσες φυσιογνωµίες από τον χώρο της ευέλικτης ανάπτυξης λογισµικού, συναντήθηκαν στο Snowbird της Utah για να συζητήσουν νέους τρόπους και «ελαφριές» (lightweight) µεθοδολογίες για την δηµιουργία προϊόντων λογισµικού, µε έµφαση στον άνθρωπο. Προϊόν αυτής της συνάντησης ήταν το Agile Manifesto, το οποίο θεωρείται η «Βίβλος» των ευέλικτων µεθόδων και των αρχών τους. Ο Cockburn ορίζει ως πυρήνα των ευέλικτων µεθόδων ανάπτυξης λογισµικού (agile software development methods) την χρήση ελαστικών αλλά αποτελεσµατικών κανόνων συµπεριφοράς αλλά και άνθρωπο-κεντρικών και επικοινωνιο-κεντρικών κανόνων. Η ευέλικτη διαδικασία είναι ελαστική και αποτελεσµατική ταυτόχρονα. Η ελαστικότητα έγκειται στην ανάγκη να υπάρχει δυνατότητα ελιγµών, ενώ η αποτελεσµατικότητα αφορά την ανάγκη µην χάνεται ο στόχος της «παραµονής στο παιχνίδι» («staying in the game») [6]. Τα χαρακτηριστικά ευελιξίας τα οποία προτείνει ο Cockburn συνοψίζονται στα παρακάτω σηµεία («sweet spots») [6]: - 3 -

14 2-8 άτοµα σε κάθε δωµάτιο Αίσθηµα κοινότητας και επικοινωνίας Ειδικοί χρηστικότητας (usage experts) είναι εφικτό να βρίσκονται επί τόπου o Μικροί και διαρκείς κύκλοι ανάδρασης o Μικρή σε έκταση ανάπτυξη και επέκταση κώδικα o 1-3 µήνες σε κάθε κύκλο, ώστε να επιτρέπόνται γρήγοροι έλεγχοι και διορθώσεις Συχνοί έλεγχοι προηγούµενων µονάδων Οι έλεγχοι µονάδων και οι έλεγχοι λειτουργικότητας κάνουν πιο σταθερό τον κώδικα και επιτρέπουν συνεχή βελτίωση. Έµπειροι προγραµµατιστές Η εµπειρία είναι καταλυτικός παράγοντας αύξησης της ταχύτητας. 2.2 Ακραίος Προγραµµατισµός (Extreme Programming) Ο Ακραίος Προγραµµατισµός (Extreme Programming, XP) αποτελεί µία µεθοδολογία ανάπτυξης λογισµικού, ίσως την πλέον χαρακτηριστική από τις ευέλικτες µεθοδολογίες. Ως ευέλικτη µέθοδος, ο Ακραίος Προγραµµατισµός διαφέρει από τις παραδοσιακές µεθοδολογίες στο γεγονός ότι θέτει την προσαρµοστικότητα (adaptability) στο επίκεντρο, αντί της προβλεψιµότητας (predictability). Στηρίζεται στις αρχές των µικρών κύκλων ανάπτυξης, των σαφέστατων αναφορών αποτελεσµάτων και της διαρκούς επικοινωνίας µεταξύ των ατόµων. Έγινε πολύ γρήγορα αποδεκτός στον τοµέα των επιχειρήσεων, όπου υφίσταται η ανάγκη γρήγορης παραγωγής λογισµικού υψηλής ποιότητας αλλά και η δυνατότητα αλλαγής κατεύθυνσης και ευελιξίας, αναλόγως την κατάσταση του επιχειρηµατικού περιβάλλοντος. Οι πρακτικές του Ακραίου Προγραµµατισµού αρχικά προορίζονταν για εφαρµογή σε µικρές οµάδες που τα µέλη της βρίσκονταν στον ίδιο χώρο, παρ όλο που έγιναν προσπάθειες για εκτεταµένη χρήση τους σε µεγαλύτερη κλίµακα. Οι πρακτικές που ακολουθούν δεν είναι αυστηροί κανόνες, αν και συχνά παρουσιάζονται ως τέτοιες, αλλά οδηγίες και προτάσεις οι οποίες είναι αρκετά εύπλαστες ώστε να ταιριάζουν στην εκάστοτε κατάσταση [6].

15 Το παιχνίδι της σχεδίασης (The planning game) Η σχεδίαση στον ακραίο προγραµµατισµό είναι αντιπροσωπευτική των ευέλικτων µεθόδων. Μικρές επαναλήψεις διάρκειας 3 εβδοµάδων, συχνές αναθεωρήσεις της σχεδίασης και ανάθεση «ιστοριών» (user stories) είναι τα χαρακτηριστικά της σχεδίασης στον Ακραίο Προγραµµατισµό. Μικρές παραδόσεις (Small releases) Κάθε παραδοτέα µονάδα του συστήµατος θα πρέπει να περιέχει όσο το δυνατόν µικρότερη λειτουργικότητα, υπό την έννοια ότι θα πρέπει να είναι περιορισµένη κατά το δυνατόν στις επιχειρησιακές απαιτήσεις. Αρχιτεκτονική εικόνα (Metaphor) Η έννοια της µεταφοράς έχει να κάνει µε την προσπάθεια να βρεθεί ένα κοινό σηµείο επικοινωνίας και κατανόησης µεταξύ των προγραµµατιστών και του πελάτη. ίνει µια γενική εικόνα του συστήµατος, ώστε τόσο η οµάδα ανάπτυξης, όσο και η πλευρά του πελάτη να µπορούν να διατηρούν την γενική εποπτεία. Συχνά συγχέεται µε την αρχιτεκτονική του συστήµατος, από την οποία όµως διαφέρει ως προς το ότι είναι πιο αφαιρετική και λιγότερο λεπτοµερής (συνδέσεις, σύµβολα κτλ) από την αρχιτεκτονική. Απλή σχεδίαση (Simple design) Η εφαρµογή αυτής της πρακτικής απαιτεί δύο στοιχεία: Σχεδίαση για την παρούσα ορισµένη λειτουργικότητα, όχι για πιθανές µελλοντικές λειτουργίες ηµιουργία της απλούστερης δυνατής σχεδίασης για την µετέπειτα υλοποίηση της επιθυµητής λειτουργίας. Αναθεώρηση κώδικα (Refactoring) Συχνά θεωρείται η ειδοποιός διαφορά του Ακραίου Προγραµµατισµού από τις άλλες προσεγγίσεις ανάπτυξης. Η αναθεώρηση του κώδικα έχει να κάνει µε την διαρκή επανασχεδίαση και τροποποίηση του κώδικα, ώστε να είναι πιο δεκτικός στις µελλοντικές αλλαγές. Έλεγχοι (Testing) Στον Ακραίο Προγραµµατισµό συναντώνται κυρίως δύο είδη ελέγχων: Μονάδων (Unit) - 5 -

16 Λειτουργικότητας (Functional) Αξίζει να σηµειωθεί πως οι έλεγχοι µονάδων συνήθως ετοιµάζονται πριν την συγγραφή του κώδικα. Γενικότερα, οι έλεγχοι θα πρέπει να είναι αυτοµατοποιηµένοι, υπό την έννοια ότι µόλις τελειώσει η συγγραφή του κώδικα, θα πρέπει να γίνεται χρήση κάποιου πακέτου ή «σουίτας» (suite) ελέγχων και να ακολουθεί άµεση ανατροφοδότηση της οµάδας µε πληροφορίες ως ανάδραση. Προγραµµατισµός σε ζευγάρια (Pair Programming, PP) Μία από τις λίγες πρακτικές που χαίρει σχεδόν καθολικής αναγνώρισης είναι η εποπτεία του κώδικα. Στην βέλτιστη περίπτωση, παρατηρείται αύξηση της ταχύτητας εκµάθησης και ανάνηψης από λάθη, ενώ στην χειρότερη παρατηρείται µία σειρά από προσωπικές διενέξεις και γραφειοκρατική «έκρηξη» µετρικών και αναφορών. Η διαρκής εποπτεία του κώδικα δεν µειώνει µόνο το κόστος επιδιόρθωσης λαθών, αλλά µειώνει και την πιθανότητα εµφάνισής τους εξ αρχής. Ο προγραµµατισµός ανά ζεύγη πάει την απλή παρακολούθηση κώδικα ένα βήµα παραπέρα, καθώς δεν υφίσταται απλά αυξητική εκµάθηση αλλά διαρκής πρόσκτηση γνώσεων. Όπως αναφέρει ο Kent Beck «ο προγραµµατισµός σε ζεύγη είναι ένας διάλογος µεταξύ δύο ανθρώπων που προσπαθούν ταυτόχρονα να προγραµµατίσουν και να κατανοήσουν το πρόγραµµα καλύτερα» [6]. Η ταυτόχρονη εργασία δύο ατόµων µπροστά στον ίδιο υπολογιστή, µε το ένα να ασχολείται µε κώδικα ή ελέγχους και το άλλο να εποπτεύει και να σκέφτεται δηµιουργεί µία διαρκή συνδιαλλαγή δυναµικού χαρακτήρα. Συλλογική ιδιοκτησία (Collective ownership) Η συλλογική ιδιοκτησία δίνει σε κάθε µέλος της οµάδας ανάπτυξης το δικαίωµα να τροποποιήσει οποιοδήποτε µέρος του κώδικα οποιαδήποτε στιγµή. Θα µπορούσε να θεωρηθεί επέκταση του συνεργατικού πνεύµατος που προσπαθεί να περάσει ο προγραµµατισµός σε ζευγάρια. Αντί µόνο δύο άτοµα να δουλεύουν συνεργατικά, προκύπτει συνεργασία µεταξύ όλων των µελών της οµάδας. ιαρκής ενσωµάτωση κώδικα (Continuous integration) Στις περισσότερες εταιρείες λογισµικού, οι καθηµερινές ενσωµατώσεις µονάδων στο υπό ανάπτυξη σύστηµα είναι κάτι το συνηθισµένο. Στον ακραίο προγραµµατισµό, αυτή η προσέγγιση θεωρείται αναποτελεσµατική, µε τις συχνές ενσωµατώσεις κάθε λίγες ώρες να θεωρούνται πιο κατάλληλες. Οι κίνδυνοι των ελαττωµατικών - 6 -

17 ολοκληρώσεων υφίστανται πάντα, αλλά η πειθαρχία στον ακραίο προγραµµατισµό και τα καινούρια εργαλεία προσδίδουν στην υπάρχουσα γνώση περί κινδύνων µία προληπτική πλέον ιδιότητα. Υποφερτός Ρυθµός Εργασίας (40-hour week) Η φιλοσοφία στον περιορισµό των ωρών εργασίας σε 40 την εβδοµάδα, έχει να κάνει µε την αποφυγή υπερκόπωσης, σωµατικής και πνευµατικής, οπότε και εµφανίζονται συµπτώµατα εκνευρισµού, έλλειψης όρεξης και µείωσης παραγωγικότητας. ιαρκής παρουσία πελάτη (On-site customer) Η πρακτική αυτή έχει να κάνει µε την χρόνια απαίτηση για «εξέλιξη» του ρόλου του πελάτη. Ο ακραίος προγραµµατισµός απαιτεί την διαρκή παρουσία του πελάτη στον χώρο εργασίας της οµάδας έργου. Προδιαγραφές κώδικα (Coding standards) Οι πρακτικές του Ακραίου Προγραµµατισµού είναι αλληλεξαρτώµενες. Συνεπώς, εάν κάποιος προγραµµατίζει σε ζευγάρι και επιτρέψει σε κάποιον συνεργάτη την τροποποίηση του συλλογικού κώδικα, είναι απαραίτητη η ύπαρξη συγκεκριµένων προδιαγραφών για την κωδικοποίηση. 2.3 Προγραµµατισµός σε Ζευγάρια (Pair Programming) Κατά τον προγραµµατισµό σε ζευγάρια (Pair Programming,PP), δύο προγραµµατιστές δουλεύουν συνεργατικά πάνω στον ίδιο αλγόριθµο, την σχεδίαση ή το προγραµµατιστικό µέρος µίας εφαρµογής. Η εργασία τους λαµβάνει χώρα στον ίδιο υπολογιστή, µε τους προγραµµατιστές να κάθονται ο ένας δίπλα στον άλλον. Ο προγραµµατισµός σε ζευγάρια έχει γίνει ευρέως αποδεκτός τις τελευταίες δεκαετίες, καθώς αποτελεί µία βελτιωµένη µέθοδο συγγραφής κώδικα. Μερικές από τις πιο έντονες επιθέσεις που έχει δεχθεί ο Ακραίος Προγραµµατισµός αφορά τον προγραµµατισµό σε ζεύγη. Παρά το γεγονός ότι µπορεί να θεωρηθεί επέκταση ή ακόµα και βελτίωση της συνεργατικής πρακτικής της επανεξέτασης κώδικα, πολλοί πιστεύουν ότι η εργασία σε ζευγάρι είναι αλλόκοτη, ανατρεπτική και απειλητική για την ατοµικότητά τους. Ο προγραµµατισµός τόσο στην εκµάθησή του όσο και στην εφαρµογή του, αποτελούσε µία παραδοσιακά ατοµική δραστηριότητα. Πολλοί έµπειροι - 7 -

18 προγραµµατιστές είναι αρνητικοί στην ιδέα του προγραµµατισµού µε άλλο άτοµο. Αισθάνονται ότι ο κώδικας αποτελεί «προσωπική ιδιοκτησία τους» και ότι ένας συνεργάτης αποτελεί παράγοντα καθυστέρησης. Μία άλλη άποψη υποστηρίζει ότι η εργασία µε άλλο άτοµο µπορεί να προκαλέσει πρόβληµα στην κατανοµή του χρόνου εργασίας (εργατοώρες work hours) ή στο πλάνο παραγωγής των διαφόρων εκδόσεων (versions) του κώδικα [1]. Ένας ακόµη λόγος που το συµβατικό προγραµµατιστικό κατεστηµένο εναντιώνεται στην εργασία σε ζευγάρια είναι ο ισχυρισµός ότι ουσιαστικά απαιτούνται δύο άτοµα για την διεκπεραίωση µίας εργασίας την οποία θα µπορούσε να φέρει εις πέρας µόνο ένας εργαζόµενος. Οι περισσότεροι διευθυντές έργων λογισµικού, βλέπουν τους προγραµµατιστές ως µία σπάνια «πρώτη ύλη», την οποία είναι µάλλον απρόθυµοι να την σπαταλήσουν διπλασιάζοντας τον αριθµό των ανθρώπων που απαιτούνται για την ανάπτυξη του κώδικα [1]. Την ίδια στιγµή, πολλοί εξέχοντες προγραµµατιστές προτιµούν να εργάζονται σε ζευγάρια. Οι πιο έµπειροι εξ αυτών, αναφέρονται στον προγραµµατισµό σε ζευγάρια ως µία µέθοδο ανάπτυξης λογισµικού που προσφέρει «τουλάχιστον διπλάσια ταχύτητα» κατά την ανάπτυξη του λογισµικού. Μετρήσεις υποδεικνύουν ότι το προϊόν του σχεδιασµού που γίνεται σε ζευγάρια είναι καλύτερο, που συνεπάγεται πιο απλό κώδικα και συνεπώς πιο εύκολα επεκτάσιµο και τροποποιήσιµο. Ακόµα και σχετικά άπειροι προγραµµατιστές µπορούν να συµβάλλουν στον κώδικα ενός ειδήµονα προγραµµατιστή [1]

19 3 Το έργο προς ανάπτυξη Στην επιλογή του έργου το οποίο θα αναπτυσσόταν στα πλαίσια της παρούσας εργασίας µεγάλο ρόλο έπαιξε η διάθεση αφ ενός να εφαρµοστούν οι αρχές και οι πρακτικές του Ακραίου Προγραµµατισµού και αφ ετέρου να υπάρξει κάποιο προϊόν αυτής της µεθοδολογίας το οποίο θα µπορούσε να χρησιµεύσει περαιτέρω σε συνθήκες Ακραίου Προγραµµατισµού. 3.1 Ονοµασία Γενικός Σκοπός Το όνοµα που επιλέχθηκε για την προς ανάπτυξη εφαρµογή είναι «XPortofolio», όνοµα αντιπροσωπευτικό της µεθόδου ανάπτυξής του και της χρησιµότητάς του. Σε ότι αφορά την χρησιµότητα, σκοπός της ανάπτυξης ήταν η παραγωγή ενός προγράµµατος ικανού να εξυπηρετήσει τις ανάγκες χρονοπρογραµµατισµού και δηµιουργίας πλάνου µίας µικρής εταιρείας λογισµικού, η οποία εφαρµόζει ευέλικτες µεθόδους και συγκεκριµένα τον ακραίο προγραµµατισµό. Περισσότερες και πιο λεπτοµερείς αναλύσεις και πληροφορίες σχετικά µε το XPortofolio βρίσκονται στο κεφάλαιο 9. Επιπλέον, θα χρησιµεύει στην διευκόλυνση της γενικής εποπτείας του εκάστοτε έργου, τόσο στον τοµέα µετρικών και γενικότερα των «αριθµών», όσο και στις διάφορες εκφάνσεις της ανθρώπινης πλευράς του έργου. Άλλωστε, οι Jim Highsmith και Alistair Cockburn συµφωνούν ότι «το καινούριο που προσφέρουν οι ευέλικτες µέθοδοι δεν είναι οι πρακτικές που χρησιµοποιούν, αλλά η αναγνώριση του ανθρώπου ως τον κυριότερο παράγοντα επιτυχίας του εκάστοτε έργου» [3]. Εν κατακλείδι, αυτό το οποίο έχει γίνει απόπειρα να επιτευχθεί, είναι «XP για τον XP», υπό την έννοια ότι εφαρµόστηκαν αρχές του Ακραίου Προγραµµατισµού για την παραγωγή λογισµικού διαχείρισης έργων από οµάδες Ακραίου Προγραµµατισµού

20 3.2 Ρόλοι που επιλέχθηκαν Οι ρόλοι που συµβατικά ανατίθενται σε ένα έργο ανάπτυξης λογισµικού αναλύονται παρακάτω. Αναλόγως τις ανάγκες και τις συνθήκες ανάπτυξης οι ρόλοι και οι αρµοδιότητες των εµπλεκοµένων µπορεί να διαφέρουν, ωστόσο έγινε επιλογή τους µε βάσει τις πλέον αντιπροσωπευτικές και συχνές περιπτώσεις κατανοµής ρόλων και αρµοδιοτήτων [4,5]. ιαχειριστής (Manager) Ο διαχειριστής του έργου θεωρείται πως είναι ο γενικός υπεύθυνος του έργου, έχοντας την υψηλή εποπτεία. Είναι ο αποδέκτης όλων των αναφορών από τα υπόλοιπα µέλη της οµάδας (προγραµµατιστές, υπεύθυνοι ελέγχων κτλ) και επωµίζεται την ευθύνη λήψης σηµαντικών αποφάσεων βάσει των αναφορών αυτών, αλλά και των συναντήσεων (meetings) η οποίες συγκαλούνται κάθε εβδοµάδα ή όποτε χρειάζεται και θεωρείται ορθό. Συνήθως είναι κάποιος «βετεράνος» στην εφαρµογή του Ακραίου Προγραµµατισµού αλλά και της ανάπτυξης λογισµικού γενικότερα κατάλληλα καταρτισµένος, µε έµφαση στις αρχηγικές ικανότητες (leadership) και στην δυνατότητα διατήρησης των ισορροπιών. Πελάτης (Customer) Ο πελάτης είναι η απαρχή κάθε έργου ανάπτυξης λογισµικού. Στην παρούσα εργασία, ως πελάτης θεωρείται ο «on-site» customer, υπό την έννοια ότι σε κάθε φάση της ανάπτυξης του λογισµικού, είναι παρών ένας αντιπρόσωπος του εργοδότη (employer). Η κυριότερη ασχολία του πελάτη είναι ο καθορισµός των απαιτήσεων, οι οποίες συχνά µπορεί να µεταβάλλονται, σε συνεργασία µε κάποιον ειδικό επί της καταγραφής και αξιολόγησής τους, συνήθως κάποιον από την οµάδα που αναπτύσσει το πρόγραµµα (developer). Προγραµµατιστής (Developer) Ο προγραµµατιστής θεωρείται υπεύθυνος επί του σχεδιασµού αλλά και του προγραµµατιστικού µέρους της ανάπτυξης του λογισµικού. Ανά τακτά χρονικά διαστήµατα (συνήθως ανά βδοµάδα, ή και κάθε µέρα, ακόµα και σε κάθε περίπτωση σύγκλησης συσκέψεως της οµάδας), συνθέτει µία αναφορά µε το χρονοδιάγραµµά του (developer s schedule), ενώ φροντίζει να ενηµερώνει τον υπεύθυνο ανθρωπίνων πόρων για τυχόν προβλήµατα συνεργασίας ή επικοινωνίας µε τον συνεργάτη του (partner) κατά την εργασία

21 Υπεύθυνος ανθρωπίνων παραγόντων (Coach) Είναι ίσως ο κύριος εκφραστής και ο συστατικός κόµβος των µετρικών και γενικότερα των αναφορών σε ότι έχει να κάνει µε τους ανθρώπινους παράγοντες στην διαδικασία του Ακραίου Προγραµµατισµού. Η κυριότερη ασχολία του υπεύθυνου ανθρώπινων παραγόντων είναι η παρατήρηση και καταγραφή στην αναφορά τυχόν προβληµάτων ή κωλυµάτων που προκύπτουν στην συνεργασία και απόδοση των διαφόρων µελών της οµάδας του έργου. Η αναφορά του προς τον διαχειριστή του έργου αφορά κυρίως προβλήµατα απόδοσης κάποιου ζευγαριού, επισήµανση χαρακτηριστικών κάποιου µέλους της οµάδας κ.ά. Υπεύθυνος στατιστικών και µετρικών (Tracker) Το «µαθηµατικό» µέρος του έργου το αναλαµβάνει ο υπεύθυνος επί των στατιστικών και µετρικών. Η εργασία του περιλαµβάνει τις «απρόσωπες» µετρικές και αποτιµήσεις κατά την διάρκεια του έργου, όπως το εκτιµώµενο ποσοστό ολοκλήρωσης του έργου, την εκτιµώµενη ηµεροµηνία παράδοσης του κάθε τµήµατος του λογισµικού, τις µετρήσεις των ελέγχων και των περιπτώσεων ελέγχων (test cases). Η αναφορά του προς τον διαχειριστή του έργου λοιπόν περιλαµβάνει κυρίως µαθηµατικές-στατιστικές µετρήσεις, απαραίτητες για έναν πιο σαφή προσδιορισµό της τρέχουσας κατάστασης και ακριβέστερο προσδιορισµό της πορείας του έργου. Υπεύθυνος ελέγχων (Tester) Αν και στις περισσότερες επιχειρήσεις Ακραίου Προγραµµατισµού ο υπεύθυνος ελέγχων συχνά θεωρείται πολυτέλεια να είναι ξεχωριστό άτοµο από τους προγραµµατιστές, θεωρήθηκε ορθό, χάριν πληρότητας, να συµπεριληφθεί στους ρόλους ενός έργου Ακραίου Προγραµµατισµού. Υπεύθυνος για την διενέργεια και την καταγραφή των αποτελεσµάτων των ελέγχων (tests), ο υπεύθυνος ελέγχων συνεργάζεται στενά µε τον υπεύθυνο ανθρώπινων παραγόντων για την παραγωγή των µετρικών σχετικά µε τους ελέγχους. Είναι επίσης υπεύθυνος για την διαβεβαίωση ότι το προκύπτον λογισµικό έχει όσο το δυνατόν λιγότερα σφάλµατα και λάθη, ενώ φροντίζει να δηµιουργεί αυτοµατοποιηµένους ελέγχους για εξοικονόµηση χρόνου. Εξωτερικός σύµβουλος (Consultant) Όπως και ο υπεύθυνος ελέγχων, έτσι και ο εξωτερικός σύµβουλος µπορεί να θεωρηθεί «είδος πολυτελείας» για την πλειονότητα των ολιγοµελών οµάδων Ακραίου Προγραµµατισµού. Ο εξωτερικός σύµβουλος είναι συνήθως κάποιος εξωτερικός συνεργάτης, ο οποίος καλείται «εκτάκτως» σε περιπτώσεις όπου απαιτείται κάποια

22 εξειδικευµένη γνώση σε θέµατα υλικού, λογισµικού ή άλλου τοµέα, ως γνώστης της εκάστοτε περίπτωσης. 3.3 Σύνθεση οµάδας Για τους σκοπούς της εργασίας δεν ήταν απαραίτητη η σύσταση µιας πολυπληθούς οµάδας, όπου θα ήταν διαθέσιµο ένα άτοµο για κάθε ρόλο. Έτσι, η οµάδα αποτελούταν από δύο άτοµα, τον Κίµων Πολυχρονιάδη και τον Στέφανο Σκαλιστή, οι οποίοι και διαµοιράστηκαν όλους τους ρόλους κατά την ανάπτυξη του έργου Σύσταση µικρής οµάδας Τα οφέλη Η δυνατότητα που δόθηκε στην οµάδα µε την ύπαρξη ενός µόνο ζευγαριού ήταν προφανώς η επικέντρωση και καλύτερη κατανόηση του προγραµµατισµού σε ζευγάρι. Προφανώς και έλαβαν µέρος και άλλες διεργασίες κατά την ανάπτυξη της εφαρµογής, ωστόσο δόθηκε ιδιαίτερη έµφαση στην πλευρά του προγραµµατισµού σε ζευγάρι, καθώς εµφανίζεται ιδιαίτερη επικοινωνιακή δράση από τα εµπλεκόµενα άτοµα. Το µείζον θέµα δεν είναι χρηστικότητα και η πρακτικότητα του προγραµµατισµού σε ζευγάρια και της συλλογικής ιδιοκτησίας του κώδικα. Σε αυτή την φάση το πραγµατικό ζήτηµα είναι εάν και κατά πόσον τα µέλη µιας τέτοιας οµάδας (ακόµα και δύο ατόµων ) θα εφαρµόσουν τις πρακτικές τις συνεργασίας και της επικοινωνίας ή θα υλοποιούν πρακτικές που αποτελούν «µεταλλάξεις» των αρχών του Ακραίου Προγραµµατισµού αλλά στην πραγµατικότητα προβαίνουν στην ανάπτυξη του έργου µε συµβατικές µεθόδους. Η ύπαρξη δύο µόνο ατόµων στη οµάδα ήταν ευεργετική, ιδιαίτερα στον τοµέα της επικοινωνίας. Η ευελιξία που δίνει µία τέτοια οµάδα έχει σαφείς προεκτάσεις (ίσως και το επίκεντρό της) στον επικοινωνιακό τοµέα, όπου οι συζητήσεις, τα «µίνι-συµβούλια» και οι εποικοδοµητικές διαφωνίες και ανταλλαγή απόψεων ήταν η κυριότερη έκφανση του ανθρώπινου παράγοντα στον Ακραίο Προγραµµατισµό. Τα παραπάνω οφέλη θα αναλυθούν πιο διεξοδικά στις επόµενες ενότητες. 3.4 Ικανότητες και εξιότητες Στις αρχικές συζητήσεις που προηγήθηκαν της συγγραφής κώδικα, έγινε επιλογή της Java για την ανάπτυξης του XPortofolio, την οποία γνώριζαν και τα δύο µέλη της

23 οµάδας. Η αµοιβαία γνώση της Java δεν παρουσίασε οφέλη µόνο κατά τον προγραµµατισµό, αλλά και στις συζητήσεις και συσκέψεις οι οποίες έλαβαν µέρος κατά την περίοδο ανάπτυξης της εφαρµογής. Η Java ως κοινό σηµείο αναφοράς αποτελούσε µία στερεή βάση επικοινωνίας και παράγοντα βελτιστοποίησης των προϊόντων της εκάστοτε επικοινωνίας µέσα στην οµάδα Agile Software Development Ecosystems ASDE Η ανάπτυξη ενός έργου λαµβάνει χώρα σε περιβάλλοντα όπου οι συνθήκες και τα δεδοµένα διαρκώς αλλάζουν. Αυτή η διακύµανση συνθηκών γίνεται αντιληπτή και λαµβάνεται υπ όψιν µόνο εφόσον δοθεί βαρύτητα στον ανθρώπινο παράγοντα, ο οποίος είναι και ο κυριότερος παράγοντας διαµόρφωσης ενός τέτοιου περιβάλλοντος. Στην ξένη βιβλιογραφία, ο όρος που χρησιµοποιείται για την περιγραφή ενός περιβάλλοντος ανάπτυξης όπως το παραπάνω είναι «Agile Software Development Ecosystems» ή αλλιώς ASDE. Ένα από τα επιχειρήµατα των επικριτών των ASDE είναι πως απαιτούν άτοµα µε εξαιρετικές ικανότητες, τόσο σε ηγετικές θέσεις, όσο και στα υπόλοιπα µέλη της οµάδας. Με αυτήν την λογική, οι «παραδοσιακές» µέθοδοι µπορούν να υλοποιηθούν από άτοµα µε έλλειψη ικανοτήτων [6]. Ωστόσο δεν πρόκειται να γίνει περαιτέρω ανάλυση των παραδοσιακών µεθοδολογιών και των πρακτικών τους, αλλά παρουσίαση της επιρροής που είχαν οι ικανότητες του κάθε µέλους της οµάδας στο συνολικό έργο, απ όπου θα προκύψουν και τα όποια συµπεράσµατα Συνδυασµός και αξιολόγηση δεξιοτήτων και ικανοτήτων Σε ευέλικτα περιβάλλοντα ανάπτυξης, είναι εξαιρετικά σηµαντικό να επικεντρώνεται η προσοχή στον βαθµό δυσκολίας του προβλήµατος που προκύπτει. Για παράδειγµα, στην περίπτωση ενός σύνθετου και πολύπλοκου προβλήµατος, το καλύτερο είναι να αναλάβει την αντιµετώπισή του ένα πιο πεπειραµένο και ικανό µέλος της οµάδας, ενώ ένα πιο απλό πρόβληµα µπορεί να αντιµετωπιστεί από κάποιο µέλος σχετικά άπειρο και µειωµένων ικανοτήτων ή γνώσεων. Η σχέση λοιπόν που πρέπει να λαµβάνεται υπ όψιν είναι ικανότητας-προβλήµατος και όχι ικανότητας-µεθοδολογίας [6]. Όπως θα περιγραφεί και παρακάτω, η επίλυση του εκάστοτε προβλήµατος έγινε µετά από συνδιαλλαγή µεταξύ των µελών της οµάδας, από κοινού λήψη αποφάσεων

24 και υλοποίηση του τρόπου αντιµετώπισης από τον προγραµµατιστή ο οποίος κατείχε τα απαραίτητα για την περίσταση προσόντα. Άλλωστε ο συνδυασµός των ατοµικών ταλέντων των µελών της οµάδας προσφέρει µεγάλη αύξηση της αποτελεσµατικότητας της οµάδας, όπως φάνηκε και στην πράξη, κατά την διάρκεια της έρευνας. 3.5 Εργαλεία που χρησιµοποιήθηκαν Η ανάπτυξη του προγράµµατος έγινε σε γλώσσα Java, µε αρχική υλοποίηση στο περιβάλλον ανάπτυξης Net Beans. Ο περίφηµος σχεδιαστής φορµών (form designer) του συγκεκριµένου ολοκληρωµένου περιβάλλοντος ανάπτυξης (Integrated Development Environment, IDE) ήταν µάλλον δύσχρηστος. Συνεπώς η αρχική ανάπτυξη του προγράµµατος, του οποίου το µεγαλύτερο µέρος ήταν γραφικές διεπαφές (Graphical User Interfaces, GUIs) έγινε µε απλό προγραµµατισµό, δηλαδή µόνο κώδικα και καθόλου χρήση form designer. Η συγκεκριµένη επιλογή µοιάζει µετά το πέρας του έργου αρκετά περίεργη, σε σηµείο που ορισµένοι συνάδελφοι το θεώρησαν χαµένο κόπο και χρόνο. Ωστόσο αξίζει να σηµειωθεί ότι ο «παραδοσιακός» προγραµµατισµός έδωσε περισσότερες αφορµές για συνδιαλέξεις και ανταλλαγή απόψεων, δηλαδή επικοινωνία µεταξύ των µελών του ζεύγους προγραµµατισµού. Η µεγάλη αλλαγή στην ταχύτητα ήρθε ωστόσο µε την χρήση του περιβάλλοντος Eclipse. Η χρήση του σχεδιαστή φορµών και η µεγάλη εξοικείωση του Στέφανου µε το συγκεκριµένο περιβάλλον ανάπτυξης έδωσε ιδιαίτερη ώθηση στην οµάδα, µε τις γραφικές διεπαφές χρήστη (GUI) να αναπτύσσονται ταχύτατα και η χρήση αποκλειστικά κώδικα να περιορίζεται στα υπολογιστικά θέµατα του προγράµµατος

25 4 Το «παιχνίδι» Κατά τον Alistair Cockburn, «η ανάπτυξη λογισµικού µπορεί να θεωρηθεί ως ένα «συνεργατικό παιχνίδι (cooperative game) επινοητικότητας και επικοινωνίας» [6]. Όπως και σε κάθε παιχνίδι λοιπόν, έτσι και σε αυτό, υφίστανται κάποιοι κανόνες, οι οποίοι έχουν οριστεί σε παραπάνω ενότητες και σκιαγραφούν τις έννοιες και τις πρακτικές του Ακραίου Προγραµµατισµού. Ωστόσο αξίζουν ιδιαίτερης αναφοράς οι έννοιες της συνεργασίας, της επινοητικότητας και της επικοινωνίας. 4.1 Το συνεργατικό κοµµάτι του παιχνιδιού Στο «παιχνίδι» της ανάπτυξης λογισµικού, το πρώτο βήµα είναι η συνεργασία. Συνεργασία µεταξύ των µελών του ζεύγους προγραµµατιστών, των οµάδων ανάπτυξης, των πελατών και των προγραµµατιστών και δεκάδες άλλες µορφές συνεργασίας, οι οποίες είναι όλες απαραίτητες για την επιτυχή και αποδοτική ανάπτυξη του έργου. Θεωρούµενο άλλωστε ως οµαδικό παιχνίδι, η συνεργασία ανάµεσα στα µέλη της οµάδας και η ύπαρξη της οµάδας καθεαυτής είναι αλληλένδετες έννοιες. Στην παρούσα εργασία, η συνεργασία µεταξύ του Στέφανου και του Κίµων ήταν απαραίτητη, αφού αποτελούσαν ουσιαστικά και τα µοναδικά µέλη της οµάδας ανάπτυξης. Ο προγραµµατισµός σε ζευγάρια δεν αποτελούσε την µοναδική έκφανση συνεργασίας µεταξύ των ατόµων της οµάδας, υπό την έννοια ότι οι λόγοι της συνεργασίας δεν ήταν µόνο η δηµιουργία παραδοτέου λογισµικού, αλλά συµπεριλάµβαναν και την λήψη αποφάσεων (σε διάφορες φάσεις του έργου), καθώς και τον διαµοιρασµό της πληροφορίας και γνωσιακών στοιχείων που προέκυπταν στην πορεία ανάπτυξης. Σε αυτό το σηµείο είναι χρήσιµο να γίνει διάκριση µεταξύ των εννοιών της συνεργασίας και την επικοινωνίας. Όπως αναφέρει και ο Cockburn, «η επικοινωνία περιλαµβάνει την ανταλλαγή πληροφοριών µεταξύ δύο ατόµων, ενώ η συνεργασία

26 έχει να κάνει µε την από κοινού συµµετοχή στην παραγωγή ενός προϊόντος, ή στην από κοινού λήψη κάποιας απόφασης» [6] Παράγοντες επιρροής στην συνεργασία Τα µέλη της οµάδας ανάπτυξης είχαν την τύχη να γνωρίζονται πριν από την ανάληψη της εργασίας, µε συνέπεια να υπάρχει µία σχετική εµπιστοσύνη και αλληλοκατανόηση ανάµεσά τους. Η διαπροσωπική αυτή σχέση βοήθησε εξαιρετικά στον τοµέα της συνεργασίας κάνοντάς την πιο εύκολη και αποδοτική. Η έννοια της εµπιστοσύνης δεν αφορούσε µόνο την διεκπεραίωση των ανατιθέµενων εργασιών, αλλά και την βεβαιότητα αποδοτικότητας, αποτελεσµατικότητας και ωφέλιµου αποτελέσµατος µετά το πέρας της εκάστοτε συνεργατικής δραστηριότητας. Ένας ακόµα παράγοντας που ωφέλησε την συνεργασία ήταν η κουλτούρα του κάθε µέλους της οµάδας. Τόσο ο Κίµων όσο και ο Στέφανος ήταν συµφοιτητές, είχαν κοινά σηµεία σε ότι αφορά αξίες και αρχές, µε αποτέλεσµα να υφίσταται τελικά µια συµφωνία χαρακτήρων. Κατά συνέπεια, οι όποιες διαφορές του κάθε ατόµου µόνο ευεργετικά µπορούσαν να λειτουργήσουν στην συνεργασία, υπό την έννοια ότι οι διαφορές στον χαρακτήρα του καθενός συνέβαλλαν στο «παιχνίδι» της οµάδας περισσότερο ως παράγοντες ενίσχυσης της συνεργασίας παρά ως τροχοπέδη. Η δοµή της οµάδας ήταν επίσης καταλυτική σε ό,τι αφορά τον παράγοντα «συνεργασία». Η οργάνωση, οι πρακτικές και η τεχνολογία που χρησιµοποιήθηκαν ήταν σχεδιασµένες, επιλεγµένες και εφαρµοσµένες από τα µέλη της οµάδας για τα µέλη της οµάδας. Αυτό το γεγονός προϋπόθετε την συνεργασία µεταξύ του Κίµων και του Στέφανου, µε αποτέλεσµα η ανάπτυξη του έργου να έχει την σφραγίδα της συνεργασίας από τα θεµέλιά του. Συνεπώς επετεύχθη διαµόρφωση ενός εξαιρετικού περιβάλλοντος για την ανάπτυξη, την εφαρµογή και την ενδυνάµωση της συνεργασίας 4.2 Η επινοητικότητα ως µέρος του παιχνιδιού Η επινοητικότητα είναι µία από τις κυριότερες εκφάνσεις της ανθρώπινης πλευράς κατά την ανάπτυξη του έργου. Είναι στοιχείο της ανθρώπινης διάνοιας και µετουσιώνει τις γνώσεις και τις ικανότητες του κάθε µέλους της οµάδας σε «χειροπιαστά» στοιχεία, ωφέλιµα για την επίτευξη του εκάστοτε στόχου

27 Οι «εκρήξεις» επινοητικότητας (αν µπορεί να θεωρηθεί µία τέτοια φράση ως δόκιµη) παρατηρήθηκαν κατά τον προγραµµατισµό σε ζευγάρι. Μία σύντοµη µατιά στις φόρµες προγραµµατιστών (βλ. Παράρτηµα Γ), δείχνει επανειληµµένες αναθεωρήσεις και καινοτοµίες κατά την ανάπτυξη του κώδικα, οι οποίες προήλθαν από την γενική θεώρηση της τρέχουσας κατάστασης και την κρίση του εκάστοτε µέλους σχετικά µε τις µελλοντικές κινήσεις και ενέργειες που θα ήταν καλό να γίνουν για την βέλτιστη υλοποίηση και διεκπεραίωση των στόχων. Θα µπορούσε να ειπωθεί λοιπόν ότι η επινοητικότητα, ιδίως κατά την υλοποίηση της εφαρµογής είναι ο κυριότερος παράγοντας διακύµανσης (και ενίοτε ανατροπής) του χρονοδιαγράµµατος και των σχεδιαστικών επιλογών που έχουν προηγηθεί. Παράδειγµα των παραπάνω αποτελεί η επιλογή διαφορετικού IDE για την ανάπτυξη του προγράµµατος, µε την χρήση του Eclipse αντί του NetBeans. Ο Στέφανος διαπίστωσε ότι η παραγωγή κώδικα µε τον «παραδοσιακό» τρόπο ήταν µάλλον χρονοβόρα, γνώριζε το συγκεκριµένο περιβάλλον ανάπτυξης και έκρινε πως ήταν καλό να µεταφερθεί η οµάδα σε άλλο περιβάλλον ανάπτυξης. Ο χρονοπρογραµµατισµός της οµάδας δεν άλλαξε σηµαντικά, τα δύο µέλη της οµάδας είχαν άνεση µε το Eclipse και η οµάδα τελικά βελτίωσε σε µεγάλο βαθµό τον ρυθµό και την απόδοσή της. Ένα δεύτερο και αρκετά κοινό παράδειγµα, το οποίο επεκτείνεται στον γενικότερο τοµέα ανάπτυξης έργων είναι η έννοια των YAGNI (You Aren t Going to Need It). Για παράδειγµα η ύπαρξη περιττών στοιχείων στον κώδικα αποτέλεσε συχνά ζήτηµα αναθεώρησης του κώδικα και συνήθως ήταν αποτέλεσµα της επινοητικότητας του προγραµµατιστή, η οποία οδηγούσε σε πιο σύντοµη, λιτή και περιεκτική κωδικοποίηση. 4.3 Το επικοινωνιακό παιχνίδι Φυσική συνέχεια της επινοητικότητας είναι η επικοινωνία, µε την έννοια ότι τα προϊόντα της επινοητικότητας ενός µέλους της οµάδας γνωστοποιούνται στα υπόλοιπα µε την επικοινωνιακή διαδικασία. Σύµφωνα µε τον Alistair Cockburn «η πιο αποτελεσµατική επικοινωνία είναι η διαπροσωπική[...]. Θα πρέπει να βασιζόµαστε σε άτυπες συζητήσεις, όχι απλά να τις δεχόµαστε». Η επικοινωνία µεταξύ των ατόµων πρέπει να αποτελέσει βασικό κοµµάτι της διαδικασίας ανάπτυξης» [6]

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

29 Εικόνα 1: Η φόρµα προγραµµατιστών και η λίστα «TODO». Επικοινωνία σε άλλες χρονικές στιγµές. Η εκ των προτέρων γνωριµία και οικειότητα των µελών της οµάδας έδινε την δυνατότητα για συζήτηση σε άλλες περιστάσεις, όπως σε έξοδο για καφέ ή φαγητό. Αυτό ήταν εξαιρετικά χρήσιµο στην οµάδα καθώς, απαλλαγµένα από το άγχος και την πίεση της εργασίας, τα άτοµα σκέφτονταν και συνοµιλούσαν πιο χαλαρά και ευχάριστα, µε τα προϊόντα της επικοινωνίας τους να είναι συχνά αναπάντεχα ωφέλιµα και έδιναν έναν εξαιρετικά εποικοδοµητικό χαρακτήρα στην συζήτηση

30 4.4 Ο συνδυασµός των µερών του παιχνιδιού Σε αντίθεση µε τις «παραδοσιακές» µεθοδολογίες ανάπτυξης λογισµικού, οι ευέλικτες µέθοδοι δίνουν έµφαση στην επικοινωνία. Ένα ASDE, όπως περιγράφηκε παραπάνω, επικεντρώνεται στις αλληλεπιδράσεις, την ανταλλαγή πληροφοριών µεταξύ των ατόµων της οµάδας. Οι διαπροσωπικές συζητήσεις, ακόµα και συζητήσεις µεταξύ ατόµων σε µακρινή απόσταση, δίνουν την δυνατότητα κατανόησης και επίλυσης κάθε είδους προβληµάτων. Οι συζητήσεις, οι προβληµατισµοί και ο διάλογος κατά την παρούσα εργασία έδωσαν πνοή σε καινοτόµες ιδέες, οι οποίες ουδέποτε θα προέκυπταν από µία ατοµική ανάπτυξη της εφαρµογής ή από την απλή ανάγνωση εγγράφων και αναφορών. Ακόµα και τώρα, που η οµάδα ανάπτυξης έχει ολοκληρώσει το έργο της, µπορεί να της είναι εξαιρετικά δύσκολο να κατανοήσει το περιεχόµενο, το νόηµα και την προέλευση των φορµών που η ίδια συµπλήρωνε κατά την διαδικασία υλοποίησης της εφαρµογής. Πρέπει να τονιστεί ότι η επινοητικότητα, η επικοινωνία ή η συνεργασία µεµονωµένα δεν θα προσέφερε κάτι το ιδιαίτερο στην ανάπτυξη του έργου. Ο συνδυασµός τους είναι αυτός που δηµιούργησε ένα περιβάλλον καινοτοµίας, παραγωγικής ενασχόλησης µε τα διάφορα εργαλεία που χρησιµοποιήθηκαν και το αίσθηµα αυτοεκτίµησης για κάθε άτοµο της οµάδας. Για παράδειγµα, έστω ότι ο Κίµων ήταν ο programmer και ο Στέφανος ο navigator. Αν στην συζήτηση πριν την συγγραφή του κώδικα είχε αποφασιστεί συγκεκριµένη µέθοδος συγγραφής κώδικα (π.χ. χρήση form designer) και ο Κίµων συνέχιζε την εργασία µε κάποια δικιά του πρωτοβουλία, η επικοινωνία θα είχε µεν επιτευχθεί (στο «συµβούλιο») αλλά από άποψη συνεργασίας το αποτέλεσµα θα ήταν µηδενικό, ακόµα και αν η επινοητικότητα του Κίµωνα τον οδηγούσε στην ανάληψη της πρωτοβουλίας. Είναι φανερό λοιπόν πως οι τρεις έννοιες είναι αλληλένδετες και στενά εξαρτηµένες σε ότι αφορά την αποδοτικότητα της εφαρµογής τους. 4.5 Ατοµικές ικανότητες και οµαδικό παιχνίδι Όπως προκύπτει από τα παραπάνω, η ανάπτυξη λογισµικού µπορεί να θεωρηθεί ως «παιχνίδι». Ένα παιχνίδι οµαδικό, συνεργατικό, το οποίο από την φύση του έχει δύο

31 πλευρές: τις ατοµικές ικανότητες δεξιότητες και τις οµαδικές ικανότητες, οι οποίες συνδέονται άρρηκτα µε την έννοια της συνεργασίας. Για την κατανόηση της φύσης του «παιχνιδιού», ο Cockburn παραθέτει το παράδειγµα των ορειβατών [6], σύµφωνα µε το οποίο µία ορειβατική οµάδα δεν θα ήταν φρόνιµο να αποπειραθεί την ανάβαση ακόµα και µίας εύκολα προσβάσιµης (πόσο µάλλον απόκρηµνης) κορυφής χωρίς το αρκούντως υψηλό επίπεδο ατοµικών ικανοτήτων των µελών της. Ωστόσο η ορειβασία σε ακραίες και επικίνδυνες συνθήκες απαιτεί εξαιρετικά µεγάλη οµαδικότητα και συνεργατικό πνεύµα. Κατ αντιστοιχία λοιπόν, σε ένα έργο λογισµικού οποιασδήποτε κλίµακας, τα ατοµικά χαρακτηριστικά κάθε ατόµου δεν πρέπει να παραβλέπονται ή να υποτιµούνται. Ωστόσο πρέπει να δίνεται ιδιαίτερη έµφαση στην έννοια της οµάδας (και ότι αυτή αντιπροσωπεύει και περιλαµβάνει), καθώς και στην διατήρηση της ισορροπίας µεταξύ των ατοµικών χαρακτηριστικών και αυτών της οµάδας. 4.6 Εµπιστοσύνη Συχνά το µεγαλύτερο πρόβληµα στις ανθρώπινες σχέσεις είναι η έλλειψη εµπιστοσύνης. Άµεσο αποτέλεσµα είναι η εµφάνιση του ίδιου προβλήµατος και στις περιπτώσεις όπου υπάρχει ανάγκη συνεργασίας. Στα έργα λογισµικού για παράδειγµα, οι αποφάσεις είναι απαραίτητο να λαµβάνονται από άτοµα που έχουν γνώση της κατάστασης. Ένας διαχειριστής έργου είναι απαραίτητο να περιβάλλεται από άτοµα τα οποία εµπιστεύεται, τουλάχιστον σε ότι έχει να κάνει µε τον τοµέα που τα αφορούν. Η αλληλοεκτίµηση, η εµπιστοσύνη και η αλληλοϋποστήριξη των ατόµων είναι το τρίπτυχο για την δηµιουργία ενός ευέλικτου περιβάλλοντος εργασίας, το ήδη αναφερθέν ASDE [6] Εµπιστοσύνη και ικανότητες Στην οµάδα ανάπτυξης του XPortofolio η ύπαρξη εµπιστοσύνης ήταν δεδοµένη λόγω της a priori γνωριµίας των µελών της οµάδας. Τόσο ο Κίµων όσο και ο Στέφανος ήταν γνώστες σε ικανοποιητικό βαθµό των δυνατοτήτων και των χαρακτηριστικών δεξιοτήτων τους, ενώ δεν ήταν δύσκολο να αποκτήσουν καλύτερη εικόνα του συνεργάτη τους µε την εφαρµογή του προγραµµατισµού σε ζευγάρια

32 Πολλοί διαχειριστές έργων είναι πιστοί στην άποψη ότι «για να γίνει κάτι σωστά, πρέπει να το κάνεις µόνος σου» [6]. Η γενική τακτική της οµάδας του XPortofolio διαφοροποιήθηκε από αυτή την άποψη, προσπαθώντας να γίνει ακόµα πιο έντονη η έµφαση στις αρχές της ευέλικτης ανάπτυξης. Τέτοιες απόψεις βέβαια υποδεικνύουν παντελή έλλειψη διάθεσης για επικοινωνία και είναι άκρως αντίθετες µε τις αρχές και τις πρακτικές των ευέλικτων τεχνικών. Παρακάτω ακολουθούν οι δύο περιπτώσεις που παρουσιάστηκαν στην πορεία ανάπτυξης και ο τρόπος αντιµετώπισης από το ζευγάρι προγραµµατισµού. Πλήρης έλλειψη γνώσης Σε περιπτώσεις όπου ουδείς εκ των δύο γνώριζε την λύση στο πρόβληµα που προέκυπτε, η άµεση αντίδραση της οµάδας ήταν να ανατρέξει τόσο σε κάποιο σύγγραµµα το οποίο θα µπορούσε να βοηθήσει, όσο και η αναζήτηση στο ιαδίκτυο. Ο τελευταίος τρόπος ήταν και ο πιο γρήγορος και εύκολος, αφού ούτως ή αλλιώς η ανάπτυξη της εφαρµογής γινόταν σε ηλεκτρονικό υπολογιστή. Εφόσον µάλιστα η συγγραφή του κώδικα γινόταν σε γλώσσα Java, η διαδικτυακή τεκµηρίωση της Java από την sun [7] ήταν η βέλτιστη και η πλέον συµφέρουσα λύση. Μερική έλλειψη γνώσης Η πιο συνήθης περίπτωση ήταν η αδυναµία ενός εκ των δύο προγραµµατιστών να βρει λύση σε κάποιο πρόβληµα. Η συνδροµή του έτερου συνεργάτη ήταν σε αυτές τις περιπτώσεις καταλυτική. Γινόταν αυτοµάτως αλλαγή ρόλων (ο προγραµµατιστής αναλάµβανε χρέη παρατηρητή και αντίστροφα) και η εργασία συνεχιζόταν, µε τον προγραµµατιστή να εξηγεί τι ακριβώς ενέργειες έκανε για την επίλυση του προβλήµατος. Επιπλέον, µε την συνδροµή της τεκµηρίωσης της Java (Java API Specification, βλ. Εικόνα 2) [7], η επεξήγηση και κατανόηση της προκύπτουσας λύσεως γινόταν ευκολότερη και ταχύτερη

33 Εικόνα 2: H Java API Specification στο ιαδίκτυο [6]. 4.7 Μετάδοση γνώσης Η µετάδοση γνώσης δεν συντελέστηκε µόνο µε τις µεθόδους που περιγράφηκαν παραπάνω (βλ. ενότητες 4.6 και 4.7). Κατά την ανάπτυξη της εφαρµογής ήταν φανερή η ανάγκη για πρακτική κατανόηση κάποιων εννοιών, ιδίως κατά την συγγραφή του κώδικα. Περαιτέρω ανάλυση αυτού του φαινοµένου παραπέµπει και απαιτεί µελέτη πιο πολύπλοκων εννοιών που έχουν να κάνουν µε την πρόσκτηση γνώσης και αφορούν τους τοµείς της εκπαιδευτικής επιστήµης και γνωστικών αναλύσεων. Ο Jim Highsmith οριοθετεί το παραπάνω φαινόµενο στα πλαίσια του τοµέα της ανάπτυξης λογισµικού µε την αναφορά στις έννοιες της «σιωπηρής» και της «ρητής» γνώσης [6] «Σιωπηρή» γνώση Η «σιωπηρή» γνώση (tacit knowledge) αναφέρεται στην γνώση την οποία κατέχει ένα άτοµο και την οποία δεν µπορεί να την µεταδώσει µεταφέροντάς την από το µυαλό στο χαρτί [6]. εν είναι δηλαδή δυνατή η µεταφορά της γνώσης τέτοιου είδους σε γραπτή ή άλλου είδους αναπαράσταση. Αντίθετα, είναι απαραίτητη η εµπλοκή του ατόµου το οποίο αποσκοπεί στην πρόσκτηση της γνώσης σε διάφορες δραστηριότητες και εργασίες. Ο λόγος είναι πως η γνώση αυτή δεν βασίζεται µόνο στα γεγονότα, αλλά και στις συνδέσεις και τις συσχετίσεις µεταξύ τους. Αυτό το

34 «σηµασιολογικό δίκτυο» είναι που χρησιµεύει στους ανθρώπους για την αντιµετώπιση οποιουδήποτε προβλήµατος, σύµφωνα µε τον Highsmith [6]. Η οµάδα ανάπτυξης του XPortofolio συνάντησε ανάγκη πρόσκτησης τέτοιου είδους γνώσης κατά την συγγραφή του κώδικα. Ο καλύτερος τρόπος για το ένα µέλος του ζευγαριού προγραµµατισµού να αντιληφθεί κάποια έννοια ή τεχνική κωδικοποίησης ήταν να παρακολουθήσει τον συνεργάτη του κατά την συγγραφή και κατόπιν να αναλάβει χρέη programmer, για την πρακτική εφαρµογή των όσων παρακολούθησε. Ευρεία πρόσκτηση «σιωπηρής» γνώσης π.χ. έγινε από τον Κίµωνα κατά την µετάβαση από το IDE του NetBeans στο Eclipse. Έχοντας ο Στέφανος µεγαλύτερη εξοικείωση και εµπειρία µε το Eclipse, είχε τον πρώτο λόγο αρχικά στην χρήση του IDE και κατόπιν ο Κίµων, υπό την καθοδήγηση ορισµένες φορές του Στέφανου, προχωρούσε στην συγγραφή του κώδικα και την τέλεση ορισµένων ενεργειών επί του IDE «Ρητή» VS «Σιωπηρή» γνώση Σε αντίθεση µε την «σιωπηρή» γνώση, η «ρητή» γνώση (explicit knowledge) µπορεί να κωδικοποιηθεί και να καταγραφεί. Ωστόσο, όπως αναφέρει και ο Highsmith [6], πρέπει να επισηµανθεί ότι ενώ οι διάφορες πρακτικές και µέθοδοι µπορούν να καταγραφούν, απαιτείται η «σιωπηρή» γνώση (εµπειρία, κρίση, σκέψη, αξιολόγηση) για την εφαρµογή τους. Η «ρητή» λοιπόν γνώση παρέχει του κανόνες, ενώ η «σιωπηρή» προσφέρει µία καλύτερη κατανόηση του πότε και πώς είναι επιθυµητό να παραβιαστούν αυτοί οι κανόνες. Στην περίπτωση της ανάπτυξης του XPortofolio, παρουσιάστηκε αυτό το φαινόµενο στην περίπτωση των διαγραµµάτων ροής δεδοµένων και κλάσεων. Τα όποια διαγράµµατα δεν δηµιουργήθηκαν βάσει των τυποποιηµένων κανόνων που συναντούνται στην βιβλιογραφία [8,9] αλλά έγινε αποτύπωση στο χαρτί αφαιρετικών σκίτσων τα οποία παρέπεµπαν στα τυποποιηµένα διαγράµµατα. Η οµάδα είχε σαφή άποψη και κατανόηση των αφαιρετικών διαγραµµάτων, µε κάθε µέλος της να σχεδιάζει όποτε θεωρούταν απαραίτητο µία τέτοια διαγραµµατική αναπαράσταση. Κατόπιν, µε την µεταφορά των διαγραµµάτων σε κώδικα γινόταν καλύτερη κατανόησή τους και αποσαφήνιση των σηµείων που προκαλούσαν απορία σε οποιοδήποτε µέλος της οµάδας

35 5 Προσωπικότητες και Ιδιοσυγκρασίες Όπως ήδη αναφέρθηκε επανειληµµένα, ο ανθρώπινος παράγοντας είναι το σηµείο αναφοράς στην ανάπτυξη λογισµικού µε χρήση ευέλικτων µεθόδων. Συνεπώς θεωρήθηκε φρόνιµο χάριν πληρότητας της µελέτης να περιγραφεί και να αναλυθεί η σχέση µεταξύ της προσωπικότητας και των ιδιοσυγκρασιών του κάθε µέλους της οµάδας και της συνεργασίας που επετεύχθη. Άλλωστε, όπως αναφέρει και ο Highsmith, κάθε άτοµο είναι ικανό για δυνητικά ξεχωριστή συνεισφορά και η διαφορετικότητά των ατόµων είναι συχνά εχέγγυο επιτυχίας [6]. εδοµένου ότι οι ευέλικτες µέθοδοι δεν δίνουν ιδιαίτερη βαρύτητα στις αυστηρές µεθοδολογίες και κανόνες, είναι απαραίτητη η ανάπτυξη του πνεύµατος συνεργασίας, ώστε το κάθε άτοµο ξεχωριστά να βρει την µεθοδολογία εργασίας που ταιριάζει σε αυτό και όχι να γίνει προσπάθεια να µπει σε κάποιο µεθοδολογικό «καλούπι». 5.1 Η επιρροές στην συνεργασία και την επικοινωνία Από την στιγµή που η συνεργασία και η επικοινωνία ήταν σε διαπροσωπικό επίπεδο, ο χαρακτήρας και οι ιδιοσυγκρασίες τόσο του Κίµωνα όσο και του Στέφανου ήταν αναµενόµενο να παίξουν σηµαντικό ρόλο στην πορεία του έργου. Αναφορά στον ρόλο τους άλλωστε έγινε και στο Κεφάλαιο 4. Κατά την πορεία του έργου, ουδέποτε επήλθε κάποια σύγκρουση ή ιδιαίτερα έντονη διαφωνία σε οποιοδήποτε ζήτηµα. Τα «συµβούλια» τα οποία γίνονταν πριν και µετά την συγγραφή κώδικα, αλλά και οι συζητήσεις κατά την διάρκειά της συγγραφής ήταν χαρακτηριστικές του κλίµατος που επικρατούσε

36 5.1.1 ιαφωνία στον προγραµµατισµό Παράδειγµα αποτελεί η διαφωνία στην αρχή της ανάπτυξης της εφαρµογής, ως προς την µορφή του γραφικού περιβάλλοντος της κλάσης ViewMoreScreen.java (βλ. παράρτηµα Α). Ο Κίµων ισχυριζόταν ότι θα ήταν καλύτερα να χρησιµοποιηθεί πίνακας για την εµφάνιση των πληροφοριών του project. Από την άλλη, ο Στέφανος ήταν υπέρ της χρήσης λίστας αντί για πίνακα. Η λύση δόθηκε µε την συνταγή «δοκιµή και επιτυχία». Πιο συγκεκριµένα, η δοµή του GUI βασίστηκε αρχικά στην χρήση πίνακα, σύµφωνα µε την γνώµη του Κίµων και κατόπιν χρησιµοποιήθηκε λίστα. Τελικά και οι δύο προγραµµατιστές συµφώνησαν ότι η λύση που πρότεινε ο Στέφανος ήταν καλύτερη και συνέχισαν τον προγραµµατισµό µε χρήση λίστας Εξωγενείς παράγοντες επιρροής Όπως κάθε άνθρωπος, έτσι και τα άτοµα στην οµάδα ανάπτυξης ήταν φυσικό να επηρεάζονται από γεγονότα άσχετα από το έργο το οποίο είχαν αναλάβει. Το πιο συχνό πρόβληµα ήταν η αρχή κάθε συνεδρίας, οπότε και τα µέλη της οµάδας ήταν συνήθως ανήµπορα να επικοινωνήσουν και να συνεργαστούν ικανοποιητικά. Όπως άλλωστε φαίνεται και από τις φόρµες προγραµµατιστών (βλ. Παράρτηµα Γ), η αρχή ήταν συνήθως αρκετά νωχελική και η οµάδα παρουσίαζε χαµηλή απόδοση. Άλλη περίπτωση εξωγενούς επιρροής ήταν η αναβολή συνεδρίας λόγω προσωπικού προβλήµατος κάποιου µέλους της οµάδας (αναβολές που µερικές φορές προκαλούσαν χρονικό κενό µεταξύ των συνεδριών ακόµα και πέρα των 20 ηµερών). Ακόµα και να γινόταν τελικά η συνεδρία ήταν φανερές οι επιδράσεις του εκάστοτε παράγοντα στην απόδοση του Κίµων ή του Στέφανου. Σε αυτές τις περιπτώσεις γινόταν συγκεκριµένη κατανοµή ρόλων. Αν π.χ. ο Κίµων δεν ήταν σε θέση να εργαστεί ικανοποιητικά κατά τον προγραµµατισµό σε ζευγάρι, ο Στέφανος αναλάµβανε χρέη προγραµµατιστή και µερική ευθύνη της παρακολούθησης του κώδικα, µε τον Κίµων να θεωρείται ως παρατηρητή, στον βαθµό που µπορούσε να φέρει εις πέρας τον ρόλο του. Έτσι συνεχιζόταν η εργασία µε τις λιγότερες δυνατές απώλειες

37 5.2 Λήψεις αποφάσεων Τόσο το µέγεθος της οµάδας ανάπτυξης (δύο µόλις άτοµα) όσο και η δοµή της και οι διαπροσωπικές σχέσεις µεταξύ των µελών της έκαναν πιο εύκολη και αποτελεσµατική την διαδικασία λήψης αποφάσεων. Το µικρό µέγεθος της οµάδας και η εξαιρετική επικοινωνία βοήθησαν την οµάδα να έχει πλήρη εικόνα και γνώση της πορείας του έργου σε κάθε φάση του Σηµασία της διαδικασίας λήψης αποφάσεων Στα τέλη της δεκαετίας του 1990, ο Ken Schwaber διενήργησε µία έρευνα σε µία οµάδα ανάπτυξης στην Ιρλανδία, για την βελτίωση της ταχύτητας παράδοσης του λογισµικού από την οµάδα των προγραµµατιστών [6]. Όπως προέκυψε από την έρευνα, δύο ήταν οι παράγοντες που επηρέαζαν την ταχύτητα παράδοσης: Σύγχυση σχετικά µε το πρόγραµµα, την διαχείριση του προϊόντος ή τους ρόλους του κάθε µέλους της οµάδας στο έργο. Ελαττωµατική διαδικασία λήψης αποφάσεων µεταξύ του κέντρου ανάπτυξης στο ουβλίνο και το «αρχηγείο» στις Η.Π.Α. Άµεσο συµπέρασµα των παραπάνω, είναι πως η αποτελεσµατική διαδικασία λήψης αποφάσεων και η συνεργασία των εµπλεκοµένων προς τον στόχο αυτό είναι µείζονος σηµασίας και οφείλει να δοθεί ιδιαίτερη βαρύτητα και προσοχή στον τοµέα αυτό Ο ανθρώπινος παράγοντας στην διαδικασία λήψης αποφάσεων Ως επικοινωνιακή διαδικασία, η λήψη αποφάσεων σε ένα έργο λογισµικού επηρεάζεται προφανώς από τις προσωπικότητες και τις ιδιοσυγκρασίες του κάθε ατόµου στην οµάδα ανάπτυξης. Στις παραδοσιακές µεθοδολογίες η λήψη αποφάσεων υφίσταται µεν, αλλά δεν είναι πρωτεύουσας σηµασίας όπως σε ευέλικτα περιβάλλοντα ανάπτυξης (βλ. ASDE). Υπάρχει σαφής περιορισµός στο ποιος, που και πότε παίρνει τις αποφάσεις, µε αυστηρά προκαθορισµένη ροή πληροφοριών (συνήθως «από πάνω προς τα κάτω», βάσει της συνήθους ιεραρχίας), απαξιώνοντας έτσι µία ακόµα έκφανση του ανθρώπινου παράγοντα. Κατά την δηµιουργία του XPortofolio, η λήψη αποφάσεων ήταν µια συχνή διαδικασία, της οποίας παράδειγµα παρατέθηκε σε προηγούµενη ενότητα. Στην εν

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

39 6 Γενικότερες επιδράσεις του ανθρώπινου παράγοντα Η φύση του ανθρώπου δεν επιτρέπει εγγυηµένες προβλέψεις και υποθετικά µοντέλα χρονοπρογραµµατισµού, αφού πάντα υπάρχει η διακύµανση και οι εναλλαγές στην συµπεριφορά, τον τρόπο δράσης και εργασίας του κάθε ατόµου. Σε ένα έργο λογισµικού, υπό το καθεστώς παραδοσιακών µεθοδολογιών ανάπτυξης, τέτοιες διακυµάνσεις και αποκλείσεις θεωρούνται απαγορευµένες και γίνεται προσπάθεια εξάλειψής τους. Η διαφορά στις ευέλικτες µεθόδους και τον ακραίο προγραµµατισµό σε σχέση µε τα παραπάνω είναι πως σε κανένα σηµείο της ανάπτυξης του προγράµµατος δεν γίνεται προσπάθεια «αποστείρωσης» της οµάδας από την ανθρώπινη πλευρά των µελών της. Οι εκφάνσεις της ανθρώπινης φύσης τους είναι όχι απλά δεκτές, αλλά επιθυµητές και, όπως αναφέρει και ο Jim Highsmith, είναι προτιµότερο ο διαχειριστής του έργου να επιλέγει διαφορετικά µεταξύ τους άτοµα και να ποντάρει στην ποικιλία των εργαζοµένων για την επιτυχία του έργου [6]. Η οµάδα ανάπτυξης του XPortofolio βίωσε και κατέγραψε τις επιδράσεις του ανθρώπινου παράγοντα στις φόρµες προγραµµατιστών, διαπίστωσε τις αποκλίσεις και τις αναταράξεις στον αρχικό χρονοπρογραµµατισµό και τις αρχικές προβλέψεις. 6.1 Ανθρώπινη µνήµη Αναφέρθηκαν ήδη οι επιδράσεις της ανθρώπινης φύσης στον τοµέα της συνεργασίας, της επικοινωνίας, της επινοητικότητας και της λήψης αποφάσεων. Ωστόσο είναι χρήσιµο να γίνει σαφής αναφορά και στον τρόπο που επηρέασε ο ανθρώπινος παράγοντας την χρονική αλυσίδα των συνεδριών προγραµµατισµού σε ζευγάρι σε έκτακτες περιπτώσεις. Πιο συγκεκριµένα, παρουσιάστηκε ήδη η περίπτωση αναβολής µίας συνεδρίας προγραµµατισµού. Η αναβολή µπορεί να οφειλόταν σε προσωπικό πρόβληµα, ασθένεια, ακόµα και αδυναµία του µέλους να είναι παρών στον χώρο όπου λάµβανε χώρα η ανάπτυξη της εφαρµογής. Όταν µάλιστα η οµάδα αποτελούταν από δύο άτοµα και η ανάπτυξη γινόταν στο σπίτι ενός εκ των δύο, γίνεται αντιληπτό πως η

40 παραµικρή αιτία όπως οι προαναφερθείσες θα µπορούσε να οδηγήσει σε αποκλίσεις από τον αρχικό προγραµµατισµό. Οι µακρόχρονες διακοπές έκαναν αρκετή ζηµιά στην οµάδα, αφού στην επιστροφή τους, ο Κίµων και ο Στέφανος χρειάζονταν κάποιο χρόνο για να επανέλθουν στο επίπεδο που βρίσκονταν πριν, σε ό,τι αφορά την απόκτηση της γενικής εικόνας και σχετικής άνεσης µε τον κώδικα, κάτι που έχει καταγραφεί και στις φόρµες προγραµµατιστών (βλ. Παράρτηµα Γ). Αξίζει να σηµειωθεί ότι παρά την αρχή της «συλλογικής ιδιοκτησίας» του κώδικα, δεν θεωρήθηκε σκόπιµο να γίνεται µετατροπή του από οποιοδήποτε εκ των δύο µελών της οµάδας, αφού ήταν αρκετά εύκολη η πρόκληση σύγχυσης στο άλλο µέλος µετά από σχετικά µακροχρόνια διακοπή της πορείας ανάπτυξης. 6.2 Η ανθρώπινη φύση ως παράγοντας επιτυχίας Οι εξωγενείς παράγοντες επιρροής στην απόδοση της οµάδας ήταν κατά την ανάπτυξη του XPortofolio και οι πλέον απρόβλεπτοι. Τέτοια φαινόµενα συχνά αποτελούν επιχείρηµα των υπέρµαχων των «παραδοσιακών» µεθοδολογιών κατά των ευέλικτων µεθόδων και ενισχύει την αντίληψη περί αυστηρών χρονοδιαγραµµάτων, άκαµπτων µεθόδων και διαδικασιών και απρόσωπων τεχνικών βελτιστοποίησης παραγωγικότητας. Ο Jack Bolles, διαχειριστής έργου στην εταιρεία ThoughtWorks αναφέρει ότι «οι πραγµατικοί άνθρωποι δεν είναι άτεγκτοι όπως τα διαγράµµατα και οι µέθοδοι διεργασιών. Αντίθετα είναι ακατάστατοι, συχνά ανοργάνωτοι και δυσνόητοι, αλλά ταυτόχρονα επιδεικνύουν εφευρετικότητα, καινοτοµία και πάθος για την εργασία τους» [6]. Η εργασία της οµάδας ανάπτυξης του XPortofolio συµβάδιζε µε την άποψη του J.Bolles, µε την εµφάνιση ενός πνεύµατος «φιλοτιµίας». Πιο συγκεκριµένα, σε περιπτώσεις όπου η απόδοση και η παραγωγικότητα της οµάδας ήταν χειρότερη του αναµενόµενου, υπήρχε στην οµάδα ανάπτυξης ένα κοινό αίσθηµα ανάγκης για βελτίωση των αποτελεσµάτων της εργασίας της. Ταυτόχρονα, γινόταν προσπάθεια για τήρηση των αρχικών δεσµεύσεων σε ότι αφορά το γενικό χρονοδιάγραµµα µε απόληξη ένα αίσθηµα ενθουσιασµού όταν παρατηρούταν πρόοδος κατά την προσπάθεια αυτή, συχνά µεγαλύτερη του αναµενόµενου

41 7 «Έλλειψη» διαγραµµάτων και λοιπών αναπαραστάσεων Στις παραδοσιακές µεθόδους ανάπτυξης λογισµικού, ιδιαίτερα σε περιπτώσεις κλιµάκωσης του έργου (είτε γεωγραφικής, είτε πληθυσµιακής), παρουσιάζεται µία έντονη τάση για ευρεία τεκµηρίωση, µοντελοποίηση και εισαγωγή παραµέτρων στην όλη διαδικασία. Η απάντηση των ευέλικτων µεθόδων σε τέτοιες περιπτώσεις είναι η αύξηση των διαπροσωπικών αλληλεπιδράσεων µεταξύ των ατόµων της οµάδας και µπαίνει σε δεύτερη µοίρα η (κατά το δυνατόν µικρότερη) αύξηση της τυποποιηµένης τεκµηρίωσης των διαφόρων διεργασιών κατά την ανάπτυξη. Στην ανάπτυξη το XPortofolio τα διαγράµµατα και τα µοντέλα έπαιξαν πολύ µικρό έως µηδενικό ρόλο, αφού δεν θεωρήθηκε απαραίτητη η διαρκής µοντελοποίηση ή άλλου είδους αναπαράσταση των εκάστοτε σκέψεων του κάθε ατόµου. 7.1 Απλά «σκαριφήµατα» αντί διαγραµµάτων Όπως ήδη αναφέρθηκε, πριν και µετά την συγγραφή κώδικα λάµβαναν χώρα κάποια συµβούλια αλλά και κάποιες συζητήσεις κατά την διάρκεια συγγραφής. Σε περιπτώσεις όπου το υπό συζήτηση θέµα είχε να κάνει µε δοµή δεδοµένων (π.χ. συσχετίσεις κλάσεων ή µεγεθών και µεταβλητών) ή ροή πληροφοριών, θεωρούταν σαφώς πιο χρήσιµο να γίνει µια αναπαράσταση από τον Κίµων ή τον Στέφανο για την καλύτερη κατανόηση του ζητήµατος. Ωστόσο η αναπαράσταση ουδέποτε θεωρήθηκε ως αυτοσκοπός ή το κυριότερο µέσο επίλυσης του προβλήµατος. Αποτελούσε µέσο µεταφοράς της σκέψης του ενός συνεργάτη προς τον άλλον, ακόµα και βοήθηµα µνήµης σε περιπτώσεις κωλύµατος, ποτέ όµως δεν δόθηκε ιδιαίτερο βάρος στην ορθή µορφή των γραφικών αναπαραστάσεων σύµφωνα µε τις τυποποιηµένες µεθόδους

42 Παράδειγµα αποτελεί η αναπαράσταση των κλάσεων στην αρχή ακόµα της δηµιουργίας της εφαρµογής. εν υπήρχε τυποποιηµένη µορφή διαγράµµατος (π.χ. UML ή άλλο διάγραµµα κλάσεων [8, 9]), κάτι που αναφέρθηκε και στο Κεφάλαιο 4. Στην Εικόνα 3 παρουσιάζεται ενδεικτικά η αρκετά λιτή µορφή αναπαράστασης των κλάσεων Customer και Developer. Εικόνα 3: Αναπαράσταση των κλάσεων Customer, Developer. Αυτή η τακτική συµβαδίζει και µε την άποψη που κυριαρχεί στους κόλπους των ευέλικτων προγραµµατιστών, οι οποίοι υφίστανται έντονη κριτική στην απόφασή τους να µην χρησιµοποιούν τα προϊόντα των δηµιουργών µοντέλων. Η αιτία είναι πως µόνο οι ίδιοι οι προγραµµατιστές µπορούν να αντιληφθούν το χάσµα που υφίσταται µεταξύ των µοντέλων και των διαγραµµάτων και της καθεαυτής συγγραφής κώδικα. Αυτό το χάσµα µετάφρασης συχνά θεωρείται (λανθασµένα και χωρίς ιδιαίτερη λογική) µηδαµινό. Άµεσο επακόλουθο του χάσµατος είναι η ευφάνταστη άποψη ότι η πραγµατική δουλειά γίνεται από τους δηµιουργούς των µοντέλών και ότι η συγγραφή κώδικα αποτελεί την πλέον εύκολη και απλή δουλειά [6]!

43 8 Έλεγχοι Κατά την ανάπτυξης ενός έργου λογισµικού, η οµάδα ανάπτυξης καλείται να εκτελέσει διάφορους ελέγχους (tests) ώστε να µπορεί το τελικό προϊόν (καθώς και όλα τα ενδιάµεσα υπο-προϊόντα) να πληρούν κάποια κριτήρια, τα οποία δίνουν απάντηση σε ορισµένα ερωτήµατα. Τα πιο συνηθισµένα από αυτά είναι: Το σύστηµα κάνει αυτό το οποίο περιγράφεται στις απαιτήσεις του συστήµατος πως πρέπει να κάνει; Πόσο γρήγορα επιτελούνται οι λειτουργίες µε χρήση του λογισµικού; Το κατασκευασµένο σύστηµα συµβαδίζει µε τις απαιτήσεις του πελάτη; Η διόρθωση ενός λάθους µήπως έχει προκαλέσει την εµφάνιση ενός άλλου; Αυτά και άλλα ερωτήµατα καλούνται να απαντήσουν οι έλεγχοι, οι οποίοι συνήθως εκτελούνται από τον ίδιο τον προγραµµατιστή, ενώ σε εξαιρετικές περιπτώσεις τους αναλαµβάνει ένας ειδικός υπεύθυνος επί των ελέγχων τους συστήµατος. 8.1 Είδη ελέγχων και χρησιµότητα Στις περισσότερες περιπτώσεις ανάπτυξης λογισµικού, όπου οι οµάδες ανάπτυξης εφαρµόζουν Ευέλικτες Μεθόδους, οι ρόλοι του προγραµµατιστή και του υπεύθυνου για τους ελέγχους ταυτίζονται. Παρακάτω ακολουθεί µία συνοπτική περιγραφή των διαφόρων ειδών ελέγχων, για την καλύτερη κατανόηση του Κεφαλαίου 9, όπου γίνεται αναλυτικότερη παρουσίασή τους κατά την ανάπτυξη του XPortofolio Έλεγχοι Μονάδων (Unit Tests) Στόχος των ελέγχων µονάδων είναι να εντοπιστούν τα σφάλµατα τα οποία υπάρχουν στα συστατικά µέρη του συστήµατος. Ο κώδικας των µερών διαβάζεται, συγκρίνεται και ελέγχεται έτσι για σφάλµατα σε δεδοµένα, την σύνταξη ή και για λογικά λάθη. Προφανώς προηγείται του ελέγχου ολοκλήρωσης, αφού πρώτα είναι απαραίτητο να

44 ελεγχθούν τα µέρη του συνολικού προγράµµατος και κατόπιν εκτελείται η ενσωµάτωσή τους στο σύστηµα Έλεγχοι Ενσωµάτωσης (Integration Tests) Αφού οι κατασκευαστές είναι βέβαιοι ότι τα συστατικά µέρη λειτουργούν σωστά και συµβαδίζουν µε την σχεδίαση και τους στόχους που έχουν τεθεί, ακολουθεί η ενσωµάτωσή τους σε ένα σύστηµα, το οποίο τελικά θα είναι και το προϊόν της ανάπτυξης του έργου. Σηµαντικό ρόλο παίζει η σειρά ενσωµάτωσης, ενώ είναι αναγκαίο να γίνονται διαρκώς αυτού του είδους οι έλεγχοι (έλεγχοι ενσωµάτωσης), µε δεδοµένη την διαρκή ενσωµάτωση κώδικα ως µία από τις 12 πρακτικές που εφαρµόζονται σε έργα Ακραίου Προγραµµατισµού Έλεγχοι Λειτουργικότητας (Functionality Tests) Οι έλεγχοι αυτού του τύπου πραγµατοποιούνται για να επαληθευτεί η συµβατότητα του υπό δηµιουργία συστήµατος σε σχέση µε τις καταγεγραµµένες απαιτήσεις. Ελέγχεται δηλαδή το αν και κατά πόσον το λογισµικό επιτελεί τις λειτουργίες τι οποίες είναι υποχρεωµένο από τις απαιτήσεις. Στο XPortofolio για παράδειγµα, έπρεπε να ελεγχθεί το αν και κατά πόσον το σύστηµα δέχεται τα στοιχεία ενός νέου έργου (project), τα αποθηκεύει και δίνεται κατόπιν η δυνατότητα για επεξεργασία. Αυτή η περιγραφή λειτουργίας βέβαια είναι πολύ γενική, αλλά αρκεί προς το παρόν για να αντιληφθεί κανείς την χρησιµότητα των ελέγχων λειτουργικότητας. Για περισσότερες πληροφορίες σχετικά µε το XPortofolio και τις λειτουργίες του ο αναγνώστης παραπέµπεται στο Παράρτηµα Α Έλεγχοι Αποδοχής (Acceptance Tests) Ο έλεγχος αποδοχής ουσιαστικά εκτελείται από τους πελάτες, ώστε αν υπάρχει η βεβαιότητα ότι το λογισµικό ικανοποιεί τις απαιτήσεις και τις ανάγκες τους, καθώς οι κατασκευαστές µπορεί να έχουν σχηµατίσει διαφορετική, αλλοιωµένη εικόνα σχετικά µε αυτές. Έτσι οι πελάτες διαβεβαιώνονται ότι το λογισµικό που δηµιουργήθηκε είναι αυτό το οποίο ζήτησαν. Είναι σηµαντικό να διαχωριστούν οι έλεγχοι αυτού του τύπου από τους υπόλοιπους, καθώς οι συγκεκριµένοι δεν βασίζονται στις υποθέσεις και τις αντιλήψεις των κατασκευαστών του συστήµατος σχετικά µε το προϊόν της εργασίας τους. Επίσης οι κατασκευαστές δεν εµπλέκονται µε τον ίδιο τρόπο στην εκτέλεση των ελέγχων αποδοχής, καθώς ουσιαστικά οι έλεγχοι γίνονται από τους πελάτες

45 9 Περίπτωση µελέτης Ανάπτυξη (Case Study) Η παρούσα µελέτη αφορά την ανάπτυξη του λογισµικού XPortofolio και σε καµία περίπτωση δεν συνιστά εγχειρίδιο ανάπτυξης ή παρεµφερούς µελέτης άλλων έργων λογισµικού. Ο σκοπός της παρούσας µελέτης είναι καθαρά ερευνητικός πειραµατικός. 9.1 Περίληψη Η παρούσα µελέτη αφορά στην ανάπτυξη ενός λογισµικού διαχείρισης έργου, µε το όνοµα XPortofolio. Η εφαρµογή σχεδιάστηκε και αναπτύχθηκε για χρήση από επιχειρήσεις οι οποίες ασκούν τις αρχές και τις πρακτικές των Ευέλικτων Μεθόδων (Agile Methods) και του Ακραίου Προγραµµατισµού (Extreme Programming). Σκοπός της όλης διαδικασίας ήταν να µελετηθούν και να καταγραφούν τα εξής: 1. Η εφαρµογή των Ευέλικτων Μεθόδων Methods και του Ακραίου Προγραµµατισµού. Ουσιαστικά πρόκειται για εφαρµογή των 12 πρακτικών του Ακραίου Προγραµµατισµού και παρατήρησης του τρόπου που εφαρµόζονται. εν έχει να κάνει τόσο µε µετρικές και αριθµητικές παραµέτρους, όσο την εµπειρική διαπίστωση και πρακτική εµπέδωση των πρακτικών. 2. Ο ανθρώπινος παράγοντας στον τρόπο εφαρµογής των 12 πρακτικών. Στην εφαρµογή των πρακτικών που αναφέρεται στο σηµείο 1 της µελέτης, µεγάλο ρόλο θεωρείται πως παίζει ο ίδιος ο άνθρωπος, υπό την έννοια ότι επηρεάζει ολόκληρη την διεργασία. Έτσι ορίζεται ένας ιδιαίτερος παράγοντας επιρροής, ο ανθρώπινος. Οι πτυχές της επιρροής και οι εκφάνσεις τους είναι εξαιρετικής σηµασίας, ίσως και το κοµβικότερο σηµείο της µελέτης. 3. Τα αποτελέσµατα της εφαρµογής των 12 πρακτικών ως προς το προϊόν λογισµικού που προέκυψε από την όλη διαδικασία

46 Όπως είναι λογικό και αναµενόµενο, προϊόν της διαχείρισης έργου µε χρήση Ευέλικτων µεθόδων είναι µία εφαρµογή. Η εφαρµογή αυτή είναι ένα πρόγραµµα διαχείρισης έργων µε χρήση Ευέλικτων Μεθόδων και ουσιαστικά αποτελεί το σηµείο εφαρµογής των 12 πρακτικών που αναφέρθηκε παραπάνω. εν είναι το πρωτεύον ζήτηµα η δηµιουργία λογισµικού, ωστόσο είναι αρκετά ενδιαφέρον και χρήσιµο να διαπιστωθούν οι επιδράσεις και τα αποτελέσµατα της χρήσης ευέλικτων µεθόδων µε κάποιο «χειροπιαστό» υλικό, το οποίο είναι το προϊόν της εργασίας της οµάδας ανάπτυξης. Μετά από την διενέργεια της µελέτης και της έρευνας, προέκυψαν τα εξής: 1. Μια καταγεγραµµένη σειρά από εκφάνσεις και παραλλαγές των 12 πρακτικών των Ευέλικτων Μεθόδων, όπως καταγράφηκαν κατά την διάρκεια της ανάπτυξης του λογισµικού. 2. Μια σαφής καταγεγραµµένη συσχέτιση του ανθρώπινου παράγοντα σε ό,τι αφορά την εφαρµογή των πρακτικών και των αρχών των Agile µεθοδολογιών, το τελικό προϊόν και την αναπτυξιακή διαδικασία γενικότερα. 3. Η εφαρµογή «XPortofolio», η οποία απευθύνεται σε οµάδες ανάπτυξης ευέλικτου λογισµικού και αποτελεί καρπό της παρούσας εργασίας. Υφίσταται έτσι ένα «µετρήσιµο» και «χειροπιαστό» υλικό για την αξιολόγηση της εφαρµογής των Ευέλικτων Μεθόδων, σε συνδυασµό πάντα µε τις καταγεγραµµένες πληροφορίες που προέκυψαν κατά την ανάπτυξη του XPortofolio. Η αξιολόγηση και ο έλεγχος ορθότητας των πρακτικών που ακολούθησε η οµάδα ανάπτυξης του XPortofolio (ως προς τον αντικειµενικό σκοπό της εργασίας) έγινε από τους κυρίους Σταµέλο Ιωάννη, Επίκουρο Καθηγητή στο Τµήµα Πληροφορικής του Αριστοτελείου Πανεπιστηµίου Θεσσαλονίκης και Σφέτσο Παναγιώτη, Καθηγητή Εφαρµογών στο Τµήµα Πληροφορικής των Τ.Ε.Ι. Θεσσαλονίκης. Επίσης ακολουθήθηκαν διαδικασίες και αρχές οι οποίες περιγράφονται από εγκεκριµένες βιβλιογραφικές και διαδικτυακές πηγές, όπως αυτές αναφέρονται στο Κεφάλαιο 10 ( Βιβλιογραφία Πηγές)

47 9.2 Στόχοι / Σκοποί Η πίεση και η ανάγκη για την παραγωγή λειτουργικού λογισµικού «κατά παραγγελία» ωθούν τους προγραµµατιστές στην αναζήτηση λύσεων για ταχύτερη ανάπτυξη. Οι µέθοδοι που προκύπτουν µοιάζουν αρκετά ξένες και περίεργες σε άλλους προγραµµατιστές και συνεπώς επικρατεί µία επιφυλακτική στάση σε ό,τι αφορά την εφαρµογή τους. Προϊόν της αναζήτησης αυτής ήταν το Agile Manifesto, όπως αναλύθηκε στο Κεφάλαιο 2. Κατά καιρούς έχουν παρουσιαστεί διάφορες µελέτες και έρευνες σχετικά µε τις µεθόδους ανάπτυξης λογισµικού, είτε τις «παραδοσιακές», είτε τις ευέλικτες. Για τις ευέλικτες µεθόδους, οι οποίες είναι και ο κύριος άξονας του αντικειµένου που πραγµατεύεται η παρούσα µελέτη, έχει γίνει επαρκής ανάλυση και παρουσίαση των αρχών και της γενικότερης θεωρίας που συνιστούν το υπόβαθρο των εν λόγω µεθοδολογιών. Ωστόσο η αναφορά στον ανθρώπινο παράγοντα κατά την ανάπτυξη λογισµικού µε χρήση Ευέλικτων Μεθόδων είναι συνήθως ελάχιστη έως µηδενική. Συνεπώς µία ακόµα πρακτική και πειραµατική επιβεβαίωση των κανόνων και των πρακτικών του Ακραίου Προγραµµατισµού θα ενίσχυε µεν το κύρος και την αξιοπιστία τους, αλλά δεν θα προσέφερε κάτι παραπάνω στην «περιθωριοποιηµένη» (από άποψη πειραµατικής µελέτης) έννοια του ανθρώπινου παράγοντα. Σκοπός της παρούσας εργασίας ήταν η ανάδειξη των αξιών, των αρχών και των κανόνων που διακατέχουν την ευέλικτη ανάπτυξης λογισµικού, µε ιδιαίτερη όµως έµφαση στις επιδράσεις, τα αποτελέσµατα και τις καινοτοµίες που προσφέρει η ανθρώπινη πλευρά κάθε εµπλεκόµενου σε µία διαδικασία ευέλικτης ανάπτυξης λογισµικού. Επίκεντρο και αντικείµενο εφαρµογής των ευέλικτων µεθόδων, καθώς και καταγραφής των σχετικών παρατηρήσεων ήταν το λογισµικό XPortofolio. Η επιλογή ονόµατος και λειτουργικότητας του προγράµµατος µόνο τυχαία δεν ήταν σε σχέση µε τον σκοπό και τον στόχο της µελέτης, κάτι το οποίο προκύπτει και σε περαιτέρω ανάλυση η οποία γίνεται παρακάτω. Για την καλύτερη κατανόηση του πλάνου µελέτης είναι χρήσιµο να αναφερθεί ότι το XPortofolio επιχειρήθηκε να αποτελέσει εφαρµογή για χρήση από οµάδες προγραµµατιστών οι οποίοι εφαρµόζουν Ευέλικτες Μεθόδους, ώστε κατά την διαδικασία ανάπτυξης να µπορούσε να επιτευχθεί «Agile Developing για Agile Devel

48 opers». Σηµειώνεται ωστόσο ότι η δηµιουργία της εφαρµογής δεν αποτελούσε αυτοσκοπό για την ερευνητική δραστηριότητα. Θα µπορούσε να ειπωθεί λοιπόν, ότι το σχέδιο µελέτης και καταγραφής ήταν το παρακάτω: 1. Η εφαρµογή των Ευέλικτων Μεθόδων και του Ακραίου Προγραµµατισµού για την ανάπτυξη του XPortofolio. a. ιαδικασία παραγωγής λειτουργικού-παραδοτέου λογισµικού. b. Καταγραφή όλων των παραµέτρων κατά το βήµα 1.A. 2. Καταγραφή των αποτελεσµάτων. a. Καταγραφή των αποτελεσµάτων σε ό,τι αφορά το λογισµικό (ποιότητα, λειτουργικότητα). b. Αξιολόγηση των αποτελεσµάτων από το βήµα 1.B και καταγραφή των προκυπτόντων αποτελεσµάτων από την αξιολόγηση στο παρόν βήµα. 3. Συσχέτιση και αξιολόγηση του ανθρώπινου παράγοντα. a. Συλλογή των αποτελεσµάτων από τα βήµατα 1 και 2. b. Αξιολόγηση συσχετίσεων και αλληλεπιδράσεων βάσει των αποτελεσµάτων από το 3.Α, των καταγραφών και τις εµπειρικής γνώσης των εµπλεκοµένων κατά την διαδικασία ανάπτυξης του λογισµικού XPortofolio. 4. Αξιολόγηση των αποτελεσµάτων που προέκυψαν από το βήµα 3. Η 4η φάση της µελέτης είναι και η ουσία της, υπό την έννοια ότι αποτελεί το κυριότερο και πλέον επιθυµητό προϊόν της εργασίας. Πιο αναλυτικά, τα βασικότερα θέµατα τα οποία µελετήθηκαν και καταγράφηκαν είναι τα εξής: Οι ανθρώπινοι παράγοντες στον προγραµµατισµό (Human Factors). Παρουσίαση των ρόλων των προγραµµατιστών. ιαφορές µεταξύ των παραδοσιακών και ευέλικτων µεθοδολογιών. Οι ρόλοι του προγραµµατιστή στον προγραµµατισµό ανά ζεύγη (Pair Programming). Οι ρόλοι του προγραµµατιστή µέσα στις οµάδες εργασίας (work groups - teams). Ο ρόλος της Προσωπικότητας και της Ιδιοσυγκρασίας του προγραµµατιστή

49 Οι απαιτούµενες Ικανότητες και εξιοτεχνίες του προγραµµατιστή για την επιτυχή περάτωση των ανατιθέµενων ρόλων. Χειρισµός της Γνώσης και οι διαφορετικοί ρόλοι. Επικοινωνία και συνεργασία (Communication - Collaboration) και οι διαφορετικοί ρόλοι. ηµιουργία Ευέλικτων Μοντέλων Αποτίµησης και Βελτιστοποίησης. Προϋποθέσεις και Απαιτήσεις. 9.3 Τοποθεσία Η ανάπτυξη του XPortofolio έλαβε χώρα στην πόλη της Θεσσαλονίκης, όπου φοιτούσαν και τα άτοµα της οµάδας ανάπτυξης. Ο χώρος ανάπτυξης ήταν κατά κύριο λόγο η οικεία του Κίµων Πολυχρονιάδη, µέλους της οµάδας ανάπτυξης, η σύσταση της οποίας περιγράφεται σε παρακάτω ενότητα. Η επιλογή της οικείας ως χώρος ανάπτυξης έγινε για τους εξής λόγους: 1. Η οικεία του Κ. Πολυχρονιάδη ήταν η πιο εύκολη και άνετη λύση από άποψη χρόνου, κόστους και εγκλιµατισµού. 2. Εφόσον ο προγραµµατισµός γινόταν στο σπίτι ενός µέλους της οµάδας, ήταν εξαιρετικά εύκολο να ρυθµιστεί ο ηλεκτρονικός υπολογιστής πάνω στον οποίο γινόταν κατά το µεγαλύτερο µέρος της η ανάπτυξη του λογισµικού. 3. Εάν είχε επιλεχθεί ως κύριος χώρος ανάπτυξης κάποια εξωτερική τοποθεσία (π.χ. κάποιο εργαστήριο του Αριστοτελείου Πανεπιστηµίου), θα ήταν ιδιαίτερα δύσκολος ο συγχρονισµός της οµάδας µε το ωράριο του πανεπιστηµίου, ενώ θα ήταν σαφώς πιο δύσκολη η εγκατάσταση των απαραίτητων προγραµµάτων και λοιπών τεχνολογικών µέσων στον εκάστοτε ηλεκτρονικό υπολογιστή. 9.4 Εµπλεκόµενα άτοµα Σύσταση οµάδας Η οµάδα ανάπτυξης του XPortofolio αποτελούταν από 2 προπτυχιακούς φοιτητές του Τµήµατος Πληροφορικής του Αριστοτελείου Πανεπιστηµίου Θεσσαλονίκης (Α.Π.Θ.), τους Πολυχρονιάδη Κίµων και Σκαλιστή Στέφανο

50 Επιβλέποντες της όλης διαδικασίας ανάπτυξης αλλά και της γενικότερης έρευνας και µελέτης ήταν οι κύριοι Σταµέλος Ιωάννης, Επίκουρος Καθηγητής του Τµήµατος Πληροφορικής του Αριστοτελείου Πανεπιστηµίου Θεσσαλονίκης. Σφέτσος Παναγιώτης, Καθηγητής Εφαρµογών στο Τµήµα Πληροφορικής του Τεχνολογικού Εκπαιδευτικού Ιδρύµατος Θεσσαλονίκης. Ο ρόλος του κ. Σφέτσου έγκειται στην βαθιά γνώση των Ευέλικτων Μεθόδων και του Ακραίου Προγραµµατισµού, του αντικειµένου έρευνας δηλαδή της παρούσας εργασίας. Επίσης ήταν διαρκής συµβουλευτική πηγή και η ιδιαίτερα σηµαντική καθοδήγηση και δυνατότητα αποσαφήνισης που παρείχε έδωσαν σηµαντική ώθηση στην οµάδα ανάπτυξης σε περιπτώσεις κωλύµατος ή άλλων αδιεξόδων. Για την καλύτερη κατανόηση εννοιών και αναλύσεων που παρατίθενται παρακάτω, είναι σηµαντικό να αναφερθεί η εκ των προτέρων γνωριµία των 2 µελών της οµάδας ανάπτυξης, ιδιαίτερα από την στιγµή που ήταν οµήλικοι συµφοιτητές. Αυτό άλλωστε ήταν και βασικό κριτήριο για την εύρεση των ατόµων και την σύσταση τελικά της οµάδας, βάσει του προγραµµατισµού σε ζευγάρι που ακολούθησε. Επίσης ήταν σηµαντική η γνώση της γλώσσας Java από τον Κίµων και τον Στέφανο αµφότερους, αφού θεωρήθηκε ως «σήµα-κατατεθέν» της αντικεµενοστρεφούς ανάπτυξης λογισµικού. Επί προσθέτως, µε χρήση της Java ήταν δυνατή και η χρήση του JUnit, για την διενέργεια ελέγχων (tests), ζήτηµα που αναλύεται σε παρακάτω ενότητα Οι ρόλοι στην οµάδα ανάπτυξης Όπως γίνεται αντιληπτό, µε µόλις δύο άτοµα στην οµάδα ανάπτυξης, οι ρόλοι οι οποίοι επιλέχθηκαν προς διεκπεραίωση µοιράστηκαν µεταξύ των δύο µελών και συχνά γινόταν ανταλλαγή τους. Κοινώς, το κάθε µέλος αναλάµβανε πολλαπλούς ρόλους κατά την διάρκεια της ανάπτυξης. Οι ρόλοι που επιλέχθηκαν περιγράφηκαν στο κεφάλαιο 3, ωστόσο χάρη πληρότητας είναι επιθυµητό να αναφερθούν και πάλι, ενώ θα γίνει και αναφορά στα άτοµα τα οποία ανέλαβαν τον εκάστοτε ρόλο. Η παρουσίαση των ρόλων είναι εφάµιλλη αυτής του κεφαλαίου 3, αλλά χάριν σφαιρικότητας παρατίθενται σύµφωνα µε τους P.Abrahamsson, O.Salo, J.Ronkainen και J.Warsta [3]. Σε παρενθέσεις στο

51 περιγραφικό µέρος του κάθε ρόλου αναφέρονται τα άτοµα τα οποία ανέλαβαν τον εκάστοτε ρόλο: Προγραµµατιστής (Programmer) Οι προγραµµατιστές (Κ. Πολυχρονιάδης, Σ. Σκαλιστής) έχουν την ευθύνη των ελέγχων (tests) και της διατήρησης κατά το δυνατόν απλού και ουσιαστικού τον κώδικα. Βασικό χαρακτηριστικό της συνεργασίας πρέπει να είναι η επικοινωνία και ο συγχρονισµός µεταξύ τους. Πελάτης (Customer) Ο πελάτης (αρχικά µόνο ο Π. Σφέτσος και κατόπιν και οι Κ. Πολυχρονιάδης και Σ. Σκαλιστής ως ευέλικτοι προγραµµατιστές και οι ίδιοι) έχει ην ευθύνη για την συγγραφή των απαιτήσεων χρηστών και προετοιµασία των ελέγχων λειτουργικότητας (user stories and functional tests). Επίσης θέτει την ιεραρχία σηµαντικότητας σχετικά µε την υλοποίηση των απαιτήσεων. Υπεύθυνος ελέγχων (Tester) Σκοπός του υπεύθυνου ελέγχων (Κ. Πολυχρονιάδης, Σ. Σκαλιστής) είναι η συνδροµή του στην συγγραφή των λειτουργικών ελέγχων από τον πελάτη. Ακόµα, έχει ευθύνη για την διαρκή προετοιµασία ελέγχων, την διανοµή των αποτελεσµάτων τους και την ευθύνη των εργαλείων ελέγχων. Υπεύθυνος στατιστικών και µετρικών (Tracker) Ο υπεύθυνος στατιστικών και µετρικών (Κ. Πολυχρονιάδης, Σ. Σκαλιστής) είναι ο παράγοντας «ανάδρασης» στο έργο, υπό την έννοια ότι ανατροφοδοτεί την οµάδα ανάπτυξης µε πληροφορίες. Οι πληροφορίες αυτές έχουν να κάνουν µε διάφορες εκτιµήσεις (π.χ. αναµενόµενο χρόνο διεκπεραίωσης ενός user story) και σκοπός είναι η βελτίωση µελλοντικών προβλέψεων, ώστε να είναι όσο το πιο δυνατόν η απόκλιση από την πραγµατικότητα. Επίσης παρακολουθεί την πρόοδο κάθε κύκλου λειτουργίας / ανάπτυξης (iteration, βλ. Εικόνα 4) της ανάπτυξης και υπολογίζει εάν και κατά πόσον ο εκάστοτε στόχος µπορεί να επιτευχθεί βάσει των δοθέντων πόρων και χρονικών περιορισµών. Τέλος, έχει την ευθύνη για την επισήµανση τυχόν απαραίτητων αλλαγών που πρέπει να γίνουν κατά την διάρκεια µίας επανάληψης

52 Εικόνα 4: Τυπικοί κύκλοι ανάπτυξης (iterations) σε έργο XP [13]. Υπεύθυνος ανθρώπινων παραγόντων (Coach) Ο υπεύθυνος ανθρώπινων παραγόντων (Π. Σφέτσος) είναι υπεύθυνος για το σύνολο της διαδικασίας. Απαιτείται βαθιά γνώση του Ακραίου Προγραµµατισµού ώστε να είναι σε θέση να καθοδηγεί τα άλλα µέλη της οµάδας κατά την ανάπτυξη του έργου λογισµικού. Εξωτερικός σύµβουλος (Consultant) Ο εξωτερικός σύµβουλος (Π. Σφέτσος, Σ. Σκαλιστής, Κ. Πολυχρονιάδης), είναι συνήθως κάποιος εξωτερικός συνεργάτης, ο οποίος κατέχει συγκεκριµένο πεδίο γνώσης, τεχνικός ειδήµων. Ο ρόλος του είναι η καθοδήγηση και συνδροµή στην επίλυση συγκεκριµένων προβληµάτων που αντιµετωπίζει η οµάδα ανάπτυξης. ιαχειριστής (Manager) Ο διαχειριστής (Π. Σφέτσος αρχικά και κατόπιν Κ. Πολυχρονιάδης, Σ. Σκαλιστής) θα µπορούσε να χαρακτηριστεί ως το «αφεντικό» της οµάδας ανάπτυξης. Είναι ο κεντρικός κόµβος στην λήψη αποφάσεων και ως εκ τούτου, είναι αναγκαία η επικοινωνία του µε τα µέλη της οµάδας για τον καθορισµό της τρέχουσας κατάστασης και να διακρίνει τυχόν δυσκολίες ή άλλα προβλήµατα στην διαδικασία ανάπτυξης. 9.5 Ανάπτυξη Όπως ήδη αναφέρθηκε, το προϊόν της έρευνας ήταν το λογισµικό XPortofolio. Το XPortofolio απευθύνεται σε οµάδες ανάπτυξης λογισµικού, οι οποίες εφαρµόζουν

53 Ευέλικτες Μεθόδους και τις τεχνικές του Ακραίου Προγραµµατισµού. Έτσι δινόταν η δυνατότητα για άµεση σύνδεση της διαδικασίας ανάπτυξης, της υπό δηµιουργίας εφαρµογής και του θεωρητικού υπόβαθρου στο οποίο βασίστηκε η παρούσα µελέτη. Ο όρος «Agile Developing για Agile Developers» που χρησιµοποιήθηκε σε παραπάνω ενότητα, αποτυπώνει αυτή ακριβώς την σύνδεση Γενική θεώρηση του Ακραίου Προγραµµατισµού Σύµφωνα µε τον Thomas Duziak [4], ο Ακραίος Προγραµµατισµός αποτελεί τόσο µία διαδικασία ανάπτυξης λογισµικού όσο και µία γενικότερη µεθοδολογία. Ως διαδικασία, ορίζει ποιος κάνει τι, πότε και πώς. Αυτό σηµαίνει ότι παρέχει αρχές, τεχνικές και πρακτικές για ώστε η παραγωγή λογισµικού να είναι κατά το δυνατόν αποτελεσµατική και προβλέψιµη. Συνεπώς, η διαδικασία αποτελεί έναν «οδηγό» για την ανάπτυξης έργων λογισµικού. Ο Ακραίος Προγραµµατισµός είναι επίσης ένα πλαίσιο διεργασιών, καθώς µπορεί δυνητικά να ταιριάξει στις ιδιαίτερες ανάγκες της εκάστοτε οµάδας, έργου, εταιρίας κτλ. Ο Ακραίος Προγραµµατισµός αποτελεί µία «λιτή» (lightweight) µεθοδολογία. Γενικά, οι µεθοδολογίες αυτού του είδους παρουσιάζουν υψηλή παραγωγικότητα και αντοχή σε σφάλµατα. Η επικοινωνία είναι συνήθως πιο ισχυρή σε διαπροσωπικές επαφές, ιδιαίτερα όταν αυτές δεν αφορούν επίσηµες συζητήσεις και καταγεγραµµένες πληροφορίες. Υπάρχει µικρό εύρος παραδοτέου προϊόντος (deliverables) αλλά ταυτόχρονα υφίστανται και συχνές παραδόσεις (releases). Οι µεθοδολογίες αυτού του τύπου περιλαµβάνουν επίσης έναν µικρό αριθµό ρόλων και δραστηριοτήτων. 9.6 Οι πρακτικές του Ακραίου Προγραµµατισµού στην ανάπτυξη του XPortofolio Στο κεφάλαιο 2 αναφέρθηκαν συνοπτικά οι 12 πρακτικές του Ακραίου Προγραµµατισµού. Στην παρούσα ενότητα θα γίνει και πάλι µία παρουσίαση των πρακτικών αυτών, ωστόσο θα γίνει και µία συσχέτιση µε την άποψη της οµάδας του XPortofolio, όπως προέκυψε κατά την διαδικασία ανάπτυξης του έργου και του τρόπου εφαρµογής των 12 πρακτικών

54 9.6.1 Γενική θεώρηση των 12 πρακτικών του XP Όπως αναφέρει ο Steve Hayes [10], εάν κάθε µία από τις πρακτικές του Ακραίου Προγραµµατισµού εξεταστεί αποµονωµένα, µπορούν να διαπιστωθούν διάφορα ελαττώµατα. Ωστόσο είναι σηµαντική η κατανόηση του γεγονότος ότι οι 12 πρακτικές είναι αλληλένδετες. Η µία καλύπτει τα κενά και τα ελαττώµατα της άλλης, δηµιουργώντας έτσι µία σχέση αλληλοϋποστήριξης, κάτι που φαίνεται και στην Εικόνα 5. Κάθε µία από τις αρχές του Ακραίου Προγραµµατισµού µπορεί εύκολα να περιγραφεί, αλλά δύσκολα µπορεί κάποιος να αποκτήσει βαθιά γνώση και κατανόηση. Εικόνα 5: Αλληλεπίδραση των 12 πρακτικών [13]. Ο συνδυασµός των 12 αρχών οδηγεί σε πιο πολύπλοκη και ενίοτε απρόβλεπτη συµπεριφορά της ανάπτυξης του έργου. Ωστόσο κάθε µία αρχή έχει κάποιο ρόλο στην διατήρηση και την τροποποίηση του χαµηλού κόστους αλλαγών. Οι πρακτικές του Ακραίου Προγραµµατισµού παραθέτονται παρακάτω και σε κάθε µία γίνεται αναφορά στον τρόπο εφαρµογής τους και σε κάποια συµπεράσµατα που τυχόν ανέκυψαν µετά την ολοκλήρωση της έρευνας αλλά και κατά την διάρκειά της, καθώς και από την σφαιρική θεώρηση του έργου Οι 12 πρακτικές και η εφαρµογή τους στην ανάπτυξη του XPortofolio Προδιαγραφές Κώδικα (Coding Standards) Η συγγραφή κώδικα είναι οµαδική διαδικασία. Συνεπώς κατά την συγγραφή είναι βέβαιο ότι θα εµφανιστούν διαφορετικές νοοτροπίες συγγραφής και µορφής κώδικα. Ωστόσο από την στιγµή που διαφορετικά άτοµα θα δουλεύουν κατά καιρούς σε διαφορετικά κοµµάτια κώδικα, είναι απαραίτητη η ύπαρξη κάποιων προδιαγραφών

55 ώστε ο προκύπτων κώδικας να δίνει κατά το δυνατόν την εντύπωση ότι προήλθε από έναν µοναδικό προγραµµατιστή. XPortofolio: Από την πρώτη στιγµή που ξεκίνησε η διαδικασία συγγραφής κώδικα, υπήρξε καθορισµός των προδιαγραφών της συγγραφής. εν υπήρξε κάποια ιδιαίτερη διαφωνία µεταξύ Στέφανου και Κίµων για την µορφή και την τακτική που θα ακολουθούταν σε αυτόν τον τοµέα. Άλλωστε η πρότερη συνεργασία των δύο σε προηγούµενες περιπτώσεις είχε προσφέρει την αµοιβαία γνώση για τον τρόπο συγγραφής κώδικα. Το όφελος της ενιαίας µορφής κώδικα ήταν προφανώς η ευκολία εγκλιµατισµού οποιουδήποτε εκ των δύο προγραµµατιστών όταν αναλάµβανε χρέη προγραµµατιστή (developer). Ακόµα και ο προγραµµατιστής που είχε τον ρόλο του παρατηρητή (navigator) κατά τον προγραµµατισµό σε ζευγάρια είχε την δυνατότητα εύκολης παρακολούθησης και κατανόησης του υπό συγγραφή κώδικα. Οι προδιαγραφές δεν είχαν αναρτηθεί ή σηµειωθεί σε κάποιο χαρτί ή λευκοπίνακα. Αρκούσε η προφορική σύµβαση των κανόνων και η πρακτική εφαρµογή τους και από τους δύο προγραµµατιστές για να διατηρηθούν τα πρότυπα που τέθηκαν αρχικά. Οι συµβάσεις σχετικά µε την µορφή του κώδικα βρήκαν εύκολα σύµφωνους και τα δύο µέλη του ζεύγους ανάπτυξης, µιας και από προηγούµενη προγραµµατιστική εµπειρία είχα αποκτήσει (έως ένα βαθµό τυχαία) την ίδια µεθοδολογία συγγραφής. Η ευκολία εύρεσης κοινού τρόπου ανάπτυξης κώδικα έγκειτο επίσης και στην µικρή αριθµητικά οµάδα ανάπτυξης. Μόλις δύο άτοµα ήταν εξαιρετικά εύκολο να συνεννοηθούν και να καταλήξουν σε µία κοινή απόφαση, ενώ και η τήρησή της ήταν επίσης εύκολη διαδικασία.. Τέλος, ένα εξαιρετικά χρήσιµο χαρακτηριστικό της χρήσης προδιαγραφών κώδικα ήταν το γεγονός ότι ο παραγόµενος κώδικας παρουσίαζε τέτοια οµοιοµορφία, ώστε σε αρκετά σηµεία που προβλεπόταν να γραφεί παραπλήσιος κώδικας µε προηγούµενα, οι προγραµµατιστές είχαν την δυνατότητα για χρήση του ήδη υπάρχοντος κώδικα, µε απλή αντιγραφή και επικόλληση στο σηµείο που απαιτούταν. Ακολούθως, µε τις σχετικές µετατροπές (εφόσον απαιτούταν αυτό), ο κώδικας στο σηµείο το οποίο εργαζόταν το ζευγάρι προγραµµατισµού ήταν ουσιαστικά έτοιµος. Αυτό σήµαινε εξοικονόµηση όχι µόνο χρόνου, αλλά και κόπου εύρεσης τρόπων επίλυσης διαφόρων προβληµάτων, αφού η λύση ήταν συχνά έτοιµη σε κάποιο σηµείο

56 από τα προηγούµενα κοµµάτια κώδικα. Η πρακτική αυτή συνδυάστηκε άψογα µε την χρήση των φορµών για ανάκληση τρόπων αντιµετώπισης παραπλήσιων προβληµάτων κάθε είδους (βλ. παρακάτω). Απλή Σχεδίαση (Simple Design) Η διατήρηση του κόστους σε χαµηλά επίπεδα συνεπάγεται την όσο το δυνατόν πιο απλή µορφή του συστήµατος, καθώς και την αποφυγή υλοποίησης χαρακτηριστικών του συστήµατος αµφίβολης µετέπειτα χρηστικής αξίας. Σε περίπτωση που απαιτηθεί τελικά η υλοποίησή τους, είναι σχεδόν βέβαιο ότι κάτι τέτοιο θα γίνει µε το ελάχιστο πρόσθετο κόστος. XPortofolio: Η εφαρµογή γενικά βασιζόταν σε γραφικές διεπαφές χρήστη (GUIs), οπότε ήταν σχετικά εύκολο να χωριστεί η ανάπτυξη της εφαρµογής σε µέρη, βάσει των οθονών που θα δηµιουργούνταν. Πιο συγκεκριµένα, έγινε αρχικά µια λιτή σχεδίαση σε χαρτί των οθονών που θα δηµιουργούνταν και συζήτηση επί αυτών, ώστε να καταλήξει η οµάδα σε µία τελική µορφή. Ωστόσο κατά την σχεδίαση λαµβανόταν υπόψη ο τρόπος υλοποίησης σε Java, υπό την έννοια ότι επιλέγονταν τα κατάλληλα γραφικά στοιχεία (components) σε κάθε οθόνη, ώστε σε περίπτωση ανάγκης τροποποιήσεων µετά την δηµιουργία τους να µην χρειάζονταν ευρείες (και συνεπώς χρονοβόρες) αλλαγές. Στην Εικόνα 6 φαίνεται η αναπαράσταση της σχεδίασης της οθόνης MainScreen.java

57 Εικόνα 6: Σχεδίαση της MainScreen.java Κατά την σχεδίαση των οθονών δεν τέθηκε επίσης ποτέ το θέµα του υπολογιστικού µέρους της εφαρµογής. Αυτό σήµαινε ότι δεν µελετήθηκε σε αυτήν την φάση ο υπολογισµός π.χ. των εργατοωρών (βλ. Παράρτηµα A) και η διαδικασία εµφάνισής τους, παρά µόνον η µορφή εµφάνισής τους στην γραφική διεπαφή. Αξίζει επίσης να αναφερθεί ότι κατά την διάρκεια της συγγραφής κώδικα γίνονταν συζητήσεις οι οποίες ενίοτε οδηγούσαν σε περαιτέρω αλλαγές ή τροποποιήσεις, ωστόσο η ύπαρξη ενός «σκαριφήµατος» όπως αυτό στην Εικόνα 6, ήταν εξαιρετικά χρήσιµο για την εκκίνηση της δηµιουργίας της εκάστοτε γραφικής διεπαφής. Παράδειγµα αποτελεί η ονοµατολογία των διαφόρων γραφικών περιεχοµένων, όπως το «EDD», το οποίο τελικά θεωρήθηκε καλύτερο να εµφανίζεται µε πλήρες όνοµα, δηλαδή Estimated Delivery Date. Ακόµα και τα ονόµατα των στηλών του Πίνακα 1 της MainScreen άλλαξαν αρκετές φορές µέχρι να αποφασιστεί τελικά ποια χαρακτηριστικά θα υφίστανται και µε τι όνοµα θα εµφανίζονται στην οθόνη. Τέλος, είναι εξαιρετικά σηµαντικό να τονιστεί ότι κατά την σχεδίαση του προγράµµατος αποφασίστηκε να χωριστεί η ανάπτυξη σε δύο µέρη. Το πρώτο µέρος περιλάµβανε την δηµιουργία της γραφικής διεπαφής και το δεύτερο την ανάπτυξη του υπολογιστικού µέρους της εφαρµογής. Μετά την ανάπτυξη της γραφικής διεπαφής δηλαδή, θα γινόταν η εισαγωγή των υπολογιστικών διαδικασιών και των δοµών

58 δεδοµένων που θα χρησιµοποιούνταν για την αποθήκευση, δηµιουργία και επεξεργασία των στοιχείων και των πληροφοριών, που ακολούθως θα εµφανίζονταν αναλόγως στην διεπαφή. Έλεγχοι (Testing) Κάθε απαίτηση αντανακλάται στους ελέγχους αποδοχής (acceptance tests), τα οποία είναι ιδιοκτησία του πελάτη. Οι προγραµµατιστές δηµιουργούν περιπτώσεις ελέγχου (test cases) πριν την συγγραφή κώδικα και οι έλεγχοι τους καθοδηγούν προς τους στόχους τους, ενώ ορίζουν και τις διάφορες διεπαφές (test-first-design). Όλες οι περιπτώσεις ελέγχου είναι αυτοµατοποιηµένες και εκτελούνται σε τακτά χρονικά διαστήµατα. Οι προγραµµατιστές µπορούν να προβαίνουν δυναµικά σε αλλαγές του κώδικα, καθώς οι έλεγχοι θα υποδείξουν την ύπαρξη τυχόν λαθών. XPortofolio: Η δοµή της εφαρµογής βασιζόταν σε γραφικές διεπαφές και ελάχιστα σε υπολογιστικές ή άλλου είδους «παρασκηνιακές» διεργασίες. Συνεπώς, οι έλεγχοι οι οποίοι θα γίνονταν αφορούσαν περισσότερο την «εµφάνιση» της εφαρµογής. Επίσης, θεωρώντας ότι το µεγαλύτερο µέρος του προγραµµατισµού αφορά το GUI, ο οποιοσδήποτε έλεγχος θα αφορούσε το εάν και κατά πόσον εµφανίζονται τα στοιχεία στην οθόνη κατά τον επιθυµητό τρόπο. Επί προσθέτως, η δηµιουργία γραφικής διεπαφής µπορεί να θεωρηθεί και σαν µία διαδικασία σαφώς πιο «καλλιτεχνική» από τον προγραµµατισµό άλλων, καθαρά υπολογιστικών διεργασιών. Η γενική τακτική λοιπόν που ακολουθήθηκε από την οµάδα ανάπτυξης ήταν αυτή της «δοκιµής και επιτυχία». ηλαδή µε χρήση του σχεδιαστή φορµών (form designer) του χρησιµοποιούµενου περιβάλλοντος εργασίας που χρησιµοποιήθηκε (βλ. παρακάτω) γινόταν γρήγορη και εύκολη ανάπτυξη της αρχικής µορφής της εκάστοτε οθόνης. Κατόπιν, γινόταν η προεπισκόπηση του GUI που είχε προκύψει και, εφόσον υπήρχαν ενστάσεις σχετικά µε το αποτέλεσµα (που σε ένα έργο λογισµικού είναι απολύτως λογικό να υπάρχουν), γινόταν τροποποίησή του, το ίδιο εύκολα µε την δηµιουργία του. Ακόµα και σε κάθε βήµα εισαγωγής κάποιου στοιχείου της γραφικής διεπαφής γινόταν προεπισκόπηση του αποτελέσµατος ώστε να έχει η οµάδα πλήρη εποπτεία της µορφής και κατόπιν γινόταν η εισαγωγή περαιτέρω στοιχείων στην εν λόγω γραφική διεπαφή. Στην Εικόνα 7 φαίνεται συνοπτικά η σταδιακή εισαγωγή των γραφικών περιεχοµένων (components) στην οθόνη NewProjectScreen.java

59 Εικόνα 7: Σταδιακή προσθήκη στοιχείων στην οθόνη NewProjectScreen.java 1. Πεδία εισαγωγής, 2. Προσθήκη Combo Box, 3. Προσθήκη λιστών, 4. Προσθήκη πλήκτρων εν υπήρχαν εποµένως κάποιοι συγκεκριµένοι προετοιµασµένοι έλεγχοι οι οποίοι εκτελούνταν όταν θεωρούταν απαραίτητο (είτε σαν acceptance είτε σαν functionality tests). Σε αυτό επίσης συνέβαλλε και το γεγονός ότι οι δηµιουργοί του XPortofolio άνηκαν και οι ίδιοι στον χώρο που απευθύνεται η εφαρµογή, µε συνέπεια την πιο εύκολη και αποτελεσµατική υλοποίηση των επιθυµητών λειτουργιών. Είδη ελέγχων και εφαρµογή τους στο XPortofolio Στην ιδανική περίπτωση, το προκύπτον πρόγραµµα µία οµάδας ανάπτυξης λογισµικού, ανεξάρτητα από την µεθοδολογία ανάπτυξης, λειτουργεί τέλεια κάθε φορά που χρησιµοποιείται. Ωστόσο µία τέτοια ιδανική και «αποστειρωµένη» περίπτωση λογισµικού δεν είναι δυνατόν να υφίσταται. Οι πολύπλοκοι µαθηµατικοί υπολογισµοί και αλγόριθµοι που συχνά εµφανίζονται, καθώς και η αδυναµία πλήρους εικόνας της επιθυµίας του πελάτη εξ αρχής οδηγούν στην αναπόφευκτη παρουσία σφαλµάτων. Άµεση απόρροια των εµφανιζόµενων σφαλµάτων είναι η ανάγκη για ύπαρξη µηχανισµών εντοπισµού σφαλµάτων. Αυτόν τον ρόλο αναλαµβάνουν να επιτελέσουν

60 οι έλεγχοι (tests). Υπάρχουν διάφορα ήδη ελέγχων, τα οποία αναφέρθηκαν στο κεφάλαιο 8. Παρακάτω ακολουθούν τα είδη ελέγχων που συναντιόνται κατά την ανάπτυξη ενός έργου λογισµικού και πλήρη αναφορά της εφαρµογής τους κατά την εργασία της οµάδας στο XPortofolio. Έλεγχοι Μονάδων (Unit Tests) Στόχος των ελέγχων µονάδων είναι ο εντοπισµός σφαλµάτων των συστατικών µερών του υπό ανάπτυξη συστήµατος. Στην περίπτωση του XPortofolio σηµαντικό ρόλο σε αυτήν την διαδικασία έπαιξε η διαρκής εξέταση του κώδικα, η σύγκρισή του µε τις προδιαγραφές και τον σχεδιασµό, καθώς και η µεταγλώττισή του Η εξέταση του κώδικα επιτεύχθηκε κατά κύριο λόγο από τον ρόλο του παρατηρητή κατά τον προγραµµατισµό σε ζευγάρι. Ενώ ο ένας προγραµµατιστής συνέγραφε κώδικα, ο άλλος παρατηρούσε το τι γραφόταν και όταν διαπίστωνε ατέλειες ή άλλα στοιχεία άξια διόρθωσης το επισήµαινε εγκαίρως και κατόπιν γίνονταν οι απαραίτητες τροποποιήσεις. Γενικότερα, η ανάγνωση του κώδικα ακόµα και µετά το πέρας του προγραµµατισµού ή σε ενδιάµεσες διακοπές έδινε την δυνατότητα για εντοπισµό σφαλµάτων σε δεδοµένα, σύνταξη ή και αλγοριθµικών σφαλµάτων. Προφανώς µε την χρήση του σχεδιαστή φορµών η πλευρά αυτή των ελέγχων έγινε σαφώς πιο σύντοµη και περιορισµένη σε έκταση. Συχνά η οµάδα ανάπτυξης ανέτρεχε στον αρχικό σχεδιασµό για να διαπιστώσει εάν υπάρχουν ασυµβατότητες µεταξύ της σχεδίασης και του κώδικα που γραφόταν. Ο ρόλος του Παρατηρητή ήταν και πάλι βασικός σε αυτόν τον τοµέα, αφού συνήθως αυτός ήταν που είχε µπροστά του το σχετικό υλικό ώστε να µπορεί να προχωρήσει σε προτάσεις και διαπιστώσεις πάνω στον κώδικα. Τέλος, µε την µεταγλώττιση του κώδικα διαπιστώνονταν τυχόν συντακτικά λάθη και η οµάδα ανάπτυξης µπορούσε να προχωρήσει στην διόρθωσή τους. Αξίζει να σηµειωθεί ότι εφόσον δεν είχαν διαπιστωθεί λάθη ακόµα και µετά την µεταγλώττιση, γινόταν πρακτική διαπίστωση των λαθών, δηλαδή εκτελούταν το πρόγραµµα και από την χρήση του προγράµµατος διαπιστώνονταν τυχόν σφάλµατα. Αναφέρθηκε άλλωστε ήδη η λογική της «δοκιµής και επιτυχίας», που ήταν και η κύρια µέθοδος ελέγχων κατά την ανάπτυξη του XPortofolio. Μετά τον τελικό έλεγχο και τον συνδυασµό όλων των οθονών της εφαρµογής που είχαν δηµιουργηθεί, ακολούθησε το υπολογιστικό κοµµάτι του προγραµµατισµού, κάτι που αναφέρθηκε και στην ενότητα της πρακτικής περί απλού σχεδιασµού.

61 Σε περίπτωση που τα λάθη στο υπολογιστικό κοµµάτι δεν είχαν διαπιστωθεί µέχρι και την µεταγλώττιση, ήταν αναπόφευκτο να εντοπίζονται κατά την πρακτική αποσφαλµάτωση του προγράµµατος. Εφόσον οι πληροφορίες οι οποίες πραγµατευόταν το εν λόγω προγραµµατιστικό κοµµάτι εµφανίζονταν µέσω της γραφικής διεπαφής (GUI) στον χρήστη, ήταν εξαιρετικά εύκολος ο εντοπισµός λαθών, µε απλή χρήση της εφαρµογής, στο σηµείο που είχε βέβαια αναπτυχθεί κάθε φορά. Με πολλαπλές εκτελέσεις και διαφορετικά εισαγόµενα δεδοµένα διαπιστώνονταν τυχόν αποκλίσεις και άλλες ατέλειες. Σηµαντικό κοµµάτι της πρακτικής αποσφαλµάτωσης ήταν η εισαγωγή «πιλοτικών» στοιχείων για την διαδικασία αυτή. Η εισαγωγή δεν γινόταν από κάποια οθόνη της εφαρµογής, αλλά µε συγγραφή µικρών κοµµατιών κώδικα. Όταν η χρησιµότητά τους έπαυε, έµπαιναν σε µορφή σχολίων ώστε να είναι διαθέσιµα για τυχόν µετέπειτα ελέγχους, όχι όµως και µόνιµα λειτουργικά. Έλεγχοι Ενσωµάτωσης (Integration Tests) Όταν θεωρηθεί ότι οι διάφορες µονάδες λειτουργούν σωστά και συµφωνούν µε τους προκαθορισµένους στόχους, πρέπει να συνδυαστούν (integrate) σε ένα ενιαίο σύστηµα. Έχει εξαιρετική σηµασία ο συντονισµός και η προσεκτική σχεδίαση της ολοκλήρωσης, ώστε να είναι όσο το δυνατόν πιο εύκολος ο εντοπισµός τυχόν δυσλειτουργιών. Μετά τους ελέγχους µονάδων που είχαν γίνει µε τον τρόπο που αναφέρθηκε στην προηγούµενη ενότητα, η ενσωµάτωση των οθονών ήταν ακόµα πιο εύκολη εργασία. Ο λόγος ήταν απλός και είχε να κάνει µε το γεγονός ότι το µόνο που απαιτούταν από τους προγραµµατιστές ήταν η σύνδεση των διαφόρων οθονών µεταξύ τους, µε προσθήκη της λειτουργικότητας στα σχετικά στοιχεία της γραφικής διεπαφής (πλήκτρα πλοήγησης, menu κτλ). Ωστόσο όταν ήρθε η στιγµή για την ενοποίηση µερών που συµπεριλάµβαναν παρασκηνιακές υπολογιστικές διαδικασίες, τα πράγµατα ήταν πιο δύσκολα. Αυτό οφειλόταν στο γεγονός ότι κάποια δεδοµένα µπορεί να εµφανίζονταν ή και να επηρεάζονταν από διαφορετικές οθόνες της εφαρµογής αλλά και να υπήρχε αλληλεπίδραση µεταξύ των δεδοµένων. Συνέπεια αυτού ήταν ένας σχετικά υψηλός βαθµός πολυπλοκότητας στις συσχετίσεις δεδοµένων. Η λύση στο πρόβληµα του ελέγχου κατά την ολοκλήρωση έδωσε και πάλι η πρακτική εκσφαλµάτωση. Με χρήση της εφαρµογής διαπιστώνονταν τα λάθη που

62 προέκυπταν κατά την εκτέλεσή της και το µόνο που απαιτούταν από τους προγραµµατιστές ήταν να ακολουθήσουν την διαδροµή των δεδοµένων και τις κατευθύνσεις που παρείχε το ίδιο το περιβάλλον ανάπτυξης. Έλεγχοι Λειτουργικότητας (Functionality Tests) Οι τύποι ελέγχων που περιγράφτηκαν µέχρι εδώ αφορούσαν τα συστατικά µέρη του συστήµατος και τις αλληλεπιδράσει µεταξύ τους. Οι έλεγχοι λειτουργικότητας συχνά αποκαλούνται και «έλεγχοι µαύρου κουτιού» (black box tests), αφού δεν υπάρχει ενδιαφέρον ως προς το ποια συστατικά του συστήµατος εκτελούνται. Το ενδιαφέρον της οµάδας ανάπτυξης σε αυτό το σηµείο στρέφεται στις λειτουργικές απαιτήσεις του συστήµατος και στο αν και κατά πόσον το σύστηµα κάνει αυτά που υποτίθεται ότι πρέπει να κάνει. Στο XPortofolio, η λειτουργικότητα του συστήµατος ελέγχθηκε µε συνεχείς επανεκτελέσεις της εφαρµογής. Πιο συγκεκριµένα, η οµάδα ανάπτυξης εισήγαγε συγκεκριµένα δεδοµένα για τα οποία προέβλεπε ποια θα έπρεπε να είναι η συµπεριφορά του προγράµµατος. Για παράδειγµα, δηµιουργήθηκαν διαφορετικά έργα (Projects) και διαφορετικοί υπάλληλοι (Employees), στα πλαίσια της συγγραφής κώδικα για εισαγωγή στοιχείων, όπως περιγράφηκε και στην ενότητα για του έλεγχους ενσωµάτωσης. Έλεγχοι Αποδοχής (Acceptance Tests)- Για την διενέργεια των ελέγχων αποδοχής του XPortofolio δεν απαιτήθηκε η συνδροµή άλλου ατόµου πλην των κατασκευαστών. Το γεγονός ότι οι κατασκευαστές του XPortofolio ήταν και δυνητικοί χρήστες του, καθιστούσε την διαδικασία ελέγχων αποδοχής ισοδύναµη µε την χρήση της εφαρµογής. Ακολούθως, τα µέλη της οµάδας προχωρούσαν σε µία σχετική συζήτηση η οποία αφορούσε την εικόνα που είχαν αποκοµίσει τα µέλη από την χρήση του XPortofolio, από την οποία προέκυπταν χρήσιµα συµπεράσµατα και απόψεις σχετικά µε το προϊόν της εργασίας τους. Η αποδοχή του συστήµατος συντελούταν µε σύµφωνη άποψη και των δύο προγραµµατιστών και βασιζόµενη στην πρότερη εµπειρία τους από την χρήση άλλων εφαρµογών όπου κυριαρχούσε παραθυρικό περιβάλλον. JUnit Αναφορά στο JUnit και στις δυνατότητές του γίνεται συχνά στην βιβλιογραφία αντικειµενοστραφών µεθοδολογιών ανάπτυξης λογισµικού. Αποτελεί βασικό στοιχείο

63 αντικειµενοστραφών αναπτύξεων λογισµικού και δη µε χρήση της γλώσσας Java. Η αξιοποίησή του περιλαµβάνει ελέγχους µονάδων αλλά και ενσωµάτωσης. Κατά την ανάπτυξη του XPortofolio υπήρξε µηδενική χρησιµοποίηση του JUnit. Σε σχέση µε την ευκολία εύρεσης λαθών χωρίς χρήση τεχνολογικά υποβοηθούµενων ελέγχων παρατηρήθηκαν τα εξής: Η εφαρµογή ήταν βασισµένη κυρίως σε GUI και συνεπώς τα λάθη ήταν «χειροπιαστά» και εύκολα στον εντοπισµό. Η εφαρµογή ήταν σχετικά περιορισµένη σε έκταση και ήταν επίσης εύκολος ο εντοπισµός των λαθών. Η ευκολία εντοπισµού σφαλµάτων στον κώδικα λοιπόν ήταν ο κύριος λόγος που δεν αξιοποιήθηκαν οι δυνατότητες του JUnit. Ύστερα από συζήτηση πάνω σε αυτό το θέµα η οµάδα ανάπτυξης κατέληξε στο συµπέρασµα ότι η συγγραφή περαιτέρω κώδικα θα οδηγούσε σε πλεονάζουσα κατανάλωση χρόνου χωρίς σηµαντικό αντίκρισµα. Συνεπώς η συγγραφή ελέγχων για µικρό σε έκταση κώδικα που αφορούσε υπολογισµούς δεν θεωρήθηκε συµφέρουσα, ιδιαίτερα από την στιγµή που η εξοικείωση των µελών της οµάδας µε το συγκεκριµένο εργαλείο θα ήταν ζηµιογόνος διαδικασία για την ανάπτυξη του έργου. Όπως προκύπτει από τα παραπάνω το συνολικό κόστος του αθροίσµατος των διαδικασιών αυτών θεωρήθηκε εξαιρετικά ασύµφορο σε σχέση µε την µορφή, την φύση και την έκταση του XPortofolio οπότε δεν υπήρξε περαιτέρω ενασχόληση της οµάδας µε το JUnit Η Εικόνα 8 δείχνει τον υπολογισµό του συνολικού χρόνου που θα απαιτούταν για την αξιοποίηση του JUnit.. Εικόνα 8: Υπολογισµός χρόνου χρησιµοποίησης του JUnit. Προγραµµατισµός σε Ζευγάρια (Pair Programming, PP) Η συγγραφή του κώδικα καθεαυτή γίνεται από δύο άτοµα που µοιράζονται το ίδιο µηχάνηµα. Αντίθετα µε την συχνά επικρατούσα άποψη, αυτή είναι σαφώς πιο αποτελεσµατική µέθοδος από την εργασία δύο ατόµων που δουλεύουν ξεχωριστά. Τα

64 ζευγάρια εναλλάσσονται συχνά, ώστε η γνώση και η εµπειρία να διαµοιράζεται στην οµάδα. Ο κώδικας επιθεωρείται διαρκώς. Το XPortofolio, όπως ήδη αναφέρθηκε, δηµιουργήθηκε από µία οµάδα δύο ουσιαστικά ατόµων. Σχεδόν όλες οι διαδικασίες και οι ρόλοι διεκπεραιώθηκαν από τον Κίµων και τον Στέφανο, οπότε ο προγραµµατισµός σε ζευγάρια ήταν και φυσική απόρροια της σύνθεσης της οµάδας ανάπτυξης. Τόσο ο Κίµων όσο και ο Στέφανος είχαν συνηθίσει σε ατοµική συγγραφή κώδικα. Ακόµα και σε προηγούµενες εργασίες που είχαν αναλάβει, ακόµα και αν ήταν µέλη κάποιας οµάδας, η τελική συγγραφή του κώδικα γινόταν από ένα µόνο άτοµο. Ακόµα και οι ίδιοι είχαν κάποιες επιφυλάξεις απέναντι στην συγκεκριµένη πρακτική. Η ιδέα «εξάρτησης» από άλλο άτοµο και η ανάγκη συγχρονισµού του ρυθµού τους αποτελούσαν σηµαντικούς παράγοντες ανησυχίας. Τελικά µετά το πέρας των πρώτων συνεδριών προγραµµατισµού σε ζευγάρι, η άποψη των δύο προγραµµατιστών άλλαξε άρδην σε ότι αφορά την εν λόγω πρακτική. ιαπιστώθηκε πως ο συγχρονισµός του ρυθµού ήταν σαφώς πιο εύκολος απ ότι προβλεπόταν. Μπορεί ενίοτε να υπήρχε η ανάγκη για µείωση του ρυθµού ενός από τους δύο προγραµµατιστές, ωστόσο ο χρόνος που «χανόταν» (αν µπορεί να θεωρηθεί «χαµένος») ήταν σαφώς µικρότερος από τον χρόνο ελέγχων για αναζήτηση λαθών που εξοικονοµούταν. Αυτό οφείλεται στην παρουσία του παρατηρητή (navigator) κατά την διαδικασία του προγραµµατισµού. Η διαρκής παρακολούθηση του κώδικα από δεύτερο άτοµο, πέρα από τον ίδιο τον προγραµµατιστή (developer) ήταν καταλυτική για την µείωση των λαθών κατά την συγγραφή, την αύξηση της επινοητικότητας στην οµάδα και τόνωσε το αίσθηµα της κοινής ιδιοκτησίας κώδικα (βλ. παρακάτω) και του συνεργατικού αποτελέσµατος. Με την παρουσία δύο προγραµµατιστών στο ίδιο µηχάνηµα υπήρχε η δυνατότητα για διαρκή ανταλλαγή απόψεων (βλ. Κεφάλαιο 4) µε το αντικείµενο που πραγµατευόταν η εκάστοτε συζήτηση να βρίσκεται µπροστά στους προγραµµατιστές. Το αποτέλεσµα κάθε συζήτησης εφαρµοζόταν απευθείας στον κώδικα και καθόριζε την πορεία της συγγραφής. Αν επί παραδείγµατι αποφασιζόταν ότι µία κλάση, βάσει της µορφής που είχε, δεν εξυπηρετούσε τους σκοπούς που είχαν τεθεί για αυτή, υπήρχε περίπτωση ακόµα και να «πεταχτεί» και να ξεκινήσει η συγγραφή της εξ αρχής

65 Συλλογική Ιδιοκτησία Κώδικα (Collective Code Ownership) Κάθε άτοµο στην οµάδα έχει δικαίωµα να τροποποιήσει οποιοδήποτε µέρος του κώδικα, υπό τις προϋποθέσεις ότι θα το κάνει µε κάποιον συνεργάτη, θα συµµορφωθεί µε τις προδιαγραφές κώδικα και θα βεβαιωθεί ότι όλοι έλεγχοι είναι επιτυχείς όταν ολοκληρώσει την τροποποίηση. Αυτή η πρακτική εξαλείφει τα στεγανά τα οποία προκύπτουν σε µία οµάδα από την ατοµική ιδιοκτησία κώδικα. XPortofolio: Οι αναθεωρήσεις του κώδικα στο XPortofolio έγιναν µε την παρουσία και των δύο συνεργατών του ζεύγους προγραµµατισµού. Σπάνια αναλάµβαναν τα µέλη της οµάδας κάποια ιδιαίτερη πρωτοβουλία να αρχίσουν την συγγραφή κώδικα χωρίς να έχει προσυµφωνηθεί κάτι σε κάποια από τα «συµβούλια» που λάµβαναν χώρα κατά την ανάπτυξη της εφαρµογής. Ωστόσο όταν αυτό γινόταν, είχε ευεργετικά αποτελέσµατα. Σε περιπτώσεις που η οµάδα αντιµετώπιζε πρόβληµα στην επίλυση κάποιου προβλήµατος και βρισκόταν σε αδιέξοδο, υπήρχε σαφής καθυστέρηση του έργου. «Εκλάµψεις» κάποιου µέλους της οµάδας ήταν όχι απλά ωφέλιµες, αλλά (όπως ειπώθηκε σε κάποιο σηµείο όπου είχε επέλθει µεγάλο κώλυµα στην ανάπτυξη) «µάννα εξ ουρανού». Η διατύπωση της ιδέας και η άµεση (αν όχι ταυτόχρονη) εφαρµογή της στον κώδικα έδινε ώθηση στην οµάδα ανάπτυξης, αναπτέρωνε το ηθικό της και ενίοτε οδηγούσε σε ταχύτατη αναπλήρωση του χαµένου χρόνου. Αξίζει να αναφερθεί ότι αλλαγές στον κώδικα βάσει των ξαφνικών ιδεών επίλυσης αδιεξόδων δεν συνιστούν αλλαγές βάσει αόριστων σκέψεων. Ουδέποτε έγιναν άσκοπες ή ακατανόητες µετατροπές στον κώδικα, ποσώς δε µέσω ατοµικής εργασίας. Οι αλλαγές στις οποίες προέβαιναν τα µέλη της οµάδας βασίζονταν στην µελέτη του προβλήµατος και την εφαρµογή συγκεκριµένων λύσεων, οι οποίες βέβαια δεν είναι εγγυηµένα επιτυχηµένες, αλλά παραµένουν δυνητικές λύσεις. Αναθεώρηση Κώδικα (Refactoring) Η τεχνική γνωστή ως αναθεώρηση κώδικα είναι διαδικασία κατά την οποία επιτυγχάνεται βελτίωση του σχεδιασµού του ήδη υπάρχοντος κώδικα, χωρίς αλλοίωση της λειτουργικότητάς του. Η αναθεώρηση κώδικα είναι εφικτή διότι σε µία οµάδα Ακραίων Προγραµµατιστών υπάρχουν ήδη οι έλεγχοι για τον εντοπισµό των λαθών. Επίσης επιτρέπει τις αλλαγές στον κώδικα ώστε να αντανακλάται και η διαρκώς καλύτερη κατανόηση του προβλήµατος και να υφίσταται η δυνητική

66 δυνατότητα για τον εµπλουτισµό του απλού σχεδιασµού που αναφέρθηκε ως µία πρακτικές του Ακραίου Προγραµµατισµού. XPortofolio: Η διαδικασία της αναθεώρησης του κώδικα στο XPortofolio θεωρούταν εξαιρετικά σηµαντική και γι αυτό δινόταν ιδιαίτερο βάρος. Η οµάδα ανάπτυξης αφιέρωνε ολόκληρη την συνεδρία προγραµµατισµού σε ζευγάρι για αυτόν τον σκοπό. Αρχικά γινόταν µια αναδροµή στην εργασία που είχε γίνει µέχρι εκείνη την στιγµή, ώστε να δίνεται η δυνατότητα στην οµάδα να µελετάει τον κώδικα µε µεγαλύτερη άνεση. Κατόπιν, εντοπίζονταν τα σηµεία όπου θα ήταν επιθυµητή η εφαρµογή της αναθεώρησης του κώδικα και αναλύονταν οι διαθέσιµες δυνατότητες. Σε τυχόν αλλαγές του κώδικα γίνονταν άµεσα οι απαραίτητοι έλεγχοι (όπως περιγράφτηκαν σε παραπάνω ενότητα) και η διαδικασία συνέχιζε µε τον εντοπισµό του επόµενου σηµείου πιθανών αλλαγών στον κώδικα. ιαρκής Ενσωµάτωση Κώδικα (Continuous Integration) Οι οµάδες Ακραίου Προγραµµατισµού δουλεύουν µε µικρά βήµατα και ενσωµατώνουν τον κώδικά τους σε µεγαλύτερα σύνολα πολλές φορές την µέρα. Αυτό συνεπάγεται γρήγορο εντοπισµό προβληµάτων στην ολοκλήρωση και εύκολη διόρθωσή τους. Η διαρκής ολοκλήρωση µειώνει τις πιθανότητες µακρόχρονων αλλά ασύµβατων κοµµατιών κώδικα και εξασφαλίζει την ενηµερωµένη µορφή κάθε µέρους του συνολικού κώδικα του συστήµατος σε κάθε στιγµή. XPortofolio: Τα νέα συστατικά µέρη του συστήµατος που επιλέγονταν να δηµιουργηθούν επιλέγονταν βάσει δυνατότητας ενσωµάτωσης. Αυτό συνέβαινε ώστε να υπάρχει η δυνατότητα για άµεσο έλεγχο, αφού η γενική µεθοδολογία ελέγχων οδηγούσε ούτως ή αλλιώς σε µία τέτοια τακτική (βλ. παραπάνω ενότητα). Έτσι π.χ. µετά την ολοκλήρωση της MainScreen.java, το επόµενο βήµα ήταν να δηµιουργηθεί η ViewMoreScreen.java, αφού η τελευταία αποτελεί παράθυρο το οποίο εµφανίζεται µε το πάτηµα του κατάλληλου πλήκτρου στην MainScreen (βλ. Παράρτηµα). Στην Εικόνα 9 και στην Εικόνα 10 φαίνεται η εν λόγω περίπτωση ενσωµάτωσης των παραπάνω κλάσεων

67 Εικόνα 9: Η οθόνη MainScreen.java. Με κόκκινο κύκλο τονίζεται το πλήκτρο του οποίου υλοποιήθηκε η λειτουργικότητα. Εικόνα 10: Η οθόνη ViewMoreScreen.java. Θα µπορούσε λοιπόν να ειπωθεί πως η ανάπτυξη των οθονών ήταν κατά κάποιον τρόπο και οδηγούµενη από τα περιεχόµενα κάθε οθόνης («component driven»), υπό την έννοια ότι κάθε οθόνη δηµιουργούταν για την εξυπηρέτηση της λειτουργικότητας κάθε στοιχείου της διεπάφης. Προφανώς αυτή η άποψη συµβαδίζει µε την µεθοδολογία που αναφέρθηκε παραπάνω, δηλαδή µε την δυνατότητα ενσωµάτωσης. Μικρές Εκδόσεις (Small Releases) Οι εκδόσεις πρέπει να είναι κατά το δυνατόν µικρότερες ενώ ταυτόχρονα να προσφέρουν αρκετή χρηστική αξία ώστε να θεωρούνται αξιοποιήσιµες. Οι εκδόσεις από οµάδες Ακραίου Προγραµµατισµού προκύπτουν ύστερα από κύκλους ανάπτυξης µερικών εβδοµάδων, λόγω των µικρών βηµάτων ανάπτυξης που αναφέρθηκαν στην

68 πρακτική της διαρκούς ενσωµάτωσης. Οι εκδόσεις υφίστανται ελέγχους παλινδρόµησης (ώστε να µην υφίστανται περιπτώσεις λαθών κατά την προσθήκη νέων λειτουργιών) και ενσωµατώνονται διαρκώς. Σε κάποια έργα Ακραίου Προγραµµατισµού παρουσιάζονται περιπτώσεις όπου υφίστανται εκδόσεις ακόµα και σε καθηµερινή βάση. XPortofolio: Άρρηκτα δεµένη µε την συχνή ολοκλήρωση συστατικών του συστήµατος, η δηµιουργία µικρών εκδόσεων του XPortofolio υπήρξε διαρκής επιδίωξη της οµάδας ανάπτυξης. Άλλωστε ήδη αναφέρθηκε ότι εξ αρχής είχε συµφωνηθεί να δηµιουργηθεί πρώτα το γραφικό κοµµάτι της εφαρµογής και µετά να ασχοληθεί η οµάδα µε τις παρασκηνιακές υπολογιστικές διαδικασίες. Όταν ολοκληρώθηκε και η φάση δηµιουργίας των γραφικών διεπαφών, δηµιουργήθηκαν οι αλληλεπιδράσεις πλοήγησης µεταξύ τους και στο τέλος έγινε η προσθήκη των υπολογισµών, επεξεργασίας και αξιοποίησης µη-γραφικών δεδοµένων Σε κάθε βήµα της παραπάνω διαδικασίας αλλά και σε κάθε ενδιάµεση έκδοση που θεωρούσε η οµάδα ανάπτυξης, γινόταν σύσκεψη µε τον κο Π. Σφέτσο, ο οποίος σε αυτήν την περίπτωση κατείχε τον ρόλο τόσο του υπεύθυνου ανθρώπινων παραγόντων αλλά και εν µέρει του διαχειριστή (οι ρόλοι αναλύθηκαν περαιτέρω σε παραπάνω ενότητα), πέρα από την ιδιότητά του ως άµεσος επιβλέπων της εργασίας. ιαρκής Παρουσία Πελάτη (On-site Customer) Καµία απαίτηση σε γραπτή µορφή δεν είναι τέλεια ή απόλυτα σαφής. Οι χρειάζονται πάντα την επικοινωνία µε τον πελάτη για αποσαφήνιση διαφόρων σηµείων, ανεξάρτητα από την προσπάθεια για τελειότητα που µπορεί να έγινε κατά την αρχικό καθορισµό απαιτήσεων. Οι οµάδες Ακραίου Προγραµµατισµού απλοποιούν αρκετά την κατάσταση µε την αποφυγή ιδιαίτερου φόρτου εργασίας κατά την καταγραφή των απαιτήσεων και την παρουσία πελάτη καθ όλη την διάρκεια ανάπτυξης. εν υφίσταται ζήτηµα «πρόβλεψης» ή «υπόθεσης» για κάποιο χαρακτηριστικό, αφού ο πελάτης είναι πάντοτε διαθέσιµος για διευκρινίσεις. XPortofolio: Στους ρόλους ήδη περιγράφηκε ότι οι Κ. Πολυχρονιάδης και Σ. Σκαλιστής ανέλαβαν οι ίδιοι τον ρόλο του πελάτη, οπότε υπήρχε η ευτυχής συγκυρία να είναι διαρκώς παρόν το άτοµο στο οποίο απευθύνεται το προϊόν. Προφανώς οι διευκρινίσεις που απαιτούνταν προέκυπταν από την επικοινωνία των δύο µελών της οµάδας. Η αρχική

69 καταγραφή των απαιτήσεων είχε γίνει παρουσία του κου Π. Σφέτσου, ωστόσο λόγω της φύσεως της εργασίας, πελάτες θεωρήθηκαν οι προαναφερόµενοι. Ως πελάτης, είτε ο Κίµων είτε ο Στέφανος ανέλαβαν την πιλοτική χρήση του XPortofolio ώστε να µπορέσουν να αποκτήσουν µία εικόνα του πως έχει διαµορφωθεί το πρόγραµµα. Η χρήση του XPortofolio ως πελάτης από τα δύο µέλη της οµάδας γινόταν συνήθως σε µέρες διαφορετικές από αυτές της συνεδρίας προγραµµατισµού σε ζευγάρι, ώστε να µην συγχέεται η συγγραφή του κώδικα µε την εκτιµητική χρήση της εφαρµογής. Προφανώς (πέρα από τα σηµεία που θεωρούνταν ως σηµεία κλειδιά - milestones) γινόταν παρουσίαση του προγράµµατος και στον κο Π. Σφέτσο για πιο σφαιρική, εµπεριστατωµένη και ευρύτερα αποδεκτή άποψη περί της εφαρµογής. Το Παιχνίδι του Σχεδιασµού (The Planning Game) Ο Ακραίος Προγραµµατισµός µετατρέπει τις συνήθεις συνδιαλλαγές σχετικά µε την λειτουργικότητα που προκύπτουν σε ένα έργο λογισµικού σε «παιχνίδι». Το «παιχνίδι του σχεδιασµού» λαµβάνει χώρα σε κάθε κύκλο ανάπτυξης (δηλαδή κάθε λίγες εβδοµάδες) για τον καθορισµό της επόµενης λειτουργικότητας προς υλοποίηση στην ακόλουθη (µικρή, όπως ήδη αναφέρθηκε στην σχετική πρακτική) έκδοση. Οι προγραµµατιστές παίρνουν αποφάσεις στον τεχνικό τοµέα (estimates) και οι πελάτες λαµβάνουν επιχειρηµατικές αποφάσεις (επιλέγοντας το λειτουργικό χαρακτηριστικό το οποίο θα είναι και το πιο συµφέρον). Αξίζει να σηµειωθεί ότι όλες οι αποφάσεις λαµβάνονται µε πλήρη γνώση του ήδη υπάρχοντος λειτουργικού συστήµατος. XPortofolio: Το «παιχνίδι» του σχεδιασµού «παιζόταν» µε τα διάφορα «συµβούλια» τα οποία γίνονταν κατά την ανάπτυξη του XPortofolio και την γενικότερη επικοινωνία ζητήµατα τα οποία αναλύθηκαν στο κεφάλαιο 4. Σηµαντικότατο επίσης παράγοντα στον σχεδιασµό αποτελούσαν οι αναπαραστάσεις, όπως αυτές περιγράφτηκαν στο κεφάλαιο 7. Η βασική αφορµή τόσο χρονικά όσο και λογικά για την έναρξη του σχεδιαστικού «παιχνιδιού» ήταν η ολοκλήρωση των στόχων που είχαν επιτευχθεί σε προηγούµενες σχεδιαστικές συσκέψεις της οµάδας. Αυτές περιελάµβαναν την γενική θεώρηση της προόδου και των ολοκληρωµένων εργασιών µέχρι εκείνη την στιγµή, την αξιολόγησή τους και κατόπιν την συζήτηση για την συµφωνία των επόµενων στόχων της οµάδας ανάπτυξης

70 Υποφερτός Ρυθµός Εργασίας (40-hour Week) Η ανάπτυξη λογισµικού είναι µία εργασία που απαιτεί επινοητικότητα και δηµιουργικότητα και τέτοια γνωρίσµατα δεν µπορούν να παρουσιαστούν εφόσον υφίσταται κόπωση από πλευράς εργαζοµένων. Ο περιορισµός των εργάσιµων ωρών σε 40 την εβδοµάδα διατηρεί τα άτοµα σε ξεκούραστη κατάσταση, µειώνει τα λάθη και βελτιώνει την ποιότητα του προκύπτοντος προϊόντος. XPortofolio: Ο υποφερτός ρυθµός εργασίας σε µία επαγγελµατική ανάπτυξη λογισµικού, ορίζεται σε 40 ώρες την εβδοµάδα, δηλαδή 8 ώρες εργασίας για κάθε εργάσιµη µέρα. Προφανώς λόγω της φύσης του έργου και βάσει της µορφής και της σύνθεσης της οµάδας, ο υποφερτός ρυθµός εργασίας οριζόταν υποκειµενικά από τα µέλη της οµάδας. Αυτό σήµαινε ότι η οµάδα δούλευε µέχρι το σηµείο όπου εµφανίζονταν εµφανή σηµάδια κούρασης, κόπωσης και αδυναµίας συγκέντρωσης. Σε περιπτώσεις όπου παρατηρούταν καθυστέρηση της προόδου του έργου, η εργασία πάνω στο XPortofolio µπορούσε να διενεργείται ακόµα και το Σάββατο ή την Κυριακή, εφόσον αυτό θεωρούταν θεµιτό Ποτέ ωστόσο δεν αναπτυσσόταν κώδικας υπό συνθήκες κόπωσης ή άλλων αντίστοιχων παραγόντων που αποτελούσαν τροχοπέδη στην απόδοση του Στέφανου ή του Κίµων. εν είναι τυχαίο άλλωστε πως όταν αποφάσιζε η οµάδα να εργαστεί υπό τέτοιες συνθήκες, παρατηρούταν ιδιαίτερα χαµηλή αποδοτικότητα και αποτελεσµατικότητα, καθώς και ένα αίσθηµα «χασίµατος χρόνου», άµεση απόρροια των προηγουµένων. Σε αυτό το σηµείο αξίζει να αναφερθεί ότι η ανάπτυξη του έργου αναστελλόταν κατά την διάρκεια εξεταστικών περιόδων η σε χρονικά διαστήµατα όπου παρατηρούταν µεγάλος φόρτος από άλλες πανεπιστηµιακές αναθέσεις εργασιών οι οποίες απαιτούσαν άµεση διεκπεραίωση. Σε αυτό το σηµείο παρατηρούταν επίσης το πρόβληµα εγκλιµατισµού της οµάδας µετά από σχετικά µακρά περίοδο απραξίας (βλ. Κεφάλαιο 6). Αρχιτεκτονική Εικόνα (Metaphor) Η αρχιτεκτονική εικόνα του συστήµατος δίνει στην οµάδα µία συνέπεια στην χρησιµοποιούµενη ονοµατολογία κατά την παράθεση προβληµάτων και λύσεων (π.χ. «το σύστηµα αντιστοιχεί σε µία γραµµή παραγωγής» ή χρήση επιχειρηµατικών αντικειµένων για αναφορά το σύστηµα).

71 XPortofolio: Στο XPortofolio, η εικόνα του συστήµατος δινόταν από τις διάφορες αναπαραστάσεις που δηµιουργούταν κατά την διάρκεια του σχεδιαστικού «παιχνιδιού» και των ποικίλων επικοινωνιακών περιστάσεων κατά την ανάπτυξη του έργου. Σηµαντικό ρόλο στην διατήρηση συνέπειας και συνοχής στην εικόνα που είχαν τα µέλη της οµάδας για το σύστηµα έπαιξαν και οι µικρές εκδόσεις και οι διαρκείς ενσωµατώσεις. Η εφαρµογή αυτών των δύο πρακτικών έδινε την δυνατότητα στα µέλη της οµάδας του XPortofolio για διατήρηση της γενικής εποπτείας του έργου, πλήρη γνώση των συνδέσεων και σχέσεων των συστατικών µερών του και την µάλλον ασυνείδητη- δηµιουργία ενός µοντέλου της εφαρµογής στο µυαλό του κάθε προγραµµατιστή. Θα µπορούσε να ειπωθεί ότι παραγόταν µία «εγκεφαλική» αναπαράσταση του κώδικα και της εφαρµογής γενικότερα βάσει των µικρών βηµάτων ανάπτυξης και συχνών εκδόσεων περιορισµένου µεγέθους Εργαλεία Τεχνολογία Ανάπτυξης Μέρος της ιδεολογικής θεµελίωσης των Ευέλικτων Μεθόδων είναι η άποψη ότι τα εργαλεία και οι τεχνικές τίθενται σε δεύτερη µοίρα σε σχέση µε την ανθρώπινη πλευρά της ανάπτυξης έργου. Ωστόσο δεν παύουν να αποτελούν κοµµάτι της ανάπτυξης και απαραίτητο συστατικό της, αφού η δηµιουργία προϊόντων λογισµικού βασίζεται σε µεθοδολογίες και πρακτικές, αλλά η πραγµάτωσή τους συντελείται µε την χρησιµοποίηση εργαλείων ανάπτυξης και εκµετάλλευση τεχνολογιών και τεχνικών µέσων. Παρακάτω ακολουθεί µία παρουσίαση των εργαλείων, τεχνολογιών και µέσων που χρησιµοποιήθηκαν κατά την ανάπτυξη του XPortofolio. Επιλογή περιβάλλοντος ανάπτυξης Η αρχική επιλογή ενός Ολοκληρωµένου Περιβάλλοντος Ανάπτυξης (Integrated Development Environment, IDE), έγινε µε τα εξής κριτήρια: 1. Προηγούµενη γνώση του IDE 2. Ευκολία εκµάθησης και εγκλιµατισµού µε το IDE 3. Ευκολία και αποδοτικότητα χρήσης του IDE 4. Ελεύθερη πρόσκτηση του λογισµικού IDE

72 Βασικό κριτήριο για την επιλογή του IDE ήταν τυχόν προηγούµενη γνώση του από τα µέλη ανάπτυξης ή έστω από το ένα µέλος. Αυτό έδινε την δυνατότητα για αξιολόγηση του λογισµικού τόσο σε ό,τι αφορά την ευκολία εκµάθησης (κριτήριο 2) όσο και την αποδοτικότητα (κριτήριο 3). Η ευκολία εκµάθησης και εγκλιµατισµού ήταν εξαιρετικά σηµαντικά στοιχεία για την επιλογή του όποιου περιβάλλοντος ανάπτυξης. Όπως αποδείχτηκε και κατά τον Προγραµµατισµό σε Ζευγάρι, συνέβαλλαν στην ταχύτερη συγγραφή, παρακολούθηση και διόρθωση του κώδικα, κάτι το οποίο δεν είναι απλά χρήσιµο χαρακτηριστικό ενός περιβάλλοντος ανάπτυξης, αλλά κρίσιµο σηµείο διαφοροποίησης µεταξύ των δυνατών επιλογών. Ακόµα και αν γνώριζαν τα µέλη της οµάδας ανάπτυξης να χειρίζονται κάποιο συγκεκριµένο περιβάλλον ανάπτυξης, τίθεται το ερώτηµα του κατά πόσον είναι πρακτικό ή ακόµα και εύχρηστο το IDE. Μπορεί π.χ. κάποιος προγραµµατιστής να χρησιµοποιεί το IDE «Α» το οποίο είναι πολύ πιο δύσκολο στην χρήση από το IDE «Β», αλλά επειδή έχει συνηθίσει την χρήση του «Α» να συνεχίσει να το χρησιµοποιεί, ακόµα και αν αποδεδειγµένα είναι σαφώς πιο αποδεκτό πρακτικά και χρηστικά το IDE «Β». Τέλος, η δυνατότητα για δωρεάν (αλλά όχι και παράνοµη) διάθεση του επιλεγµένου περιβάλλοντος ανάπτυξης, έπαιξε πολύ σηµαντικό ρόλο, δεδοµένης της αδυναµίας διάθεσης χρηµατικών ποσών για απόκτηση των όποιων µέσων ανάπτυξης. Η οµάδα δεν δούλευε δηλαδή µε κάποιον προϋπολογισµό (budget). Αυτό ωστόσο ιδιαίτερα περιοριστικός παράγοντας, αφού υπάρχουν διάφορα και ποικίλων προδιαγραφών περιβάλλοντα ανάπτυξης, τα οποία είναι διαθέσιµα δωρεάν µέσω διαδικτύου. NetBeans vs. Eclipse Η αρχική επιλογή ήταν να γίνει η ανάπτυξη της εφαρµογής στο NetBeans (της Sun Microsystems, δηµιουργός εταιρεία της γλώσσας Java [12]). Οι λόγοι ήταν οι εξής: Ο Κίµων ήξερε ήδη το εν λόγω περιβάλλον ανάπτυξης, λόγω πρότερης χρήσης για δηµιουργία εφαρµογών. Ο Στέφανος ανέφερε ότι ήταν εύκολη η εκµάθησή του λόγω σχετικής οµοιότητας (ως ένα βαθµό) µε το Eclipse, το οποίο χρησιµοποιούσε ο ίδιος

73 Για δηµιουργία γραφικών διεπαφών το NetBeans θεωρούταν εξαιρετική επιλογή, πρακτικά διαπιστωµένη. Η χρήση του σχεδιαστή φορµών (form designer) έδινε την δυνατότητα για γρήγορη και εύκολη δηµιουργία GUI. Η διάθεσή του ήταν δωρεάν µέσω διαδικτύου [13] και είχε ένα αρκετά καλό υλικό τεκµηρίωσης (documentation). Επίσης διαπιστώθηκε, έστω και τυχαία, η ύπαρξη πολλών περιοχών συζητήσεων (forums) µε θέµατα σχετικά µε το NetBeans, πηγή πολύτιµων πληροφοριών και συµβουλών. Έτσι ξεκίνησε η δηµιουργία της εφαρµογής µε χρήση του περιβάλλοντος NetBeans και δη τον σχεδιαστή φορµών (Εικόνα 11), µετά από µία ολιγόωρη διαδικασία εκµάθησης και εγκλιµατισµού από τον Στέφανο. Εικόνα 11: Ο σχεδιαστής φορµών του NetBeans. Με κύκλο τονίζονται 1. Η κύρια οθόνη, 2. Τα στοιχεία γραφικής διεπαφής (components) και 3. Οι ιδιότητες του κάθε τοποθετηµένου γραφικού στοιχείου. Μετά από το πέρας των πρώτων συνεδριών Προγραµµατισµού σε Ζευγάρι, διαπιστώθηκε ωστόσο από τον Στέφανο ότι υστερούσε σηµαντικά σε ότι αφορά την σχεδίαση των γραφικών διεπαφών µε τον σχεδιαστή φορµών. Το IDE παρήγαγε κώδικα ο οποίος δεν ήταν επεξεργάσιµος (Εικόνα 12), ενώ παρουσίαζε ιδιαίτερα µεγάλη πολυπλοκότητα, χωρίς να προσφέρει κάτι το σηµαντικά ωφέλιµο στην οµάδα ανάπτυξης και στο έργο γενικότερα

74 Εικόνα 12: Ο παραγόµενος κώδικας του NetBeans στο GUI του σχήµατος Με κύκλο τονίζεται ο µη-επεξεργάσιµος κώδικας Συνέπεια των παραπάνω ήταν να συνεχιστεί η συγγραφή του κώδικα απόλυτα χειροκίνητα («by hand»). Αυτό µπορεί να ξενίζει αρχικά, ακόµα και του ίδιους τους προγραµµατιστές του XPortofolio. Ωστόσο πρέπει να τονιστεί ότι το XPortofolio είναι προϊόν της ευρύτερης ερευνητικής εργασίας και ουχί αυτοσκοπός. Συνεπώς, η ανάπτυξη του έργου «χειροκίνητα» δεν φάνηκε στα µάτια της οµάδας ανάπτυξης ως αγγαρεία (τουλάχιστον στον βαθµό που µπορούσε να θεωρηθεί υπό άλλες συνθήκες!), αλλά ως µία πρώτης τάξεως ευκαιρία για την εµβριθή εφαρµογή των πρακτικών και αξιών των Ευέλικτων Μεθόδων. Η «χειροκίνητη» κωδικοποίηση των γραφικών της εφαρµογής έδινε περισσότερες ευκαιρίες για διορθώσεις, παρατηρήσεις και γενικότερη επικοινωνία, άρα υπήρχε µεγαλύτερο σύνολο καταγεγραµµένων στοιχείων και παρατηρήσεων. Από κάποιο σηµείο της ανάπτυξης και µετά ωστόσο διαπιστώθηκε ότι, πέρα από το ερευνητικά οφέλη του χειροκίνητου προγραµµατισµού, υπήρχε µεγάλη καθυστέρηση στην ανάπτυξη του προγράµµατος. Αυτή η άποψη είχε ιδιαίτερη βαρύτητα από την στιγµή που ο Στέφανος είχε διαπιστώσει ότι ο σχεδιαστής φορµών του Eclipse ήταν σαφώς καλύτερο και πιο εύχρηστο από τον αντίστοιχο του NetBeans. Συνεπώς οι σκέψεις για αλλαγή IDE εξελίχθηκαν σε συζήτηση και τελικά η οµάδα ανάπτυξης κατέληξε στην µεταπήδηση από το NetBeans στο Eclipse. Αξίζει να σηµειωθεί ότι στο µεταίχµιο της αλλαγής από το ένα IDE στο άλλο, η οµάδα του XPortofolio δεν δίστασε να «πετάξει» την οθόνη NewProjectScreen.java ώστε να δηµιουργηθεί εκ νέου και βελτιωµένη µε χρήση του Eclipse. Το Eclipse διέθετε στοιχεία τα οποία ικανοποιούσαν τα κριτήρια επιλογής του εκάστοτε περιβάλλοντος ανάπτυξης. Πιο συγκεκριµένα:

75 Ο Στέφανος ήξερε εξαιρετικά καλά το Eclipse λόγω πρότερης χρήσης για δηµιουργία ποικίλων εφαρµογών. Η εκµάθησή του από τον Κίµων ήταν αρκετά εύκολη, λόγω σχετικής οµοιότητας µε το περιβάλλον NetBeans, κάτι που αναφέρθηκε και παραπάνω. Ο σχεδιαστής φορµών του Eclipse ήταν, όπως αποδείχτηκε και στην πορεία ανάπτυξης του έργου, σαφώς ανώτερος από τον αντίστοιχο του NetBeans, αφού δεν προέκυπταν τα προβλήµατα που αναφέρθηκαν παραπάνω και συσχετίζονταν µε την χρήση του σχεδιαστή φορµών του NetBeans. Το λογισµικό του Eclipse ήταν δωρεάν και µάλιστα το κατείχε ήδη ο Στέφανος σε CD, οπότε η εγκατάστασή του στο µηχάνηµα όπου γινόταν η ανάπτυξη θα ήταν σύντοµη και άµεση. Μετά την µεταπήδηση από το ένα περιβάλλον ανάπτυξης στο άλλο, παρατηρήθηκε σαφής αύξηση της ταχύτητας ανάπτυξης. Επίσης, έγιναν πιο σύντοµοι οι έλεγχοι και οι όποιες δοκιµές, καθώς όπως αναφέρθηκε σε παραπάνω ενότητα, η κύρια τακτική ήταν «δοκιµή και επιτυχία». Στο µετέπειτα υπολογιστικό κοµµάτι προφανώς δεν διαπιστώθηκε κάτι το ιδιαίτερο, αφού η ανάπτυξή του έλαβε χώρα µόνο στο Eclipse. Στην Εικόνα 13 φαίνεται το περιβάλλον ανάπτυξης Eclipse και η σαφείς οµοιότητες του σχεδιαστή φορµών µε το IDE NetBeans. Εικόνα 13: Το περιβάλλον Eclipse µε τον αντίστοιχο σχεδιαστή φορµών. ιακρίνονται µε κύκλο 1. το κεντρικό παράθυρο του σχεδιαστή φορµών, 2. τα διαθέσιµα γραφικά στοιχεία προς εισαγωγή, 3. ο παραγόµενος κώδικας, 4. οι ιδιότητες του κάθε επιλεγµένου γραφικού στοιχείου

76 Οι φόρµες προγραµµατιστών Κατά την ανάπτυξη του XPortofolio, χρησιµοποιήθηκαν κάποιες φόρµες, οι οποίες συµπληρώνονταν κατά την διάρκεια των συνεδριών ακραίου προγραµµατισµού. Η χρησιµότητά τους έγκειται τόσο στην καταγραφή των βασικών ενεργειών του ζευγαριού προγραµµατισµού, όσο και στις σηµαντικότερες αλληλεπιδράσεις µεταξύ των δύο συνεργατών. Επίσης σηµειώνονταν περαιτέρω πληροφορίες πέραν του προγραµµατιστικού κοµµατιού, οι οποίες συσχετίζονταν µε άλλες ενέργειες κατά την διάρκεια της συνεργασίας την εκάστοτε ηµέρα. Μορφή και τρόπος συµπλήρωσης Κάθε φόρµα προγραµµατιστή συµπληρωνόταν σε κάθε συνεδρία Προγραµµατισµού σε Ζευγάρι. Αυτό σηµαίνει ότι κάθε συνεδρία καταγραφόταν σε µία φόρµα, µε αποτέλεσµα να υπάρχει µετά το πέρας της ανάπτυξης του έργου ένα αρχείο ενεργειών και αλληλεπιδράσεων σχετικά µε την διαδικασία ανάπτυξης. Μία φόρµα που συµπλήρωνε η οµάδα ανάπτυξης φαίνεται στην Εικόνα 14. Εικόνα 14: Η φόρµα προγραµµατιστή Κάθε γραµµή της φόρµας αποτελεί καταγραφή πληροφορίας για κάποια ενέργεια που έγινε από τον έναν ή τον άλλον προγραµµατιστή στο ζευγάρι. Παρακάτω ακολουθεί µία σύντοµη περιγραφή του τρόπου συµπλήρωσης των πεδίων Στις στήλες 2-7 σηµειώνεται απλά µε για να προσδιοριστεί το είδος της ενέργειας: 1. Αριθµός Devel: Σηµειώνεται το αρχικό γράµµα ή ο αριθµός που αντιστοιχεί στον προγραµµατιστή (Developer) που κάνει την όποια ενέργεια. 2. Εύρεση Στοιχείου: Σε αυτή την περίπτωση θεωρείται ότι ο προγραµµατιστής έχει βρει κάποιο στοιχείο στην υπό ανάπτυξη κλάση το οποίο εν συνεχεία προστίθεται

77 3. Εύρεση Λάθους: Κάποιος προγραµµατιστής εντοπίζει κάποιο λάθος στον κώδικα. 4. Προσθήκη στοιχείου: Ο προγραµµατιστής προσθέτει κάποιο στοιχείο στην υπό επεξεργασία κλάση. Συνήθως αυτή η ενέργεια ακολουθούσε την ενέργεια Αφαίρεση Στοιχείου: Σηµειωνόταν στην περίπτωση που κάποιος από τους δύο προγραµµατιστές διέγραφε κάποιο στοιχείο της κλάσης. 6. Αλλαγή Στοιχείου: Σηµειωνόταν σε περίπτωση που γινόταν αλλαγή στοιχείου της κλάσης από κάποιον προγραµµατιστή. 7. Έλεγχος JUnit: Ουσιαστικά δεν χρησιµοποιήθηκε καθόλου από την οµάδα ανάπτυξης, εξαιτίας των λόγων που αναφέρθηκαν σε παραπάνω ενότητα σχετικά µε τους ελέγχους. 8. Άλλο Περιγραφή: Σηµειώνονταν µερικές επιπλέον πληροφορίες σχετικά µε την εκάστοτε δράση, για µεγαλύτερη σαφήνεια. 9. Ώρα Έναρξης pp: Η ώρα εκκίνησης της συνεδρίας προγραµµατισµού σε ζευγάρι. 10. Ώρα Λήξης pp: Η ώρα λήξης της συνεδρίας προγραµµατισµού σε ζευγάρι. Αξίζει επίσης να σηµειωθεί ότι στην κορυφή της φόρµας σηµειωνόταν συνήθως η κλάση µε την οποία ασχολούταν το ζευγάρι προγραµµατισµού την συγκεκριµένη συνεδρία. Επίσης, στο τέλος της φόρµας, µετά τον πίνακα, σηµειώνονταν επιπλέον πληροφορίες σχετικά µε την συνεδρία, όπως η πολύ σηµαντική TODO List, η οποία αναφέρθηκε σε προηγούµενο κεφάλαιο. Άλλα παραδείγµατα επιπλέον πληροφοριών αποτελούν οι σηµειώσεις για διαφωνίες ή προβληµατισµούς σχετικά µε κάποιο πρόβληµα που έχριζε επίλυσης ή κάποιου ζητήµατος που ωφελούσε συζητήσεις και άλλες επικοινωνιακές διαδικασίες. Για την καλύτερη κατανόηση των παραπάνω στην Εικόνα 15 παρατίθεται µία συµπληρωµένη φόρµα

78 9.7 Συµπεράσµατα Εικόνα 15: Συµπληρωµένη φόρµα προγραµµατιστών Ακολουθεί µία σειρά από αποτελέσµατα και συµπεράσµατα τα οποία προέκυψαν από την µελέτη και την έρευνα κατά την ανάπτυξη του XPortofolio. Να σηµειωθεί ότι τα ακόλουθα στοιχεία που παραθέτονται δεν βασίζονται µόνο στην µνήµη και τις εµπειρίες των µελών της οµάδας ανάπτυξης, αλλά και στην µελέτη και γενική θεώρηση των φορµών που συµπληρώθηκαν Ο Ανθρώπινος Παράγοντας Καταλυτικός παράγοντας επιρροής για την κατάληξη αλλά και την γενικότερη διεκπεραίωση του XPortofolio αποδείχτηκε η ανθρώπινη πλευρά του έργου. Ο ανθρώπινος παράγοντας ήταν αυτός που µε τις ποικίλες εκφάνσεις του διαµόρφωσε το τελικό αποτέλεσµα σε κάθε µία υπο-διεργασία της συνολικής διαδικασίας ανάπτυξης. Ουδείς µπορεί να αµφισβητήσει ότι οι πρακτικές, τα µοντέλα ανάπτυξης και οι θεµελιώδεις µεθοδολογίες είναι η βάση για την ανάπτυξη λογισµικού. Με χρήση των Ευέλικτων Μεθόδων όµως αποδείχτηκε ότι η ενίσχυση που προσφέρει η υιοθέτηση

79 του ανθρώπου ως παράγοντα ωφέλιµης διακύµανσης και ποικιλίας δράσεων είναι κάτι παραπάνω από ευπρόσδεκτη. Ο Ανθρώπινος παράγοντας στις 12 πρακτικές του Ακραίου Προγραµµατισµού Οι ανθρώπινες ιδιοσυγκρασίες και προσωπικότητες των προγραµµατιστών προσέφεραν ατράνταχτα στοιχεία σε ότι αφορά την επιρροή τους στην εφαρµογή των πρακτικών του Ακραίου Προγραµµατισµού. Αξίζει να σηµειωθεί ότι, όπως ήδη ειπώθηκε, ότι οι πρακτικές είναι αλληλένδετες και αλληλεπικαλυπτόµενες. Εποµένως και οι εκφάνσεις της ανθρώπινης φύσης σε σχέση µε τις εν λόγω πρακτικές είναι λογικό να συνδέονται µεταξύ τους και να συσχετίζονται µε ποικίλους τρόπους Προδιαγραφές κώδικα και Αρχιτεκτονική εικόνα Στην σύσταση των προδιαγραφών για τον υπό συγγραφή κώδικα, η προσωπική άποψη και πρότερη εµπειρία δηµιουργούσαν και τις απόψεις του κάθε προγραµµατιστή. Σε ότι αφορά πάντως την εξοικονόµηση χρόνου σε ότι αφορά αυτόν τον τοµέα, η οµάδα ανάπτυξης ήταν τυχερή να αποτελείται από δύο µέλη τα οποία είχαν πρότερη συνεργασία και οι απόψεις τους πάνω σε αυτό το θέµα συνέκλιναν στο ίδιο περίπου σηµείο. Η τελική διαπίστωση είναι ότι παρά την γενική συµφωνία το µεγαλύτερο πλεονέκτηµα ήταν ότι όποιος και αν αναλάµβανε την συγγραφή του κώδικα είχε άµεσα µία πλήρη εικόνα και δυνατότητα πλήρους εγκλιµατισµού στο ήδη υπάρχον προϊόν πρότερης εργασίας της οµάδας. Η ονοµατολογία των στοιχείων του κώδικα βασιζόταν λοιπόν στις προδιαγραφές που είχαν οριστεί και συνδεόταν άµεσα µε την αρχιτεκτονική εικόνα του συστήµατος που κατείχαν οι προγραµµατιστές. Αυτό συνέβαινε διότι συνέδραµε η εικόνα του συστήµατος στην σύνθεση περιβάλλοντος εγκλιµατισµού µε το προηγούµενο και ήδη υπάρχον κώδικα. Έτσι, οι προσωπικές ιδιοσυγκρασίες και κουλτούρα κωδικοποίησης του κάθε προγραµµατιστή διαµόρφωναν τις προδιαγραφές κώδικα οι οποίες µε την σειρά του χρησίµευαν για την σύνθεση αρχιτεκτονικής εικόνας του έργου, ιδιαίτερα στις εσωτερικές αναπαραστάσεις στο µυαλό κάθε µέλους της οµάδας ανάπτυξης Αναθεώρηση κώδικα Οι προδιαγραφές κώδικα ακολούθως χρησίµευαν κατά την αναθεώρηση του κώδικα. Έτσι, έστω και έµµεσα, παρατηρούταν επιρροή των προσωπικών απόψεων στην αναθεώρηση του κώδικα. Ωστόσο δεν διαπιστώθηκε ιδιαίτερα ευρεία διενέργεια

80 αναθεωρήσεων, πέραν ορισµένων συνεδριών προγραµµατισµού σε ζευγάρι οι οποίες ήταν ειδικά αφιερωµένες για αυτόν τον σκοπό. Στις ελάχιστες πάντως αυτές περιπτώσεις η αναµόρφωση του κώδικα έδωσε την οµοιοµορφία, σαφήνεια και καθαρότητα που απαιτείται για ένα ευανάγνωστο και απόλυτα κατανοητό πρόγραµµα Απλή σχεδίαση Η απλή σχεδίαση του κώδικα ήταν επίσης µία πρακτική η οποία δεν ακολουθήθηκε κατά γράµµα ή µηχανικά από την οµάδα του XPortofolio. Η ανάγκη για βραχυπρόθεσµους σχεδιασµούς και η αποφυγή µακρόπνοων πλάνων και προβλέψεων απέρρεε από την ασυνείδητα εφαρµοζόµενη τακτική της οµάδας και συσχετιζόταν άµεσα µε τις προσωπικότητες και τις ιδιοσυγκρασίες των προγραµµατιστών. Αποτέλεσµα του απλού σχεδιασµού ήταν η εξαιρετικά ευέλικτη ανάπτυξη του XPortofolio. Η µη-σχεδίαση µεγάλου εύρους χαρακτηριστικών της εφαρµογής εξάλειψε κάθε ίχνος εξαρτήσεων και αλληλεπιδράσεων του υπο ανάπτυξη συστήµατος µε τα µελλοντικά συστατικά του ή τις συνθήκες και το περιβάλλον ανάπτυξης. Ουσιαστικά δηλαδή η απλή σχεδίαση αποτελούσε και δικλείδα ασφαλείας για την ικανοποιητική αντιµετώπιση των διακυµάνσεων και ποικίλων απροόπτων που προέκυπταν κατά την ανάπτυξη του έργου Έλεγχοι Η εξαιρετική σηµασία των ελέγχων στην ανάπτυξη ενός έργου λογισµικού περιγράφηκε σε προηγούµενες ενότητες. Ωστόσο η µέθοδος και η τακτική που ακολουθήθηκε στην εκτέλεση των ελέγχων ήταν άρρηκτα συνδεδεµένες µε τον τρόπο σκέψης των προγραµµατιστών. Ο τύπος για παράδειγµα που φαίνεται στην Εικόνα 8 έχει προκύψει µετά από συζήτηση και παράθεση των προσωπικών προβλέψεων και σκέψεων των συνεργατών του ζευγαριού ανάπτυξης. Η φύση ωστόσο του έργου έκανε την ανθρώπινη πλευρά της ανάπτυξης ακόµα πιο έντονη στις εκφάνσεις της, ιδιαίτερα κατά την αποτίµηση και αξιολόγηση των αποτελεσµάτων των ελέγχων. Αυτό σηµαίνει ότι η οµάδα ανάπτυξης δηµιουργούσε µία εφαρµογή η οποία, όπως αναφέρθηκε στο Κεφάλαιο 2, ήταν προϊόν εφαρµογής των αρχών του Ακραίου Προγραµµατισµού για την µελέτη του Ακραίου Προγραµµατισµού. Συνεπώς, θα µπορούσε να ειπωθεί ότι η οµάδα ανάπτυξης του

81 XPortofolio δηµιουργούσε ένα προϊόν λογισµικού το οποίο δυνητικά (και υποθετικά) θα µπορούσε να χρησιµοποιηθεί και από τους ίδιους. Άµεση απόρροια αυτού του γεγονότος ήταν η προσωπική γνώµη και εµπειρία του κάθε προγραµµατιστή να είναι σηµαντικότατοι παράγοντες κατά την διενέργεια των ελέγχων, ιδιαίτερα αυτών που αφορούσαν την λειτουργικότητα του XPortofolio. Ο προγραµµατιστής έµπαινε άµεσα στην θέση του πελάτη και του προοριζόµενου χρήστη (άλλωστε περιγράφηκε και στην ανάλυση των ρόλων σε παραπάνω ενότητα) και είχε την δυνατότητα για βέλτιστη αξιολόγηση των εν λόγω ελέγχων. Σε τελική ανάλυση λοιπόν οι συνθήκες και η τελική διαµόρφωση της διεκπεραίωσης των ρόλων του έργου από τα µέλη της οµάδας του XPortofolio αποδείχθηκαν εξαιρετικά ωφέλιµοι παράγοντες ιδίως στον τοµέα των ελέγχων Προγραµµατισµός σε ζευγάρι Ο προγραµµατισµός σε ζευγάρι ήταν ο συνδετικός κρίκος όλων των πρακτικών, από την άποψη ότι οι προγραµµατιστές χρησιµοποιούσαν τις πρακτικές του Ακραίου Προγραµµατισµού µε επίκεντρο και πεδίο εφαρµογής τον προγραµµατισµό σε ζευγάρι. Οι ανθρώπινες ιδιοσυγκρασίες και προσωπικότητες του κάθε προγραµµατιστή δεν ήταν απλοί παράγοντες επιρροής της εν λόγω πρακτικής, αλλά θα µπορούσε να πει κανείς ότι συνιστούσαν την πρακτική αυτή. Αυτό οφείλεται στο γεγονός ότι η συνεργασία και η επικοινωνία (βασικά στοιχεία για να µπορεί κάποιος να ισχυρίζεται ότι εφήρµοσε επιτυχώς την εν λόγω πρακτική) είναι άρρηκτα συνδεδεµένες µε την ανθρώπινη πλευρά των µελών της οµάδας. Ο προγραµµατισµός σε ζευγάρι δεν είναι, όπως αποδείχτηκε στην πορεία του έργου, αποδοτικός σε περιπτώσεις εξωγενών παραγόντων, όπως άσχηµη ψυχολογική κατάσταση των συνεργατών. Ο προγραµµατιστής δεν γίνεται να προγραµµατίσει σωστά έχοντας τις όποιες έννοιες και ο παρατηρητής δεν µπορεί να παρακολουθεί αποτελεσµατικά τον υπό συγγραφή κώδικα µην έχοντας την απαιτούµενη συγκέντρωση. Άλλωστε ακόµα και σε ατοµικό προγραµµατισµό ο συγγραφέας του κώδικα αδυνατεί να αποδώσει ικανοποιητικά. Έτσι η γενική τακτική στον προγραµµατισµό σε ζευγάρι της οµάδας ήταν να γράφει κώδικα όποιος αισθανόταν καλύτερα και είχε την µεγαλύτερη διάθεση. Επίσης, όταν υπάρχει ατοµικό πρόβληµα του ενός εκ των δύο συνεργατών είναι απόλυτα λογικό να επηρεάζονται και οι δύο, ενώ έχει σηµαντικές επιπτώσεις στην

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

83 δυνητικό ανασχεδιασµό και µετατροπή του κώδικα του XPortofolio. Είναι και σε αυτό το σηµείο φανερή η ευελιξία και η δυνατότητα αλλαγής πλάνων και στόχων, βάσει των προκυπτόντων συνθηκών και γεγονότων. Αυτονόητο επίσης είναι ότι διαρκής ενσωµάτωση συστατικών στοιχείων στο συνολικό σύστηµα δεν γινόταν να επιτευχθεί χωρίς την ύπαρξη ενός, µικρού έστω, ποσοστού υποµονής από πλευράς των προγραµµατιστών, σε περιπτώσεις που εµφανίζονταν προβλήµατα στην όλη διαδικασία. Η αναµονή ήταν πολύ µεγάλη περιµένοντας να εµφανιστεί το τελικό αποτέλεσµα της εκάστοτε ενσωµάτωσης. Σε όλα τα στάδια της ανάπτυξης είναι απαραίτητη η υποµονή και η ψυχραιµία. Παρατηρήθηκε ωστόσο ότι τα πιο συνήθη περιστατικά αγανάκτησης είχαν να κάνουν µε ατυχείς ενσωµατώσεις και αποτελέσµατα των αντίστοιχων ελέγχων. Η υποµονή δεν είναι µόνο αρετή για την ανάπτυξη του κώδικα, αλλά και για την επιτυχηµένη αποσφαλµάτωση και µετατροπή του ιαρκής παρουσία πελάτη Η διαρκής παρουσία του πελάτη ήταν αυτονόητη από την στιγµή που οι προγραµµατιστές ήταν και δυνητικοί χρήστες του XPortofolio. Η µορφή αυτή της διαρκούς παρουσίας πελάτη ωστόσο µπορούσε να αποδειχθεί αµφίβολης ωφέλειας, αφού ήταν εξαιρετικά πιθανό να υπάρχει η απαραίτητη πελατειακή πιστοποίηση µεν, αλλά µε σαφή έλλειψη αντικειµενικότητας και γενικότερης αποδοχής. Αιτία αυτού ήταν προφανώς το γεγονός ότι µεταξύ χρηστών και δηµιουργών υπήρχε ταυτοπροσωπία. Η συγκεκριµένη εφαρµογή της εν λόγω πρακτικής ωστόσο δεν είναι απαραίτητο να συνιστά κίνδυνο για την αντικειµενικότητα των ενεργειών και απόψεων του πελάτη, αρκεί η οµάδα ανάπτυξης να είναι αρκετά µεγάλη και µε ικανοποιητική λήψη εξωτερικών απόψεων και συµβουλών οι οποίες ενισχύουν την ευρύτερη δυνατή αποδοχή του εκάστοτε προϊόντος λογισµικού. Στην περίπτωση του XPortofolio η απόψεις που λήφθηκαν υπ όψιν ήταν αυτές των Σ. Σκαλιστή και Κ. Πολυχρονιάδη, που ήταν και οι προγραµµατιστές του έργου. Ωστόσο η µεγάλη και κυριότερη ενίσχυση αξιοπιστίας και αποδοχής του συστήµατος προήλθε από τον Π. Σφέτσο, ο οποίος λόγω εµπειρίας, γνώσεων και εξοικείωσης µε τα ζητήµατα και το πεδίο που συνδέεται µε το XPortofolio είχε την δυνατότητα για καλύτερη και πιο στέρεες απόψεις και συµβουλές επί του θέµατος. Ωστόσο δεν ήταν δυνατή η διαρκής παρουσία του στον χώρο ανάπτυξης, εξαιτίας των

84 περιορισµών που προκύπτουν από την περιγραφή της σύστασης της οµάδας στην ενότητα 3 της παρούσας µελέτης Το «παιχνίδι» του σχεδιασµού Η επιλογή του τι θα δηµιουργηθεί σε κάθε µία από τις εκδόσεις του XPortofolio γινόταν βάσει των συσκέψεων της οµάδας ανάπτυξης. Σε αυτές τις συσκέψεις εµφανίζονταν σαφείς προσωπικές απόψεις και τρόποι σκέψης, ενώ θα µπορούσε να ειπωθεί ότι υπήρχε µία εξαιρετικά καλή διάθεση µεταξύ των µελών της οµάδας, µε αποτέλεσµα οι συσκέψεις να είναι πιο σύντοµες και αποδοτικές. Πρέπει να τονιστεί όµως ότι η διαλλακτικότητα και η καλή διάθεση επικοινωνίας των µελών δεν συνιστούσαν απώλεια προσωπικής άποψης και ουδέποτε θεωρείται ωφέλιµο να συµβαίνει κάτι τέτοιο. Το ένα µέλος υπολόγιζε για παράδειγµα πόσο χρόνο θα απαιτούσε η δηµιουργία της ViewMoreScreen.java και της NewProjectScreen.java και ακολούθως επέλεγε µία από τις δύο οθόνες προς δηµιουργία, ώστε να εξοικονοµηθεί χρόνος σε εκείνη την χρονική στιγµή. Ο συνεργάτης του ωστόσο µπορεί να θεωρούσε ως βασικό παράγοντα επιλογής την πολυπλοκότητα του απαιτούµενου κώδικα, οπότε κατά την άποψή του θα έπρεπε να δηµιουργηθεί η ViewMoreScreen. Στην σύσκεψη που θα ακολουθούσε δεν επέβαλλε κανείς την γνώµη του. Γινόταν παράθεση απόψεων, ανταλλαγή τους και διαµόρφωση µιας κοινής τελικής άποψης, η οποία µπορούσε να είναι υβριδική µορφή των απόψεων των δύο µελών της οµάδας. Το αποτέλεσµα ήταν ταχύτερο, βέλτιστο και πλέον αποδοτικό, αφού δεν είχε χαθεί χρόνος σε ατυχείς προσπάθειες επιβολής και ακλόνητες απόψεις αντί ουσιαστικής επικοινωνίας και συνεργασίας. Προφανώς σε µεγαλύτερες οµάδες ανάπτυξης, ο απαιτούµενος χρόνος για επιλογές και λήψεις αποφάσεων κατά τον σχεδιασµό (και όχι µόνο) είναι µεγαλύτερος και ελλοχεύουν περισσότερες διακυµάνσεις και καθυστερήσεις Υποφερτός ρυθµός εργασίας Η επιλογή του χρόνου εργασίας από τα µέλη της οµάδας του XPortofolio εξαρτιόταν όχι µόνο από εξωτερικούς παράγοντες αλλά και από την προσωπική κρίση και διάθεση των µελών

85 Στους εξωτερικούς παράγοντες περιλαµβάνονται άλλες υποχρεώσεις (π.χ. εξετάσεις) και προκύπτοντα ζητήµατα (π.χ. ασθένεια, ξαφνική υποχρέωση), κάτι που είναι απόλυτα λογικό και αναµενόµενο, από την στιγµή που το λογισµικό αναπτύσσεται από ανθρώπους. Πιο περίπλοκοι ήταν οι λόγοι που βασίζονταν στην προσωπικότητα του κάθε προγραµµατιστή, την διάθεσή του και την κατάστασή του σε ότι αφορά την κούραση. Ήδη αναφέρθηκε ότι δεν υπήρχε η δυνατότητα για οκτάωρη εργασία όπως σε επαγγελµατικές περιπτώσεις ανάπτυξης λογισµικού, ούτε η σύσταση αυστηρού ωραρίου. Ουσιαστικά λοιπόν, το ωράριο διαµορφωνόταν σύµφωνα µε την συζήτηση που ακολουθούσε κάθε συνεδρία προγραµµατισµού σε ζευγάρι. Από το σηµείο αυτό και µετά έµπαιναν στο παιχνίδι της διαµόρφωσης του ωραρίου εργασίας οι παράγοντες διάθεση, κούραση κτλ. Λόγω αυτών των παραγόντων µπορούσε η συνεδρία να συρρικνωθεί, να µετατραπεί το περιεχόµενό της ή ακόµα και να ακυρωθεί. Αυτό είναι και ένα τρανταχτό παράδειγµα διακυµάνσεων λόγω ανθρώπινων παραγόντων και γεγονότων αποκλίσεων από τον αρχικό χρονοπρογραµµατισµό οι οποίες δεν ήταν δυνατό να προβλεφθούν. Το επίθετο «υποφερτός» για τον ρυθµό εργασίας, δεν αφορούσε λοιπόν µόνο την σωµατική κούραση, αλλά και την ψυχική κόπωση η οποία δεν προκαλούταν αποκλειστικά από την προγραµµατιστική εργασία, αλλά είχε και πάλι επιπτώσεις στην απόδοση του προγραµµατιστή και την ποιότητα του παραγόµενου προϊόντος κάθε συνεδρίας Χρησιµότητα των φορµών Οι φόρµες προγραµµατιστών τις οποίες συµπλήρωναν τα µέλη της οµάδας κατά τον προγραµµατισµό σε ζευγάρια δεν χρησίµευσαν µόνο στην καταγραφή συµβάντων και συµπερασµάτων τα οποία κατόπιν αξιοποιήθηκαν µονάχα ερευνητικά. Εξαιρετικά µεγάλη χρησιµότητα παρουσίασαν τόσο η «TODO List», η οποία σηµειωνόταν στην φόρµα αλλά και τα σηµεία προβληµατισµού και µεγάλης κατανάλωσης χρόνου, τα οποία υποδείκνυαν αδιέξοδα στην πορεία της ανάπτυξης. Η λίστα εκκρεµοτήτων («TODO List») Η εν λόγω λίστα αναφέρθηκε και περιγράφηκε ήδη σε παραπάνω ενότητες. Υπήρξε εξαιρετικά χρήσιµο µέσο για την οµάδα ώστε να θυµάται τι πρέπει να γίνει και να µπορεί έτσι να γίνεται ένας χρονοπρογραµµατισµός και καθορισµός προτεραιοτήτων

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

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

88

89 10 Βιβλιογραφία Πηγές 1. Alistair Cockburn, Laurie Williams, The Costs and Benefits of Pair Programming, Pekka Abrahamsson, Outi Salo, Jussi Ronkainen, Juhani Warsta, Agile Software Development Methods Review and Analysis, VTT, Thomas Dudziak, Extreme Programming An Overview, Chromatic, Extreme Programming Pocket Guide, O'Reilly Media, Jim Highsmith, Agile Software Development Ecosystems, Addison-Wesley, Shari Lawrence Pfleeger, Software Engineering: Theory and Practice, Pearson Education Inc., Β. Γερογιάννης, Γ Κακαρόντζας, Α. Καµέας, Γ. Σταµέλος, Π. Φιτσίλης, «Αντικειµενοστρεφής Ανάπτυξη Λογισµικού µε την UML», Κλειδάριθµος, Steve Hayes, An Introduction to Extreme Programming, on_to_extreme_programming/0, , ,00.htm, Robert Gittins, Sian Hope, A study of Human Solutions in Extreme Programming, Ι. Σταµέλος, Π. Σφέτσος, «Ευέλικτες Μέθοδοι και Ακραίος Προγραµµατισµός»,

90

91 Παράρτηµα Α XPortofolio Εγχειρίδιο Χρήσης Η εφαρµογή XPortofolio απευθύνεται σε οµάδες ανάπτυξης προϊόντων λογισµικού, οι οποίες εφαρµόζουν Ευέλικτες Μεθόδους ανάπτυξης εφαρµογών και πιο συγκεκριµένα τις αρχές του Ακραίου Προγραµµατισµού. Σκοπός του XPortofolio είναι να βοηθήσει την οµάδα ανάπτυξης στην διατήρηση ενός αρχείου µε τα έργα υπό κατασκευή, καθώς και την καταγραφή των απαραίτητων πληροφοριών σχετικά µε αυτά. Στα προηγούµενα κεφάλαια έγιναν κάποιες µικρές αναφορές στην εφαρµογή, ωστόσο για την καλύτερη κατανόηση και αντίληψή της θεωρήθηκε επιθυµητό ένα εγχειρίδιο χρήσης. Η εφαρµογή γενικά είναι σχετικά απλή και διόλου πολύπλοκη, αυτό όµως δεν αποτελεί εχέγγυο για την άνετη περιήγηση και χρήση της από κάθε ενδιαφερόµενο. Έτσι, το παρόν εγχειρίδιο δύναται να παρουσιάσει εξαιρετική χρησιµότητα σε κάθε χρήστη. Γενικά για τις λειτουργίες του XPortofolio Ως χρήστης του XPortofolio θεωρείται ο διαχειριστής της οµάδας ανάπτυξης, ο οποίος είναι ο κεντρικός αποδέκτης όλων των πληροφοριών που διακινούνται ανάµεσα στα µέλη της οµάδας. Ο πληροφορίες που λαµβάνει ο διαχειριστής από τους συνεργάτες του αλλά και τα παραγόµενα από αυτόν δεδοµένα εισάγονται στο σύστηµα, το οποίο δίνει την δυνατότητα για αποθήκευση, επεξεργασία και επισκόπηση των εξής πληροφοριών:

92 Ονοµασία έργου Ηµεροµηνίες εκκίνησης και εκτιµώµενης ολοκλήρωσης ανάπτυξης έργου. Ποσοστό ολοκλήρωσης έργου. Απασχολούµενο προσωπικό στο έργο. Λεπτοµέρειες απασχολούµενου προσωπικού στο έργο. Αναφορές από διάφορα µέλη της οµάδας του έργου. Οι ενέργειες που µπορεί να κάνει ο διαχειριστής µε χρήση του XPortofolio είναι οι παρακάτω: ηµιουργία νέου έργου και εισαγωγή των στοιχείων του, όπως περιγράφηκαν παραπάνω. Επεξεργασία πληροφοριών έργου. Αποθήκευση αλλαγών δεδοµένων. Επισκόπηση απαιτήσεων από πελάτη. Επισκόπηση αναφορών και χρονοδιαγράµµατος προγραµµατιστών του έργου. Επισκόπηση αναφορών από υπεύθυνο ανθρώπινων παραγόντων του έργου. Επισκόπηση αναφορών από υπεύθυνο µετρικών και στατιστικών του έργου. Επισκόπηση αναφορών από υπεύθυνο ελέγχων του έργου. Αλλαγή δεδοµένων µελών της οµάδας ανάπτυξης του έργου(ονοµατεπώνυµο, στοιχεία επικοινωνίας κ.ά.). Η κύρια οθόνη Η κύρια οθόνη του XPortofolio (Εικόνα 16) προσφέρει στον διαχειριστή µία συνοπτική και περιεκτική εικόνα του κάθε έργου. Ακολουθεί µία αναλυτική περιγραφή των λειτουργιών της κεντρικής οθόνης

93 Εικόνα 16: Η κύρια οθόνη του XPortofolio Στα όπως φαίνεται και στην εικόνα, η οθόνη είναι χωρισµένη σε δύο µέρη. Το αριστερό µέρος περιλαµβάνει τον πίνακα έργων, κάθε µία γραµµή του οποίου αντιστοιχεί σε ένα έργο λογισµικού. Κάθε γραµµή περιλαµβάνει τα εξής στοιχεία: 1. Project Name Το όνοµα το οποίο έχει δοθεί στο συγκεκριµένο έργο. 2. Start Date Η ηµεροµηνία έναρξης ανάπτυξης του έργου. 3. Deadline Η ηµεροµηνία στην οποία αναµένεται να ολοκληρωθεί το έργο. 4. Completed % - Το ποσοστό ολοκλήρωσης του έργου. 5. Days Left: - Πόσες µέρες αποµένουν για την ολοκλήρωση του έργου, δηλαδή µέχρι την εκτιµώµενη ηµεροµηνία ολοκλήρωσης. Στο δεξί µέρος της οθόνης, αρχικά δεν υφίσταται οποιαδήποτε πληροφορία, ωστόσο περιέχονται δύο ανενεργά αρχικά πλήκτρα, τα εξής: 6. Edit Project s Data Εµφάνιση οθόνης επεξεργασίας στοιχείων του έργου. 7. View More Εµφάνιση περαιτέρω στοιχείων του έργου. Ακόµα, υπάρχει όπως πάντα και η µπάρα στο πάνω µέρος της οθόνης, η οποία περιέχει τα µενού File και Help, τα οποία δίνουν την δυνατότητα για τις εξής ενέργειες: 8. File ίνει τις επιλογές New Project, Save και Exit (Εικόνα 17). Όπως υποδηλώνουν τα ονόµατα των επιλογών, οι λειτουργίες τους είναι οι εξής: New Project Εµφανίζει την οθόνη για εισαγωγή στοιχείων ενός νέου έργου. Add Personnel Εµφανίζει την οθόνη για εισαγωγή στοιχείων ενός νέου ατόµου στην εταιρεία

94 Save Αποθήκευση τυχόν αλλαγών στοιχείων στις οποίες έχει προβεί ο χρήστης. Exit Αποθήκευση αλλαγών και έξοδος από το πρόγραµµα. Εικόνα 17: Το µενού File. 9. Help ίνει τις επιλογές Help Topics και About (Εικόνα 18). Help Topics Εµφανίζει την ενσωµατωµένη στο πρόγραµµα βοήθεια. Στην αρχική έκδοση του XPortofolio δεν είναι διαθέσιµη. About Εµφανίζει τις πληροφορίες σχετικά µε την έκδοση του XPortofolio και τους δηµιουργούς του προγράµµατος. Εικόνα 18: Το µενού Help. Εφόσον ο χρήστης επιλέξει κάποιο από τα διαθέσιµα έργα στον πίνακα, τα κουµπιά 6 και 7 γίνονται διαθέσιµα, ενώ εµφανίζονται κάποιες βασικές πληροφορίες του επιλεγµένου έργου (Εικόνα 19). Οι πληροφορίες που εµφανίζονται στο δεξί µέρος της οθόνης είναι οι εξής: 1. Name Το όνοµα του έργου. 2. Start Date Ηµεροµηνία έναρξης ανάπτυξης του έργου. 3. Estimated Delivery Date Αναµενόµενη ηµεροµηνία ολοκλήρωσης του έργου. 4. Employer Ο εργοδότης του έργου καθώς και ο πελάτης ο οποίος είναι διαρκώς παρόν στον χώρο ανάπτυξης (on-site customer). 5. % Complete Εισαγωγή νέου ποσοστού ολοκλήρωσης του έργου

95 6. Deviation Days Εισαγωγή νέου αριθµού ηµερών καθυστέρησης του έργου. 7. Total Work Hours Ο συνολικός αριθµός εργατοωρών (δηλ. Πόσες ώρες έχουν ξοδέψει συνολικά όλα τα µέλη της οµάδας ανάπτυξης για το εν λόγω έργο). 8. # Tests Αριθµός συνολικών ελέγχων στο έργο. 9. % Successful Tests Ποσοστό επιτυχηµένων ελέγχων στο έργο. Εικόνα 19: Η αρχική οθόνη µετά την επιλογή ενός έργου από τον πίνακα. Η οθόνη δηµιουργίας νέου έργου (New Project) Πατώντας το πλήκτρο New Project από το µενού File της κύριας οθόνης, εµφανίζεται η οθόνη δηµιουργίας νέου έργου. Η µορφή της φαίνεται στην Εικόνα

96 Εικόνα 20: Η οθόνη δηµιουργίας νέου έργου. Όπως φαίνεται και στη εικόνα, υπάρχουν 3 διαθέσιµα πεδία εισαγωγής, µία λίστα πολλαπλών επιλογών (combo box), δύο λίστες και ένα πεδίο κειµένου. Οι λειτουργίες των παραπάνω γραφικών στοιχείων καθώς και των κουµπιών περιγράφονται παρακάτω: 1. Name Εισαγωγή ονόµατος του νέου έργου. 2. Start Date Ηµεροµηνία έναρξης ανάπτυξης του έργου. 3. Estimated Date Αναµενόµενη ηµεροµηνία ολοκλήρωσης του έργου. 4. Company Επιλέγεται ο πελάτης ο οποίος είναι διαρκώς παρόν στον χώρο ανάπτυξης. 5. Οι δύο λίστες χρησιµεύουν για την εισαγωγή/ εξαγωγή ατόµων στην/ από οµάδα του έργου. Η εισαγωγή και η εξαγωγή γίνεται µε επιλογή του επιθυµητού ατόµου και πάτηµα του πλήκτρου Add ή Remove αντίστοιχα. 6. Στα δεξιά της οθόνης, εφόσον υπάρχει κάποια ιδιαίτερη πληροφορία σχετικά µε ένα µέλος της οµάδας, εµφανίζεται ένα κείµενο το οποίο είναι ουσιαστικά αναφορά η οποία µπορεί να περιέχει ιστορικό συνεργασίας, επισηµάνσεις προβληµάτων κ.ά. 7. Μετά την ολοκλήρωση των αλλαγών, πατώντας το πλήκτρο OK γίνεται αποθήκευση των αλλαγών και επιστροφή στην κεντρική οθόνη, µε το νέο έργο εµφανίζεται στον πίνακα (βλ. Κεντρική Οθόνη). Πατώντας το πλήκτρο

97 Cancel γίνεται επιστροφή στην κεντρική οθόνη χωρίς αποθήκευση των αλλαγών. Η οθόνη προσθήκης νέου ατόµου (Add New Personnel) Από την κεντρική οθόνη, επιλέγοντας το Add New Personnel από το µενού File εµφανίζεται η οθόνη προσθήκης νέου συνεργάτη (Εικόνα 21). Εικόνα 21: Η οθόνη Add New Personnel. Ο χρήστης καλείται να εισάγει τα στοιχεία του εισαγόµενου ατόµου. Τα στοιχεία, όπως φαίνονται και στην παραπάνω εικόνα, είναι τα εξής: 1. Select Role - Επιλογή ρόλου του νέου ατόµου από µία λίστα πολλαπλών επιλογών (combo box). 2. Surname Εισαγωγή του επωνύµου. 3. Name Εισαγωγή του ονόµατος. 4. Telephone No Εισαγωγή τηλεφωνικού αριθµού. 5. Address Εισαγωγή διεύθυνσης ηλεκτρονικής αλληλογραφίας. 6. Company Name / Expertise Πεδίο το οποίο συµπληρώνεται αναλόγως εάν ο επιλεγµένος ρόλος είναι εξωτερικός σύµβουλος (Consultant) ή πελάτης (Customer). Το πεδίο εµφανίζεται και έχει το αντίστοιχο όνοµα αναλόγως τον ρόλο που επιλέγεται (Expertise και Company Name για Consultant και Customer αντίστοιχα) (Εικόνα 22 και Εικόνα 23)

98 Εικόνα 22: Εισαγωγή στοιχείων στην περίπτωση Consultant. Τονίζεται η επιλογή του ρόλου η οποία επηρεάζει το τελευταίο πεδίο συµπλήρωσης το οποίο εµφανίζεται. Εικόνα 23: Εισαγωγή στοιχείων στην περίπτωση Customer. Τονίζεται η επιλογή του ρόλου η οποία επηρεάζει το τελευταίο πεδίο συµπλήρωσης το οποίο εµφανίζεται. 7. Τα πλήκτρα OK και Cancel έχουν την ίδια λειτουργικότητα µε την οθόνη New Project (βλ. παραπάνω). Η οθόνη τροποποίησης στοιχείων έργου (Edit Project s Data) Από την κεντρική οθόνη, επιλέγοντας ένα από τα διαθέσιµα έργα στον πίνακα και πατώντας το πλήκτρο Edit Project s Data, ο χρήστης µεταφέρεται στην οθόνη µετατροπής των στοιχείων του έργου (Εικόνα 24)

99 Εικόνα 24: Η οθόνη Edit Project s Data Ο χρήστης µπορεί να τροποποιήσει τα στοιχεία του έργου, εισάγοντας τα επιθυµητά νέα δεδοµένα στα αντίστοιχα πεδία: 1. Πεδίο Start Date Εισαγωγή νέας ηµεροµηνίας έναρξης του έργου. 2. Estimated Delivery Εισαγωγή νέας εκτιµώµενης ηµεροµηνίας παράδοσης του έργου. 3. Deviation Days Εισαγωγή νέου αριθµού ηµερών καθυστέρησης του έργου. 4. % Complete Εισαγωγή νέου ποσοστού ολοκλήρωσης του έργου. 5. # Tests Αριθµός συνολικών ελέγχων στο έργο. 6. # Successful Tests Αριθµός επιτυχηµένων ελέγχων στο έργο. 7. Η λίστες µε τα άτοµα της οµάδας λειτουργούν όπως ακριβώς και στην οθόνη New Project (βλ. παραπάνω). 8. Στα δεξιά του παραθύρου εµφανίζονται οι αναφορές από τον υπεύθυνο ανθρώπινων παραγόντων και τον υπεύθυνο µετρικών και στατιστικών. 9. Τα πλήκτρα OK και Cancel έχουν την ίδια λειτουργικότητα µε την οθόνη New Project (βλ. παραπάνω)

100 Η οθόνη Project Details Επιλέγοντας ένα από τα διαθέσιµα έργα στον πίνακα στην κεντρική οθόνη και πατώντας το πλήκτρο View More, εµφανίζεται η οθόνη Project Details, όπου περιέχονται αναλυτικά οι ρόλοι οι οποίοι υφίστανται σε ένα έργο αναπτυσσόµενο µε χρήση Ευέλικτων Μεθόδων, καθώς και τα άτοµα της οµάδας τα οποία τους καλύπτουν (Εικόνα 25). Εικόνα 25: Η οθόνη Project Details Η οθόνη Project Details χωρίζεται σε τρία µέρη, τα οποία περιγράφονται παρακάτω: 1. Λίστα επιλογής ρόλων Ο χρήστης επιλέγει τον ρόλο του οποίου θέλει να δει περαιτέρω λεπτοµέρειες. 2. Λίστα επιλογής ατόµου Ο χρήστης επιλέγει το άτοµο της οµάδας του οποίου επιθυµεί να δει πιο λεπτοµερή στοιχεία του. 3. Λεπτοµέρειες ατόµου Εµφανίζονται οι λεπτοµέρειες του ατόµου της οµάδας ανάπτυξης του έργου το οποίο έχει επιλεχθεί. Επίσης εµφανίζεται πλήκτρο εµφάνισης εγγράφων ή αναφορών, αναλόγως τον ρόλο που επιλέχθηκε. Επίσης είναι πιθανό να υπάρχει η δυνατότητα αλλαγής στοιχείων και

101 πληροφοριών που συσχετίζονται µε το εν λόγω άτοµο, όπως στην περίπτωση επιλογής του ρόλου του υπεύθυνου ανθρώπινων παραγόντων (Coach) (Εικόνα 26). Εικόνα 26: Η οθόνη Project Details µε επιλεγµένο τον ρόλο του Coach. Τονίζονται τα πλήκτρα αλλαγής στοιχείων του Coach και εµφάνισης αναφοράς. Οι λεπτοµέρειες του κάθε µέλους της οµάδας οι οποίες παρουσιάζονται στο δεξί µέρος της οθόνης συνοψίζονται στα εξής: 1. Surname - Το επώνυµο του ατόµου. 2. Name Το όνοµα του άτοµου. 3. Join Date Η ηµεροµηνία κατά την οποία ξεκίνησε η εργασία του εν λόγω ατόµου στο συγκεκριµένο έργο. 4. TelNo Ο τηλεφωνικός αριθµός του ατόµου. 5. Η διεύθυνση ηλεκτρονικής αλληλογραφίας του ατόµου. 6. Address Η διεύθυνση του ατόµου

102 7. Work Hours Η εργατοώρες του ατόµου (δηλαδή πόσες ώρες έχει καταναλώσει το εν λόγω άτοµο στο συγκεκριµένο έργο). Ο αριθµός εργατοωρών που εισάγει ο χρήστης προστίθεται στο ήδη υπάρχον σύνολο. 8. Άλλο Περαιτέρω πληροφορία σχετικά µε το άτοµο. Στην περίπτωση του προγραµµατιστή (developer) αυτή είναι ο συνεργάτης του στον προγραµµατισµό σε ζευγάρι (partner), ενώ για τον εξωτερικό σύµβουλο (consultant) είναι η ειδικότητά του (expertise). Επίσης στην περίπτωση του «onsite» πελάτη αναφέρεται η εταιρεία στην οποία ανήκει και λογικά είναι και ο εργοδότης του συγκεκριµένου έργου. Στην άνω µπάρα εργαλείων εµφανίζονται τα µενού File και Help. Στο µενού File υπάρχει η επιλογή Back, µε την οποία ο χρήστης επιστρέφει στην αρχική οθόνη του προγράµµατος. Οι λειτουργίες του µενού Help περιγράφτηκαν για την περίπτωση της κύριας οθόνης. Η οθόνη Edit Personnel Data Με πάτηµα του πλήκτρου Edit <ρόλος> Data στην οθόνη Project Data, εµφανίζεται η οθόνη Edit Personnel Data, µέσω της οποίας είναι εφικτή η αλλαγή ή/ και ενηµέρωση στοιχείων του εκάστοτε µέλους της οµάδας ανάπτυξης (Εικόνα 27). Εικόνα 27: Η οθόνη Edit Personnel Data. Τα διαθέσιµα στοιχεία προς αλλαγή είναι τα εξής: 1. Surname Το επώνυµο του ατόµου

103 2. Name Το όνοµα του άτοµου. 3. TelNo Ο τηλεφωνικός αριθµός του ατόµου. 4. Η διεύθυνση ηλεκτρονικής αλληλογραφίας του ατόµου. 5. Address Η διεύθυνση του ατόµου. 6. Work Hours Η εργατοώρες του ατόµου (δηλαδή πόσες ώρες έχει καταναλώσει το εν λόγω άτοµο στο συγκεκριµένο έργο). Ο αριθµός εργατοωρών που εισάγει ο χρήστης προστίθεται στο ήδη υπάρχον σύνολο. 7. Άλλο Περαιτέρω πληροφορία σχετικά µε το άτοµο. Στην περίπτωση του προγραµµατιστή (Developer) αυτή είναι ο συνεργάτης του στον Προγραµµατισµό σε Ζευγάρι (partner), ενώ για τον εξωτερικό σύµβουλο (Consultant) είναι η ειδικότητά του (Expertise). 8. Τα πλήκτρα OK και Cancel έχουν την ίδια λειτουργικότητα µε τις αντίστοιχες οθόνες τροποποίησης στοιχείων (βλ. παραπάνω). Έγγραφα και Αναφορές Πατώντας το πλήκτρο εµφάνισης αναφοράς/ εγγράφου στην οθόνη Project Details (βλ. παραπάνω), εµφανίζεται στο δεξί µέρος της οθόνης ένα κείµενο του οποίου το περιεχόµενο είναι αντίστοιχο του ρόλου που έχει επιλέξει ο χρήστης (Εικόνα 28). Εικόνα 28: Εµφάνιση εγγράφου/ αναφοράς στην οθόνη Project Details

104 Με επιλογή του πλήκτρου Back εµφανίζονται και πάλι οι πληροφορίες του επιλεγµένου ατόµου. Οι αναφορές και γενικότερα όλα τα έγγραφα τα οποία προέρχονται από τα µέλη της οµάδας ανάπτυξης του εκάστοτε έργου είναι σε µορφή εµπλουτισµένου κειµένου (RTF, Rich Text Format). Τα έγγραφα συγγράφονται από τα αρµόδια άτοµα και δίδονται στον διαχειριστή, ο οποίος έπειτα έχει την δυνατότητα να τα δει και µέσω του XPortofolio. Για την επεξεργασία τους και την εκτύπωσή τους µπορεί ο χρήστης να χρησιµοποιήσει κάποιον επεξεργαστή κειµένου, ο οποίος του δίνει όλες αυτές τις δυνατότητες. Ωστόσο, για να µπορεί το XPortofolio να αναγνωρίσει και να παρουσιάσει τα κείµενα στον χρήστη, οφείλει ο συγγραφέας τους να χρησιµοποιεί συγκεκριµένη ονοµατολογία, η οποία παρουσιάζεται στον Πίνακας 1. Πίνακας 1: Ονοµατολογία αρχείων εγγράφων RTF. Είδος εγγράφου Απαιτήσεις πελάτη Χρονοδιάγραµµα προγραµµατιστή Αναφορά στατιστικών Αναφορά ελέγχων Λεπτοµέρειες / Ιστορικό ατόµου Ονοµατολογία <Όνοµα έργου>-specifications. rtf <Όνοµα έργου>-<επώνυµο προγραµµατιστή Όνοµα προγραµµατιστή>-schedule.rtf <Όνοµα έργου>-statistics. rtf <Όνοµα έργου>-<επώνυµο υπευθύνου Όνοµα υπευθύνου>- Tests. rtf <Επώνυµο ατόµου Όνοµα ατόµου>-details. rtf Τα έγγραφα RTF πρέπει να βρίσκονται στον ίδιο φάκελο που βρίσκονται και τα αρχεία δεδοµένων.xp τα οποία περιέχουν τις πληροφορίες σχετικά µε το προσωπικό της οµάδας (Personnel.XP), τα έργα (Projects.XP) και τους πελάτες (Customers.XP). Σχετικά µε την εσωτερική τεκµηρίωση του κώδικα Όπως σε κάθε κώδικα λογισµικού, έτσι και στον κώδικα του XPortofolio, υπάρχει η σχετική εσωτερική τεκµηρίωση (σχόλια). Η χρήση σχολίων ωστόσο δεν είναι ιδιαίτερα εκτεταµένη, λόγω της απλότητας του κώδικα σε αρκετά σηµεία. Η ευρεία ανάπτυξη GUI και η επαναληπτική χρήση κώδικα παραπλήσιας µορφής σε διάφορα σηµεία κατέστησε την εισαγωγή σχολίων αρκετά λιτή. Άλλωστε πρέπει να σηµειωθεί ότι το πρόγραµµα απευθύνεται σε άτοµα τα οποία είναι δυνατόν να έχουν µία σαφώς

105 καλύτερη κατανόηση των γραµµών του κώδικα από τους µέσους χρήστες των περισσότερων προϊόντων λογισµικού. Εκτός αυτού, η απαίτηση για συντήρηση του λογισµικού και συνεπώς ενδεχόµενες τροποποιήσεις είναι δυνατές και διευκολύνονται από την προαναφερθείσα χρήση σχολίων. Τέλος, υφίσταται και µία σχετική τεχνική εξωτερική τεκµηρίωση µε αναλυτική παρουσίαση των κλάσεων του κώδικα. Η τεκµηρίωση δηµιουργήθηκε µε αυτόµατα µε χρήση του Eclipse (Εικόνα 29). Εικόνα 29: Η επιλογή από το µενού του Eclipse για την αυτόµατη δηµιουργία τεκµηρίωσης του project. Συνοπτική ανάλυση απόδοσης χρηστικότητας Για την καλύτερη αξιολόγηση του XPortofolio, η οµάδα ανάπτυξης επιδόθηκε σε µία σειρά από ενέργειες µε χρήση του λογισµικού, ώστε να µπορέσει να µετρηθεί ο χρόνος ο οποίος απαιτείται για τις βασικές λειτουργίες του µέσου χρήστη της εφαρµογής. Η λειτουργίες για τις οποίες χρησιµοποιήθηκε και αξιολογήθηκε ως προς την χρηστική απόδοση σε ότι αφορά τον χρόνο για την επιτέλεση τους, ήταν οι εξής: ηµιουργία νέου έργου Προσθήκη προσωπικού εταιρείας Σύντοµη επισκόπηση λεπτοµερειών έργου Τροποποίηση στοιχείων έργου Τροποποίηση στοιχείου ατόµου

106 Η χρονοµέτρηση έγινε προφανώς µε ταυτόχρονη χρήση της εφαρµογής. Οι καταγεγραµµένες µετρήσεις έγιναν βάσει της οθόνης του προγράµµατος που χρησιµοποιήθηκε για την εκτέλεσή τους. Επικεντρώθηκε η προσοχή δηλαδή η προσοχή στην αξιολόγηση της εκάστοτε χρησιµοποιούµενης οθόνης. Επίσης, είναι σηµαντικό να τονιστεί ότι είναι λογικό οι µετρήσεις να είναι κατά προσέγγιση και να διαφοροποιούνται ανάλογα µε τον χρήστη του XPortofolio. Στον Πίνακας 2 φαίνονται οι καταγεγραµµένες µετρήσεις, µε τον χρόνο εκτέλεσης της κάθε λειτουργίας και της οθόνης στη οποία επικεντρώνεται η κάθε µία. Έτσι είναι και πιο εύκολο να βγουν συµπεράσµατα σχετικά µε καθυστερήσεις που παρουσιάζονται σε κάθε οθόνη. Πίνακας 2: Χρόνοι εκτέλεσης λειτουργιών για εκτέλεση βασικών λειτουργιών µε χρήση του XPortofolio. Προσθήκη έργου Προσθήκη ατόµου Επισκόπηση λεπτοµερειών έργου Τροποποίηση έργου Τροποποίηση ατόµου Οθόνη New Project Add New Personnel View More Screen Edit Project Data Edit Personnel Data Χρόνος Με µία σύντοµη µατιά στον πίνακα µπορεί κανείς να παρατηρήσει ότι, όπως είναι λογικό, οι τροποποιήσεις των στοιχείων του κάθε έργου ή ατόµου απαιτούν και τον περισσότερο χρόνο, καθώς είναι σηµαντικό οι αλλαγές που γίνονται να είναι σωστές, καθώς έχουν επιπτώσεις στα στατιστικά και τα χρονοδιαγράµµατα του έργου. Αντίθετα, οι προσθήκες ατόµων και έργων απαιτούν µεν χρόνο, αλλά σαφώς λιγότερο από τον αντίστοιχο της τροποποίησης, καθώς συνιστούν ουσιαστικά διαδικασία αντιγραφής στοιχείων που λογικά έχει στην διάθεσή του ο χρήστης διαχειριστής

107 ΠΑΡΑΡΤΗΜΑ Β Τεκµηρίωση του κώδικα του XPortofolio υπό µορφή Javadoc Η Javadoc τεκµηρίωση του κώδικα δεν περιλαµβάνει όλα τα στοιχεία του συστήµατος, καθώς κάτι τέτοιο δεν θα ήταν πρακτικό και δεν θα προσέφερε κάτι παραπάνω στην κατανόηση και γενική επισκόπηση του κώδικα. Η γενική επισκόπηση του πακέτου κλάσεων (package) της εφαρµογής φαίνεται στην Εικόνα 30. Εικόνα 30: Το πακέτο κλάσεων του XPortofolio

108 xportofolio Class Main java.lang.object xportofolio.main public class Main extends java.lang.object Field Summary static java.lang.string customersfilename static java.util.arraylist<xportofolio.customer> customerslist static java.lang.string personnelfilename static java.util.arraylist<person> personnellist static java.lang.string projectsfilename static java.util.arraylist<project> projectslist static MainScreen XPMain Constructor Summary Main()

109 Method Summary static void loadall() static void main(java.lang.string[] args) static void saveall() Methods inherited from class java.lang.object clone, equals, finalize, getclass, hashcode, notify, notifyall, tostring, wait, wait, wait Field Detail customersfilename public static final java.lang.string customersfilename See Also: Constant Field Values customerslist public static java.util.arraylist<xportofolio.customer> customerslist personnelfilename public static final java.lang.string personnelfilename See Also: Constant Field Values

110 personnellist public static java.util.arraylist<person> personnellist projectsfilename public static final java.lang.string projectsfilename See Also: Constant Field Values projectslist public static java.util.arraylist<project> projectslist XPMain public static final MainScreen XPMain Constructor Detail Main public Main() Method Detail loadall public static void loadall() main public static void main(java.lang.string[] args) Parameters: args - the command line arguments saveall public static void saveall()

111 xportofolio Class MainScreen java.lang.object java.awt.component java.awt.container java.awt.window java.awt.frame javax.swing.jframe xportofolio.mainscreen public class MainScreen extends javax.swing.jframe implements java.awt.event.actionlistener, java.awt.event.mouselistener Constructor Summary MainScreen() Creates a new instance of MainScreen Method Summary void addproject(project project) javax.swing.jpanel getpinfo() javax.swing.jscrollpane getstablecontainer() javax.swing.jtable gettprojecttable() void loadprojectstable()

112 Constructor Detail MainScreen public MainScreen() Creates a new instance of MainScreen Method Detail actionperformed public void actionperformed(java.awt.event.actionevent e) Specified by: actionperformed in interface java.awt.event.actionlistener addproject public void addproject(project project) getpinfo public javax.swing.jpanel getpinfo() getstablecontainer public javax.swing.jscrollpane getstablecontainer() gettprojecttable public javax.swing.jtable gettprojecttable() loadprojectstable public void loadprojectstable()

113 xportofolio Class DiskHandler java.lang.object xportofolio.diskhandler public class DiskHandler extends java.lang.object Constructor Summary DiskHandler() Creates a new instance of DiskHandler Method Summary static void loadcustomers(java.lang.string customersfilename) static void loadpersons(java.lang.string personsfilename) static void loadprojects(java.lang.string projectsfilename) static void savecustomers(java.lang.string customersfilename) static void savepersons(java.lang.string personsfilename) static void saveprojects(java.lang.string projectsfilename)

114 Constructor Detail DiskHandler public DiskHandler() Creates a new instance of DiskHandler Method Detail loadcustomers public static void loadcustomers(java.lang.string customersfilename) loadpersons public static void loadpersons(java.lang.string personsfilename) loadprojects public static void loadprojects(java.lang.string projectsfilename) savecustomers public static void savecustomers(java.lang.string customersfilename) savepersons public static void savepersons(java.lang.string personsfilename) saveprojects public static void saveprojects(java.lang.string projectsfilename)

115 xportofolio Class Person java.lang.object xportofolio.person All Implemented Interfaces: java.io.serializable public abstract class Person extends java.lang.object implements java.io.serializable Field Summary protected Project currentproject Constructor Summary Person(java.lang.String name, java.lang.string telno, java.lang.string address) Creates a new instance of Person java.lang.string surname, java.lang.string , Method Summary void addworkinghourstoproject(java.lang.string projectname, long hours) java.lang.string getaddress() Project getcurrentproject()

116 java.lang.string get () java.lang.string getname() java.lang.string getsurname() java.lang.string gettelno() long gettotalworkhours() long getworkhoursforproject(java.lang.string projectname) boolean isoccupied() void setaddress(java.lang.string address) void setcurrentproject(project currentproject) void set (java.lang.string ) void setname(java.lang.string name) void setsurname(java.lang.string surname) void settelno(java.lang.string telno) void settotalworkhours(int totalworkhours)

117 Field Detail currentproject protected Project currentproject Constructor Detail Person public Person(java.lang.String name, java.lang.string surname, java.lang.string telno, java.lang.string , java.lang.string address) Creates a new instance of Person Method Detail addworkinghourstoproject public void addworkinghourstoproject(java.lang.string projectname, long hours) getaddress public java.lang.string getaddress() getcurrentproject public Project getcurrentproject() get public java.lang.string get () getname public java.lang.string getname()

118 getsurname public java.lang.string getsurname() gettelno public java.lang.string gettelno() gettotalworkhours public long gettotalworkhours() getworkhoursforproject public long getworkhoursforproject(java.lang.string projectname) isoccupied public boolean isoccupied() setaddress public void setaddress(java.lang.string address) setcurrentproject public void setcurrentproject(project currentproject) set public void set (java.lang.string ) setname public void setname(java.lang.string name)

119 setsurname public void setsurname(java.lang.string surname) settelno public void settelno(java.lang.string telno) settotalworkhours public void settotalworkhours(int totalworkhours)

120 xportofolio Class EditDataScreen java.lang.object java.awt.component java.awt.container java.awt.window java.awt.frame javax.swing.jframe xportofolio.editdatascreen public class EditDataScreen extends javax.swing.jframe implements java.awt.event.windowlistener Nested Class Summary Constructor Summary EditDataScreen(Person tobemodified, This is the default constructor javax.swing.jframe Parent) Constructor Detail EditDataScreen public EditDataScreen(Person tobemodified, javax.swing.jframe Parent) This is the default constructor

121 xportofolio Class NewPersonnelScreen java.lang.object java.awt.component java.awt.container java.awt.window java.awt.frame javax.swing.jframe public class NewPersonnelScreen extends javax.swing.jframe implements java.awt.event.windowlistener See Also: Serialized Form Constructor Summary NewPersonnelScreen() This is the default constructor Constructor Detail NewPersonnelScreen public NewPersonnelScreen() This is the default constructor

122 xportofolio Class Project java.lang.object xportofolio.project All Implemented Interfaces: java.io.serializable public class Project extends java.lang.object implements java.io.serializable Constructor Summary xportofo- Project(java.lang.String name, java.util.date estimateddeliverydate, lio.customer projectemployer) Creates a new instance of Project java.util.date startdate, Method Summary void addperson(person tobeadded) int calculatedaysleft() void calculatetotalworkhours() int getdeviationdays() java.util.date getestimateddeliverydate() java.lang.string getname()

123 long getnooftests() float getpercentcomplete() float getpercentoftestsuccess() xportofolio.customer getprojectemployer() java.util.arraylist<person> getremovedstaff() java.util.arraylist<person> getstaff() java.util.date getstartdate() long getsuccessfultests() long gettotalworkhours() void removeperson(person toberemoved) void setdeviationdays(int deviationdays) void setestimateddeliverydate(java.util.date estimateddeliverydate) void setname(java.lang.string name) void setnooftests(long nooftests)

124 void setpercentcomplete(float percentcomplete) void setprojectemployer(xportofolio.customer projectemployer) void setstaff(java.util.arraylist<person> staff) void setstartdate(java.util.date startdate) void setsuccessfultests(long successfultests) void settotalworkhours(long totalworkhours) Constructor Detail Project public Project(java.lang.String name, java.util.date startdate, java.util.date estimateddeliverydate, xportofolio.customer projectemployer) Creates a new instance of Project Method Detail addperson public void addperson(person tobeadded) calculatedaysleft public int calculatedaysleft()

125 calculatetotalworkhours public void calculatetotalworkhours() getdeviationdays public int getdeviationdays() getestimateddeliverydate public java.util.date getestimateddeliverydate() getname public java.lang.string getname() getnooftests public long getnooftests() getpercentcomplete public float getpercentcomplete() getpercentoftestsuccess public float getpercentoftestsuccess() getprojectemployer public xportofolio.customer getprojectemployer() getremovedstaff public java.util.arraylist<person> getremovedstaff() getstaff public java.util.arraylist<person> getstaff()

126 getstartdate public java.util.date getstartdate() getsuccessfultests public long getsuccessfultests() gettotalworkhours public long gettotalworkhours() removeperson public void removeperson(person toberemoved) setdeviationdays public void setdeviationdays(int deviationdays) setestimateddeliverydate public void setestimateddelivery- Date(java.util.Date estimateddeliverydate) setname public void setname(java.lang.string name) setnooftests public void setnooftests(long nooftests) setpercentcomplete public void setpercentcomplete(float percentcomplete)

127 setprojectemployer public void setprojectemployer(xportofolio.customer projectemployer) setstaff public void setstaff(java.util.arraylist<person> staff) setstartdate public void setstartdate(java.util.date startdate) setsuccessfultests public void setsuccessfultests(long successfultests) settotalworkhours public void settotalworkhours(long totalworkhours)

128 xportofolio Class ViewMoreScreen java.lang.object java.awt.component java.awt.container java.awt.window java.awt.frame javax.swing.jframe xportofolio.viewmorescreen public class ViewMoreScreen extends javax.swing.jframe implements java.awt.event.windowlistener See Also: Serialized Form Constructor Summary ViewMoreScreen(Project _selectedproject) Creates XPMain new instance of ViewMoreScreen Constructor Detail ViewMoreScreen public ViewMoreScreen(Project _selectedproject) Creates XPMain new instance of ViewMoreScreen

129 xportofolio Class EditProjectScreen java.lang.object java.awt.component java.awt.container java.awt.window java.awt.frame javax.swing.jframe xportofolio.editprojectscreen public class EditProjectScreen extends javax.swing.jframe implements java.awt.event.windowlistener See Also: Serialized Form Constructor Summary EditProjectScreen(Project selectedproject) This is the default constructor Constructor Detail EditProjectScreen public EditProjectScreen(Project selectedproject) This is the default constructor

130 xportofolio Class NewProjectScreen java.lang.object java.awt.component java.awt.container java.awt.window java.awt.frame javax.swing.jframe xportofolio.newprojectscreen public class NewProjectScreen extends javax.swing.jframe implements java.awt.event.windowlistener See Also: Serialized Form Constructor Summary NewProjectScreen() This is the default constructor Constructor Detail NewProjectScreen public NewProjectScreen() This is the default constructor

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

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156