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

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

Δρ. Μαρία Ι. Ανδρέου

Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 2

Περιεχόμενα

The Unified Process Το μοντέλο της επανάληψης και της Σταδιακής

Εκλέπτυνσης στο ΟΟ παράδειγμα Η δραστηριότητα των Απαιτήσεων Η δραστηριότητα της ανάλυσης Η δραστηριότητα του Σχεδιασμού Η δραστηριότητα της υλοποίησης Η δραστηριότητα του ελέγχου


Περιεχόμενα (συνέχ.) Συντήρηση μετά την παράδοση (Postdelivery maintenance)

Απόσυρση Η φάση της Unified Process Μοντέλα κύκλου ζωής Μιας-διάστασης έναντι

μοντέλων δυο-διαστάσεων Βελτιώνοντας την διαδικασία ανάπτυξης λογισμικού Ικανότητες Ώριμων μοντέλων Άλλες αρχές βελτίωσης της διαδικασίας ανάπτυξης

λογισμικού Κόστος και κέρδος από τη βελτίωση της διαδικασίας

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


The Unified Process

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


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 (για συντομία)


The Unified Process (συνέχ.) Η Unified Process ΔΕΝ είναι μια σειρά από βήματα

με στόχο την κατασκευή ενός προϊόντος λογισμικού Καμία μεθοδολογία δεν θα μπορούσε να υπάρξει που

να εφαρμόζεται σε όλες τις περιπτώσεις Υπάρχει μια μεγάλη ποικιλία από διαφορετικούς

τύπους λογισμικών

Η Unified Process είναι μια προσαρμόσιμη μεθοδολογία Πρέπει να τροποποιείται σε κάθε συγκεκριμένο προϊόν

λογισμικού που θα αναπτυχθεί


The Unified Process (συνέχ.)

Η UML είναι μια γραφική γλώσσα Μια εικόνα είναι ίση με χίλιες λέξεις

Τα UML διαγράμματα επιτρέπουν στον μηχανικό του λογισμικού να επικοινωνεί γρήγορα και με ακρίβεια (accuracy)


Επανάληψη και Σταδιακή Πρόοδος στο OO Παράδειγμα Η Unified Process είναι μια τεχνική για

μοντελοποίηση Ένα μοντέλο (model) είναι ένα σύνολο από UML

διαγράμματα που αναπαριστούν διάφορες πτυχές του προϊόντος λογισμικού που θέλουμε να αναπτύξουμε

UML είναι η σημειογραφία για τη unified modeling language Η UML είναι ένα εργαλείο που χρησιμοποιούμε για να

αναπαραστήσουμε (model) το προϊόν λογισμικού που έχουμε σαν στόχο να αναπτύξουμε


Επανάληψη και Σταδιακή Πρόοδος στο OO Παράδειγμα (συνεχ.)

Το ΟΟ παράδειγμα περιλαμβάνει από τη φύση του επαναλήψεις και στάδια τα UML διαγράμματα μπορούν να χρησιμοποιηθούν

για να αναπαραστήσουμε τις επαναλήψεις και τα στάδια.


Επανάληψη και Σταδιακή Πρόοδος στο OO Παράδειγμα (συνέχ.)

Η έκδοση της Unified Process που θα χρησιμοποιήσουμε σε αυτό το μάθημα είναι για Προϊόντα λογισμικού που είναι αρκετά μικρά για να

αναπτυχθούν από μια ομάδα 3-4 φοιτητών μέσα σε ένα εξάμηνο

Παρόλα αυτά, θα συζητήσουμε και τις τροποποιήσεις που θα πρέπει να γίνουν στην Unified Process για να μπορεί να αναπτυχθεί ένα μεγάλο Προϊόν Λογισμικού


Επανάληψη και Σταδιακή Πρόοδος στο OO Παράδειγμα (συνέχ.) Δυο από τους βασικούς στόχους αυτού του μαθήματος είναι Η πλήρης κατανόηση του πως αναπτύσσεται ένα μικρής

κλίμακας προϊόν λογισμικού Κατανόηση των θεμάτων που πρέπει να λάβουμε υπόψη

μας όταν κατασκευάζονται μεγάλα προϊόντα λογισμικού Δεν είναι εύκολο να μάθουμε πλήρως τις δυνατότητες

της Unified Process στα πλαίσια αυτού του μαθήματος Χρειάζεται εκτενέστερη μελέτη και συνεχής πρακτική Η Unified Process έχει πάρα πολλές δυνατότητες Η μελέτη σε UML ενός μεγάλης κλίμακας προϊόντος

λογισμικού είναι πολύ πολύπλοκη


Η δραστηριότητα των απαιτήσεων The Requirements Workflow

Ο στόχος της δραστηριότητας των απαιτήσεων Να καθορίσει τις ανάγκες του πελάτη


Περιγραφή της Δραστηριότητας των Απαιτήσεων

Αρχικά, καταλαβαίνουμε το πλαίσιο της εφαρμογής (application domain) (ή πλαίσιο, domain για συντομία) Αυτό είναι το επιχειρηματικό περιβάλλον στο οποίο θα

λειτουργεί το προϊόν λογισμικού που καλούμαστε να αναπτύξουμε

Δεύτερο, κατασκευή του επιχειρηματικού μοντέλου (business model) χρήση UML για να περιγραφούν οι επιχειρηματικές

δραστηριότητες (business processes) Αν σε κάποια στιγμή ο πελάτης δεν πιστεύει ότι το κόστος

αιτιολογείται, η ανάπτυξη τερματίζεται άμεσα


Περιγραφή της Δραστηριότητας των Απαιτήσεων (συνέχ.) Είναι ζωτικής σημασίας να καθορίσουμε τους περιορισμούς

που θέτει ο πελάτης Προθεσμίες (Deadline)

τα σημερινά προϊόντα λογισμικού έχουν συχνά κρίσιμη (μεγάλη) σημασία

Παράλληλη εκτέλεση Φορητότητα (Portability) Αξιοπιστία (Reliability) Ταχύ, γρήγορο χρόνο απόκρισης (Rapid response time) Κόστος

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

Χρησιμοποιείται μια διαδικασία πλειοδοσίας (bidding procedure)


Περιγραφή της Δραστηριότητας των Απαιτήσεων (συνέχ.)

Ο στόχος αυτής της εξερεύνησης του θέματος είναι για να καθορίσουμε Τι χρειάζεται ο πελάτης ΌΧΙ το τι θέλει ο πελάτης


Περιγραφή της Δραστηριότητας των Απαιτήσεων The Analysis Workflow Ο στόχος της δραστηριότητας των απαιτήσεων είναι

Να αναλύσει και να βελτιώσει τις απαιτήσεις (requirements)

Γιατί δεν το κάνουμε αυτό κατά τη δραστηριότητα των απαιτήσεων ; Τα παραδοτέα (artifacts) που αφορούν τις απαιτήσεις

πρέπει να είναι πλήρως κατανοητά και από το πελάτη

Τα παραδοτέα της δραστηριότητας των απαιτήσεων πρέπει να είναι γραμμένα σε μια φυσική γλώσσα Όλες οι φυσικές γλώσσες είναι ασαφής


Περιγραφή της Δραστηριότητας των Απαιτήσεων (συνέχ.) Παράδειγμα για ένα σύστημα μιας βιομηχανικής

εταιρίας: “μια εγγραφή εξαρτήματος (part record) και μια

εγγραφή εργοστασίου (plant record) διαβάζονται από μια βάση δεδομένων. Αν περιλαμβάνει το γράμμα A να ακολουθείται άμεσα από το γράμμα Q, τότε υπολόγισε το κόστος της μεταφοράς αυτού του εξαρτήματος σε αυτό το εργοστάσιο”

Σε τι αναφέρεται; στο part record; στο plant record; Ή στη βάση δεδομένων;


Περιγραφή της Δραστηριότητας των Απαιτήσεων (συνέχ.)

Χρειάζονται δυο διαφορετικές δραστηριότητες Τα παραδοτέα (artifacts) στης δραστηριότητας των

απαιτήσεων πρέπει να εκφράζονται στην γλώσσα του πελάτη (client)

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


Έγγραφο Προδιαγραφών Specification Document Κείμενο (έγγραφο, τεκμήριο) Προδιαγραφών

(Specification document ή “specifications”) Συνιστά συμβόλαιο Δεν πρέπει να περιλαμβάνει μη ακριβείς φράσεις

όπως “optimal,” ή “98 percent complete”

Το να έχουμε ολοκληρωμένες και σωστές τις προδιαγραφές (specifications) είναι ουσιαστικής σημασίας για Τον έλεγχο, ότι το έργο ικανοποιεί τις απαιτήσεις του

πελάτη και είναι ολοκληρωμένο,και Συντήρηση


Έγγραφο Προδιαγραφών (συνέχ.)

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


Σχέδιο Διαχείρισης Έργου ΛογισμικούSoftware Project Management Plan (SPMP)

Όταν ο πελάτης υπογράψει τις προδιαγραφές, αρχίζει η κατάστρωση ενός λεπτομερούς σχεδίου με τα χρονοδιαγράμματα του έργου μαζί με μια εκτίμηση κόστους

Το software project management plan, περιλαμβάνει Εκτίμηση κόστους (Cost estimate) Εκτίμηση Διάρκειας (Duration estimate) Παραδοτέα (Deliverables) Ορόσημα (Milestones) Προϋπολογισμός (Budget)

Το SPMP δεν θα μπορούσε να γίνει νωρίτερα


Η δραστηριότητα του Σχεδιασμού The Design Workflow

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

Πολλές μη λειτουργικές απαιτήσεις (requirements) πρέπει να οριστικοποιηθούν (finalized) τώρα. Αυτές συμπεριλαμβάνουν

Επιλογή της γλώσσας προγραμματισμού (programming language)

Θέματα επαναχρησιμοποίησης (Reuse issues) Θέματα φορητότητας (Portability issues)


Κλασικός Σχεδιασμός Classical Design

Ο κλασικός σχεδιασμός περιλάμβανε: Το Αρχιτεκτονικό Σχέδιο (Architectural design)

Διαμελισμόν του έργου σε τμήματα (modules)

Λεπτομερές Σχεδιασμό (Detailed design) Σχεδιασμό κάθε τμήματος (module):

Δομές δεδομένων (Data structures) Αλγόριθμοι (Algorithms)


Αντικειμενοστρεφές Σχεδιασμός Object-Oriented Design οι Κατηγορίες (Classes) επιλέγονται κατά τη

διάρκεια του της δραστηριότητας της ΟΟ ανάλυσης, και Σχεδιάζονται (ορίζονται τα μέλή τους, δηλ., πεδία και

μέθοδοι) κατά τη δραστηριότητα του σχεδιασμού Συνεπώς

Το κλασικό αρχιτεκτονικό σχέδιο αντιστοιχεί σε ένα μέρος του της δραστηριότητας της ΟΟ ανάλυσης

Ο κλασικός λεπτομερής σχεδιασμός στο ΟΟ παράδειγμα αντιστοιχεί σε ένα μέρος της δραστηριότητας του Σχεδιασμού


Δραστηριότητα Σχεδιασμού (συνέχ.)

Διατήρηση των αποφάσεων του design Για το πότε θα τελειώσει το έργο,και Για να προστατέψουμε την ομάδα που θα κάνει

συντήρηση από το να ξαναανακαλύψει τον τροχό


Η Δραστηριότητα της Υλοποίησης The Implementation Workflow

Ο στόχος της δραστηριότητας της υλοποίησης είναι να υλοποιήσει το στοχεύομενο προϊόν λογισμικού στην γλώσσα προγραμματισμού που έχει επιλεγεί Ένα μεγάλο προϊόν λογισμικού χωρίζεται σε

υποσυστήματα (subsystems) τα υποσυστήματα αποτελούνται από συστατικά μέρη ή

μέρη από κώδικα (code artifacts)


Η δραστηριότητα του Ελέγχου

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

assurance group)

Η ονοματολογία όλων των κομματιών (artifacts), έτσι ώστε να μπορούμε στην συνέχεια να αναφερόμαστε με ακρίβεια σε αυτά (traceability of artifacts) είναι μια σημαντική απαίτηση για επιτυχή έλεγχο


Συστατικά Μέρη/Κομμάτια/Παραδοτέα των Απαιτήσεων Requirements Artifacts Κάθε στοιχείο στα παραδοτέα (ή άλλο συστατικό

μέρος) της φάσης της ανάλυσης (analysis artifacts) πρέπει να παραπέμπει (must be traceable) σε ένα στοιχείο των παραδοτέων της φάσης των απαιτήσεων (requirements artifacts) Παρομοίως, το ίδιο θα πρέπει να ισχύει για τα

παραδοτέα της φάσης του σχεδιασμού και της υλοποίησης


Συστατικά Μέρη / Παραδοτέα της Ανάλυσης

Analysis Artifacts Τα παραδοτέα (και όλα τα άλλα συστατικά μέρη)

της φάσης της ανάλυσης πρέπει να ελεγχθούν με μεθόδους εξέτασης (review) Αντιπρόσωποι από τις ομάδες των πελατών (client)

και των αναλυτών (analysis) πρέπει να παρευρίσκονται

Το SPMP πρέπει να ελεγχθεί παρομοίως Δίνεται ιδιαίτερη σημασία στις εκτιμήσεις για το κόστος

και τη διάρκεια


Παραδοτέα/ Συστατικά Μέση Του Σχεδιασμού Μέρη Design Artifacts Η Εξέταση (έλεγχος) του Σχεδιασμού είναι

ουσιαστική και απαραίτητη Δεν συνηθίζεται να υπάρχει εκπρόσωπος του πελάτη

σε αυτή την εξέταση


Παραδοτέα/ Συστατικά Μέση την Υλοποίησης Implementation Artifacts

Κάθε κομμάτι ελέγχεται (tested) μόλις ολοκληρωθεί Έλεγχος μονάδας (Unit testing)

Στο τέλος κάθε επανάληψης (iteration), τα ολοκληρωμένα κομμάτια συνδέονται και ελέγχονται Έλεγχος ενσωμάτωσης (Integration testing)

Όταν το προϊόν είναι σχεδόν ολοκληρωμένο ελέγχεται σαν σύνολο Έλεγχος προϊόντος (Product testing)

Όταν το ολοκληρωμένο προϊόν εγκατασταθεί στους υπολογιστές του πελάτη, τότε το ελέγχει και ο πελάτης Έλεγχος αποδοχής (Acceptance testing)


Παραδοτέα/ Συστατικά Μέση της Υλοποίησης (συνέχ.) Λογισμικά τύπου COTS αφήνονται να ελεγχθούν

από ενδεχόμενους πελάτες Πρώτη Φάση (Alpha release) Δεύτερη Φάση (Beta release)

Υπάρχουν πλεονεκτήματα και μειονεκτήματα του να υπάρχει alpha ή beta release


Συντήρηση μετά την παράδοση Postdelivery Maintenance

Η συντήρηση ενός λογισμικού μετά την παράδοση του είναι ένα σημαντικό μέρος (κομμάτι) του το οποίο πρέπει να λαμβάνεται υπόψη και κατά την ανάπτυξης (development) του λογισμικού Ξοδεύονται περισσότερα χρήματα για συντήρηση

μετά την παράδοση παρά σε όλα τα άλλα κομμάτια μαζί

Προβλήματα μπορεί να προκύψουν λόγο Έλλειψης τεκμηρίωσης παντός είδους


Συντήρηση μετά την παράδοση (συνέχ.)

Χρειάζονται δυο είδη ελέγχου Έλεγχος των αλλαγών που έγιναν κατά την διάρκεια

του postdelivery maintenance Έλεγχος οπισθοδρόμησης (Regression testing)

όλες οι προηγούμενες περιπτώσεις ελέγχου (και τα αναμενόμενα αποτελέσματα τους) πρέπει να καταγράφονται και να διατηρούνται


Απόσυρση Retirement

Το λογισμικό μπορεί να ΜΗΝ μπορεί να συντηρηθεί πλέον επειδή Έχει συμβεί μια δραστική αλλαγή Το προϊόν πρέπει να υλοποιηθεί σε ένα εντελώς νέο

υλικό/ λειτουργικό σύστημα (hardware/operating system)

Έλλειψη ή ανακρίβειες στην τεκμηρίωση Αλλαγή υλικού—μπορεί να είναι πιο φθηνό να

ξαναγραφτεί το λογισμικό από την αρχή παρά να τροποποιηθεί

Αυτές είναι κάποιες περιπτώσεις/λόγοι για συντήρηση


Απόσυρση (συνέχ.)

Πραγματική απόσυρση (retirement) δεν είναι συχνό φαινόμενο

Συμβαίνει όταν ο οργανισμός του πελάτη δεν χρειάζεται πια τις υπηρεσίες που του προσφέρει το προϊόν


Οι φάσεις της Unified Process

Τα στάδια (increments) ταυτίζονται με τις ακόλουθες φάσεις

Figure 3.1


Οι φάσεις της Unified Process (συνέχ.)

Τα τέσσερα στάδια ονομάζονται Φάση έναρξης (Inception phase) Φάση επεξεργασίας (Elaboration phase) Φάση κατασκευής (Construction phase) Φάση μετάβασης (Transition phase)

Οι φάσεις (phases) της Unified Process είναι τα στάδια (increments)


Οι φάσεις της Unified Process (συνέχ.) Στην θεωρία, θα μπορούσε να υπάρχει οποιοσδήποτε

αριθμός από στάδια (increments) Στην πράξη, η ανάπτυξη φαίνεται να συνίσταται από τέσσερα

βασικά στάδια

Κάθε βήμα που εκτελείται στην Unified Process εμπίπτει σε Μια από τις πέντε βασικές δραστηριότητες (workflows) καθώς

επίσης και Σε μια από τις τέσσερις φάσεις (phases)

Γιατί πρέπει να λάβουμε υπόψη μας κάθε βήμα δυο φορές;


Οι φάσεις της Unified Process (συνέχ.) Δραστηριότητα (Workflow)

Τεχνικό περιεχόμενο ενός βήματος

Φάση (Phase) Επαγγελματικό περιεχόμενο κάθε βήματος


Φάση Έναρξης The Inception Phase

Ο στόχος της φάσης της έναρξης (inception phase) είναι να καθορίσει κατά πόσο το προτεινόμενο προϊόν λογισμικού είναι οικονομικά πραγματοποιήσιμο


Φάση Έναρξης (συνέχ.) 1. κερδίζουμε την κατανόηση της περιοχής

2. κατασκευή του business model

3. οριοθέτηση του πλαισίου του προτεινόμενου έργου Εστιάζομε στο μέρος του business model που

καλύπτεται από το προτεινόμενο προϊόν λογισμικού

4. Αρχίζει την initial business case


Φάση Έναρξης : The Initial Business Case

Χρειάζεται να απαντηθούν ανάμεσα σε άλλες οι ακόλουθες ερωτήσεις

Είναι το προτεινόμενο software product επικερδές; Πόσο καιρό θα πάρει για να αρχίσουμε να κερδίζουμε από αυτή την

επένδυση (απόσβεση της επένδυσης); Διαφορετικά, ποιο θα είναι το κόστος αν η εταιρία αποφασίσει να μην

αναπτύξει το προτεινόμενο προϊόν λογισμικού; Αν αυτό το προϊόν λογισμικού είναι για να πωλείται στην αγορά, έχει

γίνει η αναγκαία μελέτη για την εκμετάλλευση της αγοράς; Μπορεί το προτεινόμενο προϊόν λογισμικού να παραδοθεί στην ώρα

του; Αν το προϊόν λογισμικού θα αναπτυχθεί για να υποστηρίξει τις

δραστηριότητες της εταιρίας του πελάτη, ποιες θα είναι οι επιπτώσεις στην περίπτωση του το προτεινόμενο προϊόν λογισμικού παραδοθεί με καθυστέρηση;


Φάση Έναρξης : The Initial Business Case (συνέχ.) Ποια ρίσκα εμπλέκονται στην ανάπτυξη του ενός

προϊόντος λογισμικού, και Πως μπορούν αυτά τα ρίσκα να αμβλυνθούν;

Έχει η ομάδα που θα αναπτύξει το προτεινόμενο προϊόν λογισμικού την αναγκαία πείρα;

Χρειάζεται νέο υλικό για αυτό το λογισμικό; Αν ναι, υπάρχει ρίσκο να μην παραδοθεί (το υλικό) στην

ώρα του; Αν ναι, υπάρχει τρόπος να αμβλύνουμε αυτό το ρίσκο,

ίσως παραγγέλλοντας back-up hardware από άλλο πελάτη; Χρειάζονται κατάλληλα εργαλεία για την ανάπτυξη του

εν λόγο λογισμικού (software tools); Αν ναι είναι διαθέσιμα; Έχουν τις απαραίτητες

λειτουργικότητες;


Φάση Έναρξης : The Initial Business Case (συνέχ.)

Χρειάζονται απαντήσεις σε αυτές τις ερωτήσεις μέχρι το τέλος της φάσης έναρξης, έτσι ώστε το initial business case να μπορεί να δημιουργηθεί


Φάση Έναρξης : Ρίσκα (Risks)

Υπάρχουν τρεις κύριες κατηγορίες ρίσκων Τεχνικά ρίσκα (Technical risks)

Δες την προηγούμενη διαφάνεια Ρίσκο να μην καταλάβουμε σωστά τις απαιτήσεις

(requirements) Αμβλύνεται με το να εκτελέσουμε σωστά τη

δραστηριότητα των απαιτήσεων Ρίσκο να μην κάνουμε την αρχιτεκτονική σωστά

Η αρχιτεκτονική μπορεί να μην είναι ικανοποιητικά εύρωστη


Φάση Έναρξης : Ρίσκα (Risks)(συνέχ.) Για να αμβλύνουμε και τις τρεις κατηγορίες ρίσκων

Τα ρίσκα πρέπει να ταξινομηθούν έτσι ώστε τα πιο κρίσιμα να αμβλυνθούν πρώτα

Αυτά ολοκληρώνουν τα βήματα της φάσης έναρξης που εμπίπτουν κάτω από τη δραστηριότητα των απαιτήσεων


Φάση Έναρξης : δραστηριότητες Ανάλυσης και Σχεδιασμού Ένα μικρό μέρος από της δραστηριότητας της

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

σχεδιασμό της αρχιτεκτονικής

Συνεπώς, ένα μικρό μέρος και από τη δραστηριότητα του σχεδιασμού μπορεί να εκτελεστεί, επίσης από αυτή τη φάση


Φάση Έναρξης : Δραστηριότητα Υλοποίησης Συνήθως δεν παράγεται κώδικας κατά την φάση

έναρξης

Όμως, ένα πρωτότυπο που δείχνει το θέμα (proof-of-concept prototype) μερικές φορές κατασκευάζεται για να ελεγχθεί η δυνατότητα επίτευξης (feasibility) του, κατασκευάζοντας ένα τμήμα από το στοχευόμενου προϊόντος λογισμικού


Φάση Έναρξης : Δραστηριότητα Ελέγχου

Η δραστηριότητα ελέγχου αρχίζει σχεδόν από την αρχή της φάσης έναρξης Ο στόχος του είναι να εξασφαλίσει ότι οι απαιτήσεις

έχουν επακριβώς καθοριστεί


Φάση Έναρξης : καθορισμός Πλάνου (Planning) Δεν υπάρχουν επαρκείς πληροφορίες στην αρχή

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

ο σχεδιασμός της φάσης έναρξης

Για τον ίδιο λόγο, ο μόνος σχεδιασμός που μπορεί να γίνει στο τέλος της φάσης έναρξης είναι να σχεδιαστεί απλώς η επόμενη φάση, δηλ. η φάση της επεξεργασίας (the elaboration phase)


Φάση Έναρξης : Τεκμηρίωση (Documentation) Τα παραδοτέα της φάσης έναρξης περιλαμβάνουν:

Την αρχική έκδοση του μοντέλου του πεδίου (domain model)

Την αρχική έκδοση του business model Την αρχική έκδοση των κομματιών των απαιτήσεων

(requirements artifacts) Μια προκαταρτική έκδοση των κομματιών για την

ανάλυση (analysis artifacts) Μια προκαταρτική έκδοση της αρχιτεκτονικής Την αρχική λίστα των ρίσκων Την αρχική διάταξη των περιπτώσεων χρήσης (use

cases) (κεφ. 10) Τα σχέδιο για την φάση της επεξεργασίας Την αρχική έκδοση της business case


Φάση Έναρξης : The Initial Business Case Το να πάρουμε την αρχική έκδοση της business case είναι ο γενικός στόχος της φάσης έναρξης

Η αρχική έκδοση περιλαμβάνει Μια περιγραφή των δυνατοτήτων που θα μπορεί να

παρέχει το προτεινόμενο προϊόν λογισμικού Οικονομικές λεπτομέρειες Αν το προτεινόμενο προϊόν λογισμικού είναι για να δοθεί

προς πώληση, η business case θα περιλαμβάνει επίσης Φορολογικές προβλέψεις, εκτιμήσεις της αγοράς, εκτιμήσεις

αρχικού κόστους Αν το θα χρησιμοποιείται in-house, η business case θα

περιλαμβάνει Την αρχική ανάλυση κόστους-οφέλους (cost–benefit analysis)


Φάση Επεξεργασίας Elaboration Phase Ο στόχος της φάσης της επεξεργασίας (elaboration

phase) είναι να εκλεπτύνει (αναλύσει σε μεγαλύτερο βάθος) τις αρχικές απαιτήσεις Τελειοποίηση της αρχιτεκτονικής Επιτήρηση των ρίσκων και καθορισμός

προτεραιοτήτων μεταξύ τους Τελειοποίηση της business case Παραγωγή του software project management plan

Οι κύριες δραστηριότητες της φάσης της επεξεργασίας είναι η εκλέπτυνση/τελειοποίηση (ή επεξεργασίας) της προηγούμενης φάσης


Οι Εργασίες της Φάσης της Επεξεργασίας The Tasks of the Elaboration Phase

Οι εργασίες (tasks) της φάσης της επεξεργασίας αντιστοιχούν σε: Ολοκλήρωση της δραστηριότητας των απαιτήσεων Εικονική εκτέλεση ολόκληρης της δραστηριότητας της

ανάλυσης Έναρξη του σχεδιασμού της αρχιτεκτονικής ( the

design of the architecture)


Φάση Επεξεργασίας : Τεκμηρίωση

Τα παραδοτέα της φάσης της επεξεργασίας περιλαμβάνουν: Το ολοκληρωμένο μοντέλο του πεδίου (domain model) Το ολοκληρωμένο business model Ολοκληρωμένα τα κομμάτια των απαιτήσεων

(requirements artifacts) Ολοκληρωμένα τα κομμάτια της ανάλυσης (analysis

artifacts) Μια ενημερωμένη έκδοση της αρχιτεκτονικής Μια ενημερωμένη λίστα των ρίσκων το project management plan (για το υπόλοιπο του

project) Ολοκληρωμένη την business case


Φάση Κατασκευής Construction Phase

Ο στόχος της φάσης της κατασκευής (construction phase) είναι να παράξει την πρώτη έκδοση λειτουργικότητας-ποιότητας (operational-quality) του προϊόντος λογισμικού Αυτό μερικές φορές ονομάζεται beta release


Οι Εργασίες της Φάσης Κατασκευής The Tasks of the Construction Phase

Η έμφαση σε αυτή τη φάση είναι στα ακόλουθα: Κωδικοποίηση (Implementation), και Έλεγχο (Testing)

Μεμονωμένος έλεγχος των τμημάτων (Unit testing) Έλεγχος Ενσωμάτωσης των υποσυστημάτων ή

διαφόρων τμημάτων Έλεγχος ολόκληρου του συστήματος (Product testing)


Φάσης Κατασκευής: Τεκμηρίωση

Τα παραδοτέα της φάσης της κατασκευής περιλαμβάνουν: Το αρχικό εγχειρίδιο για τον χρήστη (user manual) και

άλλα κατάλληλα εγχειρίδια Όλα τα κομμάτια (beta release versions) Ολοκληρωμένη αρχιτεκτονική Ενημερωμένη λίστα ρίσκων το project management plan (για το υπόλοιπο project) Αν χρειάζεται, ενημερωμένη η business case


Φάση Μετάβασης The Transition Phase Ο στόχος της φάσης της μετάβασης (transition

phase) είναι η εξασφάλιση ότι οι απαιτήσεις (requirements) του πελάτη έχουν ικανοποιηθεί Λάθη (Faults) στο προϊόν λογισμικού διορθώνονται Ολοκλήρωση όλων των εγχειριδίων Γίνεται προσπάθεια για εύρεση ρίσκων τα οποία

μπορεί να μην έχουν εντοπιστεί νωρίτερα

Αυτή η φάση καθοδηγείται από αναδράσεις (feedback) από τις πλευρές όπου έχει εγκατασταθεί το beta release


Φάση Μετάβασης : Τεκμηρίωση

Τα παραδοτέα της φάσης της μετάβασης περιλαμβάνουν: Τελικές εκδόσεις όλων των κομματιών (artifacts) Ολοκληρωμένα τα εγχειρίδια


One- and Two-Dimensional Life-Cycle Models

Figure 3.2


Γιατί two-Dimensional Model;

Ένας παραδοσιακός κύκλος ζωής είναι ένα μοντέλο μιας-διάστασης (one-dimensional model) Αναπαριστάται από ένα απλό άξονα στην

προηγούμενη διαφάνεια Παράδειγμα: το μοντέλο του Καταρράκτη (Waterfall

model) Η Unified Process είναι δυο-διαστάσεων μοντέλο

(two-dimensional model) Αναπαριστάται από δύο άξονες στην προηγούμενη

διαφάνεια Η εικόνα στο two-dimensional δείχνει

Τις δραστηριότητες (τεχνικό περιεχόμενο), και Τις φάσεις (επιχειρηματικό περιεχόμενο)


Γιατί το Two-Dimensional Model; (συνέχ.) Το μοντέλο του καταρράκτη

(The waterfall model)

Μιας-διάστασης

(One-dimensional)

Figure 2.3 (again)


Γιατί το Two-Dimensional Model; (συνέχ.) Μοντέλο Δέντρου Εξέλιξης (Evolution tree model) Δυο-διαστάσεων (Two-dimensional)

Figure 2.2 (again)


Γιατί το Two-Dimensional Model; (συνέχ.)

Είναι αναγκαία η επιπλέον πολυπλοκότητα του μοντέλου δυο-διαστάσεων (two-dimensional model);

Σε ένα ιδεατό κόσμο, κάθε δραστηριότητα θα ολοκληρωνόταν πριν αρχίσει η επόμενη


Γιατί το Two-Dimensional Model; (συνέχ.) Στην πραγματικότητα, το έργο της ανάπτυξης είναι

πολύ μεγάλο για κάτι τέτοιο

Σαν συνέπεια του Miller’s Law Η εργασία της ανάπτυξης (development task) πρέπει

να διαιρεθεί σε στάδια (increments, phases) Σε κάθε στάδιο, εκτελούνται επαναλήψεις (iterations)

μέχρι να ολοκληρωθεί η εργασία


Γιατί το Two-Dimensional Model; (συνέχ.) Στην αρχή της διαδικασίας, δεν υπάρχει αρκετή

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

Ένα προϊόν λογισμικού πρέπει να διαιρεθεί σε υποσυστήματα (subsystems)

Ακόμα και τα υποσυστήματα μερικές φορές είναι πολύ μεγάλα Τα Τμήματα (Modules) μπορεί να είναι τα μόνα μέρη που

μπορούν να διαχειριστούν μέχρι που να δοθεί μια πιο πλήρης κατανόηση όλων των μερών (parts) του προϊόντος σαν σύνολο


Γιατί το Two-Dimensional Model; (συνέχ.) Η Unified Process διαχειρίζεται τις αναπόφευκτες αλλαγές/προβλήματα με ένα ικανοποιητικό (καλό) τρόπο Το πρόβλημα της αλλαγής στόχου (moving target probl.) Τα αναπόφευκτα λάθη

Η Unified Process είναι η καλύτερη λύση που βρέθηκε μέχρι σήμερα για το χειρισμό μεγάλων προβλημάτων σαν ένα σύνολο από μικρότερα, ανεξάρτητα υποπροβλήματα Παρέχει το πλαίσιο εργασίας (framework) για επανάληψη

και σταδιακή πρόοδο (iteration and incrementation) Στο μέλλον, είναι αναπόφευκτό ότι θα αντικατασταθεί από

καλύτερες μεθοδολογίες


Βελτιώνοντας την Διαδικασία Ανάπτυξης Λογισμικού Software Process Παράδειγμα:

U.S. Department of Defense initiative

Software Engineering Institute (SEI)

Το θεμελιώδες πρόβλημα με το λογισμικό η διαδικασία ανάπτυξης λογισμικού (software

process) διαχειρίζεται ΚΑΚΑ


Βελτιώνοντας την Διαδικασία Ανάπτυξης Λογισμικού (συνέχ.)

Πρωτοβουλίες για βελτίωση της Διαδικασία Ανάπτυξης Λογισμικού

Μοντέλο Ωριμότητας των Ικανοτήτων (Capability maturity model CMM)

ISO 9000-series ISO/IEC 15504


Ικανότητες Ώριμων Μοντέλων Capability Maturity Models

Όχι ΈΝΑ μοντέλο Κύκλου Ζωής Κατά προτίμηση, ένα σύνολο στρατηγικών (strategies) για

βελτίωση της Διαδικασία Ανάπτυξης Λογισμικού SW–CMM for software P–CMM for human resources (“people”) SE–CMM for systems engineering IPD–CMM for integrated product development SA–for software acquisition

Αυτές οι στρατηγικές ενσωματώνονται στο CMMI (capability maturity model integration)


SW–CMM

Μια στρατηγική για βελτίωση της Διαδικασία Ανάπτυξης Λογισμικού

Άρχισε το 1986 από το SEI

Βασικές ιδέες: Βελτίωση της Διαδικασία Ανάπτυξης Λογισμικού οδηγεί σε

Βελτιωμένης ποιότητας λογισμικό Παράδοση εντός των προθεσμιών και του προϋπολογισμού Βελτιωμένη διαχείριση οδηγεί σε

Βελτιωμένες τεχνικές


SW–CMM (συνέχ.)

Ορίζονται Πέντε επίπεδα Ωριμότητας (maturity) Ωριμότητα (Maturity) είναι ένα μέτρο (τρόπος

μέτρησης) των ικανοτήτων της διαδικασίας που ακολουθείται

Ένας οργανισμός (εταιρία) ανάπτυξης λογισμικού βελτιώνεται βήμα βήμα από το ένα επίπεδο στο άλλο


Level 1. αρχικό επίπεδο (Initial Level)

Ad hoc προσέγγιση Ολόκληρη η διαδικασία είναι άστατη

(απρόβλεπτη) Η διαχείριση συνίσταται από κρίσεις σε κρίσεις

Πολλοί οργανισμοί σε ολόκληρο τον κόσμο είναι στο level 1


Level 2. Επαναλαμβανόμενο επίπεδο (Repeatable Level) Βασική διαχείριση λογισμικού

Αποφάσεις για τη διαχείριση πρέπει να λαμβάνονται με βάση προηγούμενη εμπειρία από παρόμοια προϊόντα

Γίνονται μετρήσεις Αυτές μπορεί να χρησιμοποιηθούν για να γίνουν

προβλέψεις κόστους και διάρκειας επόμενων έργων Όταν εντοπιστούν προβλήματα, λαμβάνονται άμεσα

διορθωτικές ενέργειες


Level 3. Καθορισμένο επίπεδο (Defined Level)

Η διαδικασία ανάπτυξης λογισμικού είναι πλήρως τεκμηριωμένη Πτυχές διοίκησης και τεχνικές πτυχές είναι ξεκάθαρα

ορισμένες Γίνεται συνεχής προσπάθεια για βελτίωση της

ποιότητας (quality) και της παραγωγικότητας (productivity)

Γίνονται εξετάσεις για βελτίωση της ποιότητας του λογισμικού

Χρήση CASE tools


Level 4. Ελεγχόμενο Επίπεδο (Managed Level) Στόχοι ποιότητας και παραγωγικότητας θέτονται

για κάθε έργο Ποιότητα και παραγωγικότητα παρακολουθούνται

συνεχώς Θέτονται σε εφαρμογή στατιστικοί ποιοτικοί έλεγχοι

(Statistical quality controls)


Level 5. Επίπεδο βελτιστοποίησης (Optimizing Level) Συνεχής βελτίωση της διαδικασίας

Στατιστική μέτρηση της ποιότητας και έλεγχοι στην διαδικασία

Αναδράσεις και γνώσεις μεταφέρονται από το ένα έργο στο άλλο


Περίληψη

Figure 3.3


Εμπειρία από το SW–CMM

Παίρνει: 3 με 5 χρόνια για να πάμε από το level 1 στο level 2 1.5 με 3 χρόνια για να πάμε από το level 2 στο level 3 SEI ερωτηματολόγια προβάλλουν ανεπάρκειες,

εισηγούνται τρόπους βελτίωσης της διαδικασίας


Key Process Areas

Υπάρχουν περιοχές κλειδιά στην διαδικασία (key process areas (KPAs)) σε κάθε επίπεδο


Key Process Areas (συνέχ.) Level-2 KPAs περιλαμβάνουν:

Requirements management Project planning Project tracking Configuration management Quality assurance

Σύγκριση Level 2: Detection and correction of faults Level 5: Prevention of faults


Στόχοι

Αρχικός στόχος (Original goal): Υποστηρίξει συμβολαίων (Defense contracts) πρέπει να

χορηγείται μόνο από ικανές εταιρίες

The U.S. Air Force ορίζει σαφώς και κατηγορηματικώς ότι κάθε κατασκευαστής Air Force πρέπει να φτάσει στο SW–CMM level 3 μέχρι το 1998

Παρόμοια έπραξε και η DoD στη συνέχεια

The CMM has now gone far beyond the limited goal of improving DoD software


Άλλες πρωτοβουλίες για βελτίωση της Software Process

Άλλες πρωτοβουλίες για βελτίωση της software process (SPI) περιλαμβάνουν: ISO 9000-series ISO/IEC 15504


ISO 9000

A set of five standards for industrial activities ISO 9001 for quality systems ISO 9000-3, guidelines to apply ISO 9001 to software There is an overlap with CMM, but they are not identical Not process improvement There is a stress on documenting the process There is an emphasis on measurement and metrics ISO 9000 is required to do business with the EU Also required by many U.S. businesses, including GE More and more U.S. businesses are ISO 9000 certified


ISO/IEC 15504

Original name: Software Process Improvement Capability dEtermination (SPICE) International process improvement initiative Started by the British Ministry of Defence (MOD) Includes process improvement, software procurement Extends and improves CMM, ISO 9000 A framework, not a method

CMM, ISO 9000 conform to this framework Now referred to as ISO/IEC 15504 Or just 15504 for short


Κόστος και Ωφέλεια από την βελτίωση της Software Process (Costs and Benefits of Software Process Improvement) Hughes Aircraft (Fullerton, CA) spent $500K (1987–

90) Savings: $2M per year, moving from level 2 to level 3

Raytheon moved from level 1 in 1988 to level 3 in 1993 Productivity doubled Return of $7.70 per dollar invested in process

improvement


Costs and Benefits of Software Process Improvement (contd) Tata Consultancy Services (India) used ISO 9000

and CMM (1996–90) Errors in estimation decreased from 50% to 15% Effectiveness of reviews increased from 40% to 80%

Motorola GED has used CMM (1992–97) Results are shown in the next slide


Results of 34 Motorola Projects

MEASL – Million equivalent assembler source lines

Motorola does not reveal productivity data Productivity is measured relative to that of a selected level-2 project No fault or productivity data available for level-1 projects (by definition)

Figure 3.4


Costs and Benefits of Software Process Improvement (contd) There is interplay between

Software engineering standards organizations, and Software process improvement initiatives

ISO/IEC 12207 (1995) is a full life-cycle software standard

In 1998, the U.S. version (IEEE/EIA 12207) was published that incorporated ideas from CMM

ISO 9000-3 now incorporates part of ISO/IEC 12207

Documents

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