Τεχνολογία Λογισμικού

Transcript

1 Πανεπιστήμιο Πειραιά Τμήμα Ψηφιακών Συστημάτων Τεχνολογία Λογισμικού 8/10/2018 Δρ. Ανδριάνα Πρέντζα Αναπληρώτρια Καθηγήτρια

2 Πανεπιστήμιο Πειραιά Τμήμα Ψηφιακών Συστημάτων Μεθοδολογίες ανάπτυξης λογισμικού

3 Κύκλος Ζωής-Ανάπτυξης Συστήματος Ο Κύκλος Ζωής Ανάπτυξης Συστήματος (System Development Life Cycle) περιλαμβάνει την πορεία του συστήματος από τον καθορισμό του προβλήματος μέχρι τη λειτουργία του, τη συντήρηση και, τέλος, την απόσυρσή του O κύκλος ζωής περιλαμβάνει τις δραστηριότητες που απαντούν στα ερωτήματα: Τι; Γιατί; Πότε; Πώς; Πού; Απο ποιόν; Ομαδοποίηση δραστηριοτήτων σε φάσεις

4 Θεμελιώδεις φάσεις σε ένα έργο ανάπτυξης λογισμικού Σε κάθε έργο και μεθοδολογία ανάπτυξης μπορούμε να εντοπίσουμε τις παρακάτω θεμελιώδεις φάσεις: 1 η φάση Προγραμματισμός (Planning) 2 η φάση Ανάλυση (Analysis) 3 η φάση Σχεδίαση (Design) 4 η φάση Υλοποίηση (Implementation) Κάθε φάση αποτελείται από στάδια (steps), βασίζεται σε τεχνικές (techniques) και έχει παραδοτέα (deliverables) Υπάρχουν πολλές διαφορετικές μεθοδολογίες με διαφορετικά στάδια ή διαφορετική σειρά σταδίων

5 1 η φάση Προγραμματισμός Απάντηση στην ερώτηση: Γιατί και πώς θα κατασκευαστεί το σύστημα; (A) Έναρξη Έργου Παραδοτέο: Μελέτη Σκοπιμότητας Τεχνική επιτευξιμότητα ιδέας μπορούμε να το φτιάξουμε? Οικονομική σκοπιμότητα θα προσφέρει όφελος στην επιχείρηση? Εταιρική σκοπιμότητα αν το κατασκευάσουμε, θα χρησιμοποιηθεί? (B) Διαχείριση Έργου (Project Management) που διαρκεί όσο και το έργο Ο συντονιστής του έργου (project manager) δημιουργεί και ενημερώνει το πλάνο εργασίας (work plan), στελεχώνει το έργο, και παρακολουθεί και ελέγχει την πρόοδό του Παραδοτέο: Πλάνο Έργου (project plan)

6 2 η φάση Ανάλυση Απάντηση στις ερωτήσεις: Ποιος θα χρησιμοποιήσει το σύστημα; Τι θα κάνει το σύστημα; Πού και πότε θα χρησιμοποιείται το σύστημα; Στάδια 1. Στρατηγική ανάλυσης ανάλυση υπάρχοντος συστήματος και των προβλημάτων του και περιγραφή του τρόπου σχεδιασμού ενός νέου συστήματος 2. Συλλογή απαιτήσεων (μέσω συνεντεύξεων, ερωτηματολογίων, κλπ) ανάπτυξη ιδέας νέου συστήματος, ανάπτυξη μοντέλων 3. Πρόταση συστήματος συνδυασμός σε έγγραφο αναλύσεων, κεντρικής ιδέας, μοντέλων Αποτέλεσμα/Παραδοτέα: Έγγραφο Περιγραφής Απαιτήσεων, Μοντελοποίηση συστήματος

7 3 η φάση Σχεδίαση Απάντηση στην ερώτηση: Πώς θα λειτουργεί το σύστημα; Στάδια: 1. Στρατηγική Σχεδιασμού (Design Strategy) Ανάπτυξη από τον ίδιο τον οργανισμό, ή εξωτερική ανάθεση (outsourcing) σε άλλη εταιρεία, ή αγορά υπάρχοντος πακέτου λογισμικού 2. Αρχιτεκτονικός Σχεδιασμός (Architecture Design) υλικό, λογισμικό, δικτυακή υποδομή, διεπαφή χρήστη, φόρμες, αναφορές, βάσεις δεδομένων, κλπ. 3. Προδιαγραφές Αρχείων και Βάσεων Δεδομένων ποια ακριβώς δεδομένα θα αποθηκεύονται και πού 4. Σχεδιασμός των Προγραμμάτων ποια προγράμματα πρέπει να γραφτούν και τι θα κάνει το κάθε ένα; Αποτέλεσμα/Παραδοτέα: Προδιαγραφή Συστήματος (System Specification) που στη συνέχεια δίνεται στην ομάδα των προγραμματιστών για την υλοποίηση

8 4 η φάση Υλοποίηση Στάδια: 1. Κατασκευή (Construction) 2. Εγκατάσταση (Installation) και Μετάβαση (Transition) Το νέο σύστημα αντικαθιστά το υπάρχον (είτε εξ ολοκλήρου, είτε μεσολαβεί διάστημα παράλληλης λειτουργίας των δύο συστημάτων, ή σε εγκατάσταση/λειτουργία σε φάσεις), πλάνο εκπαίδευσης. 3. Πλάνο Υποστήριξης (Support Plan): Τυπική ή άτυπη αξιολόγηση του συστήματος μετά την εγκατάσταση, και συστηματικός τρόπος εντοπισμού και καταγραφής των αλλαγών (ή βελτιώσεων) που πρέπει να γίνουν. Συνήθως το πιο χρονοβόρο και ακριβό τμήμα

9 Προϊόντα παραδοτέα κάθε φάσης Προγραμματισμός Πλάνο Έργου Ανάλυση Έγγραφο Περιγραφής Απαιτήσεων Μοντελοποίηση συστήματος Σχεδίαση Προδιαγραφή Συστήματος Υλοποίηση Σύστημα και Πλάνο Συντήρησης

10 Φάσεις και μεθοδολογία! Πώς ΟΜΩΣ σχετίζονται οι φάσεις με την έννοια της μεθοδολογίας; Μεθοδολογίες (ή Μοντέλα Ανάπτυξης, Μοντέλα Κύκλου Ζωής) Η μεθοδολογία μας προτείνει έναν τρόπο εργασίας Πώς ακριβώς θα εργαστούμε; Ποια βήματα; Με ποια σειρά; Ποια τα παραδοτέα και για πότε;

11 Κατηγοριοποίηση Μεθοδολογιών ανάλογα με το πού δίνεται έμφαση Διαδικασιο-κεντρικές (process centered) Δεδομενο-κεντρικές (data centered) Αντικειμενο-στρεφείς (object-oriented)

12 Κατηγοριοποίηση Μεθοδολογιών ανάλογα με το πού δίνεται έμφαση Διαδικασιο-κεντρικές (process centered) Διαδικασίες Άνθρωποι Δεδομένα Τεχνουργήματα

13 Κατηγοριοποίηση Μεθοδολογιών ανάλογα με το πού δίνεται έμφαση Δεδομενο-κεντρικές (data centered) Διαδικασίες Άνθρωποι Δεδομένα Τεχνουργήματα

14 Κατηγοριοποίηση Μεθοδολογιών ανάλογα με το πού δίνεται έμφαση Αντικειμενο-στρεφείς (object oriented) Διαδικασίες Άνθρωποι Δεδομένα Τεχνουργήματα

15 Έμφαση μεθοδολογιών Process centered (methodologies) - Emphasize on process models Focus Business processes Data that support the business Process & Data (methodologies) - Balance both by incorporating them into ONE model Data centered (methodologies) - Emphasize on data models Object oriented Δίνει έμφαση στα αντικείμενα (δεδομένα & διαδικασίες) & χρησιμοποιεί τη UML ως γλώσσα μοντελοποίησης

16 Αδυναμίες δομημένης ανάλυσης, σχεδίασης και ανάπτυξης Εγγενής αδυναμία στην απεικόνιση των οντοτήτων του πραγματικού κόσμου σε συσταστικά λογισμικού ανεξάρτητα από τα δεδομένα Δύσκολη η πειθαρχία και η αυστηρή υλοποίηση προτύπων Η «επιχειρησιακή λογική δεν μοντελοποιείται εύκολα και δεν αντιστοιχίζεται σε δεδομένα και λειτουργίες/συναρτήσεις εντελώς ανεξάρτητες μεταξύ τους Δύσκολη η επαναχρησιμοποίηση συστατικών λογισμικού σε νέες εφαρμογές Δύσκολες η ανάλυση και η προδιαγραφή απαιτήσεων και ΜΗΝ ΞΕΧΝΑΜΕ ό,τι αποτελεί κρίσιμο τμήμα στον κύκλο ζωής λογισμικού

17 Γιατί από τη δομημένη προσέγγιση στην αντικειμενοστρεφή μοντελοποίηση? Ανάγκη για γρήγορη πρόοδο στην ανάπτυξη συστημάτων Οι δομημένες μεθοδολογίες ανάλυσης και σχεδιασμού στηρίζονται σε διαδοχικούς μετασχηματισμούς που αλλάζουν δραματικά τη δομή και τα στοιχεία κάθε φάσης, καθώς πάμε από την ανάλυση στον προγραμματισμό μέσω σχεδιασμού (ΔΡΔ, ΔΔΠ, ψευδοκώδικας, κώδικας) Δύο βασικά μειονεκτήματα: Η αλλαγή από μία φάση στην άλλη και ο έλεγχος της ορθότητας κάθε μετασχηματισμού είναι δύσκολα Ακόμη και εάν οι ομάδες ανάπτυξης κάθε φάσεις καταφέρουν να κάνουν τους μετασχηματισμούς με επιτυχία, αυτός ο σωστός μετασχηματισμός δεν διαρκεί πολύ. Όταν νέες απαιτήσεις παρουσιασθούν συχνά κωδικοποιούνται αμέσως, με αλλαγές στον υπάρχοντα κώδικα. Οπότε ο φυσικός σχεδιασμός δεν αντιστοιχεί στο υπάρχον πρόγραμμα λογισμικού.

18 Από τη δομημένη στην αντικειμενοστρεφή μοντελοποίηση

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

20 Αντικειμενοστρεφής προσέγγιση Αντικειμενοστρεφής θεώρηση Μπορούμε να θεωρήσουμε τον πραγματικό κόσμο σαν ένα σύνολο από αντικείμενα τα οποία επικοινωνούν μεταξύ τους μέσω μηνυμάτων Στόχος είναι: η μοντελοποίηση αντικειμένων του πραγματικού κόσμου και της επικοινωνίας τους και ο μετασχηματισμός των μοντέλων αυτών σε αντικειμενοστρεφές λογισμικό Τι χρειάζεται: Αντικειμενοστρεφής γλώσσα μοντελοποίησης (π.χ. UML) -> Αντικειμενοστρεφή μοντέλα Αντικειμενοστρεφής μεθοδολογία ανάπτυξης (π.χ. Rational Unified Process) Αντικειμενοστρεφή εργαλεία ανάπτυξης Case Tools, π.χ. Rational Rose, ArgoUML, StarUML Γλώσσες προγραμματισμού, π.χ. C++, Java

21 Αντικειμενοστρεφής προσέγγιση Στοχεύει στην επιτάχυνση της διαδικασίας ανάπτυξης λογισμικού Είναι ευέλικτη (διευκολύνει την αλλαγή απαιτήσεων, την σταδιακή βελτίωση και επέκταση, τον έλεγχο, την συντήρηση) Έχει έμφυτη την αρχή της επανάληψης (επιστροφή σε προηγούμενες φάσεις) Εκμεταλλεύεται τις αρχές και τεχνικές του αντικειμενοστρεφούς προγραμματισμού: Ενθυλάκωση (encapsulation) Πολυμορφισμός (polymorphism) Κληρονομικότητα (inheritance) Επαναχρησιμοποίηση (reuse) Αφαίρεση (abstraction)

22 Αντικειμενοστρεφής προσέγγιση Το αντικειμενοστρεφές λογισμικό είναι ευκολότερο στην αρχική του σύλληψη μια και τα αντικείμενα είναι εν μέρει οντότητες του πραγματικού κόσμου Το αντικειμενοστρεφές λογισμικό είναι ευκολότερο στην εξέλιξή του. Η αντικειμενοστρεφής προσέγγιση επιτρέπει τη δημιουργία λογισμικού με βάση τα συστατικά (components) Σύγχρονες τεχνολογίες κατασκευής κατανεμημένων συστημάτων προσανατολισμένων στη σύνδεση επιχειρήσεων και στη σύνδεση επιχειρηματικών εφαρμογών (Enterprise Application Integration EAI), όπως οι Υπηρεσίες του παγκόσμιου ιστού (Web Services), έχουν σαν τεχνολογικό υπόβαθρο αντικειμενοστρεφείς γλώσσες προγραμματισμού (π.χ. Java, C#).

23 Αντικειμενοστρεφής προσέγγιση Η αντικειμενοστρεφής προσέγγιση διευκολύνει τη μετάβαση από τη μία φάση στην άλλη παραμερίζοντας το εμπόδιο του ριζικού μετασχηματισμού. Η μετάβαση από φάση σε φάση είναι ευκολότερη διότι σε κάθε φάση χρησιμοποιείται η ίδια «γλώσσα»: Τα αντικείμενα του πραγματικού (φυσικού) κόσμου: μοντελοποιούνται ως αντικείμενα (στη φάση ανάλυσης), μεταφράζονται άμεσα σε αντικείμενα σχεδίασης (στη φάση της σχεδίασης) υλοποιούνται ως αντικείμενα μιας αντικειμενοστρεφούς γλώσσας προγραμματισμού (Object Oriented Programming -OOP) ή Βάσης Δεδομένων (Object Oriented Data Base Systems - OODBS)

24 Αντικειμενοστρεφής Μεθοδολογία Ανάλυσης και Σχεδίασης Βασικά χαρακτηριστικά: 1. Use case driven Διαδικασία ανάπτυξης συστημάτων με βάση τις περιπτώσεις χρήσεων 2. Architecture centric Διαδικασία ανάπτυξης συστημάτων με βάση την αρχιτεκτονική 3. Iterative and incremental Επαναληπτική και αυξητική διαδικασία ανάπτυξης συστημάτων

25 Αντικειμενοστρεφής Μεθοδολογία Ανάλυσης και Σχεδίασης 1) Use case driven οδηγούμενη από Περιπτώσεις Χρήσης (Use Cases) Κύρια εργαλεία μοντελοποίησης που καθορίζουν τη συμπεριφορά του συστήματος είναι οι περιπτώσεις χρήσης Περιγράφει πώς αλληλεπιδρά ο χρήστης με το σύστημα για να εκτελέσει μία δραστηριότητα. Χρησιμοποιούνται για να προσδιορίσουν τις απαιτήσεις από το σύστημα και να τις μεταφέρουν στους προγραμματιστές που είναι υπεύθυνοι για την κατασκευή του.

26 Αντικειμενοστρεφής Μεθοδολογία Ανάλυσης και Σχεδίασης 1) Use case driven οδηγούμενη από Περιπτώσεις Χρήσης (Use Cases) Οι περιπτώσεις χρήσης χρησιμοποιούνται ως βασικά στοιχεία για: τον καθορισμό της συμπεριφοράς του συστήματος την επαλήθευση της αρχιτεκτονικής του συστήματος τη δοκιμή του συστήματος την επικοινωνία μεταξύ αυτών που εμπλέκονται στην ανάπτυξη του συστήματος

27 Αντικειμενοστρεφής Μεθοδολογία Ανάλυσης και Σχεδίασης 2) Architecture centric με επίκεντρο την αρχιτεκτονική Η υποκείμενη αρχιτεκτονική λογισμικού της προδιαγραφής του συστήματος: χρησιμοποιείται ως βασικό στοιχείο για την κατανόηση, την κατασκευή, τη διαχείριση και την εξέλιξη του υπό κατασκευή συστήματος πρέπει να οδηγεί στην προδιαγραφή (specification), κατασκευή (construction) και τεκμηρίωση (documentation) του συστήματος Πρέπει να υποστηρίζονται τουλάχιστον 3 διαφορετικές όψεις της αρχιτεκτονικής: Λειτουργική (Functional) συμπεριφορά συστήματος από χρήστη Στατική (Static) σύστημα με βάση κλάσεις, γνωρίσματα, μεθόδους Δυναμική (Dynamic) συμπεριφορά με βάση μηνύματα που μεταβιβάζονται μεταξύ αντικειμένων και αλλαγών κατάστασης

28 Αντικειμενοστρεφής Μεθοδολογία Ανάλυσης και Σχεδίασης 3) Iterative and incremental Επαναληπτική και αυξητική διαδικασία ανάπτυξης συστημάτων Συνεχείς δοκιμές και βελτιώσεις H επαναληπτική (iterative) διαδικασία αφορά στη διαχείριση των εκτελέσιμων εκδόσεων ενός συστήματος Η αυξητική (incremental) διαδικασία αφορά στη συνεχή ολοκλήρωση της αρχιτεκτονικής για την παραγωγή των εκτελέσιμων εκδόσεων του συστήματος Το λογισμικό δεν εκδίδεται μία και καλή στο τέλος του έργου Αρκετές επαναλήψεις και κάθε επανάληψη φέρνει το σύστημα όλο και πιο κοντά στις πραγματικές ανάγκες του χρήστη Κάθε νέα έκδοση αποτελεί βελτιωμένη έκδοση της προηγούμενης

29 Πανεπιστήμιο Πειραιά Τμήμα Ψηφιακών Συστημάτων Μοντέλα Κύκλου Ζωής Λογισμικού

30 Διαδικασία τεχνολογίας συστημάτων 2006 I Sommerville Βασικές αρχές Τεχνολογίας Λογισιμικού, 8 η αγγ. έκδοση

31 Προσδιορισμός φάσεων και ενεργειών Δεν υπάρχει ένας και μοναδικός τρόπος! Εξαρτώνται από: Ιδιαίτερες συνθήκες που επικρατούν εμπειρία, τεχνογνωσία κατασκευαστή Μέγεθος και θεματικό πεδίο εφαρμογής λογισμικού Εκάστοτε περιβάλλον ανάπτυξης Πιθανότητα να αλλάξουν οι απαιτήσεις από την εφαρμογή

32 Ορισμοί Δραστηριότητα ή διαδικασία ανάπτυξης λογισμικού (software process) καθορίζει ποιες ενέργειες πρέπει να γίνουν για να επιτευχθεί ένα επιθυμητό αποτέλεσμα σε κάποια από τις φάσεις του κύκλου ζωής. Μία διαδικασία μπορεί να αναλύεται σε περισσότερες από μία επιμέρους φάσεις. Μεθοδολογία ανάπτυξης λογισμικού (software development methodology) καθορίζει το πώς θα πρέπει να εκτελούνται οι δραστηριότητες ανάπτυξης, δηλαδή ποιες επιμέρους ενέργειες περιλαμβάνουν, ποια βήματα γίνονται σε καθεμιά, ποια προϊόντα παράγονται, καθώς και πότε αυτές θεωρούνται περατωθείσες.

33 Ορισμοί - συνέχεια Εργαλείο λογισμικού (CASE: Computer-Aided Software Engineering) είναι ένα σύστημα (συνήθως είναι και το ίδιο εφαρμογή λογισμικού) το οποίο υποστηρίζει τη μερική ή (σπάνια) ολική αυτοματοποίηση των εργασιών που λαμβάνουν χώρα κατά την εφαρμογή των μεθοδολογιών ανάπτυξης λογισμικού. Μοντέλο Κύκλου Ζωής Λογισμικού είναι μία περιγραφή των δραστηριοτήτων και των επιμέρους φάσεων από τις οποίες διέρχεται μία εφαρμογή λογισμικού από τη σύλληψη μέχρι την απόσυρσή της, καθώς και των εργασιών που λαμβάνουν χώρα σε καθεμία από αυτές τις φάσεις.

34 Σχέσεις εννοιών στην ανάπτυξη λογισμικού Εργαλεία Μεθοδολογίες Διαδικασίες ανάπτυξης Μοντέλα Κύκλου Ζωής Τα μοντέλα κύκλου ζωής λογισμικού προσδιορίζουν τις διαδικασίες ανάπτυξης που λαμβάνουν χώρα κατά τις γενικές φάσεις «κατασκευή» και «χρήση-συντήρηση» προσδιορίζοντας τις επιμέρους φάσεις στις οποίες αυτές αναλύονται, τα προϊόντα που παράγονται και τη σειρά εκτέλεσής τους. Κάθε διαδικασία ανάπτυξης περισσότερες από μία επιμέρους φάσεις περισσότερες από μία εργασίες

35 Χαρακτηριστικά καλής διαδικασίας ανάπτυξης λογισμικού Κατανόηση Είναι η διαδικασία σαφώς καθορισμένη και κατανοητή? Παρακολούθηση Είναι δυνατόν να παρακολουθήσουμε εξωτερικά την πρόοδο της διαδικασίας? Υποστήριξη Είναι δυνατόν να υποστηριχθεί η διαδικασία με εργαλεία (π.χ. CASE tools)? Αποδοχή Είναι η διαδικασία αποδεκτή από αυτούς που συμμετέχουν σε αυτή?

36 Χαρακτηριστικά καλής διαδικασίας ανάπτυξης λογισμικού Αξιοπιστία Ανακαλύπτονται τα λάθη της διαδικασίας πριν μετατραπούν σε λάθη στο προϊόν? Ανθεκτικότητα Είναι δυνατόν να αντεπεξέλθει η διαδικασία σε μη αναμενόμενα προβλήματα? Συντήρηση Είναι δυνατόν να εξελιχθεί η διαδικασία για την κάλυψη μεταβαλλόμενων προδιαγραφών και απαιτήσεων? Ταχύτητα Πόσο γρήγορα παράγεται το προϊόν?

37 Διάφορα μοντέλα που διαφοροποιούνται ως προς... Σύλληψη ιδέας τρόπου κατασκευής Επιμέρους φάσεις Επαναληπτικότητα εργασιών Εμβέλεια εργασιών έκταση στην οποία εφαρμόζονται οι διαδικασίες Ενδιάμεσα προϊόντα και περιγραφή Ενδιάμεσες αποτιμήσεις από πελάτη ή κατασκευαστή Οικονομικές και επιχειρηματικές πλευρές

38 Διαδικασία επίλυσης προβλημάτων Είναι κάθε μία από τις ενέργειες που περιγράφεται σε ένα μοντέλο κύκλου ζωής Ορισμός του προβλήματος Αποτίμηση τρέχουσα κατάστασης (μονάδα) Ενσωμάτωση της λύσης στο σύστημα Επιλογή μιας λύσης Υλοποίηση της λύσης Αποτίμηση τρέχουσα κατάστασης (σύστημα) Μικροσκοπικό επίπεδο Μονάδες υπό κατασκευή λογισμικού Μακροσκοπικό επίπεδο Ολόκληρο το σύστημα

39 Κύκλος Ζωής Λογισμικού Εξαγωγή & Ανάλυση Απαιτήσεων Σχεδίαση Συστήματος Σχεδίαση Προγραμμάτων Κωδικοποίηση Ελεγχος Μονάδων και Ενοποίησης Έλεγχος Συστήματος Έλεγχος Αποδοχής Παράδοση, Λειτουργία & Συντήρηση Συστήματος

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

41 Ανάλυση απαιτήσεων Δόμηση απαιτήσεων Έλεγχος απαιτήσεων Προσδιορισμός εξωτερικών παραγόντων που επηρεάζουν τις απαιτήσεις Προσδιορισμός αλληλεξαρτήσεων μεταξύ απαιτήσεων Γνώση σχετικά με τις απαιτήσεις πριν συνεχίσουμε

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

43 Σχεδίαση συστήματος 2006 I Sommerville Βασικές αρχές Τεχνολογίας Λογισιμικού, 8 η αγγ. έκδοση

44 Απαιτήσεις και σχεδιασμός Η προδιαγραφή των απαιτήσεων και ο σχεδιασμός του συστήματος είναι άρρηκτα συνδεδεμένες έννοιες. Οι περιορισμοί που τίθενται από υπάρχοντα συστήματα και από το περιβάλλον του συστήματος μπορεί να οριοθετούν τις δυνατές σχεδιαστικές επιλογές και έτσι απαίτηση μπορεί να αποτελούν ακόμα και αυτές οι επιλογές που θα χρησιμοποιηθεί. Ίσως χρειαστεί κάποιος αρχικός σχεδιασμός για τη δόμηση της διαδικασίας καθορισμού των απαιτήσεων. Καθώς η διαδικασία του σχεδιασμού προχωρά, διαπιστώνετε περισσότερα πράγματα για τις απαιτήσεις I Sommerville Βασικές αρχές Τεχνολογίας Λογισιμικού, 8 η αγγ. έκδοση

45 Υλοποίηση Μετατροπή της σχεδίασης σε μορφή κατανοητή από τη μηχανή Λεπτομερής δημιουργία διαγραμμάτων σε CASE tool Συγγραφή κώδικα σε γλώσσα προγραμματισμού

46 Ανάπτυξη υποσυστημάτων Συνήθως πρόκειται για παράλληλα έργα ανάπτυξης του υλικού, του λογισμικού και των επικοινωνιών. Μπορεί να συνεπάγεται και την προμήθεια συστημάτων εμπορικών εφαρμογών. Έλλειψη επικοινωνίας μεταξύ των ομάδων υλοποίησης. Αν ο μηχανισμός υποβολής προτεινόμενων αλλαγών στο σύστημα είναι γραφειοκρατικός και αργός, το χρονοδιάγραμμα ανάπτυξης μπορεί να επεκταθεί εξαιτίας της ανάγκης για επανεπεξεργασία I Sommerville Βασικές αρχές Τεχνολογίας Λογισιμικού, 8 η αγγ. έκδοση

47 Έλεγχος Διαδικασία εκτέλεσης και σχεδιαστικής ανασκόπησης του συστήματος με σκοπό την ανεύρεση λαθών

48 Ενοποίηση συστήματος Η διαδικασία σύνθεσης του υλικού, του λογισμικού και του ανθρώπινου δυναμικού για τη δημιουργία ενός συστήματος. Πρέπει να γίνεται βαθμιαία ώστε τα υποσυστήματα να προστίθενται ένα-ένα. Σε αυτό το στάδιο συνήθως εντοπίζονται προβλήματα που αφορούν τη διασύνδεση μεταξύ των υποσυστημάτων. Μπορεί να είναι προβλήματα που οφείλονται στην έλλειψη συντονισμού της παράδοσης των συστατικών στοιχείων του συστήματος I Sommerville Βασικές αρχές Τεχνολογίας Λογισιμικού, 8 η αγγ. έκδοση

49 Εγκατάσταση συστήματος Μετά την ολοκλήρωση, το σύστημα πρέπει να εγκατασταθεί στο περιβάλλον του πελάτη Εσφαλμένες παραδοχές σχετικά με το περιβάλλον Αντίσταση εκ μέρους του ανθρώπινου παράγοντα στην εισαγωγή ενός νέου συστήματος Το νέο σύστημα μπορεί να χρειαστεί να συνυπάρξει με εναλλακτικά συστήματα για κάποιο χρονικό διάστημα Προβλήματα που αφορούν τη φυσική εγκατάσταση του συστήματος (πχ. προβλήματα με την καλωδίωση) Πρέπει να προσδιοριστούν τα περιεχόμενα της εκπαίδευσης των χειριστών I Sommerville Βασικές αρχές Τεχνολογίας Λογισιμικού, 8 η αγγ. έκδοση

50 Συντήρηση Λόγοι: Διόρθωση σφαλμάτων. Προσαρμογή σε αλλαγές: Προδιαγραφών / Απαιτήσεων Περιβάλλοντος Διευκόλυνση μελλοντικής συντήρησης

51 Εξέλιξη συστήματος Τα μεγάλα συστήματα έχουν πολύ μεγάλη διάρκεια ζωής. Πρέπει να εξελίσσονται για να πληρούν τις μεταβαλλόμενες απαιτήσεις. Η εξέλιξη είναι εν γένει δαπανηρή Οι προτεινόμενες αλλαγές πρέπει να αναλύονται από τεχνική και επιχειρηματική σκοπιά Επειδή τα υποσυστήματα δεν είναι ποτέ εντελώς ανεξάρτητα, μπορεί να ανακύψουν απρόσμενα προβλήματα Σπάνια καταγράφεται η συλλογιστική που οδήγησε στις αρχικές σχεδιαστικές αποφάσεις Η δομή των συστημάτων φθείρεται από τις αλλαγές που πραγματοποιούνται σε αυτά. Υπάρχοντα συστήματα που πρέπει να συντηρούνται ονομάζονται και κληρονομημένα συστήματα I Sommerville Βασικές αρχές Τεχνολογίας Λογισιμικού, 8 η αγγ. έκδοση

52 Απόσυρση συστήματος Το σύστημα τίθεται εκτός υπηρεσίας μετά το τέλος της ωφέλιμης διάρκειας ζωής του. Μπορεί να απαιτεί την απομάκρυνση υλικών (πχ. επικίνδυνων χημικών) που ρυπαίνουν το περιβάλλον Η δραστηριότητα αυτή πρέπει να προβλέπεται στο σχεδιασμό του συστήματος μέσω ενθυλάκωσης. Μπορεί να απαιτείται αναδόμηση και μετατροπή των δεδομένων προκειμένου να χρησιμοποιηθούν σε κάποιο άλλο σύστημα I Sommerville Βασικές αρχές Τεχνολογίας Λογισιμικού, 8 η αγγ. έκδοση

53 Η διαδικασία ανάπτυξης λογισμικού στην πραγματικότητα

54 Χαρακτηριστικά Μοντέλα Κύκλου Ζωής Λογισμικού Μοντέλο καταρράκτη Μοντέλο πρωτοτυποποίησης Μοντέλο λειτουργικής επαύξησης Σπειροειδές μοντέλο Μοντέλο πίδακα Γενικό μοντέλο κύκλου ζωής

55 Διαδικασίες ανάπτυξης Μοντέλο καταρράκτη Επιμέρους φάσεις Εργασίες Ολόκληρη η εφαρμογή λογισμικού διέρχεται διαδοχικές φάσεις ανάπτυξης Ανάπτυξη λογισμικού: μεγάλος ογκόλιθος που μεταφέρεται από ένα σημείο σε άλλο περνώντας από στάσεις, αλλά μεταφέροντας ολόκληρο τον ογκόλιθο από τη μία στάση στην άλλη

56 Χαρακτηριστικά μοντέλου καταρράκτη Το μοντέλο καταρράκτη δεν κάνει υποθέσεις για τη μεθοδολογία και τους συμβολισμούς σε κάθε στάδιο Βασικές αρχές μοντέλου: Ακολουθία βημάτων Κάθε βήμα είναι σαφώς καθορισμένο Κάθε βήμα καταλήγει στη δημιουργία προϊόντος (έγγραφο ή κώδικας) Κάθε προϊόν αποτελεί τη βάση για το επόμενο βήμα Η ορθότητα κάθε προϊόντος μπορεί να ελεγχθεί

57 Μοντέλο καταρράκτη Επικύρωση (validation) επαληθεύεται ότι έχουν υλοποιηθεί όλες οι προδιαγραφές και το λογισμικό ανταποκρίνεται στις απαιτήσεις από το σύστημα, «το λογισμικό κάνει αυτό που ήθελε ο πελάτης να κάνει» Επαλήθευση (verification) επαληθεύεται ότι κάθε λειτουργία/μονάδα του συστήματος εκτελείται σωστά από προγραμματιστικής άποψης, «το λογισμικό κάνει σωστά αυτό που ήθελε ο πελάτης να κάνει» Κάθε επιμέρους φάση ολοκληρώνεται με μία εργασία επαλήθευσης/επικύρωσης των προϊόντων της κατά την οποία αποφασίζεται η μετάβαση ή όχι στην επόμενη Ακολουθιακή ανάπτυξη οι επιμέρους φάσεις είναι διακριτές και ακολουθούν η μία την άλλη, για να ξεκινήσει μία φάση πρέπει να έχει ολοκληρωθεί πλήρως η προηγούμενη

58 Μοντέλο καταρράκτη Καθορισμός απαιτήσεων από το σύστημα και από το λογισμικό Προκαταρκτική σχεδίαση λογισμικού καθορισμός μονάδων που θα αποτελούν το λογισμικό και οι μεταξύ τους συσχετίσεις καθορισμός σε περισσότερα από ένα επίπεδα λεπτομέρειας, ανάλογα με το μέγεθος και την πολυπλοκότητα Λεπτομερή σχεδίαση λογισμικού καθορισμός εσωτερικής δομής κάθε μονάδας λογισμικού (αλγόριθμοι, δομές δεδομένων κτλ) Συγγραφή πηγαίου κώδικα Συνένωση μονάδων σε σύστημα και έλεγχος συστήματος Παράδοση προϊόντος στον πελάτη και πέρασμα στη φάση λειτουργίας και συντήρησης

59 Μοντέλο καταρράκτη Το πιο διαδεδομένο μοντέλο κύκλου ζωής λογισμικού Χρήσιμο όταν οι απαιτήσεις από το λογισμικό είναι γνωστές από την αρχή και δεν μεταβάλλονται κατά την ανάπτυξη του λογισμικού! Μειονεκτήματα???

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

61 Μοντέλο πρωτοτυποποίησης Ανάπτυξη λογισμικού σε τμήματα, «πρωτότυπα», κάθε φορά με περισσότερα χαρακτηριστικά Επαναληπτικό μοντέλο οι διαδικασίες ανάπτυξης επαναλαμβάνονται για ένα τμήμα του συστήματος κάθε φορά

62 Μοντέλο πρωτοτυποποίησης Κάθε πρωτότυπο περιλαμβάνει τις βασικές από τις λειτουργίες που προορίζεται να εκτελεί το λογισμικό και το δοκιμάζει ο πελάτης Επανάληψη διαδικασίας κατασκευής νέου πρωτοτύπου μέχρι να γίνει αποδεκτό

63 Μοντέλο πρωτοτυποποίησης Πλεονεκτήματα Δυνατότητα απόκτησης άποψης για το λογισμικό νωρίτερα από το μοντέλο του καταρράκτη λιγότερες καθυστερήσεις και κόστη Σημαντική η διοίκηση του έργου υλοποιησιμότητα και εύκολη τροποποίηση πρωτοτύπου Αντιμετωπίζει την ασάφεια στις απαιτήσεις Αρχικά πρωτότυπα χρησιμοποιούνται για εξοικείωση από τους χρήστες Μεγαλύτερη πιθανότητα ανάπτυξης φιλικού προς το χρήστη λογισμικού Ο πελάτης εμπλέκεται στην ανάπτυξη του προϊόντος Αυξανόμενη σταδιακά ικανοποίηση του πελάτη Επικοινωνία χρηστών / ομάδας ανάπτυξης Χρησιμοποιείται Σε εφαρμογές που οι απαιτήσεις δεν είναι γνωστές από την αρχή

64 Μοντέλο πρωτοτυποποίησης Μειονεκτήματα Όχι μεγάλο μέγεθος εφαρμογής μεγάλος χρόνος ανάπτυξης πρωτοτύπου μείωση απαιτούμενης ευελιξίας

65 Διαχείριση κινδύνου Διαχειριστής έργου: Επιδιώκει ελαχιστοποίηση του ρίσκου Ρίσκο: μέτρο της αβεβαιότητας ως προς το αποτέλεσμα Δραστηριότητες υψηλού ρίσκου αυξάνουν το κόστος και προκαλούν καθυστερήσεις Το ρίσκο σχετίζεται με την ποσότητα και την ποιότητα της διαθέσιμης πληροφορίας. Όσο λιγότερη πληροφορία τόσο μεγαλύτερο το ρίσκο

66 Παραδείγματα κινδύνου Κατά τη διάρκεια ανάπτυξης εισαγωγή λογισμικού από ανταγωνιστή Αποχώρηση ατόμων από την ομάδα ανάπτυξης Ανικανότητα εμπρόθεσμης υλοποίησης ορισμένων σταδίων Το λογισμικό πληροί τις προδιαγραφές αλλά έχει πολύ μεγάλο χρόνο εκτέλεσης Μεγάλη κατανάλωση μνήμης Εμφάνιση νέων εργαλείων ανάπτυξης Λάθος κατανόηση μιας απαίτησης Αλλαγή ορισμένων από τις απαιτήσεις Αλλαγή του υλικού Μείωση προϋπολογισμού Βλάβες στο υλικό της ομάδας ανάπτυξης

67 Διαχείριση κινδύνων σε μοντέλα κύκλου ζωής λογισμικού Καταρράκτη Υψηλό ρίσκο για νέα συστήματα λόγω προβλημάτων στις προδιαγραφές και στη σχεδίαση Χαμηλό ρίσκο για πλήρως κατανοητά συστήματα που αναπτύσσονται με γνωστή τεχνολογία Πρωτοτυποποίησης Χαμηλό ρίσκο για νέες εφαρμογές λόγω του γεγονότος ότι οι προδιαγραφές και η υλοποίηση εξετάζονται ανά βήμα Υψηλό ρίσκο λόγω έλλειψης παρατήρησης

68 Μοντέλο λειτουργικής επαύξησης Ακολουθιακή ανάπτυξη μοντέλου καταρράκτη Τμηματική ανάπτυξη μοντέλου πρωτοτυποποίησης Κατάτμηση λογισμικού σε τμήματα ανεξάρτητα, το κάθε τμήμα ακολουθεί ακολουθιακή ανάπτυξη Συνένωση στο τέλος

69 Μοντέλο λειτουργικής επαύξησης Αρχική φάση ανάλυσης και σχεδίασης: σε ποια τμήματα θα κατατμηθεί η εφαρμογή??? Ανάπτυξη τμημάτων ανεξάρτητα και παράλληλα Ενσωμάτωση κάθε τμήματος μετά την ολοκλήρωση της ανάπτυξής του στο σύνολο της εφαρμογής «λειτουργική επαύξηση»

70 Μοντέλο λειτουργικής επαύξησης Πλεονεκτήματα Δυνατότητα παράλληλης ανάπτυξης Μικρότερος χρόνος Διαδοχικός εμπλουτισμός λειτουργικών χαρακτηριστικών Μειονεκτήματα Σημαντική η αρχική κατάτμηση και γενική σχεδίαση του συστήματος Αν έχουμε μεταβολή λειτουργικών απαιτήσεων κατά τη χρήση του ημιτελούς συστήματος, μπορεί να προκύψει πρόβλημα λόγω ακατάλληλης κατάτμησης εφαρμογής Χρησιμοποιείται Σε μεγάλες εφαρμογές λογισμικού Με γνωστές απαιτήσεις και μικρή μεταβλητότητα κατά την ανάπτυξη

71 Τι είδαμε μέχρι τώρα? Παραλλαγές της βασικής ιδέας του μοντέλου του καταρράκτη Ακολουθιακή διαδικασία ανάπτυξης είτε σε ολόκληρο είτε σε μέρος του συστήματος Αυθαίρετη κατάτμηση στα μοντέλα πρωτοτυποποίησης και λειτουργικής επαύξησης Καμία εκτίμηση ρίσκου Πιθανή οπισθοδρόμηση ή ανατροπή Κόστος σε χρόνο και χρήμα Δύσκολη η μετά πειθαρχίας αποδοχή των αυστηρών φάσεων του μοντέλου του καταρράκτη

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

73 Σπειροειδές μοντέλο Γενίκευση μοντέλων πρωτοτυποποίησης και λειτουργικής επαύξησης με τα εξής νέα στοιχεία: Οι φάσεις και οι διαδικασίες ανάπτυξης λογισμικού δεν είναι προκαθορισμένες από το μοντέλο, αλλά εξειδικεύονται στο χώρο εφαρμογής του Η ανάπτυξη ολόκληρου του συστήματος χωρίζεται σε πολλούς κύκλους, σε καθέναν προστίθενται νέα λειτουργικά χαρακτηριστικά Πριν από κάθε κύκλο, μελέτη σκοπιμότητας και ανάλυσης κινδύνων. Προκύπτουν: Συγκεκριμένες εργασίες που θα εκτελεστούν στον κύκλο Εφικτότητα εκτέλεσης του κύκλου

74 Σπειροειδές μοντέλο Κατηγορίες εργασιών Προσδιορισμός στόχων Επίλυση κινδύνων Εκτέλεση διαδικασιών ανάπτυξης λογισμικού Προγραμματισμός επόμενης φάσης ανάπτυξης

75 Σπειροειδές μοντέλο Κατηγορίες εργασιών Προσδιορισμός στόχων Καθορισμός αντικειμένων εργασιών κάθε επανάληψης Καταγραφή περιορισμών για το προϊόν και τη διαδικασία Κατασκευή αναλυτικού πλάνου διοίκησης Καταγραφή κινδύνων διαδικασίας Καταγραφή εναλλακτικών λύσεων αν υπάρχουν Επίλυση κινδύνων Ανάλυση κινδύνων Αποτίμηση κάθε εναλλακτικής λύσης Λήψη απόφασης για συνέχιση ή όχι, ποιο μοντέλο θα ακολουθηθεί, κατασκευή ή όχι πρωτοτύπου κ.ά.

76 Σπειροειδές μοντέλο Κατηγορίες εργασιών Εκτέλεση διαδικασιών ανάπτυξης λογισμικού Εκτέλεση βημάτων όπως αποφασίστηκαν για το τμήμα του συστήματος που αφορά η τρέχουσα επανάληψη Προγραμματισμός επόμενης φάσης ανάπτυξης

77 Σπειροειδές μοντέλο - Συμπεράσματα Δεν καθορίζει εκ των προτέρων: ποιες ακριβώς οι εργασίες ανάπτυξης λογισμικού που πρέπει να γίνουν σε ποια έκταση του συστήματος θα εφαρμοστούν Διαφορετικές διαδικασίες ανάπτυξης για διαφορετικά τμήματα λογισμικού ΣΗΜΑΝΤΙΚΟ ο καθορισμός λεπτομερειών υλοποίησης να γίνεται συνεχώς κατά την ανάπτυξη με ευθύνη και τεκμηρίωση από τον κατασκευαστή Η εφαρμογή του όχι πάντα εύκολη υπόθεση Εισαγωγή νέων εργασιών που αφορούν τεκμηρίωση σκοπιμότητας και τμηματικό προγραμματισμό ανάπτυξης ΑΡΑ κάποιο κόστος... ΟΜΩΣ μπορεί να αποσβεστεί από έγκαιρο εντοπισμό προβλημάτων και αποφυγή πιθανής αποτυχίας

78 Σπειροειδές μοντέλο Πόσο κατάλληλο είναι το σπειροειδές μοντέλο για υλοποίηση μικρών έργων ανάπτυξης λογισμικού?

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

80 Μοντέλο πίδακα Αντικειμενοστρεφής φιλοσοφία ανάπτυξης λογισμικού Επαναχρησιμοποίηση έτοιμων συστατικών

81 Μοντέλο πίδακα Αντικειμενοστρεφής τεχνολογία Οι έννοιες «ανάλυση-σχεδίασηκωδικοποίηση» έρχονται στο αντικειμενοστρεφές παράδειγμα πολύ πιο κοντά Το αποτέλεσμα κάθε διαδικασίας κατασκευής λογισμικού είναι όχι μόνο ένα σύστημα ΑΛΛΑ και επαναχρησιμοποιήσιμες μονάδες

82 Μοντέλο πίδακα Επικαλύψεις φάσεων «ανάλυση-σχεδίασηκωδικοποίηση» Ορισμένα συστατικά λογισμικού ενσωματώνονται σε δεξαμενή συστατικών και διατίθενται για χρήση στην ανάπτυξη νέων συστημάτων

83 Γενικό μοντέλο κύκλου ζωής Περιέχει γενικές κατευθύνσεις Εξειδεικεύονται στο εκάστοτε περιβάλλον ανάπτυξης, πρόβλημα κτλ Αφήνει σημαντικούς βαθμούς ελευθερίας στον κατασκευαστή Περιλαμβάνει φάσεις σύλληψης, κατασκευής και λειτουργίας Ανάλυση σε επιμέρους εργασίες Ανάλυση φάσης κατασκευής σε «κύκλους ανάπτυξης» - καθένας προσθέτει νέα χαρακτηριστικά και λειτουργίες

84 Γενικό μοντέλο κύκλου ζωής Μοντέλο καταρράκτη αλλά μόνο για το μικρό μέρος του κύκλου Ενσωματώνει χαρακτηριστικά πολλών μοντέλων Ανάπτυξη σε κύκλους σύμφωνα με τα χαρακτηριστικά και τις δυνατότητες του κατασκευαστή

85 Γενικό μοντέλο κύκλου ζωής Όλα τα μοντέλα κύκλου ζωής που αναφέρθηκαν μπορούν να θεωρηθούν ειδικές εκδοχές του γενικού μοντέλου κύκλου ζωής Κάθε κύκλος ανάπτυξης: Επανάληψη Βήμα επαύξησης Παράλληλη εκτέλεση τμήματος έργου Πλάνο εργασιών: Εκτίμηση ρίσκου συνέχισης ανάπτυξης

86 Σύγκριση μοντέλων κύκλου ζωής λογισμικού Μοντέλο Καταρράκτη Πρωτοτυποποίησης Λειτουργικής Επαύξησης Μέγεθος εφαρμογών Μικρό έως μεσαίο Μικρό έως μεσαίο Μεσαίο έως μεγάλο Μεταβολές στις απαιτήσεις Προσαρμοστικότητα στον κατασκευαστή Διάδοση Ανεπιθύμητες Καμία Μεγάλη με τάση μείωσης Δεκτές Μικρή Μικρή με τάση αύξησης Ανεπιθύμητες Καμία Μικρή με τάση μείωσης Σπειροειδές Μεσαίο έως μεγάλο Δεκτές Αρκετή Μικρή με τάση μείωσης Πίδακα Οποιοδήποτε Δεκτές Αρκετή Μικρή Γενικό Οποιοδήποτε Δεκτές Μεγάλη Μικρή με ισχυρές τάσεις αύξησης

87 Ερώτηση Ποιο/α από τα παρακάτω σχόλια που αναφέρονται στο σπειροειδές μοντέλο θεωρείτε ότι είναι σωστό/ά: A. Στο σπειροειδές μοντέλο το ρίσκο αντιμετωπίζεται νωρίς και επαναπροσδιορίζεται σε κάθε κύκλο ανάπτυξης B. Το σπειροειδές μοντέλο δεν επιτρέπει προσαρμοστικότητα στον κατασκευαστή. C. Κάθε κύκλος ανάπτυξης οδηγεί σε μια νέα γενιά λογισμικού D. Η εφαρμογή του σπειροειδούς μοντέλου στην πράξη είναι εύκολη και αυτό το καθιστά δημοφιλές.

88 Ερώτηση Ποιο/α από τα παρακάτω σχόλια που αναφέρονται στο σπειροειδές μοντέλο θεωρείτε ότι είναι σωστό/ά: A. Στο σπειροειδές μοντέλο το ρίσκο αντιμετωπίζεται νωρίς και επαναπροσδιορίζεται σε κάθε κύκλο ανάπτυξης B. Το σπειροειδές μοντέλο δεν επιτρέπει προσαρμοστικότητα στον κατασκευαστή. C. Κάθε κύκλος ανάπτυξης οδηγεί σε μια νέα γενιά λογισμικού D. Η εφαρμογή του σπειροειδούς μοντέλου στην πράξη είναι εύκολη και αυτό το καθιστά δημοφιλές.

89 Ερώτηση Σε ένα έργο ανάπτυξης λογισμικού του οποίου οι απαιτήσεις δεν είναι προσδιορισμένες με σαφήνεια, ποιο/α μοντέλο/α κύκλου ζωής θεωρείτε ότι είναι περισσότερο κατάλληλο/α: A. Ένα σειριακό μοντέλο όπως το μοντέλο του καταρράκτη B. Το μοντέλο πρωτοτυποποίησης C. Το μοντέλο της λειτουργικής επαύξησης D. Δεν υπάρχει κατάλληλο μοντέλο

90 Ερώτηση Σε ένα έργο ανάπτυξης λογισμικού του οποίου οι απαιτήσεις δεν είναι προσδιορισμένες με σαφήνεια, ποιο/ά μοντέλο/α κύκλου ζωής θεωρείτε ότι είναι περισσότερο κατάλληλο/α: A. Ένα σειριακό μοντέλο όπως το μοντέλο του καταρράκτη B. Το μοντέλο πρωτοτυποποίησης C. Το μοντέλο της λειτουργικής επαύξησης D. Δεν υπάρχει κατάλληλο μοντέλο

91 Ερώτηση Σας ζητούν να προσδιορίσετε τους πιθανούς λόγους αποτυχίας ενός έργου που βασίστηκε στο μοντέλο της λειτουργικής επαύξησης. Ποια/ες από τις παρακάτω δηλώσεις θεωρείτε ότι αποτελεί/ούν πιθανές ενδείξεις αποτυχίας; A. Η βασική αρχιτεκτονική του συστήματος άλλαζε με κάθε προσαύξηση B. Τα λειτουργικά τμήματα της εφαρμογής δεν ήταν αυτόνομα και έτσι δεν ήταν δυνατή η ανεξάρτητη ανάπτυξή τους C. Το σύστημα ήταν μεγάλης κλίμακας και το μοντέλο της λειτουργικής επαύξησης δεν ήταν το κατάλληλο. D. Το μοντέλο της λειτουργικής προσαύξησης έχει μεγάλο ποσοστό αποτυχίας.

92 Ερώτηση Σας ζητούν να προσδιορίσετε τους πιθανούς λόγους αποτυχίας ενός έργου που βασίστηκε στο μοντέλο της λειτουργικής επαύξησης. Ποια/ες από τις παρακάτω δηλώσεις θεωρείτε ότι αποτελεί/ούν πιθανές ενδείξεις αποτυχίας; A. Η βασική αρχιτεκτονική του συστήματος άλλαζε με κάθε προσαύξηση B. Τα λειτουργικά τμήματα της εφαρμογής δεν ήταν αυτόνομα και έτσι δεν ήταν δυνατή η ανεξάρτητη ανάπτυξή τους C. Το σύστημα ήταν μεγάλης κλίμακας και το μοντέλο της λειτουργικής επαύξησης δεν ήταν το κατάλληλο. D. Το μοντέλο της λειτουργικής προσαύξησης έχει μεγάλο ποσοστό αποτυχίας.

93 Ερώτηση Ποια/ες από τις παρακάτω προτάσεις είναι σωστή/ές; A. Στο μοντέλο του πίδακα όλες οι φάσεις εκτέλεσης του έργου προσαρμόζονται ανάλογα με τα επαναχρησιμοποιήσιμα συστατικά που έχουν παραχθεί κατά την ανάπτυξη προηγούμενων συστημάτων B. Το σπειροειδές μοντέλο δεν προσφέρεται για μικρές εφαρμογές, λόγω του επιπρόσθετου φόρτου που εισάγουν οι διαχειριστικές εργασίες (τεκμηρίωση σκοπιμότητας, κλπ). C. Το μοντέλο της πρωτοτυποίησης παρέχει τη δυνατότητα έγκαιρης λήψης διορθωτικών αποφάσεων για τη μετέπειτα ανάπτυξη του λογισμικού. D. Η τάση στα σύγχρονα μοντέλα κύκλου ζωής λογισμικού είναι ο αυστηρός προσδιορισμός των διεργασιών που πρέπει να εκτελούνται έτσι ώστε να μεγιστοποιείται το όφελος

94 Ερώτηση Ποια/ες από τις παρακάτω προτάσεις είναι σωστή/ές; A. Στο μοντέλο του πίδακα όλες οι φάσεις εκτέλεσης του έργου προσαρμόζονται ανάλογα με τα επαναχρησιμοποιήσιμα συστατικά που έχουν παραχθεί κατά την ανάπτυξη προηγούμενων συστημάτων B. Το σπειροειδές μοντέλο δεν προσφέρεται για μικρές εφαρμογές, λόγω του επιπρόσθετου φόρτου που εισάγουν οι διαχειριστικές εργασίες (τεκμηρίωση σκοπιμότητας, κλπ). C. Το μοντέλο της πρωτοτυποίησης παρέχει τη δυνατότητα έγκαιρης λήψης διορθωτικών αποφάσεων για τη μετέπειτα ανάπτυξη του λογισμικού. D. Η τάση στα σύγχρονα μοντέλα κύκλου ζωής λογισμικού είναι ο αυστηρός προσδιορισμός των διεργασιών που πρέπει να εκτελούνται έτσι ώστε να μεγιστοποιείται το όφελος

95 Ερώτηση Ποια/ες από τις παρακάτω φράσεις είναι σωστή/ές σχετικά με τα μοντέλα κύκλου ζωής λογισμικού. A. Υπάρχουν μοντέλα κύκλου ζωής λογισμικού τα οποία είναι σαφώς καλύτερα από άλλα για την ανάπτυξη λογισμικού. B. Το μοντέλο του καταρράκτη θεωρείται ως ένα χαρακτηριστικό επαναληπτικό μοντέλο όπου η κάθε εργασία επικοινωνεί με την προηγούμενη και την επόμενη. C. Το μοντέλο του καταρράκτη υπήρξε ένα πολύ διαδεδομένο μοντέλο κύκλου ζωής λογισμικού αλλά τώρα υπάρχουν και άλλα μοντέλα που χρησιμοποιούνται πολύ. D. Στα μοντέλα κύκλου ζωής λογισμικού δεν προβλέπεται να γίνεται κατευθείαν η συγγραφή πηγαίου κώδικά χωρίς να προηγηθεί ανάλυση και σχεδιασμός.

96 Ερώτηση Ποια/ες από τις παρακάτω φράσεις είναι σωστή/ές σχετικά με τα μοντέλα κύκλου ζωής λογισμικού. A. Υπάρχουν μοντέλα κύκλου ζωής λογισμικού τα οποία είναι σαφώς καλύτερα από άλλα για την ανάπτυξη λογισμικού. B. Το μοντέλο του καταρράκτη θεωρείται ως ένα χαρακτηριστικό επαναληπτικό μοντέλο όπου η κάθε εργασία επικοινωνεί με την προηγούμενη και την επόμενη. C. Το μοντέλο του καταρράκτη υπήρξε ένα πολύ διαδεδομένο μοντέλο κύκλου ζωής λογισμικού αλλά τώρα υπάρχουν και άλλα μοντέλα που χρησιμοποιούνται πολύ. D. Στα μοντέλα κύκλου ζωής λογισμικού δεν προβλέπεται να γίνεται κατευθείαν η συγγραφή πηγαίου κώδικά χωρίς να προηγηθεί ανάλυση και σχεδιασμός.

97 Συνοψίζοντας Κύκλος ζωής Λογισμικού Οι φάσεις από τις οποίες διέρχεται μία εφαρμογή λογισμικού από τη σύλληψή της κατά την κατασκευή, χρήση και συντήρησή της μέχρι την απόσυρσή της Το μοντέλο κύκλου ζωής περιγράφει τις φάσεις, τις εργασίες που γίνονται και τα προϊόντα που παράγονται σε κάθε φάση, τη σειρά διαδοχής

98 Τελικά... Το µοντέλο κύκλου ζωής λογισµικού περιγράφει τις φάσεις από τις οποίες διέρχεται η εφαρµογή λογισµικού από τη σύλληψη µέχρι την απόσυρσή της και τις ενέργειες που λαµβάνουν χώρα σε καθεμιά από αυτές Τα µοντέλα κύκλου ζωής λογισµικού που είδαμε διακρίνονται σε ακολουθιακά και σε επαναληπτικά. Στα ακολουθιακά µοντέλα η ανάπτυξη γίνεται σε διαδοχικές διακριτές φάσεις και για ολόκληρο το σύστηµα λογισµικού, ενώ στα επαναληπτικά η ανάπτυξη του λογισµικού γίνεται σε τµήµατα. Χαρακτηριστικότερο ακολουθιακό µοντέλο είναι αυτό του καταρράκτη, ενώ το γενικότερο από τα επαναληπτικά είναι το σπειροειδές Πρακτικά, χρησιµότερα είναι τα µοντέλα κύκλου ζωής που αφήνουν ελευθερία εξειδίκευσης στις εκάστοτε συνθήκες και δεν προσδιορίζουν µε αυστηρότητα τις ενέργειες που πρέπει να γίνουν, τα προϊόντα κτλ. Δεν υπάρχει ένα «καλύτερο» µοντέλο κύκλου ζωής, αλλά ένα καταλληλότερο στις εκάστοτε συνθήκες τόσο του κατασκευαστή όσο και του θεµατικού πεδίου της εφαρµογής λογισµικού

99 Πηγές / Acknowledgements Β. Βεσκούκης «Τεχνολογία Λογισμικού Ι», ΕΑΠ, ΠΑΤΡΑ, 2000 Χ. Αντωνόπουλος «Ανάπτυξη και Σχεδίαση Λογισμικού», Τμήμα Μηχ. Η/Υ, Τηλεπικοινωνιών και Δικτύων, Παν. Θεσσαλίας, 2007 S. L. Pfleeger, «Τεχνολογία Λογισμικού Θεωρία και πράξη», 2η έκδοση, Τόμοι Α και Β (μετάφραση, εκδ. Κλειδάριθμος) I. Sommerville, «Βασικές αρχές Τεχνολογίας Λογισμικού», 8 η αγγλική έκδοση (μετάφραση, εκδ. Κλειδάριθμος) R. Pressman, B. Maxim «Τεχνολογία Λογισμικού», 8 η έκδοση, επιμέλεια Α. Πρέντζα, Κ. Σαΐδης, εκδόσεις Τζιόλα, 2018