ΜΗΧΑΝΙΚΗ ΚΑΙ ΤΕΧΝΟΛΟΓΙΑ ΛΟΓΙΣΜΙΚΟΥ

ΘΕΩΡΙΑ

3: Διεργασίες Ανάπτυξης

Διεργασία Ανάπτυξης Λογισμικού (Software Development Process):

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

Προϊόν της τελικής φάσης είναι το πλήρες, ετοιμοπαράδοτο και απόλυτα λειτουργικό λογισμικό που ζητήθηκε.

Μία διεργασία ανάπτυξης περιλαμβάνει κριτήρια εκκίνησης και τερματισμού κάθε φάσης στον κύκλο ζωής του λογισμικού.
Μία διεργασία ανάπτυξης περιλαμβάνει κριτήρια επιλογής μεταξύ εναλλακτικών φάσεων σε ορισμένα κρίσιμα σημεία του κύκλου ζωής.
Υπάρχουν πολλαπλά μοντέλα διεργασιών ανάπτυξης. Όλα υποστηρίζονται από κατάλληλες μεθόδους αναπαράστασης (π.χ. UML) και κατάλληλα εργαλεία τα οποία αυτοματοποιούν κάποιες εργασίες.

Συνηθέστερες Φάσεις (διαδοχικά):

o Ανάλυση και Καθορισμός Απαιτήσεων

o Σχεδίαση

o Υλοποίηση (ο πραγματικός προγραμματισμός του λογισμικού)

o Έλεγχος

o Παράδοση (δεν είναι πλήρης φάση, απλώς τελειώνει η κατασκευή του ζητούμενου λογισμικού και παραδίδεται στον πελάτη που το παρήγγειλε)

o Συντήρηση (λαμβάνει χώρα μετά την ολοκλήρωση της κατασκευής του λογισμικού, για μακρό χρονικό διάστημα)

Κλασικό μοντέλο Υλοποίησης και Επιδιόρθωσης (Code and Fix):

Επικρατούσε κατά τη δεκαετία του 1950, πριν από την εμφάνιση της τεχνολογίας λογισμικού. Στα ελληνικά είναι γνωστό και ως μοντέλο Άναρχης Ανάπτυξης.
Απλώς συγγράφεται κατευθείαν ο κώδικας και αποσφαλματώνεται στην πορεία.
Μετά από πολλές διαδοχικές επιδιορθώσεις το αποτέλεσμα είναι ένας ακατανόητος και δύσκολα συντηρήσιμος κώδικας.

Σταδιακό Μοντέλο (Stage Model):

Εμφανίστηκε το 1956, έχοντας βάσεις στην παραδοσιακή μηχανική και στις προϋπάρχουσες κατασκευαστικές πρακτικές της βιομηχανίας.
Σε αυτό εκτελούνται διαδοχικά οι φάσεις που προαναφέρθηκαν, συμπεριλαμβανομένης της ανάλυσης απαιτήσεων, του σχεδιασμού και του ελέγχου.
Κάθε φάση πρέπει να έχει εκτελεστεί μέχρι κάποιο χρονικό ορόσημο (milestone).
Δεν προβλέπεται επιστροφή σε προηγούμενες φάσεις, άρα δεν περιγράφεται σωστά η συνηθισμένη διαδικασία ανάπτυξης λογισμικού: το μοντέλο δεν ανταποκρίνεται πλήρως στην πραγματικότητα.
Η έμφαση δίνεται στην αναλυτική τεκμηρίωση και στην τελειοποίηση του προϊόντος κάθε φάσης, ώστε η επόμενη φάση να ξεκινήσει σε απολύτως στέρεες βάσεις. Διαφορετικά η ανάπτυξη θεωρείται αποτυχημένη.

Μοντέλο Καταρράκτη (Waterfall Model):

Εμφανίστηκε το 1970.
Στηρίζεται στο Σταδιακό Μοντέλο αλλά μοντελοποιεί την επιστροφή σε προηγούμενες φάσεις αν κριθεί απαραίτητο (π.χ. αν η υλοποίηση κάποιων σχεδιαστικών επιλογών αποδειχθεί τελικώς αδύνατη, ή επειδή οι απαιτήσεις έχουν αναθεωρηθεί), χωρίς η ανάπτυξη να θεωρείται αποτυχημένη.
Ιδανικά, θα έπρεπε κάθε τέτοια μετάβαση να γίνεται μόνο προς την αμέσως προηγούμενη φάση, ώστε να εξοικονομούνται πόροι.
Αυτό δεν ισχύει πάντα, με αποτέλεσμα η ανάπτυξη να γίνεται χαοτική σε περίπτωση που έχουμε πολλές μεταβάσεις σε παλιές, μακρινές φάσεις (π.χ. από κάποιο στάδιο της φάσης ελέγχου στη φάση σχεδίασης κλπ).
Σημείωση: κάποιοι συγγραφείς όταν μιλούν για «Μοντέλο Καταρράκτη» αναφέρονται στην πραγματικότητα στο «Σταδιακό Μοντέλο», ενώ τον Καταρράκτη που περιγράφεται εδώ τον θεωρούν μεταγενέστερη παραλλαγή.

Πρωτότυπα:

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

Μοντέλο Καθορισμού Λειτουργικών Προδιαγραφών:

o Εμφανίστηκε το 1984.

o Στηρίζεται κι αυτό στην πρόωρη επαλήθευση και επικύρωση, με σκοπό τη μείωση της πιθανότητας μακρινών μεταβάσεων σε παλαιότερες φάσεις.

o Αρχικά οι απαιτήσεις προδιαγράφονται με τυπικό τρόπο, με μια απλή γλώσσα προγραμματισμού.

o Το σύστημα προσομοιώνεται με προτυποποιημένο τρόπο, βάσει των προδιαγραφών.

o Γίνεται επικύρωση και επαλήθευση.

o Η υλοποίηση σε κάποιον βαθμό αυτοματοποιείται, με γεννήτριες κώδικα οι οποίες απεικονίζουν τη γλώσσα περιγραφής απαιτήσεων σε πραγματικό πρόγραμμα.

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

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

Σπειροειδές Μοντέλο:

o Εμφανίστηκε το 1986.

o Προστίθεται μία νέα φάση στην αρχή του κύκλου ζωής: Καθορισμός προβλήματος και επιλογή λύσης.

o Καθεμία από τις φάσεις της διεργασίας ανάπτυξης διακρίνεται σε πέντε βήματα:

· Καθορισμός στόχων και απαιτούμενου προϋπολογισμού

· Καθορισμός εναλλακτικών προσεγγίσεων

· Καθορισμός περιορισμών για τις διάφορες εναλλακτικές προσεγγίσεις (π.χ. κόστος)

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

· Εκτέλεση κυρίως δραστηριοτήτων της φάσης

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

o Το μοντέλο σχεδιάστηκε ώστε να επιτρέπει τη ρητή διαχείριση των κινδύνων οι οποίοι πιθανώς κρύβονται σε κάθε φάση της διεργασίας ανάπτυξης.

o Χρησιμοποιείται κυρίως για μεγάλα και περίπλοκα έργα λογισμικού.

Μοντέλο Ανάπτυξης σε Φάσεις:

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

Αυξητική Ανάπτυξη (Incremental Development): Οι πελάτες προμηθεύονται γρήγορα ένα στοιχειωδώς λειτουργικό λογισμικό, το οποίο σταδιακά αποκτά περισσότερες δυνατότητες κατά τη διάρκεια πολλαπλών επαναλήψεων της διεργασίας ανάπτυξης.
Επαναληπτική Ανάπτυξη (Iterative Development): Οι πελάτες προμηθεύονται γρήγορα μία πλήρη αλλά πρώιμη έκδοση του συστήματος, η οποία σταδιακά αναπροσαρμόζεται, επανασχεδιάζεται και βελτιώνεται κατά τη διάρκεια πολλαπλών επαναλήψεων της διεργασίας ανάπτυξης.

o Στο μοντέλο αυτό μία εκδοχή του ζητούμενου προϊόντος αρχίζει να χρησιμοποιείται, ενώ ο κύκλος ζωής ακόμα συνεχίζεται. Έτσι το λογισμικό αξιολογείται σε πραγματικές συνθήκες λειτουργίας προτού υλοποιηθεί η πλήρης τελική έκδοση, καθοδηγώντας πιο αποδοτικά τον σχεδιασμό και την υλοποίηση της τελευταίας. Η αναπροσαρμογή της διεργασίας ανάπτυξης σε μεταβαλλόμενες συνθήκες και απαιτήσεις είναι πολύ πιο εύκολη απ’ ότι με τον Καταρράκτη ή τη Σπείρα.

o Το μοντέλο οδηγεί σε μικρούς χρόνους ανάπτυξης, ταχεία παράδοση και εύκολη επίλυση σφαλμάτων, αλλά οι διαρκείς αλλαγές στο σχέδιο και στον κώδικα μπορούν εύκολα να καταστρέψουν τον τελευταίο (όπως και στο μοντέλο Υλοποίησης και Επιδιόρθωσης). Επιπρόσθετα, το αναπτυσσόμενο προϊόν ίσως να μην είναι ποτέ επαρκώς ικανοποιητικό ώστε να θεωρηθεί τελικό: στη χειρότερη περίπτωση το μοντέλο μπορεί να δώσει μόνο μία αλληλουχία όλο και πολυπλοκότερων πρωτοτύπων, αντί για ένα πλήρως λειτουργικό λογισμικό.

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

o Το 1991 εμφανίστηκε ο όρος Ταχεία Ανάπτυξη Εφαρμογών (Rapid Application Development, RAD) για να περιγράψει μία σύνθεση της επαναληπτικής ανάπτυξης με τη χρήση πρωτοτύπων («πρωτοτυποποίηση λογισμικού») και βιβλιοθηκών που παρέχουν έναν έτοιμο προγραμματιστικό σκελετό για την κατασκευή νέων εφαρμογών, προκειμένου να μειωθεί σημαντικά ο χρόνος ανάπτυξης λογισμικού.

o Έτσι επιχειρήθηκε να επιλυθεί το βασικό πρόβλημα με αυστηρά μοντέλα όπως ο Καταρράκτης ή η Σπείρα: το ζητούμενο προϊόν απαιτούσε τόσο μεγάλο χρόνο κατασκευής που οι απαιτήσεις ίσως είχαν αλλάξει πριν την παράδοσή του.

Ευέλικτο Μοντέλο (Agile Development):

o Εμφανίστηκε τυπικά το 2001, έχοντας ήδη εξελιχθεί με διάφορους τρόπους από το 1995. Στην πραγματικότητα μπορεί να θεωρηθεί ένας τύπος RAD.

o Είναι περισσότερο ένα σύνολο από κεντρικές αρχές, στηριγμένες στο μοντέλο ανάπτυξης σε φάσεις και στην ευρύτερη φιλοσοφία του, παρά μία αυστηρά ορισμένη διεργασία ανάπτυξης λογισμικού.

o Το Ευέλικτο Μοντέλο διακηρύσσει πως, αντί να προσπαθεί να προβλέψει το μέλλον, προσαρμόζεται σε αυτό. Έτσι έρχεται σε αντιπαράθεση με δύσκαμπτα, αυστηρά μοντέλα όπως ο Καταρράκτης και η Σπείρα, τα οποία επιχειρούν να καταπολεμήσουν την αβεβαιότητα καταρτίζοντας λεπτομερειακά πλάνα εκ των προτέρων. Κατ’ αντιδιαστολή, στο Ευέλικτο Μοντέλο μόνο η αρχή και ο στόχος είναι πλήρως γνωστά από την πρώτη στιγμή, ενώ τα μεσαία στάδια καθορίζονται στην πορεία αναλόγως με τις συνθήκες.

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

o Ο μακροχρόνιος, συνολικός σχεδιασμός αποφεύγεται και προτιμάται ο βραχυπρόθεσμος σχεδιασμός για μικρά τμήματα του ζητούμενου προϊόντος, τα οποία μπορούν ανεξάρτητα να υλοποιηθούν, ελεγχθούν και παραδοθούν σύντομα προς χρήση και αξιολόγηση.

o Η ανάπτυξη του λογισμικού γίνεται στη βάση της αυξητικής και επαναληπτικής ανάπτυξης από συνεργαζόμενες ομάδες ατόμων, οι οποίες έρχονται σε άμεση και τακτική επαφή μεταξύ τους, με τους χρήστες και με τον πελάτη. Οι ομάδες αυτές είναι μικρές σε μέγεθος, δεν ιεραρχούνται αυστηρά και συνήθως αυτοοργανώνονται ως προς την ανάθεση καθηκόντων. Αυτό δεν σημαίνει πως δεν τηρούνται τυπικές διαδικασίες κατά την ανάπτυξη (π.χ. χρονικά ορόσημα για την ολοκλήρωση κάποιας εργασίας, καταμερισμός εργασιών κλπ), αλλά ότι η έμφαση δίνεται στην προσαρμοστικότητα και στην ευελιξία ώστε να αντιμετωπίζονται εύκολα απρόβλεπτες αλλαγές, χωρίς να συνοδεύονται από καταστροφικές επιπτώσεις στην ανάπτυξη του προϊόντος.
o Ως προβλήματα του Ευέλικτου Μοντέλου έχουν επισημανθεί η ελλιπής γραπτή τεκμηρίωση, η αδυναμία λειτουργίας με μεγάλες ομάδες εργαζομένων και οι καθυστερήσεις στις τελευταίες επαναλήψεις της διεργασίας ανάπτυξης, όταν επιχειρείται η μαζική προσθήκη στο λογισμικό πολλαπλών ζητούμενων χαρακτηριστικών που παραλείπονταν κατά τις προηγούμενες επαναλήψεις.

Ακραίος Προγραμματισμός (Extreme Programming):

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