Μοντέλα Κύκλου Ζωής Λογισμικού

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

2. Περιεχόμενα • The Unified Process • Το μοντέλο της επανάληψης και της Σταδιακής Εκλέπτυνσης στο ΟΟ παράδειγμα • Η δραστηριότητα των Απαιτήσεων • Η δραστηριότητατης ανάλυσης • Η δραστηριότητατου Σχεδιασμού • Η δραστηριότητατης υλοποίησης • Η δραστηριότητατου ελέγχου Δρ. Μαρία Ι. Ανδρέου

3. Περιεχόμενα (συνέχ.) • Συντήρηση μετά την παράδοση (Postdelivery maintenance) • Απόσυρση • Η φάση της Unified Process • Μοντέλα κύκλου ζωής Μιας-διάστασηςέναντιμοντέλων δυο-διαστάσεων • Βελτιώνοντας τηνδιαδικασία ανάπτυξης λογισμικού • Ικανότητες Ώριμων μοντέλων • Άλλες αρχές βελτίωσης της διαδικασίας ανάπτυξης λογισμικού • Κόστος και κέρδοςαπό τη βελτίωση τηςδιαδικασίας ανάπτυξης λογισμικού Δρ. Μαρία Ι. Ανδρέου

4. The Unified Process • Μέχρι πρόσφατα, τρεις από τις πιο επιτυχημένες αντικειμενοστρεφείς (object-oriented, ΟΟ)μεθοδολογίες ήταν οι • Booch’s method • Jacobson’s Objectory • Rumbaugh’s OMT Δρ. Μαρία Ι. Ανδρέου

5. The Unified Process (συνέχ.) • In 1999, Booch, Jacobson, and Rumbaugh εκδώσαν μια ολοκληρωμένη μεθοδολογία για αντικειμενοστρεφή ανάλυση και σχεδιασμό (object-oriented analysis and design)που ενοποιεί (unify) τις τρεις ξεχωριστές μεθοδολογίες που πρότειναν • Αρχικό Όνομα:Rational Unified Process (RUP) • Επόμενο Όνομα:Unified Software Development Process (USDP) • Σημερινό όνομα:Unified Process (για συντομία) Δρ. Μαρία Ι. Ανδρέου

6. The Unified Process (συνέχ.) • Η Unified Process ΔΕΝ είναι μια σειρά από βήματα με στόχο την κατασκευή ενός προϊόντος λογισμικού • Καμία μεθοδολογία δεν θα μπορούσε να υπάρξει που να εφαρμόζεται σε όλες τις περιπτώσεις • Υπάρχει μια μεγάλη ποικιλία από διαφορετικούς τύπουςλογισμικών • Η Unified Process είναι μια προσαρμόσιμη μεθοδολογία • Πρέπει να τροποποιείται σε κάθε συγκεκριμένο προϊόν λογισμικούπου θα αναπτυχθεί Δρ. Μαρία Ι. Ανδρέου

7. The Unified Process (συνέχ.) • Η UML είναι μια γραφική γλώσσα • Μια εικόνα είναι ίση με χίλιες λέξεις • Τα UML διαγράμματα επιτρέπουν στον μηχανικό του λογισμικούνα επικοινωνεί γρήγορα και με ακρίβεια (accuracy) Δρ. Μαρία Ι. Ανδρέου

8. Επανάληψη και Σταδιακή Πρόοδος στο OO Παράδειγμα • Η Unified Process είναι μια τεχνική για μοντελοποίηση • Έναμοντέλο (model)είναι ένα σύνολο από UML διαγράμματα που αναπαριστούν διάφορες πτυχές του προϊόντος λογισμικού που θέλουμε να αναπτύξουμε • UML είναι η σημειογραφία για τη unified modeling language • Η UML είναι ένα εργαλείο που χρησιμοποιούμε για να αναπαραστήσουμε (model) τοπροϊόν λογισμικού που έχουμε σαν στόχο να αναπτύξουμε Δρ. Μαρία Ι. Ανδρέου

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

10. Επανάληψη και Σταδιακή Πρόοδος στο OO Παράδειγμα (συνέχ.) • Η έκδοση της Unified Process που θα χρησιμοποιήσουμε σε αυτό το μάθημα είναι για • Προϊόντα λογισμικούπου είναι αρκετά μικρά για να αναπτυχθούν από μια ομάδα 3-4 φοιτητών μέσα σε ένα εξάμηνο • Παρόλα αυτά, θα συζητήσουμε και τις τροποποιήσεις που θα πρέπει να γίνουν στην Unified Process για να μπορεί να αναπτυχθεί ένα μεγάλο Προϊόν Λογισμικού Δρ. Μαρία Ι. Ανδρέου

11. Επανάληψη και Σταδιακή Πρόοδος στο OO Παράδειγμα (συνέχ.) • Δυο από τους βασικούς στόχους αυτού του μαθήματος είναι • Η πλήρης κατανόηση του πως αναπτύσσεται ένα μικρής κλίμακας προϊόν λογισμικού • Κατανόηση των θεμάτων που πρέπει να λάβουμε υπόψη μας όταν κατασκευάζονται μεγάλα προϊόντα λογισμικού • Δεν είναι εύκολο να μάθουμε πλήρως τις δυνατότητες της Unified Process στα πλαίσια αυτού του μαθήματος • Χρειάζεται εκτενέστερη μελέτη και συνεχής πρακτική • Η Unified Process έχει πάρα πολλές δυνατότητες • Η μελέτη σε UML ενός μεγάλης κλίμακας προϊόντος λογισμικούείναι πολύ πολύπλοκη Δρ. Μαρία Ι. Ανδρέου

12. Η δραστηριότητα των απαιτήσεωνThe Requirements Workflow • Ο στόχος της δραστηριότητας των απαιτήσεων • Να καθορίσει τις ανάγκες του πελάτη Δρ. Μαρία Ι. Ανδρέου

13. Περιγραφή της Δραστηριότητας των Απαιτήσεων • Αρχικά, καταλαβαίνουμε το πλαίσιο της εφαρμογής (application domain) (ή πλαίσιο,domain για συντομία) • Αυτό είναι το επιχειρηματικό περιβάλλον στο οποίο θα λειτουργεί το προϊόν λογισμικού που καλούμαστε να αναπτύξουμε • Δεύτερο, κατασκευή του επιχειρηματικού μοντέλου (business model) • χρήση UML για να περιγραφούν οι επιχειρηματικές δραστηριότητες (business processes) • Αν σε κάποια στιγμή ο πελάτης δεν πιστεύει ότι το κόστος αιτιολογείται, η ανάπτυξη τερματίζεται άμεσα Δρ. Μαρία Ι. Ανδρέου

14. Περιγραφή της Δραστηριότητας των Απαιτήσεων (συνέχ.) • Είναι ζωτικής σημασίας να καθορίσουμε τους περιορισμούς που θέτει ο πελάτης • Προθεσμίες (Deadline) • τα σημερινά προϊόντα λογισμικού έχουν συχνά κρίσιμη (μεγάλη) σημασία • Παράλληλη εκτέλεση • Φορητότητα (Portability) • Αξιοπιστία (Reliability) • Ταχύ, γρήγορο χρόνο απόκρισης (Rapid response time) • Κόστος • Οι πελάτες σπάνια ενημερώνουν τους κατασκευαστές για το πόσα χρήματα είναι διαθέσιμα • Χρησιμοποιείται μια διαδικασία πλειοδοσίας (bidding procedure) Δρ. Μαρία Ι. Ανδρέου

15. Περιγραφή της Δραστηριότητας των Απαιτήσεων (συνέχ.) • Ο στόχος αυτής της εξερεύνησης του θέματος είναι για να καθορίσουμε • Τι χρειάζεται ο πελάτης • ΌΧΙ το τι θέλει ο πελάτης Δρ. Μαρία Ι. Ανδρέου

16. Περιγραφή της Δραστηριότητας των Απαιτήσεων The Analysis Workflow • Ο στόχος της δραστηριότητας των απαιτήσεων είναι • Να αναλύσει και να βελτιώσει τις απαιτήσεις (requirements) • Γιατί δεν το κάνουμε αυτό κατά τη δραστηριότητα των απαιτήσεων ; • Τα παραδοτέα (artifacts) που αφορούν τις απαιτήσεις πρέπει να είναι πλήρως κατανοητά και από το πελάτη • Τα παραδοτέα της δραστηριότητας των απαιτήσεων πρέπει να είναι γραμμένα σε μια φυσική γλώσσα • Όλες οι φυσικές γλώσσες είναι ασαφής Δρ. Μαρία Ι. Ανδρέου

17. Περιγραφή της Δραστηριότητας των Απαιτήσεων (συνέχ.) • Παράδειγμα για ένα σύστημα μιας βιομηχανικής εταιρίας: • “μιαεγγραφή εξαρτήματος (part record)και μια εγγραφή εργοστασίου (plant record)διαβάζονται από μια βάση δεδομένων.Αν περιλαμβάνει το γράμμα A να ακολουθείται άμεσα από το γράμμα Q, τότε υπολόγισε το κόστος της μεταφοράς αυτού του εξαρτήματος σε αυτό το εργοστάσιο” • Σε τι αναφέρεται; • στο part record; • στο plant record; • Ή στη βάση δεδομένων; Δρ. Μαρία Ι. Ανδρέου

18. Περιγραφή της Δραστηριότητας των Απαιτήσεων (συνέχ.) • Χρειάζονται δυο διαφορετικές δραστηριότητες • Τα παραδοτέα (artifacts) στης δραστηριότητας των απαιτήσεων πρέπει να εκφράζονται στην γλώσσα του πελάτη (client) • Τα παραδοτέα στη δραστηριότητα της ανάλυσης πρέπει να είναι ακριβείς, και πλήρη έτσι ώστε οι κατασκευαστές να έχουν όλες τις πληροφορίες που χρειάζονται για να αναπτύξουν ένα προϊόν που να ικανοποιεί τις απαιτήσεις του πελάτη. Δρ. Μαρία Ι. Ανδρέου

19. Έγγραφο Προδιαγραφών Specification Document • Κείμενο (έγγραφο, τεκμήριο) Προδιαγραφών (Specification document ή “specifications”) • Συνιστά συμβόλαιο • Δεν πρέπει να περιλαμβάνει μη ακριβείς φράσεις όπως “optimal,” ή “98 percent complete” • Το να έχουμε ολοκληρωμένες και σωστές τις προδιαγραφές (specifications)είναι ουσιαστικής σημασίας για • Τον έλεγχο, ότι το έργο ικανοποιεί τις απαιτήσεις του πελάτη και είναι ολοκληρωμένο,και • Συντήρηση Δρ. Μαρία Ι. Ανδρέου

20. Έγγραφο Προδιαγραφών (συνέχ.) • Το έγγραφο προδιαγραφών ΔΕΝ πρέπει να περιλαμβάνει • Αντιφάσεις (Contradictions) • Παραλείψεις (Omissions) • Ελλείψεις (Incompleteness) Δρ. Μαρία Ι. Ανδρέου

21. Σχέδιο Διαχείρισης Έργου ΛογισμικούSoftware Project Management Plan (SPMP) • Όταν οπελάτηςυπογράψει τις προδιαγραφές, αρχίζει η κατάστρωση ενός λεπτομερούς σχεδίου με τα χρονοδιαγράμματα του έργουμαζί με μια εκτίμηση κόστους • Το software project management plan, περιλαμβάνει • Εκτίμηση κόστους (Cost estimate) • Εκτίμηση Διάρκειας (Duration estimate) • Παραδοτέα (Deliverables) • Ορόσημα (Milestones) • Προϋπολογισμός (Budget) • Το SPMP δεν θα μπορούσε να γίνει νωρίτερα Δρ. Μαρία Ι. Ανδρέου

22. Η δραστηριότητα του Σχεδιασμού The Design Workflow • Ο στόχος της δραστηριότητας του σχεδιασμού είναι να εκλεπτύνει (μπει σε μεγαλύτερο βάθος, τελειοποιήσει)τη δραστηριότητα της ανάλυσηςμέχρι που το αποτέλεσμα να είναι σε μορφή που να μπορεί να υλοποιηθεί από τους προγραμματιστές. • Πολλές μη λειτουργικές απαιτήσεις (requirements)πρέπει να οριστικοποιηθούν (finalized)τώρα. Αυτές συμπεριλαμβάνουν • Επιλογή της γλώσσας προγραμματισμού (programming language) • Θέματα επαναχρησιμοποίησης (Reuse issues) • Θέματα φορητότητας (Portability issues) Δρ. Μαρία Ι. Ανδρέου

23. Κλασικός Σχεδιασμός Classical Design • Ο κλασικός σχεδιασμός περιλάμβανε: • Το Αρχιτεκτονικό Σχέδιο (Architectural design) • Διαμελισμόν του έργουσε τμήματα (modules) • Λεπτομερές Σχεδιασμό (Detailed design) • Σχεδιασμόκάθετμήματος (module): • Δομές δεδομένων (Data structures) • Αλγόριθμοι (Algorithms) Δρ. Μαρία Ι. Ανδρέου

24. Αντικειμενοστρεφές Σχεδιασμός Object-Oriented Design • οι Κατηγορίες (Classes)επιλέγονται κατά τη διάρκεια τουτης δραστηριότητας της ΟΟ ανάλυσης, και • Σχεδιάζονται (ορίζονται τα μέλή τους, δηλ., πεδία και μέθοδοι)κατά τη δραστηριότητα του σχεδιασμού • Συνεπώς • Το κλασικό αρχιτεκτονικό σχέδιο αντιστοιχεί σε ένα μέρος τουτης δραστηριότητας της ΟΟ ανάλυσης • Ο κλασικός λεπτομερής σχεδιασμός στο ΟΟ παράδειγμα αντιστοιχεί σε ένα μέρος της δραστηριότητας του Σχεδιασμού Δρ. Μαρία Ι. Ανδρέου

25. Δραστηριότητα Σχεδιασμού (συνέχ.) • Διατήρηση των αποφάσεων του design • Για το πότε θα τελειώσει το έργο,και • Για να προστατέψουμε τηνομάδα που θα κάνει συντήρηση από το να ξαναανακαλύψει τον τροχό Δρ. Μαρία Ι. Ανδρέου

26. Η Δραστηριότητα της Υλοποίησης The Implementation Workflow • Ο στόχος της δραστηριότητας της υλοποίησης είναι να υλοποιήσει τοστοχεύομενο προϊόν λογισμικού στην γλώσσα προγραμματισμού που έχει επιλεγεί • Ένα μεγάλοπροϊόν λογισμικούχωρίζεται σε υποσυστήματα (subsystems) • ταυποσυστήματα αποτελούνται από συστατικά μέρη ή μέρη από κώδικα (code artifacts) Δρ. Μαρία Ι. Ανδρέου

27. Η δραστηριότητα του Ελέγχου • Η δραστηριότητα του ελέγχου είναι εύθυνη • κάθεκατασκευαστή και συντηρητή, και • της ομάδας διαβεβαίωσης ποιότητας (quality assurance group) • Η ονοματολογία όλων των κομματιών (artifacts), έτσι ώστε να μπορούμε στην συνέχεια να αναφερόμαστε με ακρίβεια σε αυτά (traceability of artifacts)είναι μια σημαντική απαίτηση για επιτυχή έλεγχο Δρ. Μαρία Ι. Ανδρέου

28. Συστατικά Μέρη/Κομμάτια/Παραδοτέα των Απαιτήσεων Requirements Artifacts • Κάθε στοιχείο στα παραδοτέα (ή άλλο συστατικό μέρος) της φάσης της ανάλυσης (analysis artifacts)πρέπει να παραπέμπει (must be traceable)σε ένα στοιχείο τωνπαραδοτέων της φάσης των απαιτήσεων (requirements artifacts) • Παρομοίως, το ίδιο θα πρέπει να ισχύει για ταπαραδοτέα της φάσης του σχεδιασμού και της υλοποίησης Δρ. Μαρία Ι. Ανδρέου

29. Συστατικά Μέρη / Παραδοτέα της Ανάλυσης Analysis Artifacts • Ταπαραδοτέα (και όλα τα άλλα συστατικά μέρη) της φάσης της ανάλυσης πρέπει να ελεγχθούν με μεθόδους εξέτασης (review) • Αντιπρόσωποι από τις ομάδες τωνπελατών (client)και των αναλυτών (analysis)πρέπει να παρευρίσκονται • Το SPMP πρέπει να ελεγχθεί παρομοίως • Δίνεται ιδιαίτερη σημασία στις εκτιμήσεις για το κόστος και τη διάρκεια Δρ. Μαρία Ι. Ανδρέου

30. Παραδοτέα/ Συστατικά Μέση Του Σχεδιασμού Μέρη Design Artifacts • Η Εξέταση (έλεγχος) του Σχεδιασμούείναι ουσιαστική και απαραίτητη • Δεν συνηθίζεται να υπάρχει εκπρόσωπος τουπελάτη σε αυτή την εξέταση Δρ. Μαρία Ι. Ανδρέου

31. Παραδοτέα/ Συστατικά Μέση την Υλοποίησης Implementation Artifacts • Κάθε κομμάτι ελέγχεται (tested)μόλις ολοκληρωθεί • Έλεγχος μονάδας (Unit testing) • Στο τέλος κάθε επανάληψης (iteration), τα ολοκληρωμένα κομμάτια συνδέονται και ελέγχονται • Έλεγχος ενσωμάτωσης (Integration testing) • Όταν το προϊόν είναι σχεδόν ολοκληρωμένο ελέγχεται σαν σύνολο • Έλεγχος προϊόντος (Product testing) • Όταν το ολοκληρωμένο προϊόν εγκατασταθεί στους υπολογιστές του πελάτη, τότε το ελέγχει και ο πελάτης • Έλεγχος αποδοχής (Acceptance testing) Δρ. Μαρία Ι. Ανδρέου

32. Παραδοτέα/ Συστατικά Μέση της Υλοποίησης (συνέχ.) • Λογισμικά τύπου COTS αφήνονται να ελεγχθούν από ενδεχόμενους πελάτες • Πρώτη Φάση (Alpha release) • Δεύτερη Φάση (Beta release) • Υπάρχουν πλεονεκτήματα και μειονεκτήματα του να υπάρχει alpha ή beta release Δρ. Μαρία Ι. Ανδρέου

33. Συντήρηση μετά την παράδοση Postdelivery Maintenance • Η συντήρηση ενός λογισμικού μετά την παράδοση του είναι ένα σημαντικό μέρος (κομμάτι) τουτο οποίο πρέπει να λαμβάνεται υπόψη και κατά την ανάπτυξης (development) του λογισμικού • Ξοδεύονται περισσότερα χρήματα για συντήρηση μετά την παράδοση παρά σε όλα τα άλλα κομμάτια μαζί • Προβλήματα μπορεί να προκύψουν λόγο • Έλλειψης τεκμηρίωσης παντός είδους Δρ. Μαρία Ι. Ανδρέου

34. Συντήρηση μετά την παράδοση (συνέχ.) • Χρειάζονται δυο είδη ελέγχου • Έλεγχος των αλλαγών που έγιναν κατά την διάρκεια του postdelivery maintenance • Έλεγχος οπισθοδρόμησης (Regression testing) • όλες οι προηγούμενες περιπτώσεις ελέγχου (και τα αναμενόμενα αποτελέσματα τους) πρέπει να καταγράφονται και να διατηρούνται Δρ. Μαρία Ι. Ανδρέου

35. Απόσυρση Retirement • Το λογισμικόμπορεί να ΜΗΝ μπορεί να συντηρηθεί πλέον επειδή • Έχει συμβεί μια δραστική αλλαγή • Το προϊόνπρέπει να υλοποιηθεί σε ένα εντελώς νέο υλικό/ λειτουργικό σύστημα (hardware/operating system) • Έλλειψη ή ανακρίβειες στην τεκμηρίωση • Αλλαγή υλικού—μπορεί να είναι πιο φθηνό να ξαναγραφτεί το λογισμικό από την αρχή παρά να τροποποιηθεί • Αυτές είναι κάποιες περιπτώσεις/λόγοι για συντήρηση Δρ. Μαρία Ι. Ανδρέου

36. Απόσυρση (συνέχ.) • Πραγματικήαπόσυρση (retirement) δεν είναι συχνό φαινόμενο • Συμβαίνει όταν ο οργανισμός του πελάτη δεν χρειάζεται πια τις υπηρεσίες που του προσφέρει το προϊόν Δρ. Μαρία Ι. Ανδρέου

37. Οι φάσεις της Unified Process • Ταστάδια (increments)ταυτίζονται με τις ακόλουθες φάσεις Δρ. Μαρία Ι. Ανδρέου Figure 3.1

38. Οι φάσεις της Unified Process (συνέχ.) • Τατέσσερα στάδια ονομάζονται • Φάση έναρξης (Inception phase) • Φάση επεξεργασίας (Elaboration phase) • Φάση κατασκευής (Construction phase) • Φάση μετάβασης (Transition phase) • Οι φάσεις (phases)της Unified Process είναι τα στάδια (increments) Δρ. Μαρία Ι. Ανδρέου

39. Οι φάσεις της Unified Process (συνέχ.) • Στην θεωρία, θα μπορούσε να υπάρχει οποιοσδήποτε αριθμός από στάδια (increments) • Στην πράξη, η ανάπτυξη φαίνεται να συνίσταται από τέσσεραβασικά στάδια • Κάθε βήμα που εκτελείται στην Unified Process εμπίπτει σε • Μια από τις πέντε βασικές δραστηριότητες (workflows)καθώς επίσης και • Σε μια από τις τέσσεριςφάσεις (phases) • Γιατί πρέπει να λάβουμε υπόψη μας κάθε βήμα δυο φορές; Δρ. Μαρία Ι. Ανδρέου

40. Οι φάσεις της Unified Process (συνέχ.) • Δραστηριότητα (Workflow) • Τεχνικό περιεχόμενο ενός βήματος • Φάση (Phase) • Επαγγελματικό περιεχόμενο κάθε βήματος Δρ. Μαρία Ι. Ανδρέου

41. Φάση Έναρξης The Inception Phase • Ο στόχος της φάσης της έναρξης (inception phase)είναι να καθορίσει κατά πόσο το προτεινόμενο προϊόν λογισμικού είναι οικονομικά πραγματοποιήσιμο Δρ. Μαρία Ι. Ανδρέου

42. Φάση Έναρξης (συνέχ.) • 1.κερδίζουμε την κατανόηση της περιοχής • 2. κατασκευή του business model • 3. οριοθέτηση του πλαισίου του προτεινόμενου έργου • Εστιάζομε στο μέρος του business model που καλύπτεται από το προτεινόμενο προϊόν λογισμικού • 4. Αρχίζει την initial business case Δρ. Μαρία Ι. Ανδρέου

43. Φάση Έναρξης : The Initial Business Case • Χρειάζεται να απαντηθούν ανάμεσα σε άλλες οι ακόλουθες ερωτήσεις • Είναι το προτεινόμενο software product επικερδές; • Πόσο καιρό θα πάρει για να αρχίσουμε να κερδίζουμε από αυτή την επένδυση (απόσβεση της επένδυσης); • Διαφορετικά, ποιο θα είναι το κόστος αν η εταιρία αποφασίσει να μην αναπτύξει το προτεινόμενο προϊόν λογισμικού; • Αν αυτό τοπροϊόν λογισμικούείναι για να πωλείται στην αγορά, έχει γίνει η αναγκαία μελέτη για την εκμετάλλευση της αγοράς; • Μπορεί το προτεινόμενο προϊόν λογισμικούνα παραδοθεί στην ώρα του; • Αν τοπροϊόν λογισμικούθα αναπτυχθεί για να υποστηρίξει τις δραστηριότητες της εταιρίας του πελάτη, ποιες θα είναι οι επιπτώσεις στην περίπτωση του το προτεινόμενο προϊόν λογισμικούπαραδοθεί με καθυστέρηση; Δρ. Μαρία Ι. Ανδρέου

44. Φάση Έναρξης : The Initial Business Case (συνέχ.) • Ποια ρίσκα εμπλέκονται στην ανάπτυξη του ενός προϊόντος λογισμικού, και • Πως μπορούν αυτά τα ρίσκα να αμβλυνθούν; • Έχει η ομάδα που θα αναπτύξει το προτεινόμενο προϊόν λογισμικούτην αναγκαία πείρα; • Χρειάζεται νέο υλικόγια αυτό τολογισμικό; • Αν ναι, υπάρχει ρίσκο να μην παραδοθεί (το υλικό) στην ώρα του; • Αν ναι, υπάρχει τρόπος να αμβλύνουμε αυτό το ρίσκο, ίσως παραγγέλλοντας back-up hardware από άλλο πελάτη; • Χρειάζονταικατάλληλα εργαλεία για την ανάπτυξη του εν λόγο λογισμικού (software tools); • Αν ναι είναι διαθέσιμα;Έχουν τις απαραίτητες λειτουργικότητες; Δρ. Μαρία Ι. Ανδρέου

45. Φάση Έναρξης : The Initial Business Case (συνέχ.) • Χρειάζονται απαντήσεις σε αυτές τις ερωτήσεις μέχρι το τέλος της φάσης έναρξης, έτσι ώστε το initial business case να μπορεί να δημιουργηθεί Δρ. Μαρία Ι. Ανδρέου

46. Φάση Έναρξης : Ρίσκα (Risks) • Υπάρχουν τρεις κύριες κατηγορίες ρίσκων • Τεχνικά ρίσκα (Technical risks) • Δες την προηγούμενη διαφάνεια • Ρίσκο να μην καταλάβουμε σωστά τις απαιτήσεις (requirements) • Αμβλύνεται με το να εκτελέσουμε σωστά τη δραστηριότητα των απαιτήσεων • Ρίσκο να μην κάνουμε την αρχιτεκτονική σωστά • Η αρχιτεκτονική μπορεί να μην είναι ικανοποιητικά εύρωστη Δρ. Μαρία Ι. Ανδρέου

47. Φάση Έναρξης : Ρίσκα (Risks) (συνέχ.) • Για να αμβλύνουμε και τις τρεις κατηγορίες ρίσκων • Τα ρίσκα πρέπει να ταξινομηθούνέτσι ώστε τα πιο κρίσιμα να αμβλυνθούν πρώτα • Αυτά ολοκληρώνουν τα βήματα της φάσης έναρξης που εμπίπτουν κάτω από τη δραστηριότητα των απαιτήσεων Δρ. Μαρία Ι. Ανδρέου

48. Φάση Έναρξης : δραστηριότητες Ανάλυσης και Σχεδιασμού • Ένα μικρό μέρος από της δραστηριότητας της ανάλυσης μπορεί να εκτελεστεί κατά την διάρκεια της φάσης έναρξης • Εκμαίευση των πληροφοριών που χρειάζονται για τον σχεδιασμό της αρχιτεκτονικής • Συνεπώς, ένα μικρό μέρος και από τη δραστηριότητα του σχεδιασμού μπορεί να εκτελεστεί, επίσης από αυτή τη φάση Δρ. Μαρία Ι. Ανδρέου

49. Φάση Έναρξης : Δραστηριότητα Υλοποίησης • Συνήθως δεν παράγεται κώδικας κατά την φάση έναρξης • Όμως, ένα πρωτότυπο που δείχνει το θέμα (proof-of-concept prototype) μερικές φορές κατασκευάζεται για να ελεγχθεί η δυνατότητα επίτευξης (feasibility)του, κατασκευάζοντας ένα τμήμα από το στοχευόμενου προϊόντος λογισμικού Δρ. Μαρία Ι. Ανδρέου

50. Φάση Έναρξης : Δραστηριότητα Ελέγχου • Η δραστηριότητα ελέγχου αρχίζει σχεδόν από την αρχή τηςφάσης έναρξης • Ο στόχος του είναι να εξασφαλίσει ότι οι απαιτήσεις έχουν επακριβώς καθοριστεί Δρ. Μαρία Ι. Ανδρέου