Η παρουσίαση φορτώνεται. Παρακαλείστε να περιμένετε

Η παρουσίαση φορτώνεται. Παρακαλείστε να περιμένετε

Μοντέλα Κύκλου-Ζωής Λογισμικού SOFTWARE LIFE-CYCLE MODELS Δρ. Μαρία Ι. Ανδρέου.

Παρόμοιες παρουσιάσεις


Παρουσίαση με θέμα: "Μοντέλα Κύκλου-Ζωής Λογισμικού SOFTWARE LIFE-CYCLE MODELS Δρ. Μαρία Ι. Ανδρέου."— Μεταγράφημα παρουσίασης:

1 Μοντέλα Κύκλου-Ζωής Λογισμικού SOFTWARE LIFE-CYCLE MODELS Δρ. Μαρία Ι. Ανδρέου

2 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 2 Περιεχόμενα Ανάπτυξη Λογισμικού (Software development) στη θεωρία Winburg mini case study Το δίδαγμα από το Winburg mini case study Teal tractors mini case study Επανάληψη και σταδιακή πρόοδος (Iteration and incrementation) Αναθεωρημένο το Winburg mini case study Θέματα αναφορικά με ρίσκα (risks) Διαχείριση επαναλήψεων και σταδιακής προόδου Άλλα μοντέλα κύκλου ζωής Σύγκριση μοντέλων κύκλου ζωής

3 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 3 Ανάπτυξη Λογισμικού ( Software Development) στη θεωρία Ιδανικά, ένα λογισμικό αναπτύσσεται όπως περιγράψαμε στο Κεφ. 1  Γραμμικά (Linear)  Ξεκινώντας από το μηδέν Figure 2.1

4 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 4 Ανάπτυξη Λογισμικού στην πράξη Στον πραγματικό κόσμο, η διαδικασία ανάπτυξης ενός λογισμικού είναι εντελώς διαφορετική από ότι στην θεωρία και τον ιδεατό κόσμο, επειδή  Κάνουμε λάθη (οι κατασκευαστές (developers), οι πελάτες (clients) κλπ…)  Οι ανάγκες και απαιτήσεις των πελατών αλλάζουν κατά την διάρκεια της ανάπτυξης του λογισμικού

5 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 5 Winburg Mini Case Study Επεισόδιο 1: Η πρώτη έκδοση (first version) υλοποιείται Επεισόδιο 2: εντοπισμός ενός σφάλματος (fault)  Το προϊόν είναι πολύ αργό (δηλ., εκτελείται πολύ αργά) εξαιτίας ενός λάθους στην υλοποίηση (implementation)  Άρχισαν αλλαγές στην υλοποίηση Επεισόδιο 3: Αλλαγή των απαιτήσεων (requirements)  Χρησιμοποιείται ένας πιο γρήγορος αλγόριθμος Επεισόδιο 4: Υιοθετείται ένα νέος σχεδιασμός (design)  Ολοκλήρωση της Ανάπτυξης Επίλογος: μερικά χρόνια αργότερα τα πιο πάνω προβλήματα ξαναεμφανίζονται.

6 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 6 Μοντέλο Δέντρου-Εξέλιξης (Evolution-Tree Model) Winburg Mini Case Study Figure 2.2

7 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 7 Το μοντέλο του Καταρράκτη (Waterfall Model) Το Μοντέλο του Καταρράκτη (Waterfall μοντέλο) είναι ουσιαστικά το γραμμικό μοντέλο κύκλου ζωής (linear life cycle model) με βράχους ανταπόκρισης (feedback loops) Προσέξτε ότι στο μοντέλο του καταρράκτη δεν φαίνεται η σειρά των γεγονότων Figure 2.3

8 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 8 Επιστροφή στο Μοντέλο Δέντρου-Εξέλιξης Απεικονίζει την ακριβής σειρά των γεγονότων Στο τέλος κάθε επεισοδίου  Έχουμε μια γραμμή βάσης (baseline), δηλ., ένα πλήρες σύνολο από artifacts (συστατικά μέλη) Παράδειγμα:  Γραμμή βάσης στο τέλος του επεισοδίου 4: Requirements 3, Analysis 3, Design 4, Implementation 4

9 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 9 Το δίδαγμα από το Winburg Mini Case Study Στον πραγματικό κόσμο, η ανάπτυξη λογισμικού είναι πιο χαοτική, πιο δύσκολη, από ότι στο Winburg mini case study Αλλαγές χρειάζονται συνέχεια  ένα προϊόν λογισμικού (software product) είναι ένα μοντέλο του πραγματικού κόσμου, ο οποίος συνέχεια αλλάζει.  Οι επαγγελματίες κατασκευαστές λογισμικού (software developers) είναι άνθρωποι, συνεπώς κάνουν λάθη.

10 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 10 Teal Tractors Mini Case Study Κατά την διάρκεια της κατασκευής του Teal Tractors λογισμικού, οι απαιτήσεις (requirements) του πελάτη άλλαξαν. Η εταιρία (teal tractors) επεκτείνεται στον Καναδά  Οι αλλαγές που χρειάζονται περιλαμβάνουν:  Προσθήκη νέων περιοχών όπου θα γίνονται πωλήσεις  Το λογισμικό πρέπει να μπορεί να διαχειρίζεται τις διαφορές που απορρέουν από το διαφορετικό φορολογικό σύστημα στο Καναδά και οποιεσδήποτε άλλες διαφορές αναφορικά με επιχειρήσεις  Το λογισμικό πρέπει να επεκταθεί έτσι ώστε να μπορεί να διαχειρίζεται δυο διαφορετικά νομίσματα, USD και CAD

11 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 11 Teal Tractors Mini Case Study (συνεχ.) Αυτές οι αλλαγές είναι  Πολύ καλές, θετικές, για την εταιρία του πελάτη, αλλά  Καταστροφικές για τη διαδικασία ανάπτυξης του ζητούμενου προϊόντος λογισμικού (πολλές φορές για λόγους ευκολίας θα αναφερόμαστε σε ένα προϊόν λογισμικού απλά σαν λογισμικό)

12 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 12 Το Πρόβλημα της Αλλαγής Στόχου (Moving Target Problem) Το πρόβλημα της αλλαγής στόχου (moving target problem) είναι αλλαγή/ές στις απαιτήσεις (requirements) ενόσω το προϊόν λογισμικού αναπτύσσεται. Ακόμα και όταν οι λόγοι για αυτές τις αλλαγές είναι για το καλό του πελάτη, το προϊόν λογισμικού μπορεί να επηρεασθεί αντιστρόφως  Συμπερίληψη εξαρτήσεων

13 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 13 Το Πρόβλημα της Αλλαγής Στόχου (συνέχ.) Οποιαδήποτε αλλαγή γίνει στο λογισμικό μπορεί ενδεχόμενα να προκαλέσει τέτοιο λάθος με συνέπεια να έχουν οπισθοδρόμηση (regression fault)  Ένα λάθος μπορεί φαινομενικά να μη είναι σχετικό με την αλλαγή που έγινε. Αν χρειάζονται πάρα πολλές αλλαγές  Το προϊόν (λογισμικό) ίσως να χρειαστεί να ξανασχεδιαστεί (redesigned) και να ξαναυλοποιηθεί (reimplemented)

14 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 14 Το Πρόβλημα της Αλλαγής Στόχου (συνέχ.) Αλλαγές είναι αναπόφευκτο να μην γίνουν  Αναπτυσσόμενες εταιρίες πάντα αλλάζουν τις απαιτήσεις τους Αν οι αλλαγές που καλούνται να γίνουν (στο τρέχων λογισμικό) είναι τόσο ριζικές, τότε τίποτα δεν μπορεί να απαμβλύνει το πρόβλημα ΔΕΝ υπάρχει λύση στο Πρόβλημα της Αλλαγής Στόχου (moving target problem)

15 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 15 Επανάληψη και Σταδιακή Πρόοδος Iteration and Incrementation Στην πραγματική ζωή, δεν μπορούμε να μιλάμε για «Τη φάση της ανάλυσης» (“the analysis phase”)  Αντ’αυτού, οι λειτουργίες της φάσης της ανάλυσης επεκτείνονται σε όλο το κύκλό ζωής Η βασική διαδικασία για ανάπτυξη λογισμικού είναι επαναληπτική (iterative)  Κάθε διαδοχική έκδοση (successive version) στοχεύει να είναι πιο κοντά στο τελικό στόχο (target) από ότι η προκάτοχος της (predecessor)

16 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 16 Miller’s Law Ο νόμος του Mille (Miller’s Law) λέει ότι, κάθε χρονική στιγμή, μπορούμε να επικεντρωθούμε σε περίπου επτά μεγάλα μέρη πληροφορίας (chunks units of information) Για να διαχειριστούμε μεγαλύτερη ποσότητα πληροφορίας, χρησιμοποιούμε σταδιακή εκλέπτυνση (refinement)  Εστιάζουμε στις πτυχές που είναι επί του παρόντος οι πιο σημαντικές  Αναβάλλουμε πτυχές που τώρα δεν είναι και τόσο σημαντικές  Κάθε πτυχή θα ληφθεί υπόψη όταν θα έρθει η ώρα της να είναι σημαντική. Αυτή η διαδικασία ονομάζεται σταδιακής προόδου ( incremental process)

17 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 17 Επανάληψη και Σταδιακή Πρόοδος Iteration and Incrementation Figure 2.4

18 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 18 Επανάληψη και Σταδιακή Πρόοδος (συνέχ.) Η επανάληψη (Iteration) και η σταδιακή πρόοδος (incrementation) χρησιμοποιούνται συνδυασμένες  Δεν υπάρχει μια «φάση απαιτήσεων» (“requirements phase”) ή μια «φάση σχεδιασμού» (“design phase”)  Αντίθετα, υπάρχουν πολλαπλά στιγμιότυπα κάθε φάσης Figure 2.2 (again)

19 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 19 Επανάληψη και Σταδιακή Πρόοδος (συνέχ.) Ο αριθμός των σταδίων (increments) στην σταδιακή πρόοδο δεν είναι σταθερός. Διαφέρει από έργο σε έργο

20 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 20 Κλασικές φάσεις έναντι Δραστηριοτήτων Classical Phases versus Workflows Δεν υπάρχουν ακολουθιακές φάσεις (Sequential phases) στον πραγματικό κόσμο Αντίθετα, οι πέντε βασικές δραστηριότητες (workflows) εκτελούνται καθόλη τη διάρκεια του κύκλου ζωής  Δραστηριότητα Απαιτήσεων (Requirements workflow)  Δραστηριότητα Ανάλυσης (Analysis workflow)  Δραστηριότητα Σχεδιασμού (Design workflow)  Δραστηριότητα Υλοποίησης (Implementation workflow)  Δραστηριότητα Ελέγχου (Test workflow)

21 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 21 Δραστηριότητες (Workflows) οι πέντε βασικές δραστηριότητες (workflows) εκτελούνται καθόλη τη διάρκεια του κύκλου ζωής Όμως, τις περισσότερες φορές ΜΙΑ δραστηριότητα δεσπόζει (predominates) έναντι των άλλων Παραδείγματα:  Στην αρχή του κύκλου ζωής ενός έργου λογισμικού Δεσπόζει η δραστηριότητα απαιτήσεων  Στο τέλος του κύκλου ζωής ενός έργου λογισμικού Δεσπόζουν οι δραστηριότητες υλοποίησης και ελέγχου Ενέργειες για Planning και τεκμηρίωση (documentation) εκτελούνται καθόλη τη διάρκεια του κύκλου ζωής. Δεν γίνονται σαν ξεχωριστές δραστηριότητες.

22 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 22 Επανάληψη και Σταδιακή Πρόοδος (συνέχ.) Κατά την διάρκεια κάθε σταδίου (increment) εκτελούνται ΠΟΛΛΕΣ επαναλήψεις (Iterations) Figure 2.5

23 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 23 Επανάληψη και Σταδιακή Πρόοδος (συνέχ.) Ο αριθμός των επαναλήψεων σε κάθε στάδιο ΔΕΝ είναι σταθερός. Εξαρτάται από τις ανάγκες και τη πρόοδο του κάθε έργου.

24 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 24 Αναθεωρημένο το Winburg Mini Case Study Με βάση την επόμενη διαφάνεια το μοντέλο δέντρου-εξέλιξης (evolution-tree model) τέθηκε πάνω από το μοντέλο επαναλήψεων και σταδιακής προόδου. Η δραστηριότητα ελέγχου (test workflow) έχει παραληφτεί — το μοντέλο δέντρου-εξέλιξης υποθέτει συνεχής έλεγχο (testing)

25 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 25 Αναθεωρημένο το Winburg Mini Case Study (συνεχ.) Figure 2.6

26 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 26 Περισσότερα για τα Στάδια (Increments) στο κύκλο ζωής ενός έργου Κάθε επεισόδιο αντιστοιχεί σε ένα στάδιο (increment) Κάθε στάδιο ΔΕΝ περιλαμβάνει μόνο μια δραστηριότητα αλλά πολλές δραστηριότητες Ένα στάδιο μπορεί να μην ολοκληρωθεί ποτέ (π.χ., το Increment B στο Winburg case study) Οι διακεκομμένες γραμμές δηλώνουν συντήρηση (maintenance)  Και στα τρία στάδια στο Winburg case study γίνεται συντήρηση διόρθωσης (Corrective maintenance)

27 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 27 Ρίσκα και άλλες πτυχές του μοντέλου Επανάληψης και Σταδιακής Προόδου Μπορούμε να βλέπουμε το συνολικό έργο σαν ένα σύνολο από μικρά έργα (mini projects) Κάθε mini project επεκτείνει τα συστατικά μέρη (artifacts) όλων των δραστηριοτήτων  Συστατικά μέρη απαιτήσεων  Συστατικά μέρη ανάλυσης  Συστατικά μέρη σχεδιασμού  Συστατικά μέρη υλοποίησης  Συστατικά μέρη ελέγχου Τα τελικό σύνολο όλων των Συστατικών μερών είναι το ολοκληρωμένο προϊόν

28 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 28 Ρίσκα και άλλες πτυχές του μοντέλου Επανάληψης και Σταδιακής Προόδου (συνεχ.) Κατά την διάρκεια κάθε mini project  Επεκτείνουμε τα συστατικά μέρη μερικών ή όλων των δραστηριοτήτων (σε αντιστοιχία με τα στάδια);  Ελέγχουμε τα νέα συστατικά μέρη (δραστηριότητα ελέγχου); και Όταν χρειάζεται, αλλάζουμε τα σχετικά συστατικά μέρη (σε αντιστοιχία με την επανάληψη)

29 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 29 Ρίσκα και άλλες πτυχές του μοντέλου Επανάληψης και Σταδιακής Προόδου (συνεχ.) Κάθε επανάληψη μπορεί να θεωρηθεί σαν ένα μικρό αλλά ολοκληρωμένο μοντέλο κύκλου ζωής τύπου καταρράκτη Κατά την διάρκεια κάθε επανάληψης εστιάζουμε σε ένα τμήμα (portion) του προϊόντος λογισμικού  Σε αυτό το τμήμα εκτελούμε τις κλασικές φάσεις Απαιτήσεων Ανάλυσης Σχεδιασμού Υλοποίησης

30 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 30 Πλεονεκτήματα του μοντέλου Επανάληψης και Σταδιακής Προόδου (συνεχ.) Υπάρχουν πολλαπλές ευκαιρίες να ελέγξουμε ότι το προϊόν λογισμικού που αναπτύσσεται είναι σωστό  Κάθε επανάληψη ενσωματώνει την δραστηριότητα ελέγχου  Τυχών Σφάλματα μπορούν να εντοπιστούν και να διορθωθούν γρήγορα The ευρωστία (robustness) της αρχιτεκτονικής (architecture) του προϊόντος που αναπτύσσεται μπορεί να υπολογιστεί νωρίς στον κύκλο ζωής  Αρχιτεκτονική (Architecture) — τα διάφορα συνιστώντα τμήματα (component modules) του προϊόντος και πως σχετίζονται μεταξύ τους  Ευρωστία (Robustness) — η ιδιότητα του προϊόντος να είναι ικανό να διαχειρίζεται επεκτάσεις και αλλαγές χωρίς να αποτυγχάνει.

31 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 31 Πλεονεκτήματα του μοντέλου Επανάληψης και Σταδιακής Προόδου (συνεχ.) Μπορούμε να μετριάσουμε τα ρίσκα νωρίς  Ρίσκα υπάρχουν πάντα κατά την ανάπτυξη ενός λογισμικού και κατά την συντήρηση του  Υπάρχει μια έκδοση του προϊόντος λογισμικού που δουλεύει από την αρχή (σε σχέση με το χρόνο)  Παραλλαγή: παράδοση επιμέρους εκδόσεων στον πελάτη, έτσι ώστε να εξομαλύνουμε την εισαγωγή του νέου προϊόντος στον οργανισμό του πελάτη.

32 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 32 Διαχείριση μοντέλου Επανάληψης και Σταδιακής Προόδου Το μοντέλο κύκλου ζωής επανάληψης και σταδιακής προόδου οργανώνεται σαν το μοντέλο του καταρράκτη… … επειδή το μοντέλο κύκλου ζωής επανάληψης και σταδιακής προόδου είναι το μοντέλο του καταρράκτη, εφαρμοζόμενο διαδοχικά Κάθε στάδιο είναι ένα waterfall mini project

33 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 33 Άλλα Μοντέλα Κύκλου Ζωής Θα παρουσιάσουμε και θα συγκρίνουμε στη συνέχεια τα ακόλουθα μοντέλα κύκλου ζωής :  Μοντέλο κωδικοποίησης-και-διόρθωσης (Code-and- fix)  Μοντέλο του Καταρράκτη (Waterfall)  Γρήγορο πρωτότυπο (Rapid prototyping)  Ακραίος Προγραμματισμός και Σβέλτα διαδικασία (Extreme programming and agile processes)  Μοντέλο του Συγχρονισμού και της Σταθερότητας (Synchronize-and-stabilize life-cycle model)  Το Σπιράλ μοντέλο (Spiral)

34 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 34 Μοντέλο Κύκλου Ζωής Κωδικοποίησης-και-Διόρθωσης Code-and-Fix Model Κανένας σχεδιασμός Χωρίς προδιαγραφές  Εφιαλτική συντήρηση Figure 2.7

35 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 35 Μοντέλο Κύκλου Ζωής Κωδικοποίησης-και-Διόρθωσης (συνέχ.) Ο πιο απλό τρόπος ανάπτυξης λογισμικού  άρα και ο πιο καλός; (όχι βέβαια) Είναι Ο πιο ακριβός τρόπος  Γιατί;

36 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 36 Μοντέλο Κύκλου Ζωής τύπου Καταρράκτη Waterfall Model Figure 2.8

37 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 37 Μοντέλο Κύκλου Ζωής τύπου Καταρράκτη (συνέχ.) Χαρακτηρίζεται από  Βρόχους Αντιδράσεων (Feedback loops)  Καθορίζεται από την τεκμηρίωση (Documentation- driven) Προτερήματα  Καλή Τεκμηρίωση (Documentation)  Εύκολη Συντήρηση (Maintenance) Αδυναμίες  Προδιαγραφές (Specification document) Joe and Jane Johnson Mark Marberry

38 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 38 Μοντέλο Κύκλου Ζωής Γρήγορου Πρωτοτύπου Rapid Prototyping Model Γραμμικό μοντέλο “Γρήγορο” Figure 2.9

39 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 39 Ακραίος προγραμματισμός και σβέλτα διαδικασία (Extreme Programming (ΧΡ) and Agile Processes) Μια αμφιλεγόμενη νέα προσέγγιση Ιστορίες (μελλοντικοί πελάτες θα θέλουν)  Εκτίμηση διάρκειας και κόστους κάθε ιστορίας  Επιλογή ιστοριών για μελλοντική χρήση  Κάθε κατασκεύασμα χωρίζεται σε εργασίες (tasks)  Περιπτώσεις για έλεγχο των task σχεδιάζονται πρώτα Προγραμματισμός σε ζευγάρια (pair programming) Συνεχής ενσωμάτωση εργασιών

40 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 40 Ασυνήθιστα χαρακτηριστικά του XP Οι υπολογιστές τοποθετούνται στο κέντρο ενός μεγάλου δωματίου χωρισμένο σε θαλαμίσκους Ένας εκπρόσωπος του πελάτη είναι πάντα παρόν Οι επαγγελματίες κατασκευαστές λογισμικού (Software professionals) δεν μπορούν να δουλεύουν υπερωρίες (overtime) για περισσότερο από 2 συνεχόμενες βδομάδες Δεν υπάρχουν ειδικεύσεις Τροποποίηση Σχεδιασμού Refactoring

41 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 41 Σβέλτα διαδικασία (Agile Processes) Μια συλλογή από νέα παραδείγματα που χαρακτηρίζονται από  Λιγότερη έμφαση στην ανάλυση και το σχεδιασμό  Πιο γρήγορη υλοποίηση (ένα λογισμικό που δουλεύει θεωρείται πιο σημαντικό από τη τεκμηρίωση (documentation))  Ανταπόκριση σε αλλαγές  Στενή συνεργασία με τον πελάτη

42 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 42 Αξιολόγηση του μοντέλου Ακραίου Προγραμματισμού και Σβέλτης διαδικασίας XP είχε επιτυχία σε μικρής κλίμακας έργα λογισμικού  Όμως, σε μέτριας κλίμακας και σε μεγάλης κλίμακας έργα είναι πολύ διαφορετική η απόδοση του Το κλειδί: η επίδραση της σβέλτης διαδικασίας στη συντήρηση μετά την παράδοση του έργου  Refactoring είναι ένα σημαντικό στοιχείο της σβέλτης διαδικασίας  Refactoring συνεχίζει κατά τη συντήρηση  Το refactoring θα αυξήσει το κόστος της συντήρησης μετά την παράδοση, όπως φαίνεται στην προκαταρτική έρευνα;

43 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 43 Αξιολόγηση του μοντέλου Ακραίου Προγραμματισμού και Σβέλτης διαδικασίας (συνέχ.) Οι σβέλτες διαδικασίες είναι καλές όταν οι απαιτήσεις είναι ασαφείς ή αλλάζουν συνεχώς Σύντομα θα αξιολογηθούν οι σβέλτες διαδικασίες  Δεν υπάρχουν ακόμα αρκετά δεδομένα Ακόμα και αν αποδειχθεί ότι οι σβέλτες διαδικασίες δεν είναι ικανοποιητικές  Κάποια χαρακτηρίσθηκα (όπως ο προγραμματισμός σε ζευγάρια) μπορεί να υιοθετηθούν σαν γενική τάση των πρακτικών για τεχνολογία λογισμικού

44 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 44 Μοντέλο του Συγχρονισμού και της Σταθερότητας (Synchronize-and Stabilize Model) Είναι το μοντέλο κύκλου ζωής που έχει υοθετίσει Microsoft’s Ανάλυση απαιτήσεων (Requirements analysis) — συνεντεύξεις σε ενδεχόμενους πελάτες Καθορισμός των προδιαγραφών (specifications) Διαμελισμός του έργων σε 3 ή 4 μέρη Κάθε μέρος πραγματοποιούνται (is carried out) από μικρές ομάδες που δουλεύουν παράλληλα

45 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 45 Μοντέλο του Συγχρονισμού και της Σταθερότητας (συνεχ.) Τελικά — Συγχρονισμός (έλεγχος και διόρθωση) Στο τέλος κάθε μέρους — Σταθερότητα (πάγωμα (freeze) των μερών) Τα συστατικά μέρη πάντα δουλεύουν μαζί.  Από νωρίς αποκτούμε επίγνωση για το πώς λειτουργεί ολόκληρο το έργο

46 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 46 Το Σπιράλ Μοντέλο Κύκλου Ζωής Spiral Model Απλοποιημένη μορφή  Γρήγορο πρωτότυπο συν ανάλυση ρίσκων (risk analysis) πριν από κάθε φάση Figure 2.10

47 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 47 Το σημείο κλειδί στο Spiral Model Αν δεν μπορούν να εξομαλινθούν όλα τα ρίσκα, τότε το έργο τερματίζεται άμεσα

48 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 48 Full Spiral Model Πριν από κάθε φάση  Εναλλακτικές  Ανάλυση ρίσκων Μετά από κάθε φάση  Αξιολόγηση  Σχεδιασμός της επόμενης φάσης Ακτινωτή διάσταση (radial dimension): ενημερωμένο συνολικό κόστος Γωνιακή διάσταση (angular dimension): διαδικασία δια μέσου του spiral

49 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 49 Full Spiral Model (συνέχ.) Figure 2.11

50 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 50 Ανάλυση του Spiral Model Προτερήματα  Είναι εύκολο να κρίνουμε πόσο πολύ έλεγχο να κάνουμε  Δεν γίνεται διαχωρισμός ανάμεσα στην ανάπτυξη (development) και την συντήρηση (maintenance) Αδυναμίες  Είναι μόνο για έργα μεγάλης κλίμακας (large-scale software)  Είναι μόνο για εσωτερικά (internal, in-house) έργα λογισμικού

51 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 51 Σύγκριση των Μοντέλων Κύκλου Ζωής Έχουν παρουσιαστεί διαφορετικά μοντέλα κύκλου ζωής  Το καθένα έχει τα δικά του προτερήματα και αδυναμίες Κριτήρια με βάση τα οποία θα μπορούσαμε να επιλέξουμε μοντέλο είναι  Η οργάνωση του  Η διαχείριση του  Οι ικανότητες των εργαζομένων  Η φύση του προϊόντος Η καλύτερη εισήγηση  “Mix-and-match” life-cycle model

52 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 52 Σύγκριση των Life-Cycle Models (συνέχ.) Figure 2.12


Κατέβασμα ppt "Μοντέλα Κύκλου-Ζωής Λογισμικού SOFTWARE LIFE-CYCLE MODELS Δρ. Μαρία Ι. Ανδρέου."

Παρόμοιες παρουσιάσεις


Διαφημίσεις Google