Κρίσιμοι παράγοντες βελτίωσης της διαδικασίας ανάπτυξης λογισμικού: σύγχρονες τάσεις και προκλήσεις

ΠΑΝΕΠΙΣΤΗΜΙΟ ΜΑΚΕΔΟΝΙΑΣ ΤΜΗΜΑ ΟΡΓΑΝΩΣΗΣ ΚΑΙ ΔΙΟΙΚΗΣΗΣ ΕΠΙΧΕΙΡΗΣΕΩΝ Δ.Π.Μ.Σ. ΣΤΗ ΔΙΟΙΚΗΣΗ ΕΠΙΧΕΙΡΗΣΕΩΝ ΔΙΠΛΩΜΑΤΙΚΗ ΕΡΓΑΣΙΑ Κρίσιμοι παράγοντες βελτίωσης της διαδικασίας ανάπτυξης λογισμικού: σύγχρονες τάσεις και προκλήσεις Επιβλέπουσα καθηγήτρια: Κα ΑΙΚΑΤΕΡΙΝΗ ΓΚΟΤΖΑΜΑΝΗ ΖΙΑΝΙΚΑ ΜΑΡΙΑ Α.Μ. 32/08 ΘΕΣΣΑΛΟΝΙΚΗ, Σεπτέμβριος 2009

Οτομέας της παραγωγής λογισμικού αποτελεί, κατά την προσωπική μου άποψη, ένα ιδιαίτερα ενδιαφέρον πεδίο. Κατά την διάρκεια των προπτυχιακών μου σπουδών είχα την ευκαιρία να διδαχθώ κάποιες βασικές αρχές, αλλά περισσότερο από την οπτική της επιστήμης των Ηλεκτρολόγων Μηχανικών. Αυτές οι γνώσεις έπειτα τέθηκαν σε εφαρμογή κατά την επαγγελματική μου πορεία καθώς τα τελευταία πέντε χρόνια εργάζομαι στον τομέα του προγραμματισμού λογισμικού. Κατά την διάρκεια των μεταπτυχιακών μου σπουδών είχα την ευκαιρία να αποκτήσω μια διαφορετική οπτική για την διοίκηση των επιχειρήσεων, βλέποντας πλέον αυτές όχι σαν διαφορετικά τμήματα αλλά σαν ένα σύνολο διαδικασιών. Η συστηματική μελέτη της θεωρίας της διοίκησης λειτουργιών και των συστημάτων ποιότητας με έκανε να αναρωτηθώ για τον τρόπο που αυτά μπορούν να εφαρμοστούν στον επαγγελματικό μου χώρο. Η ευκαιρία για να μελετήσω αυτό τον συνδυασμό μου δόθηκε στα πλαίσια της παρούσας διπλωματικής μελέτης όπου αναλύονται οι σύγχρονες διαδικασίες παράγωγης λογισμικού. Στο σημείο αυτό θα ήθελα να ευχαριστήσω θερμά την καθηγήτρια κα. Αικατερίνη Γκοτζαμάνη για την επιστημονική καθοδήγηση που μου προσέφερε, τις πολύτιμες υποδείξεις της και κυρίως για τη διάθεση, αλλά και το φιλικό και ευχάριστο κλίμα συνεργασίας, που υπήρχε καθ όλη τη διάρκεια της εκπόνησης της διπλωματικής εργασίας. Επίσης δεν πρέπει να παραβλέψω να ευχαριστήσω τους γονείς μου, τον αδερφό μου και τους φίλους μου για την υποστήριξη τους κατά την διάρκεια εκπόνησης αυτής της διπλωματικής και όχι μόνο._ Ζιανίκα Μαρία Σεπτέμβριος 2009

Πίνακας Περιεχόμενων 1. ΕΙΣΑΓΩΓΗ... 1 2. ΜΕΘΟΔΟΛΟΓΙΕΣ ΑΝΑΠΤΥΞΗΣ ΛΟΓΙΣΜΙΚΟΥ... 4 2.1 ΤΟ ΜΟΝΤΕΛΟ ΤΟΥ ΚΑΤΑΡΡΑΚΤΗ... 6 2.2 TO ΜΟΝΤΕΛΟ ΤΗΣ ΔΗΜΙΟΥΡΓΙΑΣ ΠΡΩΤΟΤΥΠΟΥ... 9 2.3 TO ΕΠΑΥΞΗΤΙΚΟ ΜΟΝΤΕΛΟ... 11 2.4 ΤΟ ΣΠΕΙΡΟΕΙΔΕΣ ΜΟΝΤΕΛΟ... 12 2.5 Η ΓΡΗΓΟΡΗ ΑΝΑΠΤΥΞΗ ΕΦΑΡΜΟΓΗΣ... 15 3. ΕΥΕΛΙΚΤΗ ΑΝΑΠΤΥΞΗ ΛΟΓΙΣΜΙΚΟΥ... 18 3.1 ΤΟ ΜΑΝΙΦΕΣΤΟ ΤΩΝ ΕΥΕΛΙΚΤΩΝ ΜΕΘΟΔΟΛΟΓΙΩΝ ΑΝΑΠΤΥΞΗΣ ΛΟΓΙΣΜΙΚΟΥ... 20 3.2 ΟΙ ΑΡΧΕΣ ΤΟΥ ΕΥΕΛΙΚΤΟΥ ΜΑΝΙΦΕΣΤΟ... 22 3.3 ΕΥΕΛΙΚΤΕΣ ΜΕΘΟΔΟΛΟΓΙΕΣ ΑΝΑΠΤΥΞΗΣ... 23 3.3.1 Ακραίος Προγραμματισμός (Extreme programming)... 25 3.3.1.1 Διαδικασία... 26 3.3.1.2 Ρόλοι και ευθύνες... 29 3.3.1.3 Πρακτικές... 30 3.3.2 Scrum... 34 3.3.2.1 Διαδικασία... 36 3.3.2.2 Ρόλοι και ευθύνες... 38 3.3.2.3 Πρακτικές... 40 3.3.3 Οι Μεθοδολογίες Κρυστάλλου (Crystal methodologies)... 43 3.3.3.1 Διαδικασία... 45 3.3.3.2 Ρόλοι και ευθύνες... 48 3.3.3.3 Πρακτικές... 49 3.3.4 Ανάπτυξη με βάση τα χαρακτηριστικά (Feature driven development)... 52 3.3.4.1 Διαδικασία... 53 3.3.4.2 Ρόλοι και ευθύνες... 56 3.3.4.3 Πρακτικές... 59 3.3.5 Μέθοδος Ανάπτυξης Δυναμικών Συστημάτων (Dynamic Systems Development Method) 61 3.3.5.1 Διαδικασία... 61 3.3.5.2 Ρόλοι και ευθύνες... 64 3.3.5.3 Πρακτικές... 65 3.3.6 Εναρμονισμένη ανάπτυξη λογισμικού (Adaptive Software Development)... 67 3.3.6.1 Διαδικασία... 68 3.3.6.2 Ρόλοι και ευθύνες... 71 3.3.6.3 Πρακτικές... 72 3.3.7 Ανάπτυξη λογισμικού ανοικτού πηγαίου κώδικα (Open source software development) 72 3.3.7.1 Διαδικασία... 74 3.3.7.2 Ρόλοι και ευθύνες... 75 3.3.7.3 Πρακτικές... 77 3.4 ΠΛΕΟΝΕΚΤΗΜΑΤΑ ΤΩΝ ΜΕΘΟΔΩΝ... 77 3.4.1 Μείωση του κινδύνου... 78 3.4.2 Βελτίωση του ελέγχου... 83 3.4.3 Βελτίωση των επικοινωνιών... 87 3.5 ΣΥΓΚΡΙΣΗ ΤΩΝ ΜΕΘΟΔΩΝ... 91

4. ΠΡΟΚΛΗΣΕΙΣ ΤΗΣ ΕΦΑΡΜΟΓΗΣ ΤΩΝ ΕΥΕΛΙΚΤΩΝ ΠΡΑΚΤΙΚΩΝ... 96 4.1 ΠΡΟΒΛΗΜΑΤΑ ΣΤΗ ΔΙΑΔΙΚΑΣΙΑΣ ΑΝΑΠΤΥΞΗΣ... 98 4.1.1 Μεταβλητότητα... 99 4.1.2 Διαφορετικοί κύκλοι ζωής... 100 4.1.3 Προϋπάρχοντα Συστήματα... 100 4.1.4 Απαιτήσεις... 101 4.2 ΠΡΟΒΛΗΜΑΤΑ ΣΤΙΣ ΕΤΑΙΡΙΚΕΣ ΔΙΑΔΙΚΑΣΙΕΣ... 101 4.2.1 Ανθρώπινο δυναμικό... 101 4.2.2 Μέτρηση της προόδου... 102 4.2.3 Τυποποιημένες αξιολογήσεις της διαδικασίας... 102 4.3 ΠΡΟΒΛΗΜΑΤΑ ΣΕ ΑΝΘΡΩΠΙΝΑ ΖΗΤΗΜΑΤΑ... 103 4.3.1 Διοικητική νοοτροπία... 103 4.3.2 Υλικοτεχνικά ζητήματα... 103 4.3.3 Επιτυχής διαχείριση των πιλοτικών προγραμμάτων.... 104 4.3.4 Διαχείριση αλλαγής... 104 5. ΜΕΛΕΤΕΣ ΠΕΡΙΠΤΩΣΕΩΝ... 106 5.1 ΕΦΑΡΜΟΓΗ ΚΑΙ ΑΞΙΟΛΟΓΗΣΗ ΤΩΝ ΕΥΕΛΙΚΤΩΝ ΠΡΑΚΤΙΚΩΝ... 106 5.2 ΤΑ ΣΥΜΠΕΡΑΣΜΑΤΑ ΤΗΣ ΕΦΑΡΜΟΓΗΣ... 109 5.2.1 Η Προσαρμογή του XP... 110 5.2.2 Η υποστήριξη της επικοινωνίας των ομάδων... 111 5.2.3 Οι συγκρούσεις παραδοσιακών και Ευέλικτων πρακτικών... 113 5.2.3.1 Η συνεχής αναδόμηση του κώδικα σε σύγκρουση με το CCB... 113 5.2.3.2 Η συνεχής ολοκλήρωση σε σύγκρουση με το CCB... 114 5.2.4 Οι Εταιρικές διαδικασίες παραγωγής λογισμικού... 115 5.2.4.1 Ο προγραμματισμός του πεδίου δράσης και της παράδοσης.... 115 5.2.4.2 Η διαχείριση των απαιτήσεων.... 116 5.2.4.3 Η διαχείριση των δοκιμών αποδοχής του προγράμματος... 116 5.2.4.4 Ποιοτική διαχείριση.... 116 5.3 ΜΕΛΛΟΝΤΙΚΕΣ ΠΡΟΟΠΤΙΚΕΣ ΕΦΑΡΜΟΓΗΣ ΣΤΙΣ ΕΤΑΙΡΙΕΣ... 117 6. ΣΥΜΠΕΡΑΣΜΑΤΑ... 120 7. ΕΠΙΛΟΓΟΣ... 123

ΠΕΡΙΛΗΨΗ Η βιομηχανία ανάπτυξης λογισμικού είναι μια από της πιο ταχέως εξελισσόμενες. Τα προϊόντα της πρέπει να ανταποκρίνονται συνεχώς και γρήγορα στις αλλαγές αλλά ταυτόχρονα να διατηρούν την υψηλή ποιότητά τους. Για να καλυφθούν αυτές οι απαιτήσεις μια σειρά νέων μεθοδολογιών ανάπτυξης λογισμικού έχουν πρόσφατα διατυπωθεί. Οι μεθοδολογίες αυτές αποκαλούνται «ευέλικτες» μεθοδολογίες, γεγονός που φανερώνει την ικανότητα τους να προσαρμόζονται γρήγορα στις μεταβολές του περιβάλλοντος. Στα πλαίσια αυτής της διπλωματικής μελέτης επιχειρείται η συστηματική καταγραφή αυτών. Αρχικά θα παρουσιαστούν κάποιες παραδοσιακές μεθοδολογίες στις οποίες βασίζονται οι νέες ευέλικτες μέθοδοι. Στη συνέχεια οι περισσότερες από τις υπάρχουσες ευέλικτες μεθοδολογίες θα καθοριστούν και θα ταξινομηθούν περιγράφοντας για καθεμίαν τις διαδικασίες, τους ρόλους και τις πρακτικές που τη χαρακτηρίζουν. Οι προκλήσεις για την εφαρμογή των πρακτικών αυτών συζητούνται στο τρίτο τμήμα της μελέτης αυτής. Τέλος παρατίθενται οι εμπειρίες και συνοψίζονται τα ευρήματα των εταιριών που εφάρμοσαν κάποια από τις ευέλικτες πρακτικές ABSTRACT The software development industry is one of the most fast growing industries. Its products must constantly and rapidly respond to change but at the same time maintain high standards of quality. In order to fulfill these needs a series of new software development methodologies has emerged. These methodologies are called Agile, as to denote their ability to adapt quickly to change. The present thesis aims to systematically review these methods. In the first part of this document some traditional methods, that pose the basis for agile methods, are reviewed. Then most of the agile methods are defined by describing for each one of them their process, the roles and practices. The challenges derived when applying these methods are discussed in the third part. Finally the application results of large organizations are presented. 1

2

1. Εισαγωγή Ο τομέας της ανάπτυξης λογισμικού δεν υστερεί στην εισαγωγή νέων μεθοδολογιών. Πράγματι, τα τελευταία 25 χρόνια, ένας μεγάλος αριθμός διαφορετικών προσεγγίσεων στην ανάπτυξη λογισμικού έχει προταθεί, αλλά μόνο λίγες έχουν επιζήσει για να χρησιμοποιηθούν σήμερα. Μια μελέτη (Nandhakumar και Avison, 1999) υποστηρίζει ότι οι παραδοσιακές μεθοδολογίες ανάπτυξης συστημάτων πληροφοριών «αντιμετωπίζονται πρώτιστα ως απαραίτητα εφευρήματα για να παρουσιάσουν μια εικόνα του ελέγχου ή για να παρέχουν ένα συμβολικό κύρος». Η ίδια μελέτη υποστηρίζει ότι αυτές οι μεθοδολογίες είναι πάρα πολύ μηχανιστικές για να χρησιμοποιηθούν λεπτομερώς. Άλλοι μελετητές (Truex et al, 2000) υποστηρίζουν μια ακραία θέση και δηλώνουν ότι οι παραδοσιακές μέθοδοι είναι «μόνο ανέφικτα ιδανικά και υποθετικά σκιάχτρα που παρέχουν τις κανονιστικές οδηγίες για ουτοπιστικές καταστάσεις ανάπτυξης». Κατά συνέπεια, οι βιομηχανικοί υπεύθυνοι για την ανάπτυξη λογισμικού έχουν γίνει δύσπιστοι για τις «νέες» λύσεις που είναι δύσκολο να κατανοηθούν και παραμένουν έτσι αχρησιμοποίητες (Wiegers, 1998). Αυτό ήταν το κλίμα πριν από την εμφάνιση των ευέλικτων μεθόδων ανάπτυξης λογισμικού. Ενώ δεν υπήρχε καμία συμφωνία για το τι η έννοια του «ευέλικτου» πραγματικά περιέχει, έχει παραχθεί πρόσφατα πολύ ενδιαφέρον μεταξύ των επαγγελματιών του χώρου αλλά και στον ακαδημαϊκό κόσμο. Η εισαγωγή της «ακραίας μεθόδου προγραμματισμού» (Extreme Programming XP, Beck (1999a), Beck (1999b)) έχει αναγνωριστεί ευρέως ως αφετηρία για τις διάφορες ευέλικτες προσεγγίσεις ανάπτυξης λογισμικού. Υπάρχουν επίσης διάφορες άλλες μέθοδοι είτε που εφευρίσκονται είτε εκ νέου ανακαλύπτονται και ανήκουν στην ίδια οικογένεια των μεθοδολογιών. Τέτοιες μέθοδοι είναι, π.χ., «Μεθοδολογίες Κρυστάλλου» (Crystal Methods, Cockburn (2000)), η «ανάπτυξη οδηγούμενη από τα χαρακτηριστικά γνωρίσματα» (Feature-Driven Development, Palmer and Felsing (2002)), και η «εναρμόνισμένη ανάπτυξη λογισμικού» (Adaptive Software Development, Highsmith (2000)). Η «ευέλικτη» ανάπτυξη λογισμικού, λοιπόν, αναφέρεται σε μια ομάδα μεθοδολογιών ανάπτυξης λογισμικού βασισμένων στην επαναληπτική ανάπτυξη, 1

όπου οι απαιτήσεις και οι λύσεις εξελίσσονται μέσω της συνεργασίας αυτορυθμιζόμενων και διαγώνιος-λειτουργικών ομάδων. Ο όρος χρησιμοποιήθηκε για πρώτη φορά το έτος 2001 όταν διατυπώθηκε το ευέλικτο μανιφέστο. Οι ευέλικτες μέθοδοι προωθούν γενικά μια πειθαρχημένη διαδικασία διαχείρισης ενός έργου, που ενθαρρύνει τη συχνή επιθεώρηση και αναπροσαρμογή. Ευνοούνται δε, από μια φιλοσοφία ηγεσίας που ενθαρρύνει την ομαδική εργασία, την αυτό-οργάνωση και την υπευθυνότητα, ένα γενικότερο σύνολο καλύτερων πρακτικών εφαρμοσμένης μηχανικής που επιτρέπουν τη γρήγορη παράδοση υψηλής ποιότητας λογισμικού, καθώς και μια επιχειρησιακή προσέγγιση που ευθυγραμμίζει την ανάπτυξη με τις ανάγκες των πελατών και τους στόχους της επιχείρησης. Τα εννοιολογικά θεμέλια αυτού του πλαισίου βρίσκονται στις σύγχρονες προσεγγίσεις διοίκησης και την ανάλυση των διαδικασιών, όπως η λιτή παραγωγή, η μεθοδολογία των «μαλακών» συστημάτων και η μέθοδος των 6 Σίγμα Ενώ λίγα είναι γνωστά για τα πραγματικά οφέλη της επένδυσης που γίνεται για την οργάνωση των διαδικασιών μιας εταιρίας (Glass, 1999), ακόμα λιγότερο είναι γνωστά για το πόσο μια οργάνωση θα ωφεληθεί από τη χρήση των ευέλικτων μεθοδολογιών ανάπτυξης λογισμικού. Οι αρχικές εκθέσεις από τη βιομηχανία είναι κυρίως θετικές (π.χ., Anderson et al. (1998), Grenning (2001)). Αριθμητικά μέτρα, εντούτοις, είναι δύσκολο να ληφθούν σε αυτή τη φάση. Κατά τη διάρκεια των τελευταίων χρόνων, καθώς οι δυνάμεις της αγοράς, οι απαιτήσεις των συστημάτων, η τεχνολογία των εφαρμογών, και το προσωπικό των προγραμμάτων άλλαζαν, ο ευέλικτος τρόπος ανάπτυξης παρουσιάσει τα πλεονεκτήματά του ενάντια στο παραδοσιακό και το ενδιαφέρον της βιομηχανίας παράγωγης λογισμικού είναι συνεχώς αυξανόμενο. Εντούτοις, από ότι μας είναι γνωστό, καμία συστηματική μελέτη των μεθοδολογιών της ευέλικτης ανάπτυξης δεν έχει γίνει ακόμα. Ως αποτέλεσμα αυτού, αυτήν την περίοδο, υπάρχει αριθμός από διαδικασίες διαθέσιμες στον επαγγελματία για να επιλέξει αυτή που θα φέρει το μέγιστο όφελος σε δεδομένες περιστάσεις. Ο στόχος της παρούσας εργασίας είναι να μελετήσει την υπάρχουσα βιβλιογραφία για τις ευέλικτες μεθοδολογίες ανάπτυξης λογισμικού. Αρχικά θα παρουσιαστούν κάποιες παραδοσιακές μεθοδολογίες στις οποίες βασίζονται οι νέες ευέλικτες μέθοδοι. Στη συνέχεια οι περισσότερες από τις υπάρχουσες ευέλικτες 2

μεθοδολογίες θα καθοριστούν και θα ταξινομηθούν περιγράφοντας για καθεμίαν τις διαδικασίες, τους ρόλους και τις πρακτικές που τη χαρακτηρίζουν. Οι προκλήσεις για την εφαρμογή των πρακτικών αυτών συζητούνται στο τρίτο τμήμα της μελέτης αυτής. Τέλος παρατίθενται οι εμπειρίες και συνοψίζονται τα ευρήματα των εταιριών που εφάρμοσαν κάποια από τις ευέλικτες πρακτικές 3

2. Μεθοδολογίες Ανάπτυξης Λογισμικού Η «μεθοδολογία ανάπτυξης λογισμικού» ή «η μεθοδολογία ανάπτυξης πληροφοριακών συστημάτων» στην επιστήμη των ηλεκτρονικών υπολογιστών είναι το μοντέλο που χρησιμοποιείται για να δομηθεί, να προγραμματιστεί, και να ελέχθη η διαδικασία της παραγωγής ενός λογισμικού Μια ευρεία ποικιλία τέτοιων μοντέλων έχει εξελιχθεί, το κάθε ένα με αναγνωρισμένες δυνάμεις και αδυναμίες. Μια μεθοδολογία ανάπτυξης λογισμικού δεν είναι απαραιτήτως κατάλληλη προς χρήση για κάθε δυνατό έργο. Κάθε μια από τις διαθέσιμες μεθοδολογίες είναι η καταλληλότερη για ένα συγκεκριμένο είδος προγράμματος, ανάλογα με τα διαφορετικά τεχνικά και οργανωτικά χαρακτηριστικά κάθε ομάδας και κάθε έργου. Το μοντέλο μιας μεθοδολογίας ανάπτυξης λογισμικού αποτελείται από: Μια φιλοσοφία ανάπτυξης λογισμικού, με την προσέγγιση ή τις προσεγγίσεις στη διαδικασία ανάπτυξης λογισμικού Πολλαπλά εργαλεία, μοντέλα και μεθόδους, για να βοηθήσουν στη διαδικασία ανάπτυξης λογισμικού. Αυτά τα μοντέλα είναι συχνά συνδεδεμένα με κάποια οργανισμό, o οποίος τα αναπτύσσει περαιτέρω, υποστηρίζει τη χρήση τους και προωθεί τη μεθοδολογία. Η μεθοδολογία είναι συχνά τεκμηριωμένη με κάποια επίσημη μορφή. Ένα από τα παλαιότερα εργαλεία ανάπτυξης λογισμικού είναι τα λογικά διαγράμματα, τα οποία αναπτύχθηκαν τη δεκαετία του '20. Η μεθοδολογία ανάπτυξης λογισμικού εμφανίστηκε στο προσκήνιο τη δεκαετία του '60. Η παλαιότερη τυποποιημένη μεθοδολογία για την δημιουργία των πληροφοριακών συστημάτων είναι ο κύκλος ζωής ανάπτυξης συστημάτων ( Software Development Life Cycle SDLC). Η κύρια ιδέα ήταν να ακολουθήσει η ανάπτυξη των συστημάτων πληροφοριών έναν προμελετημένο, δομημένο και συστηματικό τρόπο. Ο παραδοσιακός κύκλος ζωής ανάπτυξης συστημάτων δημιουργήθηκε στη δεκαετία του '60 για να αναπτύξει τα λειτουργικά επιχειρησιακά συστήματα μεγάλης κλίμακας. Οι 4

δραστηριότητες συστημάτων πληροφοριών περιελάμβαναν τότε βαριές ρουτίνες επεξεργασίας δεδομένων. όπως : Από τότε διάφορες μεθοδολογίες ανάπτυξης λογισμικού έχουν αναπτυχθεί, Δομημένος προγραμματισμός από το 1969 Δομημένη ανάλυση συστημάτων και μεθοδολογία σχεδιασμού (Structured Systems Analysis and Design Methodology, SSADM) από το 1980 και μετά Ο αντικειμενοστραφής προγραμματισμός (Object-oriented programming, OOP) έχει αναπτυχθεί από την αρχή της δεκαετίας του '60, και έχει επικρατήσει ως κυρίαρχη μεθοδολογία προγραμματισμού κατά τη διάρκεια τα μέσα της δεκαετίας του '90. Γρήγορη ανάπτυξη εφαρμογών (Rapid application development, RAD) από 1991, Scrum (ανάπτυξη), από την πρόσφατη δεκαετία του '90 Διαδικασία λογισμικού ομάδας (Team software process)που αναπτύσσεται από τον Watt Humphrey στο SEI 1 Ακραίος προγραμματισμός (Extreme Programming,XP) από το 1999 Λογική ενοποιημένη διαδικασία (Rational Unified Process, RUP) από 2003, Ευέλικτη ενοποιημένη διαδικασία (Agile Unified Process, AUP) από το 2005 από Scott Ambler Κάθε μεθοδολογία ανάπτυξης λογισμικού έχει λίγο πολύ τη δική της προσέγγιση στην ανάπτυξη λογισμικού. Υπάρχει ένα σύνολο γενικότερων προσεγγίσεων, οι οποίες αναπτύσσονται σε διάφορες συγκεκριμένες μεθοδολογίες. Αυτές οι προσεγγίσεις είναι: O καταρράκτης (Waterfall): γραμμικός τύπος μοντέλου. Η διαμόρφωση πρωτοτύπου (Prototyping): επαναληπτικός τύπος μοντέλου Ο επαυξητικός (Incremental): συνδυασμός γραμμικού και επαναληπτικού τύπου μοντέλου Η σπειροειδής (Spiral): γραμμικός και επαναληπτικός τύπος πλαισίου μοντέλου 1 Software Enginnerring Instutute 5

Γρήγορη ανάπτυξη εφαρμογής( Rapid Application Development RAD): Επαναληπτικός τύπος μοντέλου Με σκοπό την καλύτερη κατανόηση των ευέλικτων μεθόδων στα επόμενα κεφάλαια δίνεται μια σύντομη περιγραφή των πέντε αυτών βασικών προσεγγίσεων. Αυτές πολλές φορές χρησιμοποιούνται ως βάση αναφοράς για τις ευέλικτες μεθοδολογίες. Για παράδειγμα η «Μέθοδος ανάπτυξης δυναμικών συστημάτων» βασίζεται στην γρήγορη ανάπτυξη εφαρμογής. Οι περισσότερες από τις ευέλικτες μεθόδους επιτρέπουν ή και προτείνουν την διαμόρφωση πρωτοτύπου σε κάποιο στάδιο τους, ενώ εξ ορισμού μια μέθοδος για να είναι «ευέλικτη» πρέπει να ακολουθεί έως ένα σημείο το επαυξητικό μοντέλο. Επιπλέον αναφέρονται και οι αναγνωρισμένες δυνάμεις και αδυναμίες των προσεγγίσεων αυτών καθώς αυτές τις δυνάμεις θέλουν να εκμεταλλευτούν και αυτές αδυναμίες ήρθαν να καλύψουν οι ευέλικτες μέθοδοι. Εξάλλου όπως υποστηρίζει ο «ακραίος προγραμματισμός», μια από τις ευέλικτες μεθοδολογίες, τα ευεργετικά στοιχεία των παραδοσιακών πρακτικών ανάπτυξής λογισμικού λαμβάνονται στα «ακραία» επίπεδα. 2.1 Το Μοντέλο του Καταρράκτη Το μοντέλο του καταρράκτη είναι μια διαδοχική διαδικασία ανάπτυξης, στην οποία η ανάπτυξη θεωρείται πως διατρέχει σταθερά προς τα κάτω (όπως σε έναν καταρράκτη) της φάσεις της ανάλυσης των απαιτήσεων (Requirements), του σχεδίου (Design), της εφαρμογής (Implementation), της επικύρωσης (Verification), της ολοκλήρωσης, και της συντήρησης (Maintenance). Στην Εικόνα 2.1 φαίνεται το μοντέλο του καταρράκτη και οι επιμέρους φάσεις του Η πρώτη επίσημη περιγραφή του προτύπου καταρρακτών θεωρείται ότι είναι ένα άρθρο που δημοσιεύτηκε από τον Winston W. Royce το 1970 αν και ο ιδιος ο Royce (1970) δεν χρησιμοποίησε τον όρο "καταρράκτης" σε αυτό το άρθρο. Για να ακολουθήσει κάποιος το πρότυπο του καταρράκτη, προχωρά από τη μια φάση στην επόμενη κατά τρόπο καθαρά διαδοχικό. Παραδείγματος χάριν, πρώτα ολοκληρώνονται οι προδιαγραφές των απαιτήσεων οι οποίες δεν τίθενται σε 6

περαιτέρω διαπραγματεύσεις. Όταν οι απαιτήσεις ολοκληρώνονται πλήρως, προχωρούμε με την σχεδίαση του συστήματος. Το εν λόγω λογισμικό σχεδιάζεται και ένα προσχέδιο του δίνεται στους προγραμματιστές για να το ακολουθούν - αυτό το προσχέδιο πρέπει να είναι ένα σχέδιο για την εφαρμογή των απαιτήσεων που έχουν ήδη παγιωθεί. Όταν το σχέδιο ολοκληρώνεται πλήρως, μια εφαρμογή του σχεδίου γίνεται από τους προγραμματιστές. Προς τα τελευταία στάδια της φάσης εφαρμογής, τα χωριστά τμήματα λογισμικού συνδυάζονται για να ολοκληρωθεί η νέα λειτουργία. Το πρότυπο του καταρράκτη υποστηρίζει ότι κάποιος μπορεί να κινηθεί προς μια φάση μόνο όταν ολοκληρώνεται η προηγούμενη φάση της. Εικόνα 2.1-Το μοντέλο του καταρράκτη (Πηγή: Wikipedia, Paul Smith,2009) Συμφώνα με τις βασικές αρχές του μοντέλου κάθε έργο διαιρείται σε διαδοχικές φάσεις, με κάποια επικάλυψη και κάποιες αναθεωρήσεις να είναι αποδεκτές μεταξύ των φάσεων. Έμφαση δίνεται στον προγραμματισμό, στα χρονικά προγράμματα, τις προβλεπόμενες ημερομηνίες, τους προϋπολογισμούς και την δημιουργία ενός ολόκληρου συστήματος συγχρόνως. Ο αυστηρός έλεγχος διατηρείται κατά τη διάρκεια της ζωής του προγράμματος μέσω της χρήσης εκτενούς γραπτής τεκμηρίωσης, καθώς επίσης και μέσω των επίσημων αναθεωρήσεων που έχουν την έγκριση του πελάτη. 7

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

2.2 To Μοντέλο της Δημιουργίας Πρωτότυπου Το μοντέλο δημιουργίας πρωτότυπων είναι μια τεχνική ανάπτυξης λογισμικού κατά την οποία δημιουργούνται ελλιπείς εκδόσεις του συνολικού προγράμματος που θα αναπτυχθεί. Ένα πρωτότυπο μιμείται τα χαρακτηριστικά, μερικές πτυχές των χαρακτηριστικών γνωρισμάτων του ενδεχόμενου προγράμματος, και μπορεί να είναι απολύτως διαφορετικό από την τελική εφαρμογή. Ο συμβατικός σκοπός ενός πρωτοτύπου είναι να επιτραπεί στους χρήστες του λογισμικού να αξιολογήσουν τις προτάσεις των υπεύθυνων για την ανάπτυξη με το να δοκιμάζουν στην πράξη ένα προσχέδιο του προϊόντος, παρά να πρέπει να ερμηνεύσουν και να αξιολογήσουν ένα σχέδιο βασισμένο στις περιγραφές. Η διαμόρφωση πρωτοτύπου μπορεί επίσης να χρησιμοποιηθεί από τους τελικούς χρήστες για να περιγράψουν τις απαιτήσεις που οι υπεύθυνοι για την ανάπτυξη δεν έχουν εξετάσει, έτσι «ο έλεγχος του πρωτοτύπου» μπορεί να είναι ένας βασικός παράγοντας στην εμπορική σχέση μεταξύ των προμηθευτών της λύσης και των πελατών τους. Στο μοντέλο της δημιουργίας πρωτοτύπου μετά την αρχική διεύρυνση ξεκινά ένας κύκλος προσδιορισμού των προδιαγραφών,σχεδιασμού του συστήματος, κωδικοποίησης και δοκιμών κατά τον οποίο δημιουργείται το πρωτότυπο. Μετά την δημιουργία και την αξιολόγηση του πρωτοτύπου υλοποιείται το λογισμικό. Στην τελευταία φάση μένει μόνο η συντήρηση του λογισμικού. Για πολλούς η δημιουργία πρωτοτύπων δεν είναι μια αυτόνομη, πλήρης μεθοδολογία ανάπτυξης, αλλά μάλλον μια προσέγγιση στο χειρισμό επιλεγμένων τμημάτων μιας μεγαλύτερης, παραδοσιακότερης μεθοδολογίας ανάπτυξης όπως η επαυξητική, ή σπειροειδής. Στην ανάπτυξη λογισμικού με αυτή την μέθοδο γίνονται προσπάθειες να μειωθεί ο εγγενής κίνδυνος ενός έργου με το σπάσιμο του σε μικρότερα τμήματα και την παροχή μεγαλύτερης προσαρμογής στην αλλαγή κατά τη διάρκεια της διαδικασίας ανάπτυξης. Επιπλέον ο χρήστης περιλαμβάνεται σε όλη τη διαδικασία ανάπτυξης, γεγονός που αυξάνει την πιθανότητα της αποδοχής της 9

τελικής εφαρμογής. Τα μικρής κλίμακας πρωτότυπα του συστήματος αναπτύσσονται μετά από μια επαναληπτική διαδικασία τροποποίησης έως ότου εξελίσσεται το πρωτότυπο για να καλύψει τις απαιτήσεις των χρηστών. Ενώ τα περισσότερα πρωτότυπα αναπτύσσονται με την προσδοκία ότι θα απορριφθούν, είναι δυνατό σε μερικές περιπτώσεις να εξελιχθεί από το πρωτότυπο το ίδιο το σύστημα εργασίας. Η μέθοδος της δημιουργίας πρωτοτύπων θεώρει βασική την κατανόηση του θεμελιώδους επιχειρησιακού προβλήματος για να αποφευχθεί η λύση του λανθασμένου προβλήματος. Δυνάμεις / Αδυναμίες Η μεθοδολογία αυτή είναι ιδιαίτερα χρήσιμη για την ανάπτυξη λογισμικού με ασαφείς στόχους, για τον σχεδιασμό και την επικύρωση των προδιαγραφών των χρηστών, για τον πειραματισμό με ή και την σύγκριση των διάφορων λύσεων του προσχεδίου. Ταυτόχρονα υπάρχει η δυνατότητα να χρησιμοποιηθεί η γνώση που αποκτήθηκε από το πρωτότυπο και στο καθαυτό προϊόν. Ακόμη μπορούν πολύ νωρίς στον κύκλο ζωής του προϊόντος να προσδιοριστούν τα στοιχεία εκείνα που δημιουργούν σύγχυση ή δυσκολίες στην λειτουργία. Το μοντέλο ανάπτυξης λογισμικού μέσω πρωτοτύπων ευνοεί δε την καινοτομία Βέβαια η διαδικασία παράγωγης του πρωτοτύπου, αλλά και η τελική έγκρισή του δεν είναι ένα αυστηρά καθορισμένο γεγονός που μπορεί να οδηγήσει σε μια πλειάδα προβλημάτων. Η ανεπαρκής ανάλυση του προβλήματος μπορεί να εμφανιστεί με συνέπεια να καλύπτονται μόνο οι επιφανειακές ανάγκες. Οι προδιαγραφές μπορεί να αλλάζουν συνεχώς και σε μεγάλο βαθμό. Οι σχεδιαστές του πρωτοτύπου μπορεί να παράγουν το πρωτότυπο πολύ γρήγορα, αλλά χωρίς την ανάλυση των αναγκών του χρήστη να καταλήγει σε ένα άκαμπτό σχέδιο με στενή εστίαση κάτι που θα περιορίζει την μελλοντική επέκταση του συστήματος. Επιπλέον οι σχεδιαστές μπορεί να παραμελήσουν την τεκμηρίωση με συνέπεια την ανεπαρκή αιτιολόγηση του τελικού προϊόντος και ανεπαρκή στοιχεία για το μέλλον. Ο σχεδιασμός λειτουργικού με βάση την μεθοδολογία του πρωτοτύπου μπορεί να οδηγήσει σε κακώς σχεδιασμένα συστήματα, καθώς ανειδίκευτοι σχεδιαστές μπορούν να αντικαταστήσουν την διαμόρφωση πρωτοτύπου με αυτό καθεαυτό το προϊόν δημιουργώντας έτσι ένα «βρώμικο» σύστημα χωρίς σφαιρική εκτίμηση όλων 10

των λειτουργιών. Ενώ η αρχική ανάπτυξη του πρωτοτύπου χτίζεται συχνά για να είναι αναλώσιμο, η προσπάθεια να παραχθεί αναδρομικά ένα ολοκληρωμένο σύστημα μπορεί μερικές φορές να είναι προβληματική. Επιπλέον ένα πρωτότυπο πορεί να οδηγήσει στις ψεύτικες προσδοκίες, όπου ο πελάτης εσφαλμένα θεωρεί ότι το σύστημα είναι τελειωμένο όταν στην πραγματικότητα δεν είναι. Οι επαναλήψεις μέχρι την τελική διαμόρφωση του προϊόντος προσθέτουν στους προϋπολογισμούς και στα προγράμματα, κατά συνέπεια οι προστιθέμενες δαπάνες πρέπει να σταθμιστούν ενάντια στα πιθανά οφέλη. Τα πολύ μικρά προγράμματα μπορούν να μην είναι σε θέση να δικαιολογήσουν τους προστιθέμενους χρόνους και τα χρήματα, ενώ μόνο τα υψηλού κινδύνου τμήματα των πολύ μεγάλων, σύνθετων προγραμμάτων ωφελούνται από τη διαμόρφωση πρωτοτύπου. 2.3 To Επαυξητικό Μοντελο Διάφορες μέθοδοι είναι αποδεκτές για το συνδυασμό των γραμμικών και επαναληπτικών μεθοδολογιών ανάπτυξης συστημάτων, με τον αρχικό στόχο κάθε μιας να μειωθεί ο έμφυτος κίνδυνος του προγράμματος με το σπάσιμο ενός προγράμματος στα μικρότερα τμήματα και την παροχή μεγαλύτερης ευκολίας αλλαγής κατά τη διάρκεια της διαδικασίας ανάπτυξης. Οι βασικές αρχές της επαυξητικής ανάπτυξης είναι: μια σειρά μίνι-καταρρακτών εκτελείται, όπου όλες οι φάσεις του προτύπου ανάπτυξης καταρρακτών ολοκληρώνονται για ένα μικρό μέρος του συστήματος, πριν προχωρήσει η ομάδα στην επόμενη επαύξηση, ή οι γενικές απαιτήσεις καθορίζονται έτσι ώστε να οδηγήσουν στην ανάπτυξη μίνι-καταρρακτών των μεμονωμένων αυξήσεων του συστήματος, ή 11

η αρχική σύλληψη του λογισμικού, η ανάλυση των απαιτήσεων, και ο κεντρικός σχεδιασμός του πυρήνα της αρχιτεκτονικής και του συστήματος καθορίζεται χρησιμοποιώντας την προσέγγιση καταρρακτών. Δυνάμεις / Αδυναμίες Ένα από τα δυνατά σημεία του επαυξητικού μοντέλου είναι ότι υπάρχει η δυνατότητα να εκμεταλλευθεί τη γνώση που αποκτιέται σε μια πρόωρη αύξηση στις επόμενες. Επιπλέον διατηρείται ο έλεγχος σε μέτρια επίπεδα κατά τη διάρκεια της ζωής του προγράμματος μέσω της χρήσης της γραπτής τεκμηρίωσης, της επίσημης αναθεώρησης και της έγκρισης του χρήστη και της διοίκησης σε ορισμένα σημαντικά κύρια σημεία. Στους συμμέτοχους του προγράμματος μπορούν να δοθούν τα συγκεκριμένα στοιχεία της κατάστασης προγράμματος σε όλο τον κύκλο ζωής του. Ακόμη βοηθά να μετριαστεί ο κίνδυνος από σφάλματα αρχιτεκτονικής αρκετά νωρίς. Ένα ακόμη σημείο που πλεονεκτεί το επαυξητικό μοντέλο είναι ότι επιτρέπει την παράδοση μιας σειράς εφαρμογών που είναι βαθμιαία πληρέστερες και μπορούν να πάνε στην παραγωγή γρηγορότερα ως επαυξητικές εκδόσεις. Τέλος η βαθμιαία εφαρμογή παρέχει τη δυνατότητα να ελεγχθεί η επίδραση των επαυξητικών αλλαγών, να απομονώσει τα ζητήματα και να διενεργηθούν οι προσαρμογές προτού τα λάθη να επιδράσουν αρνητικά στην επιχείρηση. Αντίθετα, κατά χρησιμοποίηση μιας σειράς μίνι-καταρρακτών για ένα μικρό μέρος του συστήματος πριν την επόμενη αύξηση, υπάρχει συνήθως η έλλειψη της γενικής εκτίμησης του επιχειρησιακού προβλήματος και των τεχνικών απαιτήσεων του συστήματος. Ακόμη με δεδομένο ότι μερικές ενότητες θα ολοκληρωθούν πολύ νωρίτερα από άλλες, απαιτείται να είναι καθορισμένες με σαφήνεια οι αλληλεξαρτήσεις του συστήματος πολύ νωρίς. Ένας τελευταίος κίνδυνος που παρουσιάζεται κατά την χρήση του επαυξητικού μοντέλου είναι ότι τα δύσκολα προβλήματα τείνουν να ωθηθούν στο τέλος του προγράμματος ώστε αρχικά να επιδεικνύεται προς την διοίκηση κάποια πρόοδος. 2.4 Το σπειροειδές μοντέλο 12

Το σπειροειδές πρότυπο καθορίστηκε από το Barry Boehm στο άρθρο του 1988 του "Ένα σπειροειδές πρότυπο της ανάπτυξης και βελτίωσης λογισμικού ". Αυτό το πρότυπο δεν ήταν το πρώτο πρότυπο που ανέφερε την επαναληπτική ανάπτυξη, αλλά ήταν το πρώτο πρότυπο για να εξηγήσει γιατί η επανάληψη κάνει τη διαφορά. Όπως αρχικά προέβλεπε, οι επαναλήψεις ήταν τυπικά της τάξης των 6 μηνών ή 2 ετών σε διάρκεια. Κάθε φάση αρχίζει με έναν στόχο σχεδίου και τελειώνει με τον πελάτη (που μπορεί να είναι εσωτερικός) να αναθεωρεί την πρόοδο. Η ανάλυση και η εφαρμογή γίνονται σε κάθε φάση του προγράμματος, με στόχο το τέλος του προγράμματος. Οι βασικές αρχές του μοντέλου είναι η εστίαση είναι στην αξιολόγηση του κινδύνου και στην ελαχιστοποίησή του στο πρόγραμμα, με το σπάσιμο ενός προγράμματος σε μικρότερα τμήματα και την παροχή περισσότερης ευκολίας αλλαγής κατά τη διάρκεια της διαδικασίας ανάπτυξης, καθώς επίσης και την παροχή της ευκαιρίας να αξιολογηθούν οι κίνδυνοι και να γίνει η εκτίμηση της συνέχειας προγράμματος σε όλο τον κύκλο ζωής του προϊόντος «Κάθε κύκλος περιλαμβάνει μια πρόοδο μέσω της ίδιας ακολουθίας βημάτων, για κάθε τμήμα του προϊόντος και για κάθε ένα από τα επίπεδα επεξεργασίας του, από ένα γενικό έγγραφο της επιθυμητής λειτουργίας έως την κωδικοποίηση κάθε μεμονωμένου προγράμματος.» (Boehm, 1988) Κάθε ταξίδι πάνω στη σπείρα διαπερνά τέσσερα βασικά τεταρτημόρια : 1. καθορίστε τους στόχους, τις εναλλακτικές λύσεις, και τους περιορισμούς της επανάληψης (Determine objectives) 2. αξιολογήστε τις εναλλακτικές λύσεις, προσδιορίστε και επιλύστε τους κινδύνους (Identify and resolve risks ) 3. αναπτύξτε και ελέγξτε τα προϊόντα της επανάληψης (Development and test) και 4. σχεδιάστε τη επόμενη επανάληψη (Plan the next iteration). (Boehm, 1988) 13

«Αρχίστε κάθε κύκλο με τον προσδιορισμό των συμμετεχόντων στο πρόγραμμα και των όρων επιτυχίας και τελειώστε κάθε κύκλο με την αναθεώρηση και την δέσμευση των συμμετεχόντων για τον επόμενο κύκλο. (Boehm, 1988) Εικόνα 2.2 Σπειροειδές πρότυπο (Boehm 1988) (Πηγή Wikipedia, Conrad Nutschan, 2007) Δυνάμεις / Αδυναμίες Στα θετικά του σπειροειδούς μοντέλου είναι ότι ενισχύει την αποφυγή του κινδύνου. Επιπλέον είναι χρήσιμο για την επιλογή της καλύτερης μεθοδολογίας που θα ακολουθεί κατά την ανάπτυξη μιας δεδομένης επανάληψης λογισμικού. Ακόμη μπορεί να ενσωματώσει το μοντέλο του καταρράκτη, τη διαμόρφωση πρωτοτύπου και τις επαυξητικές μεθοδολογίες ως ειδικές περιπτώσεις στο πλαίσιο του, και να παρέχει τις οδηγίες ως προς το ποιος συνδυασμός αυτών των προτύπων είναι ο καλύτερος να χρησιμοποιηθεί στη δεδομένη επανάληψη με βάση τον τύπο κινδύνου του προγράμματος. Παραδείγματος χάριν, ένα πρόγραμμα με χαμηλό κίνδυνο ως προς τις απαιτήσεις των χρηστών, αλλά με υψηλό κίνδυνο ως προς τον 14

προϋπολογισμό ή το χρονοδιάγραμμα θα ακολουθούσε ουσιαστικά μια προσέγγιση καταρρακτών στις επαναλήψεις του. Αν οι παράγοντες κινδύνου αντιστραφούν η σπειροειδής μεθοδολογία θα πρότεινε μια επαναληπτική προσέγγιση. Αντίθετα στο μοντέλο είναι ιδιαίτερα δύσκολο να καθοριστεί η ακριβής σύνθεση των μεθοδολογιών ανάπτυξης που χρησιμοποιούνται για κάθε επανάληψη γύρω από τη σπείρα. Επιπλέον είναι ιδιαίτερα προσαρμοσμένο σε κάθε πρόγραμμα, και είναι έτσι αρκετά σύνθετο, με περιορισμένη την ικανότητα επαναχρησιμοποίησης. Ένας ειδικευμένος και πεπειραμένος διευθυντής προγράμματος απαιτείται για να καθορίζει πώς το μοντέλο θα εφαρμοστεί σε οποιοδήποτε δεδομένο πρόγραμμα. Ακόμη δεν υπάρχει κανένας καθιερωμένος έλεγχος για την κίνηση από έναν κύκλο προς έναν άλλο κύκλο. Χωρίς ελέγχους, κάθε κύκλος μπορεί να παραγάγει περισσότερη εργασία για τον επόμενο κύκλο. Ένα τελευταίο μειονέκτημα είναι πως δεν υπάρχει καμία σταθερή προθεσμία. Οι κύκλοι συνεχίζονται χωρίς σαφή όριο λήξης, έτσι υπάρχει ένας έμφυτος κίνδυνος να ξεπεραστούν ο προϋπολογισμούς ή το χρονοδιάγραμμα. 2.5 Η Γρήγορη Ανάπτυξη Εφαρμογής Η γρήγορη ανάπτυξη εφαρμογής (Rapid Application Development, RAD) είναι μια μεθοδολογία ανάπτυξης λογισμικού, η οποία περιλαμβάνει την επαυξητική ανάπτυξη και την κατασκευή πρωτοτύπων. Η γρήγορη ανάπτυξη εφαρμογής είναι ένας όρος που χρησιμοποιήθηκε αρχικά για να περιγράψει μια διαδικασία ανάπτυξης λογισμικού που εισάγε κατά τη διάρκεια της δεκαετίας του '80 στην ΙΒΜ o James Martin και την τυποποίησε τελικά με την έκδοση ενός βιβλίου το 1991. είναι : Οι βασικές αρχές της μεθόδου όπως περιγράφονται από τον Martin (1991) Ο βασικός στόχος είναι η γρήγορη ανάπτυξη και παράδοση ενός υψηλής ποιότητας συστήματος με σχετικά χαμηλό κόστος. Προσπαθεί να μειωθεί ο εγγενής κίνδυνος του προγράμματος με το σπάσιμο του σε μικρότερα τμήματα και την παροχή μεγαλύτερης ευκολίας για αλλαγή κατά τη διάρκεια της διαδικασίας ανάπτυξης. 15

Στοχεύει να παραγάγει υψηλής ποιότητας συστήματα γρήγορα, πρώτιστα μέσω της χρήσης της επαναληπτικής διαμόρφωσης πρωτοτύπου (σε οποιοδήποτε στάδιο ανάπτυξης), της ενεργού συμμετοχής των χρηστών, και των αυτοματοποιημένων εργαλείων ανάπτυξης. Έμφαση δίνεται στην πραγματοποίηση των επιχειρησιακών αναγκών, ενώ η τεχνολογική τελειότητα είναι μικρότερης σπουδαιότητας. Ο έλεγχος δίνει προτεραιότητα στην ανάπτυξη και τον καθορισμό των προθεσμιών παράδοσης ή των χρονικών περιθωρίων. Εάν το πρόγραμμα αρχίζει να ολισθαίνει, έμφαση δίνεται είναι στη μείωση των απαιτήσεων για να χωρέσουν στα χρονικά περιθώρια και όχι στην μετακίνηση της προθεσμίας. Γενικά περιλαμβάνει την από κοινού ανάπτυξη εφαρμογής (Joint Application Development JAD), όπου οι χρήστες περικλείονται έντονα στο σχεδιασμό συστημάτων. Η ενεργός συμμετοχή χρηστών είναι επιτακτική. Παράγει επαναληπτικά το λογισμικό, σε αντιδιαστολή με την χρήση ενός πρωτότυπου που δεν χρησιμοποιείται Παράγει την τεκμηρίωση απαραίτητη να διευκολύνει τη μελλοντική ανάπτυξη και τη συντήρηση. Οι τυποποιημένες τεχνικές ανάλυσης και σχεδιασμού συστημάτων μπορούν να εναρμονιστούν σε αυτό το μοντέλο. Δυνάμεις / Αδυναμίες Στα πλεονεκτήματα του μοντέλου είναι ότι η λειτουργική έκδοση μιας εφαρμογής είναι διαθέσιμη πολύ νωρίτερα απ' ότι στα υπόλοιπα πλαίσια. Επειδή το RAD παράγει τα συστήματα γρηγορότερα και με μια επιχειρησιακή εστίαση, αυτή η προσέγγιση τείνει να παραγάγει τα συστήματα σε χαμηλότερο κόστος. Ακόμη προκαλεί ένα μεγαλύτερο επίπεδο υποχρέωσης από τους συμμέτοχους του προγράμματος, και επιχειρησιακό και τεχνικό, από ότι το μοντέλο της σπείρας του καταρράκτη ή το επαυξητικό. Οι χρήστες θεωρούν πως κερδίζουν περισσότερα, έχοντας ένα αίσθημα ιδιοκτησίας του συστήματος, ενώ οι υπεύθυνοι για την ανάπτυξη θεωρούν πως κερδίζουν περισσότερη ικανοποίηση με το να παραγάγουν 16

επιτυχή συστήματα γρήγορα. Το μοντέλο επικεντρώνεται στα απαραίτητα στοιχεία συστημάτων από την άποψη χρηστών και παρέχει τη δυνατότητα να αλλαχτεί γρήγορα το σχέδιο του συστήματος όπως απαιτείται από τους χρήστες. Επιπλέον παράγει μια πιο στενή σχέση μεταξύ των απαιτήσεων των χρηστών και των προδιαγραφών των συστημάτων αποφεύγοντας έτσι τα περιττά στοιχεία. Γενικά παράγει δραματική αποταμίευση σε χρόνο, σε χρήματα, και σε ανθρώπινη προσπάθεια. Βέβαια η μεγαλύτερη ταχύτητα και το χαμηλότερο κόστος μπορεί να οδηγήσουν σε χαμηλότερης ποιότητας συστήματα. Υπάρχει πάντα ο κίνδυνος της μη ευθυγράμμισης του αναπτυγμένου συστήματος με την επιχείρηση λόγω της απώλειας των πληροφοριών και το πρόγραμμα μπορεί να καταλήξει με περισσότερες απαιτήσεις από ήταν απαιτημένες. Το μοντέλο μειονεκτεί καθώς μπορεί να δημιουργηθούν ασυμβίβαστα σχέδια μέσα και στα συστήματα. Επιπλέον υπάρχει η δυνατότητα για την παραβίαση των προτύπων του προγραμματισμού. Πολλές φορές εμφανίζεται δυσκολία στην επαναχρησιμοποίηση τμημάτων σε μελλοντικά συστήματα. Καθώς επίσης το σχεδιασμένο σύστημα μπορεί να στερηθεί της εξελισιμότητας. Ακόμη παρουσιάζεται υψηλό το κόστος των υποχρεώσεων εκ μέρους του βασικού χρήστη. Φυσικά οι επίσημες αναθεωρήσεις και οι λογιστικοί έλεγχοι είναι δυσκολότερο να εφαρμοστούν απ' ότι σε ένα το πλήρες σύστημα Εμφανίζεται δε η τάση τα δύσκολα προβλήματα να ωθούνται στο μέλλον για να επιδεικνύεται πρόωρη επιτυχία στη διοίκηση. Τέλος δεδομένου ότι μερικές ενότητες θα ολοκληρωθούν πολύ νωρίτερα από άλλες, οι διεπαφές απαιτείται να είναι καθορισμένες με σαφήνεια εξ αρχής. 17

3. Ευέλικτη Ανάπτυξη Λογισμικού Οι ευέλικτες μεθοδολογίες ανάπτυξης λογισμικού είναι ένας σχετικά πρόσφατος τομέας στην ανάπτυξη λογισμικού. Ουσιαστικά, ο όρος ευέλικτη ανάπτυξη παρέχει την μια εννοιολογική «ομπρέλα» για έναν αριθμό μεθοδολογιών. Οι μεθοδολογίες αυτές δεν δημιουργήθηκαν πρώτα σε θεωρητικό επίπεδο, αλλά αναδύθηκαν μέσα από τον πειραματισμό των εταιριών ώστε να καλύψουν κάποιες εταιρικές ανάγκες Οι μικρές επιχειρήσεις παρουσιάζουν ενδιαφέρον για τις ευέλικτες μεθόδους επειδή αναζητούν τις εναλλακτικές λύσεις στις παραδοσιακές μεθοδολογίες ανάπτυξης λογισμικού, τις οποίες βρίσκουν πάρα πολύ δυσκίνητες, γραφειοκρατικές, και άκαμπτες. Αισθάνονται επίσης την πίεση να παράγουν περισσότερα με χαμηλότερο κόστος. Οι ίδιες ανάγκες, όμως, οδηγούν και τις μεγάλες επιχειρήσεις. Μια ομάδα στη Motorola προσδιόρισε μια ανάγκη κοινή σε όλες τις οργανώσεις και σε αυτήν την μελέτη παρατήρησαν ότι: «Οι ομάδες ανάπτυξης λογισμικού αντιμετωπίζουν μια συνεχή μάχη για να αυξήσουν την παραγωγικότητα διατηρώντας ή βελτιώνοντας την ποιότητα.» ( J. Bowers et al, 2002). Αυτό είναι πράγματι που οδηγεί τις περισσότερες επιχειρήσεις για να ψάξουν νέους τρόπους για να αναπτυχθεί το λογισμικό. Τα προβλήματα σχετικά με τις απαιτήσεις παρείχαν μια άλλη κοινή ανάγκη, και οι υπεύθυνοι για την ανάπτυξη σε τέσσερις μεγάλες εταιρίες, ABB, DaimlerChrysler, Motorola και Nokia (A. Domingo et. al, 2004) τα προσδιόρισαν ως ισχυρό κίνητρο. Παραδείγματος χάριν, επειδή οι ορισμένες ημερομηνίες παράδοσης απαιτούν ότι η ανάπτυξη λογισμικού θα αρχίζει με καθορισμένο μόνο ένα τμήμα των απαιτήσεων, η εταιρία πρέπει να ψάξει τους καλύτερους τρόπους για να διαχειριστεί τα προγράμματα για τα οποία οι απαιτήσεις δεν έχουν οριστεί πλήρως. Ένα άλλο πρόβλημα προκύπτει όταν οι απαιτήσεις μεταβιβάζονται στην ομάδα ανάπτυξης σε υψηλό επίπεδο. Αυτό μπορεί να καταστήσει δύσκολη την ανάλυση των απαιτήσεων σε λεπτομερείς προδιαγραφές λογισμικού. Αυτό το πρόβλημα οδηγεί την οργάνωση για να βρει τους τρόπους ώστε να γίνονται καλύτερα κατανοητές οι πραγματικές 18

ανάγκες των τελικών χρηστών. Επιπλέον, η εργασία για τον ορισμό των προδιαγραφών είναι ιδιαίτερα χρονοβόρα και οι προδιαγραφές καταλήγουν συχνά να είναι ξεπερασμένες όταν πλέον οριστικοποιούνται. Εκτός από τα προβλήματα που συνδέονται με τις ανεπαρκώς καθορισμένες και υψηλού επιπέδου προδιαγραφές, οι γρήγορες αλλαγές στις απαιτήσεις και άλλοι περιβαλλοντικοί παράγοντες οδηγούν στην ανάγκη οι εταιρίες να προσαρμόζονται γρήγορα για να συμβαδίσουν με τις εξελισσόμενες αγορές και τις τεχνολογίες. Αυτό οδηγεί τις οργανώσεις για να επιδιώκουν μια ευέλικτη διαδικασία ικανή να χειρίζεται ασταθείς απαιτήσεις. Η ανάγκη να παρουσιαστεί πρόοδος πρόωρα στον πελάτη και να παρουσιαστεί στην ανώτερη διοίκηση μια πρώτη έκδοση προωθεί επίσης την χρήση των ευέλικτων μεθόδων αυτήν την συμπεριφορά. Ενώ οποιαδήποτε οργάνωση που αναπτύσσει λογισμικό μπορεί να αντιμετωπίσει αυτά τα προβλήματα, μερικά είναι πιθανότερο να εμφανιστούν στις μεγάλες οργανώσεις. Παραδείγματος χάριν, μερικοί συμμετέχοντες στην μελέτη που έγινε το 2004 (A. Domingo et. al, 2004) εξέθεσαν την απογοήτευσή τους με τις δύσκολες προσεγγίσεις στη διαδικασία και τα τρέχοντα ποιοτικά συστήματα που είναι πάρα πολύ γενικά και σύνθετα για να παρέχουν καλή υποστήριξη. Οι μεγάλες οργανώσεις είναι πιθανότερο να εφαρμόζουν καθορισμένες διαδικασίες ανάπτυξης, συμπεριλαμβανομένου ενός συστήματος για την ποιότητα σε όλη τη διαδικασία ανάπτυξης λογισμικού. Αυτές οι διαδικασίες και τα συστήματα βάζουν συχνά περιορισμούς στην ομάδα ανάπτυξης γεγονός που περιορίζει ποιες πρακτικές ανάπτυξης μπορούν και πρέπει να χρησιμοποιήσουν, κάτι που έχει επιπτώσεις στο πόσο γρήγορα μπορούν να αναπτύξουν το λογισμικό. Όταν μια ομάδα παραγωγής λογισμικού πιέζεται για να παραδώσει γρήγορα ένα προϊόν ώστε να προλάβει μια ευκαιρία της αγοράς, πρέπει να παλέψει ταυτόχρονα δύο μάχες η μια για να αναπτύξουν ένα προϊόν σε σύντομο χρονικό διάστημα και η άλλη για να ικανοποιήσει τις απαιτήσεις του συστήματος ποιότητας. Η εύρεση των εναλλακτικών τρόπων να αναπτυχθεί το λογισμικό γρηγορότερα και πιο ελαστικά χωρίς συμβιβασμό των προτύπων υψηλής ποιότητας αυτών των οργανώσεων γίνεται πλέον έτσι ουσιαστική. Οι ευέλικτες μέθοδοι ήρθαν να καλύψουν όλες αυτές τις απαιτήσεις των εταιριών. Προσφέρουν την ευκαιρία να παραδίδει μια εταιρία πιο γρήγορα το προϊόν 19

της στους πελάτες της, να εκμεταλλεύεται τις ευκαιρίες τις αγοράς, να ανταποκρίνεται πιο γρήγορα στις αλλαγές του περιβάλλοντος και στις αλλαγές των απαιτήσεων των πελατών. Ακόμη οι ευέλικτες μέθοδοι επιτρέπουν στους εργαζόμενους να απομακρύνουν όλα τα περιττά τμήματα των διαδικασιών που δυσχεράνουν ή καθυστερούν την εργασία ους κάνοντάς τους πιο παραγωγικούς αλλά ταυτόχρονα μειώνοντας και τα περιττά κόστη. Οι ιδιότητες αυτές των ευέλικτων μοντέλων τα έκανε ιδιαίτερα δημοφιλή στους κόλπους της βιομηχανίας λογισμικού και κέρδισε το ενδιαφέρον τις επιστημονικής κοινότητας. Πολλά από αυτά τα μοντέλα έχουν πλέον τεκμηριωθεί, τα οποία παρουσιάζονται και συγκρίνονται στην συνέχεια αυτού του κεφαλαίου, αφού πρώτα δοθούν οι βασικές αρχές που κάνουν μια μέθοδο ευέλικτη. 3.1 Το Μανιφέστο των Ευέλικτων Μεθοδολογιών Ανάπτυξης Λογισμικού Το Φεβρουάριο του 2001, 17 άτομα μεταξύ των οποίων εμπειρογνώμονες της ανάπτυξης λογισμικού και σύμβουλοι επιχειρήσεων παράγωγης λογισμικού, μαζεύτηκαν στη Utah των Ηνωμένων Πολιτειών της Αμερικής για να συζητήσουν το μέλλον της ανάπτυξης λογισμικού. Αποτέλεσμα αυτών των συζητήσεων ήταν η διατύπωση του «Ευέλικτου Μανιφέστο» 2 και ο σχηματισμός της «Ευέλικτης Συμμαχίας». To μανιφέστο για την ευέλικτη ανάπτυξη λογισμικού (Agile Software Development) δηλώνει: «Ανακαλύπτουμε καλύτερους τρόπους ανάπτυξης λογισμικού με το να αναπτύσσουμε λογισμικό αλλά και με το να βοηθούμε άλλους που κάνουν το ίδιο. Μέσω αυτής της εργασίας έχουμε καταλήξει στο να εκτιμούμε περισσότερο: τα άτομα και τις αλληλεπιδράσεις από τις διαδικασίες και τα εργαλεία το εν λειτουργία λογισμικό από την περιεκτική τεκμηρίωσή του 2 http://agilemanifesto.org/ 20

την συνεργασία με τους πελάτες από τη διαπραγμάτευση συμβάσεων/ συμβολαίων την ανταπόκριση στην αλλαγή από την εκτέλεση ενός σχεδίου Αυτό που εννοούμε είναι ότι ενώ υπάρχει αξία στα στοιχεία στο δεξί μέρος των παραπάνω προτάσεων εκτιμούμε τα στοιχεία στο αριστερό περισσότερο.» (Beck et al.,2003) Αρχικά, το ευέλικτο μοντέλο υπογραμμίζει την αλληλεγγύη μεταξύ των υπευθύνων για την ανάπτυξη λογισμικού και το ανθρώπινο ρόλο που απεικονίζουν οι συμβάσεις, σε αντιδιαστολή με τις θεσμοποιημένες διαδικασίες και τα εργαλεία ανάπτυξης. Στις υπάρχουσες ευέλικτες πρακτικές, αυτό φανερώνεται στις στενές σχέσεις των ομάδων, στο στενό εργασιακό περιβάλλον, στις ρυθμίσεις και τις άλλες διαδικασίες που προωθούν το ομαδικό πνεύμα. Δεύτερον, το μανιφέστο υποστηρίζει πως ο πρωταρχικός στόχος της ομάδας είναι να παράγει συνεχώς δοκιμασμένο, λειτουργικό λογισμικό. Οι νέες εκδόσεις του λογισμικού παράγονται ανά τακτά διαστήματα, σε μερικές προσεγγίσεις ακόμα και ανά μία ώρα ή καθημερινά, αλλά η πιο συνήθης πρακτική είναι διμηνιαία ή μηνιαία. Οι υπεύθυνοι για την ανάπτυξη ωθούνται για να κρατήσουν τον κώδικα απλό, εύκολα αναγνώσιμο, και όσο πιο τεχνικά προηγμένο γίνεται, ελαττώνοντας κατά συνέπεια το φορτίο της τεκμηρίωσης σε ένα κατάλληλο επίπεδο. Τρίτον, η σχέση και η συνεργασία μεταξύ των υπεύθυνων για την ανάπτυξη και των πελατών είναι προτιμητέα σε σύγκριση με τις ακριβείς συμβάσεις, αν και η σημασία μιας καλώς σχεδιασμένης σύμβασης αυξάνεται αναλογικά με το μέγεθος του λογισμικού. Η ίδια η διαδικασία διαπραγμάτευσης πρέπει να εξεταστεί ως μέσο επίτευξης και διατήρησης μιας βιώσιμης σχέσης. Από επιχειρηματικής άποψης, η ανάπτυξη λογισμικού εστιάζει στο να παραδίδεται αξία αμέσως στο έργο από την στιγμή της έναρξής του, μειώνοντας κατά συνέπεια τους κινδύνους μησυμμόρφωσης με τη σύμβαση. Τέταρτον, η ομάδα ανάπτυξης, που περιλαμβάνει και τους υπεύθυνους για την ανάπτυξη λογισμικού και τους αντιπρόσωπους των πελατών, πρέπει να καλά πληροφορημένοι, ικανοί και εξουσιοδοτημένοι να εξετάζουν τις πιθανές ανάγκες που 21

προκύπτουν κατά τη διάρκεια του κύκλου ζωής της διαδικασίας ανάπτυξης και να την αναδιαμορφώνουν αντίστοιχα. Αυτό σημαίνει ότι οι συμμετέχοντες πρέπει να είναι έτοιμοι να κάνουν τις αλλαγές και ότι επίσης οι υπάρχουσες συμβάσεις διαμορφώνονται με τέτοια εργαλεία ώστε να μπορούν να υποστηρίζουν και να επιτρέπουν τις αλλαγές. 3.2 Οι Αρχές του Ευέλικτου Μανιφέστο Στη συνέχεια παρουσιάζονται οι αρχές του ευέλικτου μανιφέστο όπως αυτές διατυπώθηκαν από τους δημιουργούς του. «Ακολουθούμε αυτές τις αρχές: 1. Η πιο υψηλή προτεραιότητά μας είναι να ικανοποιήσουμε τον πελάτη μέσω της γρήγορης και συνεχούς παράδοσης του «πολύτιμου» λογισμικού. 2. Καλωσορίζομε τις μεταβαλλόμενες απαιτήσεις / προδιαγραφές ακόμη και αν αυτές φτάσουν αργά. Οι ευέλικτες διαδικασίες τιθασεύουν την αλλαγή δημιουργώντας ανταγωνιστικό πλεονέκτημα για τον πελάτη. 3. Παραδώστε λειτουργικό λογισμικό συχνά, μέσα σε μια δυο εβδομάδες ή σε ένα δυο μήνες, με προτίμηση στο πιο σύντομο χρονοδιάγραμμα. 4. Οι επιχειρησιακοί υπάλληλοι και οι προγραμματιστές πρέπει να λειτουργούν μαζί καθημερινά. 5. Δομήστε τα έργα γύρω από τα άτομα με ισχυρή υποκίνηση. Δώστε τους το περιβάλλον και την υποστήριξη που αυτοί χρειάζονται και τους εμπιστευθείτε τους πως θα εκπληρώσουν την δουλειά 6. Η αποδοτικότερη και αποτελεσματική μέθοδος για να μεταβιβάζονται οι πληροφορίες προς την ομάδα αλλά και μέσα σε αυτήν είναι οι κατ ιδίαν συνομιλίες. 7. Το εν λειτουργία λογισμικό είναι το πρωταρχικό μέτρο της προόδου. 8. Οι ευέλικτες διαδικασίες προωθούν τη βιώσιμη ανάπτυξη. Οι χορηγοί, οι υπεύθυνοι για την ανάπτυξη και οι χρήστες πρέπει να είναι σε θέση να διατηρούν έναν σταθερό ρυθμό επ αόριστο. 9. Η συνεχής προσοχή στην τεχνική τελειότητα και ο καλός σχεδιασμός ενισχύει την ευελιξία. 22

10. Η απλότητα -η τέχνη της μεγιστοποίησης του ποσού της εργασία που δεν γίνεται - είναι θεμελιώδης χαρακτηριστικό της ευελιξίας. 11. Οι καλύτερες αρχιτεκτονικές, απαιτήσεις/προδιαγραφές και σχέδια προκύπτουν από αυτορυθμιζόμενες ομάδες 12. Σε τακτά χρονικά διαστήματα, η ομάδα εξετάζει το πώς μπορεί να γίνει αποτελεσματικότερη, συντονίζει έπειτα και ρυθμίζει τη συμπεριφορά της αναλόγως.» (Beck et al.,2003) Οι αρχές ευέλικτου μοντέλου μπορούν να βρεθούν στην «λιτή παραγωγή» και τη μέθοδο των 6 Σίγμα. Αυτές οι έννοιες περιλαμβάνουν την εξάλειψη των λαθών, αποβάλλοντας τις περιττές διαδικασίες, δημιουργώντας μια σταθερή ροή, προσθέτοντας αξία στους πελάτες, και εξουσιοδοτώντας/ ενδυναμώνοντας τους εργαζομένους. Οι έννοιες αυτές πρώτη φορά συγχωνεύτηκαν σε μια μεθοδολογία στις 14 αρχές του «Τρόπου της TOYOTA», τη 5S μεθοδολογία, και τα 14 σημεία του Deming. Αυτές οι αρχές έχουν επίσης συνοψιστεί στα επτά σημεία της «λιτής» ανάπτυξης λογισμικού. 3.3 Ευέλικτες μεθοδολογίες ανάπτυξης Οι κύριες πτυχές των ευέλικτων μεθόδων είναι η απλότητα και η ταχύτητα. Σε ένα ευέλικτο έργο ανάπτυξης, η ομάδα επικεντρώνεται μόνο στις λειτουργίες που απαιτούνται παραδίδοντας αυτές γρήγορα, συλλέγοντας την ανατροφοδότηση και αντιδρώντας στις λαμβανόμενες πληροφορίες. Αυτό που κάνει μια μέθοδο ανάπτυξης λογισμικού ευέλικτη εν τέλει είναι όταν αυτή είναι επαυξητική (μικρές εκδόσεις λογισμικού, με γρήγορους κύκλους), συνεταιριστική (πελάτης και υπεύθυνοι για την ανάπτυξη που λειτουργούν συνεχώς μαζί με στενή επικοινωνία), απλή (η ίδια η μέθοδος είναι εύκολο να μαθευτεί και να τροποποιηθεί), και προσαρμοστική (ικανή να κάνει τις τελευταίες αλλαγές στιγμής). Με βάση τα παραπάνω κριτήρια,στα επόμενα κεφάλαια παρουσιάζονται οι πλέον διαδεδομένες ευέλικτες μεθοδολογίες - οι διαδικασίες, οι ρόλοι και οι πρακτικές τους. Αυτές είναι ο «Ακραίος Προγραμματισμός»- Extreme Programming (Beck 1999b), το Scrum (Schwaber 1995; Schwaber and Beedle 2002), οι 23

«Μεθοδολογίες Κρυστάλλου» -Crystal family of methodologies (Cockburn 2002a), η «Ανάπτυξη με βάση τα χαρακτηριστικά» -Feature Driven Development (Palmer and Felsing 2002), η «Μέθοδος ανάπτυξης δυναμικών συστημάτων»- Dynamic Systems Development Method (Stapleton 1997) και η «Εναρμονισμένη Ανάπτυξη Λογισμικού»- Adaptive Software Development (Highsmith 2000). Ευέλικτες Μέθοδοι Συστήματα ανοικτού πηγαίου κώδικα Μέθοδοι με βάση τον προγραμματισμό Υπεύθυνοι για την ανάπτυξη Ευκίνητοι, πεπειραμένοι, συστεγασμένοι και συνεργάσιμοι Γεωγραφικά διανεμημένες, συνεργάσιμες, πεπειραμένες και ευκίνητες ομάδες Προσανατολισμένοι στο σχέδιο με επαρκείς δεξιότητες και πρόσβαση στην εξωτερική γνώση Πελάτες Αφοσιωμένοι, πεπειραμένος, συστεγασμένοι, συνεργάσιμοι, αντιπροσωπευτικοί και εξουσιοδοτημένοι Αφοσιωμένοι, πεπειραμένος, συνεργάσιμοι, και εξουσιοδοτημένοι Πρόσβαση στους πεπειραμένους, συνεργάσιμους, αντιπροσωπευτικούς και εξουσιοδοτημένους πελάτες Απαιτήσεις Κατά ένα μεγάλο μέρος διαμορφούμενες, γρήγορες αλλαγές Κατά ένα μεγάλο μέρος διαμορφούμενες, γρήγορες αλλαγές συνεχώς εξελίσσονται ποτέ δεν οριστικοποιούνται Γνωστές πολύ νωρίς, κατά ένα μεγάλο μέρος σταθερές Αρχιτεκτονική Σχεδιασμένη για τις τρέχουσες απαιτήσεις Ανοικτή, σχεδιασμένη για τις τρέχουσες απαιτήσεις Σχεδιασμένη για τις τρέχουσες και προβλεπόμενες απαιτήσεις Αναδόμηση Ανέξοδη Ανέξοδη Ακριβή Μέγεθος Μικρότερες ομάδες και προϊόντα Μεγαλύτερες διασκορπισμένες ομάδες και μικρότερα προϊόντα Μεγαλύτερα ομάδες και προϊόντα Αρχικός στόχος Η απόκτηση αξίας γρήγορα Η επίλυση ενός προκλητικού προβλήματος Υψηλή ασφάλεια Πίνακας 3.1. Συγκριτικός πίνακας ευέλικτων και παραδοσιακών μεθόδων, επαυξημένος με στήλη για τα συστήματα ανοικτού πηγαίου κώδικα 24

Ο Boehm (2002) αναλύει τις ευέλικτες μεθοδολογίες σε αντιπαράθεση με τις μεθοδολογίες που βασίζονται στις διαδικασίες ή όπως τις αποκαλεί τις μεθοδολογίες που βασίζονται στον προγραμματισμό. Ο Πίνακας 3.1αναλύει κάποιους τομείς της ανάπτυξης λογισμικού και δείχνει πώς το μοντέλο των συστημάτων του ανοικτού πηγαίου κώδικα ( Open Source Systems, OSS) τοποθετείται μεταξύ των δυο προηγουμένων. Το μοντέλο του OSS είναι ακόμα αρκετά νέο στο επιχειρησιακό κόσμο. Η προσέγγιση OSS ωστόσο μπορεί να θεωρηθεί ως μια παραλλαγή των ευέλικτων μεθόδων και εδώ θα αναλυθεί ως τέτοια. 3.3.1 Ακραίος Προγραμματισμός (Extreme programming) Ο «ακραίος» προγραμματισμός (Extreme Programming, XP) είναι μια μεθοδολογία που προορίζεται να βελτιώσει την ποιότητα του λογισμικού και την ανταπόκρισή του στις μεταβαλλόμενες απαιτήσεις πελατών. Ως τύπος ευέλικτης ανάπτυξης λογισμικού, υποστηρίζει τις συχνές εκδόσεις, τους σύντομους κύκλους ανάπτυξης, με σκοπό να βελτιώσει την παραγωγικότητα και να εισαγάγει εκείνα τα σημεία ελέγχου στα οποία οι νέες απαιτήσεις των πελατών μπορούν να υιοθετηθούν. Αλλά στοιχεία του ακραίου προγραμματισμού είναι: ο προγραμματισμός ανά ζεύγη, η εκτενής αναθεώρηση του υπάρχοντος κώδικα, η δοκιμή όλου του κώδικα ανά μονάδα, η αναβολή του προγραμματισμού ορισμένων χαρακτηριστικών μέχρι αυτά να είναι απολύτως απαραίτητα, μια επίπεδη διοικητική δομή, η απλότητα και η σαφήνεια στον κώδικα, η πιθανότητα για αλλαγές των απαιτήσεων του πελάτη με το πέρασμα του χρόνου και όσο το πρόβλημα γίνεται καλυτέρα κατανοητό και η συχνή επικοινωνία μεταξύ πελάτη και προγραμματιστή. Η μεθοδολογία παίρνει το όνομά της από την ιδέα ότι τα ευεργετικά στοιχεία των παραδοσιακών πρακτικών ανάπτυξής λογισμικού λαμβάνονται στα «ακραία» επίπεδα, βασισμένο στη θεωρία ότι εάν κάτι είναι καλό, τότε πολύ περισσότερο από αυτό είναι ακόμη καλύτερο. Δεν πρέπει να συγχέεται βέβαια με τη «κωδικοποίηση καουμπόι», η οποία είναι περισσότερο ελεύθερη και μη σχεδιασμένη μορφή. Ακόμη δεν υποστηρίζει τα εξοντωτικά προγράμματα εργασιών, αλλά αντί αυτού την εργασία σε έναν σταθερό ρυθμό. 25