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

Παρουσίαση με θέμα: "Μοντέλα Κύκλου Ζωής Λογισμικού"— Μεταγράφημα παρουσίασης:

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 είναι μια προσαρμόσιμη μεθοδολογία Πρέπει να τροποποιείται σε κάθε συγκεκριμένο προϊόν λογισμικού που θα αναπτυχθεί Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

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
Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

42 Φάση Έναρξης (συνέχ.) 1. κερδίζουμε την κατανόηση της περιοχής
Φάση Έναρξης (συνέχ.) 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 (συνέχ.)
Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

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

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

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

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

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

51 Φάση Έναρξης : καθορισμός Πλάνου (Planning)
Δεν υπάρχουν επαρκείς πληροφορίες στην αρχή της φάσης έναρξης για να καθοριστεί ολόκληρο το σχέδιο της ανάπτυξης του λογισμικού Το μόνο σχέδιο που γίνεται στην αρχή του έργου είναι ο σχεδιασμός της φάσης έναρξης Για τον ίδιο λόγο, ο μόνος σχεδιασμός που μπορεί να γίνει στο τέλος της φάσης έναρξης είναι να σχεδιαστεί απλώς η επόμενη φάση, δηλ. η φάση της επεξεργασίας (the elaboration phase) Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

52 Φάση Έναρξης : Τεκμηρίωση (Documentation)
Τα παραδοτέα της φάσης έναρξης περιλαμβάνουν: Την αρχική έκδοση του μοντέλου του πεδίου (domain model) Την αρχική έκδοση του business model Την αρχική έκδοση των κομματιών των απαιτήσεων (requirements artifacts) Μια προκαταρτική έκδοση των κομματιών για την ανάλυση (analysis artifacts) Μια προκαταρτική έκδοση της αρχιτεκτονικής Την αρχική λίστα των ρίσκων Την αρχική διάταξη των περιπτώσεων χρήσης (use cases) (κεφ. 10) Τα σχέδιο για την φάση της επεξεργασίας Την αρχική έκδοση της business case Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

53 Φάση Έναρξης : The Initial Business Case
Η αρχική έκδοση περιλαμβάνει Μια περιγραφή των δυνατοτήτων που θα μπορεί να παρέχει το προτεινόμενο προϊόν λογισμικού Οικονομικές λεπτομέρειες Αν το προτεινόμενο προϊόν λογισμικού είναι για να δοθεί προς πώληση, η business case θα περιλαμβάνει επίσης Φορολογικές προβλέψεις, εκτιμήσεις της αγοράς, εκτιμήσεις αρχικού κόστους Αν το θα χρησιμοποιείται in-house, η business case θα περιλαμβάνει Την αρχική ανάλυση κόστους-οφέλους (cost–benefit analysis) Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

54 Φάση Επεξεργασίας Elaboration Phase
Τελειοποίηση της αρχιτεκτονικής Επιτήρηση των ρίσκων και καθορισμός προτεραιοτήτων μεταξύ τους Τελειοποίηση της business case Παραγωγή του software project management plan Οι κύριες δραστηριότητες της φάσης της επεξεργασίας είναι η εκλέπτυνση/τελειοποίηση (ή επεξεργασίας) της προηγούμενης φάσης Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

55 Οι Εργασίες της Φάσης της Επεξεργασίας The Tasks of the Elaboration Phase
Ολοκλήρωση της δραστηριότητας των απαιτήσεων Εικονική εκτέλεση ολόκληρης της δραστηριότητας της ανάλυσης Έναρξη του σχεδιασμού της αρχιτεκτονικής ( the design of the architecture) Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

56 Φάση Επεξεργασίας : Τεκμηρίωση
Τα παραδοτέα της φάσης της επεξεργασίας περιλαμβάνουν: Το ολοκληρωμένο μοντέλο του πεδίου (domain model) Το ολοκληρωμένο business model Ολοκληρωμένα τα κομμάτια των απαιτήσεων (requirements artifacts) Ολοκληρωμένα τα κομμάτια της ανάλυσης (analysis artifacts) Μια ενημερωμένη έκδοση της αρχιτεκτονικής Μια ενημερωμένη λίστα των ρίσκων το project management plan (για το υπόλοιπο του project) Ολοκληρωμένη την business case Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

57 Φάση Κατασκευής Construction Phase
Ο στόχος της φάσης της κατασκευής (construction phase) είναι να παράξει την πρώτη έκδοση λειτουργικότητας-ποιότητας (operational-quality) του προϊόντος λογισμικού Αυτό μερικές φορές ονομάζεται beta release Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

58 Οι Εργασίες της Φάσης Κατασκευής The Tasks of the Construction Phase
Η έμφαση σε αυτή τη φάση είναι στα ακόλουθα: Κωδικοποίηση (Implementation), και Έλεγχο (Testing) Μεμονωμένος έλεγχος των τμημάτων (Unit testing) Έλεγχος Ενσωμάτωσης των υποσυστημάτων ή διαφόρων τμημάτων Έλεγχος ολόκληρου του συστήματος (Product testing) Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

59 Φάσης Κατασκευής: Τεκμηρίωση
Τα παραδοτέα της φάσης της κατασκευής περιλαμβάνουν: Το αρχικό εγχειρίδιο για τον χρήστη (user manual) και άλλα κατάλληλα εγχειρίδια Όλα τα κομμάτια (beta release versions) Ολοκληρωμένη αρχιτεκτονική Ενημερωμένη λίστα ρίσκων το project management plan (για το υπόλοιπο project) Αν χρειάζεται, ενημερωμένη η business case Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

60 Φάση Μετάβασης The Transition Phase
Ο στόχος της φάσης της μετάβασης (transition phase) είναι η εξασφάλιση ότι οι απαιτήσεις (requirements) του πελάτη έχουν ικανοποιηθεί Λάθη (Faults) στο προϊόν λογισμικού διορθώνονται Ολοκλήρωση όλων των εγχειριδίων Γίνεται προσπάθεια για εύρεση ρίσκων τα οποία μπορεί να μην έχουν εντοπιστεί νωρίτερα Αυτή η φάση καθοδηγείται από αναδράσεις (feedback) από τις πλευρές όπου έχει εγκατασταθεί το beta release Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

61 Φάση Μετάβασης : Τεκμηρίωση
Τα παραδοτέα της φάσης της μετάβασης περιλαμβάνουν: Τελικές εκδόσεις όλων των κομματιών (artifacts) Ολοκληρωμένα τα εγχειρίδια Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

62 One- and Two-Dimensional Life-Cycle Models
Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου Figure 3.2

63 Γιατί two-Dimensional Model;
Ένας παραδοσιακός κύκλος ζωής είναι ένα μοντέλο μιας-διάστασης (one-dimensional model) Αναπαριστάται από ένα απλό άξονα στην προηγούμενη διαφάνεια Παράδειγμα: το μοντέλο του Καταρράκτη (Waterfall model) Η Unified Process είναι δυο-διαστάσεων μοντέλο (two-dimensional model) Αναπαριστάται από δύο άξονες στην προηγούμενη διαφάνεια Η εικόνα στο two-dimensional δείχνει Τις δραστηριότητες (τεχνικό περιεχόμενο), και Τις φάσεις (επιχειρηματικό περιεχόμενο) Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

64 Γιατί το Two-Dimensional Model; (συνέχ.)
Το μοντέλο του καταρράκτη (The waterfall model) Μιας-διάστασης (One-dimensional) Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου Figure 2.3 (again)

65 Γιατί το Two-Dimensional Model; (συνέχ.)
Μοντέλο Δέντρου Εξέλιξης (Evolution tree model) Δυο-διαστάσεων (Two-dimensional) Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου Figure 2.2 (again)

66 Γιατί το Two-Dimensional Model; (συνέχ.)
Σε ένα ιδεατό κόσμο, κάθε δραστηριότητα θα ολοκληρωνόταν πριν αρχίσει η επόμενη Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

67 Γιατί το Two-Dimensional Model; (συνέχ.)
Στην πραγματικότητα, το έργο της ανάπτυξης είναι πολύ μεγάλο για κάτι τέτοιο Σαν συνέπεια του Miller’s Law Η εργασία της ανάπτυξης (development task) πρέπει να διαιρεθεί σε στάδια (increments, phases) Σε κάθε στάδιο, εκτελούνται επαναλήψεις (iterations) μέχρι να ολοκληρωθεί η εργασία Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

68 Γιατί το Two-Dimensional Model; (συνέχ.)
Στην αρχή της διαδικασίας, δεν υπάρχει αρκετή πληροφορία για το προϊόν λογισμικού για να διεξαχθεί πλήρως η δραστηριότητα των απαιτήσεων σε ένα στάδιο Παρομοίως και για τις άλλες δραστηριότητες Ένα προϊόν λογισμικού πρέπει να διαιρεθεί σε υποσυστήματα (subsystems) Ακόμα και τα υποσυστήματα μερικές φορές είναι πολύ μεγάλα Τα Τμήματα (Modules) μπορεί να είναι τα μόνα μέρη που μπορούν να διαχειριστούν μέχρι που να δοθεί μια πιο πλήρης κατανόηση όλων των μερών (parts) του προϊόντος σαν σύνολο Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

69 Γιατί το Two-Dimensional Model; (συνέχ.)
Η Unified Process διαχειρίζεται τις αναπόφευκτες αλλαγές/προβλήματα με ένα ικανοποιητικό (καλό) τρόπο Το πρόβλημα της αλλαγής στόχου (moving target probl.) Τα αναπόφευκτα λάθη Η Unified Process είναι η καλύτερη λύση που βρέθηκε μέχρι σήμερα για το χειρισμό μεγάλων προβλημάτων σαν ένα σύνολο από μικρότερα, ανεξάρτητα υποπροβλήματα Παρέχει το πλαίσιο εργασίας (framework) για επανάληψη και σταδιακή πρόοδο (iteration and incrementation) Στο μέλλον, είναι αναπόφευκτό ότι θα αντικατασταθεί από καλύτερες μεθοδολογίες Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

70 Βελτιώνοντας την Διαδικασία Ανάπτυξης Λογισμικού Software Process
Παράδειγμα: U.S. Department of Defense initiative Software Engineering Institute (SEI) Το θεμελιώδες πρόβλημα με το λογισμικό η διαδικασία ανάπτυξης λογισμικού (software process) διαχειρίζεται ΚΑΚΑ Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

71 Βελτιώνοντας την Διαδικασία Ανάπτυξης Λογισμικού (συνέχ.)
Πρωτοβουλίες για βελτίωση της Διαδικασία Ανάπτυξης Λογισμικού Μοντέλο Ωριμότητας των Ικανοτήτων (Capability maturity model CMM) ISO 9000-series ISO/IEC 15504 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

72 Ικανότητες Ώριμων Μοντέλων 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) Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

73 SW–CMM Μια στρατηγική για βελτίωση της Διαδικασία Ανάπτυξης Λογισμικού
Άρχισε το 1986 από το SEI Βασικές ιδέες: Βελτίωση της Διαδικασία Ανάπτυξης Λογισμικού οδηγεί σε Βελτιωμένης ποιότητας λογισμικό Παράδοση εντός των προθεσμιών και του προϋπολογισμού Βελτιωμένη διαχείριση οδηγεί σε Βελτιωμένες τεχνικές Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

74 SW–CMM (συνέχ.) Ορίζονται Πέντε επίπεδα Ωριμότητας (maturity)
Ένας οργανισμός (εταιρία) ανάπτυξης λογισμικού βελτιώνεται βήμα βήμα από το ένα επίπεδο στο άλλο Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

75 Level 1. αρχικό επίπεδο (Initial Level)
Ad hoc προσέγγιση Ολόκληρη η διαδικασία είναι άστατη (απρόβλεπτη) Η διαχείριση συνίσταται από κρίσεις σε κρίσεις Πολλοί οργανισμοί σε ολόκληρο τον κόσμο είναι στο level 1 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

76 Level 2. Επαναλαμβανόμενο επίπεδο (Repeatable Level)
Βασική διαχείριση λογισμικού Αποφάσεις για τη διαχείριση πρέπει να λαμβάνονται με βάση προηγούμενη εμπειρία από παρόμοια προϊόντα Γίνονται μετρήσεις Αυτές μπορεί να χρησιμοποιηθούν για να γίνουν προβλέψεις κόστους και διάρκειας επόμενων έργων Όταν εντοπιστούν προβλήματα, λαμβάνονται άμεσα διορθωτικές ενέργειες Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

77 Level 3. Καθορισμένο επίπεδο (Defined Level)
Η διαδικασία ανάπτυξης λογισμικού είναι πλήρως τεκμηριωμένη Πτυχές διοίκησης και τεχνικές πτυχές είναι ξεκάθαρα ορισμένες Γίνεται συνεχής προσπάθεια για βελτίωση της ποιότητας (quality) και της παραγωγικότητας (productivity) Γίνονται εξετάσεις για βελτίωση της ποιότητας του λογισμικού Χρήση CASE tools Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

78 Level 4. Ελεγχόμενο Επίπεδο (Managed Level)
Στόχοι ποιότητας και παραγωγικότητας θέτονται για κάθε έργο Ποιότητα και παραγωγικότητα παρακολουθούνται συνεχώς Θέτονται σε εφαρμογή στατιστικοί ποιοτικοί έλεγχοι (Statistical quality controls) Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

79 Level 5. Επίπεδο βελτιστοποίησης (Optimizing Level)
Συνεχής βελτίωση της διαδικασίας Στατιστική μέτρηση της ποιότητας και έλεγχοι στην διαδικασία Αναδράσεις και γνώσεις μεταφέρονται από το ένα έργο στο άλλο Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

80 Περίληψη Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου Figure 3.3

81 Εμπειρία από το SW–CMM Παίρνει:
3 με 5 χρόνια για να πάμε από το level 1 στο level 2 1.5 με 3 χρόνια για να πάμε από το level 2 στο level 3 SEI ερωτηματολόγια προβάλλουν ανεπάρκειες, εισηγούνται τρόπους βελτίωσης της διαδικασίας Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

82 Key Process Areas Υπάρχουν περιοχές κλειδιά στην διαδικασία (key process areas (KPAs)) σε κάθε επίπεδο Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

83 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 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

84 Στόχοι Αρχικός στόχος (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 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

85 Άλλες πρωτοβουλίες για βελτίωση της Software Process
Άλλες πρωτοβουλίες για βελτίωση της software process (SPI) περιλαμβάνουν: ISO 9000-series ISO/IEC 15504 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

86 ISO 9000 A set of five standards for industrial activities
ISO 9001 for quality systems ISO , 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 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

87 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 for short Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

88 Hughes Aircraft (Fullerton, CA) spent $500K (1987–90)
Κόστος και Ωφέλεια από την βελτίωση της 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 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

89 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 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

90 Results of 34 Motorola Projects
Figure 3.4 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) Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου

91 Costs and Benefits of Software Process Improvement (contd)
There is interplay between Software engineering standards organizations, and Software process improvement initiatives ISO/IEC (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 now incorporates part of ISO/IEC 12207 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου