Εβδομάδα 3: Μεθοδολογίες ανάπτυξης λογισμικού

Σημειώσεις μελέτης βασισμένες στη Διάλεξη 3: «Μεθοδολογίες Ανάπτυξης». Οι διαφάνειες, με τα διαγράμματα των μοντέλων, βρίσκονται στο Moodle.

Την Εβδομάδα 1 είδαμε ότι η ανάπτυξη λογισμικού περνά από μια σειρά σταδίων. Αυτή την εβδομάδα βλέπουμε τους διαφορετικούς τρόπους να οργανωθούν αυτά τα στάδια: από τον αυστηρό καταρράκτη ως τις ευέλικτες (Agile) μεθοδολογίες.

Ο κύκλος ζωής ανάπτυξης λογισμικού

Όπως ένας βάτραχος περνά από αυγό σε γυρίνο και μετά σε βάτραχο, έτσι και το λογισμικό περνά από στάδια, από την πρώτη ιδέα ως την απόσυρσή του. Ο κύκλος ζωής ανάπτυξης λογισμικού (Software Development Life Cycle, SDLC) είναι αυτή η σειρά βημάτων. Τα μοντέλα διαφέρουν, αλλά σχεδόν όλα περιέχουν:

Χωρίς μοντέλο: «cowboy coding»

Η πιο απλή «μέθοδος» είναι να μην υπάρχει μέθοδος: γράφεις κώδικα όσο καλύτερα μπορείς και διορθώνεις τα σφάλματα όπως εμφανίζονται. Λέγεται cowboy coding. Ίσως αρκεί για ένα πολύ μικρό πρόγραμμα που γράφει ένας άνθρωπος για τον εαυτό του. Για οτιδήποτε μεγαλύτερο, ή με ομάδα και πελάτη, είναι συνταγή αποτυχίας.

Το μοντέλο του καταρράκτη (Waterfall)

Ο καταρράκτης ήταν το πρώτο μοντέλο SDLC, γι’ αυτό λέγεται και «κλασικό». Είναι γραμμικό και διαδοχικό: όπως το νερό ενός καταρράκτη δεν ανεβαίνει πίσω, έτσι κι εδώ κάθε στάδιο ολοκληρώνεται πριν αρχίσει το επόμενο, χωρίς επικαλύψεις. Λέγεται και BDUF (Big Design Up Front), γιατί ο σχεδιασμός τελειώνει πριν γραφτεί η πρώτη γραμμή κώδικα.

• Υπέρ: απλό στην κατανόηση και τη διαχείριση· κάθε στάδιο έχει σαφή παραδοτέα και προθεσμία, οπότε, θεωρητικά, το έργο παραδίδεται στην ώρα του.
• Κατά: δεν αφήνει περιθώριο για αναθεώρηση. Αν στις δοκιμές φανεί ότι κάτι δεν είχε σκεφτεί σωστά στην αρχή, η επιστροφή είναι δύσκολη και ακριβή. Όλα πρέπει να γίνουν σωστά με την πρώτη, και ο πελάτης βλέπει το προϊόν μόνο στο τέλος.

Ειρωνικά, το άρθρο του Winston Royce (1970), που θεωρείται η πρώτη περιγραφή του καταρράκτη, τον παρουσίαζε ως παράδειγμα μοντέλου που δεν δουλεύει.

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

Παραλλαγές του καταρράκτη

• Καταρράκτης με ανατροφοδότηση: επιτρέπει επιστροφή σε προηγούμενο στάδιο, π.χ. από τον σχεδιασμό στις απαιτήσεις. Όσο πιο πίσω όμως χρειάζεται να πας, τόσο πιο δύσκολο είναι.
• Αυξητικός καταρράκτης (πολλαπλοί καταρράκτες): το έργο γίνεται σε μια σειρά από μικρούς καταρράκτες. Ο καθένας παραδίδει μια λειτουργική προσαύξηση (increment) με περισσότερες δυνατότητες από την προηγούμενη. Μετά από μερικές προσαυξήσεις μπορεί να χρειαστεί μία που δεν προσθέτει λειτουργίες, αλλά αναδιαμορφώνει τον κώδικα (refactoring), ώστε οι επόμενες να γίνονται πιο εύκολα.

Το μοντέλο V

Το μοντέλο V είναι παραλλαγή του καταρράκτη που δίνει βάρος στις δοκιμές. Σχηματίζει ένα «V»:

• Η αριστερή πλευρά κατεβαίνει από τα γενικά στα λεπτομερή: απαιτήσεις, σχεδιασμός συστήματος, αρχιτεκτονική, σχεδιασμός μονάδων.
• Η δεξιά πλευρά ανεβαίνει, με δοκιμές σε όλο και μεγαλύτερα κομμάτια: δοκιμές μονάδων, ενοποίησης, συστήματος και αποδοχής από τον χρήστη.

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

Το σπειροειδές μοντέλο (Spiral)

Το σπειροειδές μοντέλο περιγράφηκε από τον Barry Boehm το 1986. Είναι επαναληπτικό και καθοδηγείται από τον κίνδυνο: το έργο προχωρά σε κύκλους, και κάθε κύκλος περνά από τέσσερις φάσεις:

1. ορισμός στόχων, εναλλακτικών λύσεων και περιορισμών·
2. αξιολόγηση των εναλλακτικών και ανάλυση κινδύνων, π.χ. με πρωτότυπα·
3. ανάπτυξη και έλεγχος του επόμενου κομματιού·
4. σχεδιασμός του επόμενου κύκλου.

• Υπέρ: οι κίνδυνοι εντοπίζονται και αντιμετωπίζονται νωρίς· προσαρμόζεται στις αλλαγές· έχει πολλά σημεία ελέγχου όπου παίρνονται αποφάσεις.
• Κατά: η ανάλυση κινδύνου θέλει εμπειρία και κοστίζει, οπότε δεν συμφέρει σε μικρά έργα· το μοντέλο είναι πιο σύνθετο στη διαχείριση.

Ταχεία ανάπτυξη εφαρμογών (RAD)

Η RAD (Rapid Application Development) εμφανίστηκε τη δεκαετία του ’80 και έγινε δημοφιλής τη δεκαετία του ’90, ως αντίδραση στην ακαμψία του καταρράκτη. Ένας από τους πρωτοπόρους της ήταν ο James Martin. Η βασική της ιδέα: τα πράγματα αλλάζουν πάντα. Οι ανάγκες του πελάτη, οι στόχοι της εταιρείας και ο ανταγωνισμός μπορεί να αλλάξουν πριν τελειώσει το έργο.

Μια ομάδα RAD είναι συνήθως μικρή (2–6 άτομα). Μαζεύει απαιτήσεις σε εργαστήρια με τον πελάτη, φτιάχνει γρήγορα πρωτότυπα που τα δοκιμάζει ο πελάτης, και δουλεύει σε σύντομες επαναλήψεις, από μία έως λίγες εβδομάδες.

• Υπέρ: ο πελάτης μπορεί να αλλάξει απαιτήσεις στην πορεία και δίνει συχνή ανατροφοδότηση· μικρότερος χρόνος ανάπτυξης· οι συνεχείς δοκιμές βελτιώνουν την ποιότητα.
• Κατά: δύσκολο σε μεγάλα έργα, λόγω της μικρής ομάδας· η ομάδα χρειάζεται έμπειρα μέλη· κοστίζει περισσότερο αν οι απαιτήσεις είναι ήδη γνωστές και σταθερές.

Ευέλικτες (Agile) μεθοδολογίες

Το Agile είναι περισσότερο ένα σύνολο αξιών και αρχών παρά ένα μοντέλο. Το Μανιφέστο για την Ευέλικτη Ανάπτυξη Λογισμικού (2001) δίνει τέσσερις αξίες:

• άνθρωποι και αλληλεπίδραση πάνω από διαδικασίες και εργαλεία·
• λογισμικό που λειτουργεί πάνω από εξαντλητική τεκμηρίωση·
• συνεργασία με τον πελάτη πάνω από διαπραγμάτευση συμβολαίων·
• ανταπόκριση στην αλλαγή πάνω από την προσήλωση σε ένα σχέδιο.

Το Agile δεν απορρίπτει τα δεύτερα· απλώς εκτιμά περισσότερο τα πρώτα. Από τις αρχές του ξεχωρίζουν: η ικανοποίηση του πελάτη με συχνή παράδοση λογισμικού που λειτουργεί, η αποδοχή αλλαγών ακόμη και αργά στο έργο, η καθημερινή συνεργασία με τον πελάτη, ένας σταθερός, βιώσιμος ρυθμός δουλειάς και η απλότητα.

Τρία παραδείγματα Agile μεθοδολογιών:

Extreme Programming (XP)

Το XP εστιάζει στον ίδιο τον προγραμματισμό. Ξεκίνησε ως απάντηση στους παραδοσιακούς ελέγχους κώδικα, που ήταν αργοί, σπάνιοι και γίνονταν πολύ μετά τη συγγραφή του κώδικα. Στο XP ο κώδικας ελέγχεται συνεχώς, κυρίως με τον προγραμματισμό σε ζευγάρια (pair programming): δύο άνθρωποι σε έναν υπολογιστή, όπου ο ένας γράφει και ο άλλος ελέγχει. Συνηθισμένες πρακτικές του είναι και οι δοκιμές πριν από τον κώδικα, οι πολύ συχνές μικρές εκδόσεις και η απλή σχεδίαση.

Scrum

Το Scrum οργανώνει τη δουλειά σε σπριντ (sprints), σταθερές επαναλήψεις διάρκειας περίπου 1–4 εβδομάδων. Κάθε σπριντ τελειώνει με ένα κομμάτι λογισμικού πλήρως ελεγμένο και έτοιμο για παράδοση, που παρουσιάζεται σε μια συνάντηση αξιολόγησης.

Ρόλοι:

• Product Owner: εκπροσωπεί τον πελάτη και τους χρήστες. Γράφει και ιεραρχεί τη λίστα με τις επιθυμητές λειτουργίες, το product backlog, και αποφασίζει τι μπαίνει σε κάθε σπριντ.
• Scrum Master: βοηθά την ομάδα να ακολουθεί το Scrum και απομακρύνει ό,τι την εμποδίζει.
• Ομάδα ανάπτυξης: μικρή, αυτο-οργανωμένη ομάδα που φτιάχνει το προϊόν.

Οι λειτουργίες γράφονται συνήθως ως user stories, π.χ. «Ως πελάτης, θέλω να αποθηκεύω τα προϊόντα που μου αρέσουν, ώστε να τα βρίσκω αργότερα». Κάθε story παίρνει story points, μια εκτίμηση της προσπάθειας που χρειάζεται. Θα τα χρησιμοποιήσεις και στην εργασία του μαθήματος.

Feature-Driven Development (FDD)

Το FDD φτιάχτηκε για μεγάλες ομάδες. Ξεκίνησε το 1997, όταν ο Jeff De Luca δούλευε σε ένα έργο 50 ατόμων διάρκειας 15 μηνών. Το έργο οργανώνεται γύρω από μια λίστα επιθυμητών λειτουργιών (features), σε πέντε φάσεις:

1. ένα πρώτο μοντέλο του συστήματος, από ειδικούς του αντικειμένου·
2. η λίστα λειτουργιών·
3. ο προγραμματισμός με βάση τις λειτουργίες·
4. ο σχεδιασμός ανά λειτουργία·
5. η κατασκευή ανά λειτουργία.

Οι φάσεις 1–3 γίνονται μία φορά στην αρχή· οι 4 και 5 επαναλαμβάνονται για κάθε λειτουργία μέχρι να ολοκληρωθεί το προϊόν.

Σύγκριση

Ερωτήσεις αυτοαξιολόγησης

1. Γιατί ο καταρράκτης λέγεται «BDUF»;

Από το Big Design Up Front: όλος ο σχεδιασμός ολοκληρώνεται στην αρχή, πριν ξεκινήσει η υλοποίηση, και μετά δεν αλλάζει εύκολα.

2. Τι κοινό έχει το μοντέλο V με τον καταρράκτη, και σε τι διαφέρει;

Και τα δύο είναι γραμμικά και άκαμπτα στις αλλαγές. Το μοντέλο V όμως αντιστοιχίζει κάθε στάδιο σχεδιασμού με ένα επίπεδο δοκιμών, π.χ. τις απαιτήσεις με τις δοκιμές αποδοχής.

3. Ποιο είναι το κεντρικό στοιχείο του σπειροειδούς μοντέλου;

Η ανάλυση κινδύνου. Σε κάθε κύκλο αξιολογούνται οι εναλλακτικές και οι κίνδυνοι, και με βάση αυτούς αποφασίζεται πώς θα συνεχίσει το έργο.

4. Στο Scrum, ποιος αποφασίζει ποιες λειτουργίες μπαίνουν στο επόμενο σπριντ;

Ο Product Owner, που κρατά και ιεραρχεί το product backlog εκ μέρους του πελάτη και των χρηστών.

5. Ένα έργο έχει απαιτήσεις που αλλάζουν συχνά και πελάτη που θέλει να βλέπει πρόοδο κάθε δύο εβδομάδες. Καταρράκτης ή Agile;

Agile, π.χ. Scrum με σπριντ δύο εβδομάδων. Δέχεται τις αλλαγές στην πορεία και παραδίδει λειτουργικό λογισμικό σε κάθε σπριντ. Ο καταρράκτης θα έδειχνε το προϊόν μόνο στο τέλος, και κάθε αλλαγή θα ήταν ακριβή.

---

Πηγές: Διάλεξη 3 του μαθήματος· Μανιφέστο για την Ευέλικτη Ανάπτυξη Λογισμικού (στα ελληνικά)· I. Sommerville, Software Engineering (10η έκδοση).