Transcript Ο Σκοπός της Τεχνολογίας Λογισμικού

Μοντέλα Κύκλου Ζωής Λογισμικού
Δρ. Μαρία Ι. Ανδρέου
Περιεχόμενα







The Unified Process
Το μοντέλο της επανάληψης και της Σταδιακής
Εκλέπτυνσης στο ΟΟ παράδειγμα
Η δραστηριότητα των Απαιτήσεων
Η δραστηριότητα της ανάλυσης
Η δραστηριότητα του Σχεδιασμού
Η δραστηριότητα της υλοποίησης
Η δραστηριότητα του ελέγχου
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
2
Περιεχόμενα








(συνέχ.)
Συντήρηση μετά την παράδοση (Postdelivery
maintenance)
Απόσυρση
Η φάση της Unified Process
Μοντέλα κύκλου ζωής Μιας-διάστασης έναντι
μοντέλων δυο-διαστάσεων
Βελτιώνοντας την διαδικασία ανάπτυξης λογισμικού
Ικανότητες Ώριμων μοντέλων
Άλλες αρχές βελτίωσης της διαδικασίας ανάπτυξης
λογισμικού
Κόστος και κέρδος από τη βελτίωση της διαδικασίας
ανάπτυξης λογισμικού
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
3
The Unified Process

Μέχρι πρόσφατα, τρεις από τις πιο επιτυχημένες
αντικειμενοστρεφείς (object-oriented, ΟΟ)
μεθοδολογίες ήταν οι



Booch’s method
Jacobson’s Objectory
Rumbaugh’s OMT
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
4
The Unified Process

(συνέχ.)
In 1999, Booch, Jacobson, and Rumbaugh
εκδώσαν μια ολοκληρωμένη μεθοδολογία για
αντικειμενοστρεφή ανάλυση και σχεδιασμό (objectoriented analysis and design) που ενοποιεί (unify)
τις τρεις ξεχωριστές μεθοδολογίες που πρότειναν



Αρχικό Όνομα: Rational Unified Process (RUP)
Επόμενο Όνομα: Unified Software Development
Process (USDP)
Σημερινό όνομα: Unified Process (για συντομία)
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
5
The Unified Process

Η Unified Process ΔΕΝ είναι μια σειρά από βήματα
με στόχο την κατασκευή ενός προϊόντος λογισμικού



(συνέχ.)
Καμία μεθοδολογία δεν θα μπορούσε να υπάρξει που
να εφαρμόζεται σε όλες τις περιπτώσεις
Υπάρχει μια μεγάλη ποικιλία από διαφορετικούς
τύπους λογισμικών
Η Unified Process είναι μια προσαρμόσιμη
μεθοδολογία

Πρέπει να τροποποιείται σε κάθε συγκεκριμένο προϊόν
λογισμικού που θα αναπτυχθεί
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
6
The Unified Process

Η UML είναι μια γραφική γλώσσα


(συνέχ.)
Μια εικόνα είναι ίση με χίλιες λέξεις
Τα UML διαγράμματα επιτρέπουν στον μηχανικό
του λογισμικού να επικοινωνεί γρήγορα και με
ακρίβεια (accuracy)
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
7
Επανάληψη και Σταδιακή Πρόοδος στο OO Παράδειγμα

Η Unified Process είναι μια τεχνική για
μοντελοποίηση


Ένα μοντέλο (model) είναι ένα σύνολο από UML
διαγράμματα που αναπαριστούν διάφορες πτυχές του
προϊόντος λογισμικού που θέλουμε να αναπτύξουμε
UML είναι η σημειογραφία για τη unified modeling
language

Η UML είναι ένα εργαλείο που χρησιμοποιούμε για να
αναπαραστήσουμε (model) το προϊόν λογισμικού που
έχουμε σαν στόχο να αναπτύξουμε
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
8
Επανάληψη και Σταδιακή Πρόοδος στο OO Παράδειγμα

(συνεχ.)
Το ΟΟ παράδειγμα περιλαμβάνει από τη φύση του
επαναλήψεις και στάδια

τα UML διαγράμματα μπορούν να χρησιμοποιηθούν
για να αναπαραστήσουμε τις επαναλήψεις και τα
στάδια.
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
9
Επανάληψη και Σταδιακή Πρόοδος στο OO Παράδειγμα

Η έκδοση της Unified Process που θα
χρησιμοποιήσουμε σε αυτό το μάθημα είναι για


(συνέχ.)
Προϊόντα λογισμικού που είναι αρκετά μικρά για να
αναπτυχθούν από μια ομάδα 3-4 φοιτητών μέσα σε
ένα εξάμηνο
Παρόλα αυτά, θα συζητήσουμε και τις
τροποποιήσεις που θα πρέπει να γίνουν στην
Unified Process για να μπορεί να αναπτυχθεί ένα
μεγάλο Προϊόν Λογισμικού
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
10
Επανάληψη και Σταδιακή Πρόοδος στο OO Παράδειγμα

Δυο από τους βασικούς στόχους αυτού του
μαθήματος είναι



(συνέχ.)
Η πλήρης κατανόηση του πως αναπτύσσεται ένα
μικρής κλίμακας προϊόν λογισμικού
Κατανόηση των θεμάτων που πρέπει να λάβουμε
υπόψη μας όταν κατασκευάζονται μεγάλα προϊόντα
λογισμικού
Δεν είναι εύκολο να μάθουμε πλήρως τις
δυνατότητες της Unified Process στα πλαίσια
αυτού του μαθήματος
Χρειάζεται εκτενέστερη μελέτη και συνεχής πρακτική
 Η Unified Process έχει πάρα πολλές δυνατότητες
 Η μελέτη σε UML ενός μεγάλης κλίμακας προϊόντος
λογισμικού είναι πολύ πολύπλοκη
Τεχνολογία Υπολογισμού

Δρ. Μαρία Ι. Ανδρέου
11
Η δραστηριότητα των απαιτήσεων
The Requirements Workflow

Ο στόχος της δραστηριότητας των απαιτήσεων

Να καθορίσει τις ανάγκες του πελάτη
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
12
Περιγραφή της Δραστηριότητας των Απαιτήσεων

Αρχικά, καταλαβαίνουμε το πλαίσιο της εφαρμογής
(application domain) (ή πλαίσιο, domain για συντομία)


Αυτό είναι το επιχειρηματικό περιβάλλον στο οποίο θα
λειτουργεί το προϊόν λογισμικού που καλούμαστε να
αναπτύξουμε
Δεύτερο, κατασκευή του επιχειρηματικού μοντέλου
(business model)


χρήση UML για να περιγραφούν οι επιχειρηματικές
δραστηριότητες (business processes)
Αν σε κάποια στιγμή ο πελάτης δεν πιστεύει ότι το κόστος
αιτιολογείται, η ανάπτυξη τερματίζεται άμεσα
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
13
Περιγραφή της Δραστηριότητας των Απαιτήσεων

(συνέχ.)
Είναι ζωτικής σημασίας να καθορίσουμε τους περιορισμούς
που θέτει ο πελάτης





Προθεσμίες (Deadline)
 τα σημερινά προϊόντα λογισμικού έχουν συχνά κρίσιμη
(μεγάλη) σημασία
 Παράλληλη εκτέλεση
Φορητότητα (Portability)
Αξιοπιστία (Reliability)
Ταχύ, γρήγορο χρόνο απόκρισης (Rapid response time)
Κόστος
 Οι πελάτες σπάνια ενημερώνουν τους κατασκευαστές για το
πόσα χρήματα είναι διαθέσιμα
 Χρησιμοποιείται μια διαδικασία πλειοδοσίας (bidding
procedure)
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
14
Περιγραφή της Δραστηριότητας των Απαιτήσεων

(συνέχ.)
Ο στόχος αυτής της εξερεύνησης του θέματος είναι
για να καθορίσουμε


Τι χρειάζεται ο πελάτης
ΌΧΙ το τι θέλει ο πελάτης
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
15
Περιγραφή της Δραστηριότητας των Απαιτήσεων
The Analysis Workflow
 Ο στόχος της δραστηριότητας των απαιτήσεων είναι


Γιατί δεν το κάνουμε αυτό κατά τη δραστηριότητα των
απαιτήσεων ;


Να αναλύσει και να βελτιώσει τις απαιτήσεις
(requirements)
Τα παραδοτέα (artifacts) που αφορούν τις απαιτήσεις
πρέπει να είναι πλήρως κατανοητά και από το πελάτη
Τα παραδοτέα της δραστηριότητας των απαιτήσεων
πρέπει να είναι γραμμένα σε μια φυσική γλώσσα

Όλες οι φυσικές γλώσσες είναι ασαφής
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
16
Περιγραφή της Δραστηριότητας των Απαιτήσεων

Παράδειγμα για ένα σύστημα μιας βιομηχανικής
εταιρίας:


(συνέχ.)
“μια εγγραφή εξαρτήματος (part record) και μια
εγγραφή εργοστασίου (plant record) διαβάζονται από
μια βάση δεδομένων. Αν περιλαμβάνει το γράμμα A να
ακολουθείται άμεσα από το γράμμα Q, τότε υπολόγισε
το κόστος της μεταφοράς αυτού του εξαρτήματος σε
αυτό το εργοστάσιο”
Σε τι αναφέρεται;



στο part record;
στο plant record;
Ή στη βάση δεδομένων;
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
17
Περιγραφή της Δραστηριότητας των Απαιτήσεων

(συνέχ.)
Χρειάζονται δυο διαφορετικές δραστηριότητες


Τα παραδοτέα (artifacts) στης δραστηριότητας των
απαιτήσεων πρέπει να εκφράζονται στην γλώσσα του
πελάτη (client)
Τα παραδοτέα στη δραστηριότητα της ανάλυσης
πρέπει να είναι ακριβείς, και πλήρη έτσι ώστε οι
κατασκευαστές να έχουν όλες τις πληροφορίες που
χρειάζονται για να αναπτύξουν ένα προϊόν που να
ικανοποιεί τις απαιτήσεις του πελάτη.
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
18
Έγγραφο Προδιαγραφών
Specification Document

Κείμενο (έγγραφο, τεκμήριο) Προδιαγραφών
(Specification document ή “specifications”)



Συνιστά συμβόλαιο
Δεν πρέπει να περιλαμβάνει μη ακριβείς φράσεις
όπως “optimal,” ή “98 percent complete”
Το να έχουμε ολοκληρωμένες και σωστές τις
προδιαγραφές (specifications) είναι ουσιαστικής
σημασίας για


Τον έλεγχο, ότι το έργο ικανοποιεί τις απαιτήσεις του
πελάτη και είναι ολοκληρωμένο,και
Συντήρηση
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
19
Έγγραφο Προδιαγραφών

(συνέχ.)
Το έγγραφο προδιαγραφών ΔΕΝ πρέπει να
περιλαμβάνει



Αντιφάσεις (Contradictions)
Παραλείψεις (Omissions)
Ελλείψεις (Incompleteness)
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
20
Σχέδιο Διαχείρισης Έργου Λογισμικού
Software Project Management Plan (SPMP)
 Όταν ο πελάτης υπογράψει τις προδιαγραφές,
αρχίζει η κατάστρωση ενός λεπτομερούς σχεδίου
με τα χρονοδιαγράμματα του έργου μαζί με μια
εκτίμηση κόστους
 Το software project management plan,
περιλαμβάνει






Εκτίμηση κόστους (Cost estimate)
Εκτίμηση Διάρκειας (Duration estimate)
Παραδοτέα (Deliverables)
Ορόσημα (Milestones)
Προϋπολογισμός (Budget)
Το SPMP δεν θα μπορούσε να γίνει νωρίτερα
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
21
Η δραστηριότητα του Σχεδιασμού
The Design Workflow

Ο στόχος της δραστηριότητας του σχεδιασμού είναι να
εκλεπτύνει (μπει σε μεγαλύτερο βάθος, τελειοποιήσει) τη
δραστηριότητα της ανάλυσης μέχρι που το αποτέλεσμα να
είναι σε μορφή που να μπορεί να υλοποιηθεί από τους
προγραμματιστές.

Πολλές μη λειτουργικές απαιτήσεις (requirements) πρέπει να
οριστικοποιηθούν (finalized) τώρα. Αυτές συμπεριλαμβάνουν
 Επιλογή της γλώσσας προγραμματισμού (programming
language)
 Θέματα επαναχρησιμοποίησης (Reuse issues)
 Θέματα φορητότητας (Portability issues)
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
22
Κλασικός Σχεδιασμός
Classical Design

Ο κλασικός σχεδιασμός περιλάμβανε:

Το Αρχιτεκτονικό Σχέδιο (Architectural design)


Διαμελισμόν του έργου σε τμήματα (modules)
Λεπτομερές Σχεδιασμό (Detailed design)

Σχεδιασμό κάθε τμήματος (module):
Δομές δεδομένων (Data structures)
 Αλγόριθμοι (Algorithms)

Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
23
Αντικειμενοστρεφές Σχεδιασμός
Object-Oriented Design
 οι Κατηγορίες (Classes) επιλέγονται κατά τη
διάρκεια του της δραστηριότητας της ΟΟ
ανάλυσης, και


Σχεδιάζονται (ορίζονται τα μέλή τους, δηλ., πεδία και
μέθοδοι) κατά τη δραστηριότητα του σχεδιασμού
Συνεπώς


Το κλασικό αρχιτεκτονικό σχέδιο αντιστοιχεί σε ένα
μέρος του της δραστηριότητας της ΟΟ ανάλυσης
Ο κλασικός λεπτομερής σχεδιασμός στο ΟΟ
παράδειγμα αντιστοιχεί σε ένα μέρος της
δραστηριότητας του Σχεδιασμού
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
24
Δραστηριότητα Σχεδιασμού

(συνέχ.)
Διατήρηση των αποφάσεων του design


Για το πότε θα τελειώσει το έργο,και
Για να προστατέψουμε την ομάδα που θα κάνει
συντήρηση από το να ξαναανακαλύψει τον τροχό
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
25
Η Δραστηριότητα της Υλοποίησης
The Implementation Workflow

Ο στόχος της δραστηριότητας της υλοποίησης είναι
να υλοποιήσει το στοχεύομενο προϊόν λογισμικού
στην γλώσσα προγραμματισμού που έχει επιλεγεί


Ένα μεγάλο προϊόν λογισμικού χωρίζεται σε
υποσυστήματα (subsystems)
τα υποσυστήματα αποτελούνται από συστατικά μέρη ή
μέρη από κώδικα (code artifacts)
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
26
Η δραστηριότητα του Ελέγχου

Η δραστηριότητα του ελέγχου είναι εύθυνη



κάθε κατασκευαστή και συντηρητή, και
της ομάδας διαβεβαίωσης ποιότητας (quality
assurance group)
Η ονοματολογία όλων των κομματιών (artifacts),
έτσι ώστε να μπορούμε στην συνέχεια να
αναφερόμαστε με ακρίβεια σε αυτά (traceability of
artifacts) είναι μια σημαντική απαίτηση για επιτυχή
έλεγχο
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
27
Συστατικά Μέρη/Κομμάτια/Παραδοτέα των Απαιτήσεων
Requirements Artifacts

Κάθε στοιχείο στα παραδοτέα (ή άλλο συστατικό
μέρος) της φάσης της ανάλυσης (analysis artifacts)
πρέπει να παραπέμπει (must be traceable) σε ένα
στοιχείο των παραδοτέων της φάσης των
απαιτήσεων (requirements artifacts)

Παρομοίως, το ίδιο θα πρέπει να ισχύει για τα
παραδοτέα της φάσης του σχεδιασμού και της
υλοποίησης
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
28
Συστατικά Μέρη / Παραδοτέα της Ανάλυσης
Analysis Artifacts

Τα παραδοτέα (και όλα τα άλλα συστατικά μέρη)
της φάσης της ανάλυσης πρέπει να ελεγχθούν με
μεθόδους εξέτασης (review)


Αντιπρόσωποι από τις ομάδες των πελατών (client)
και των αναλυτών (analysis) πρέπει να
παρευρίσκονται
Το SPMP πρέπει να ελεγχθεί παρομοίως

Δίνεται ιδιαίτερη σημασία στις εκτιμήσεις για το κόστος
και τη διάρκεια
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
29
Παραδοτέα/ Συστατικά Μέση Του Σχεδιασμού
Μέρη Design Artifacts

Η Εξέταση (έλεγχος) του Σχεδιασμού είναι
ουσιαστική και απαραίτητη

Δεν συνηθίζεται να υπάρχει εκπρόσωπος του πελάτη
σε αυτή την εξέταση
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
30
Παραδοτέα/ Συστατικά Μέση την Υλοποίησης
Implementation Artifacts
 Κάθε κομμάτι ελέγχεται (tested) μόλις ολοκληρωθεί


Στο τέλος κάθε επανάληψης (iteration), τα
ολοκληρωμένα κομμάτια συνδέονται και ελέγχονται


Έλεγχος ενσωμάτωσης (Integration testing)
Όταν το προϊόν είναι σχεδόν ολοκληρωμένο
ελέγχεται σαν σύνολο


Έλεγχος μονάδας (Unit testing)
Έλεγχος προϊόντος (Product testing)
Όταν το ολοκληρωμένο προϊόν εγκατασταθεί στους
υπολογιστές του πελάτη, τότε το ελέγχει και ο
πελάτης

Έλεγχος αποδοχής (Acceptance testing)
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
31
Παραδοτέα/ Συστατικά Μέση της Υλοποίησης

Λογισμικά τύπου COTS αφήνονται να ελεγχθούν
από ενδεχόμενους πελάτες



(συνέχ.)
Πρώτη Φάση (Alpha release)
Δεύτερη Φάση (Beta release)
Υπάρχουν πλεονεκτήματα και μειονεκτήματα του
να υπάρχει alpha ή beta release
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
32
Συντήρηση μετά την παράδοση
Postdelivery Maintenance

Η συντήρηση ενός λογισμικού μετά την παράδοση
του είναι ένα σημαντικό μέρος (κομμάτι) του το
οποίο πρέπει να λαμβάνεται υπόψη και κατά την
ανάπτυξης (development) του λογισμικού


Ξοδεύονται περισσότερα χρήματα για συντήρηση
μετά την παράδοση παρά σε όλα τα άλλα κομμάτια
μαζί
Προβλήματα μπορεί να προκύψουν λόγο

Έλλειψης τεκμηρίωσης παντός είδους
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
33
Συντήρηση μετά την παράδοση

Χρειάζονται δυο είδη ελέγχου



(συνέχ.)
Έλεγχος των αλλαγών που έγιναν κατά την διάρκεια
του postdelivery maintenance
Έλεγχος οπισθοδρόμησης (Regression testing)
όλες οι προηγούμενες περιπτώσεις ελέγχου (και τα
αναμενόμενα αποτελέσματα τους) πρέπει να
καταγράφονται και να διατηρούνται
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
34
Απόσυρση
Retirement
 Το λογισμικό μπορεί να ΜΗΝ μπορεί να
συντηρηθεί πλέον επειδή





Έχει συμβεί μια δραστική αλλαγή
Το προϊόν πρέπει να υλοποιηθεί σε ένα εντελώς νέο
υλικό/ λειτουργικό σύστημα (hardware/operating
system)
Έλλειψη ή ανακρίβειες στην τεκμηρίωση
Αλλαγή υλικού—μπορεί να είναι πιο φθηνό να
ξαναγραφτεί το λογισμικό από την αρχή παρά να
τροποποιηθεί
Αυτές είναι κάποιες περιπτώσεις/λόγοι για
συντήρηση
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
35
Απόσυρση
(συνέχ.)

Πραγματική απόσυρση (retirement) δεν είναι
συχνό φαινόμενο

Συμβαίνει όταν ο οργανισμός του πελάτη δεν
χρειάζεται πια τις υπηρεσίες που του προσφέρει το
προϊόν
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
36
Οι φάσεις της Unified Process

Τα στάδια (increments) ταυτίζονται με τις
ακόλουθες φάσεις
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
37
Figure 3.1
Οι φάσεις της Unified Process

Τα τέσσερα στάδια ονομάζονται





(συνέχ.)
Φάση έναρξης (Inception phase)
Φάση επεξεργασίας (Elaboration phase)
Φάση κατασκευής (Construction phase)
Φάση μετάβασης (Transition phase)
Οι φάσεις (phases) της Unified Process είναι τα
στάδια (increments)
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
38
Οι φάσεις της Unified Process

Στην θεωρία, θα μπορούσε να υπάρχει οποιοσδήποτε
αριθμός από στάδια (increments)


Στην πράξη, η ανάπτυξη φαίνεται να συνίσταται από τέσσερα
βασικά στάδια
Κάθε βήμα που εκτελείται στην Unified Process εμπίπτει σε



(συνέχ.)
Μια από τις πέντε βασικές δραστηριότητες (workflows) καθώς
επίσης και
Σε μια από τις τέσσερις φάσεις (phases)
Γιατί πρέπει να λάβουμε υπόψη μας κάθε βήμα δυο φορές;
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
39
Οι φάσεις της Unified Process

Δραστηριότητα (Workflow)


(συνέχ.)
Τεχνικό περιεχόμενο ενός βήματος
Φάση (Phase)

Επαγγελματικό περιεχόμενο κάθε βήματος
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
40
Φάση Έναρξης
The Inception Phase

Ο στόχος της φάσης της έναρξης (inception phase)
είναι να καθορίσει κατά πόσο το προτεινόμενο
προϊόν λογισμικού είναι οικονομικά
πραγματοποιήσιμο
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
41
Φάση Έναρξης
(συνέχ.)

1. κερδίζουμε την κατανόηση της περιοχής

2. κατασκευή του business model

3. οριοθέτηση του πλαισίου του προτεινόμενου
έργου


Εστιάζομε στο μέρος του business model που
καλύπτεται από το προτεινόμενο προϊόν λογισμικού
4. Αρχίζει την initial business case
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
42
Φάση Έναρξης : The Initial Business Case

Χρειάζεται να απαντηθούν ανάμεσα σε άλλες οι ακόλουθες
ερωτήσεις






Είναι το προτεινόμενο software product επικερδές;
Πόσο καιρό θα πάρει για να αρχίσουμε να κερδίζουμε από αυτή την
επένδυση (απόσβεση της επένδυσης);
Διαφορετικά, ποιο θα είναι το κόστος αν η εταιρία αποφασίσει να μην
αναπτύξει το προτεινόμενο προϊόν λογισμικού;
Αν αυτό το προϊόν λογισμικού είναι για να πωλείται στην αγορά, έχει
γίνει η αναγκαία μελέτη για την εκμετάλλευση της αγοράς;
Μπορεί το προτεινόμενο προϊόν λογισμικού να παραδοθεί στην ώρα
του;
Αν το προϊόν λογισμικού θα αναπτυχθεί για να υποστηρίξει τις
δραστηριότητες της εταιρίας του πελάτη, ποιες θα είναι οι επιπτώσεις
στην περίπτωση του το προτεινόμενο προϊόν λογισμικού παραδοθεί με
καθυστέρηση;
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
43
Φάση Έναρξης : The Initial Business Case
(συνέχ.)
 Ποια ρίσκα εμπλέκονται στην ανάπτυξη του ενός
προϊόντος λογισμικού, και
 Πως μπορούν αυτά τα ρίσκα να αμβλυνθούν;


Έχει η ομάδα που θα αναπτύξει το προτεινόμενο
προϊόν λογισμικού την αναγκαία πείρα;
Χρειάζεται νέο υλικό για αυτό το λογισμικό;

Αν ναι, υπάρχει ρίσκο να μην παραδοθεί (το υλικό) στην
ώρα του;


Αν ναι, υπάρχει τρόπος να αμβλύνουμε αυτό το ρίσκο, ίσως
παραγγέλλοντας back-up hardware από άλλο πελάτη;
Χρειάζονται κατάλληλα εργαλεία για την ανάπτυξη του
εν λόγο λογισμικού (software tools);

Αν ναι είναι διαθέσιμα; Έχουν τις απαραίτητες
λειτουργικότητες;
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
44
Φάση Έναρξης : The Initial Business Case

(συνέχ.)
Χρειάζονται απαντήσεις σε αυτές τις ερωτήσεις
μέχρι το τέλος της φάσης έναρξης, έτσι ώστε το
initial business case να μπορεί να δημιουργηθεί
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
45
Φάση Έναρξης : Ρίσκα (Risks)

Υπάρχουν τρεις κύριες κατηγορίες ρίσκων

Τεχνικά ρίσκα (Technical risks)


Ρίσκο να μην καταλάβουμε σωστά τις απαιτήσεις
(requirements)


Δες την προηγούμενη διαφάνεια
Αμβλύνεται με το να εκτελέσουμε σωστά τη
δραστηριότητα των απαιτήσεων
Ρίσκο να μην κάνουμε την αρχιτεκτονική σωστά

Η αρχιτεκτονική μπορεί να μην είναι ικανοποιητικά
εύρωστη
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
46
Φάση Έναρξης : Ρίσκα (Risks)

Για να αμβλύνουμε και τις τρεις κατηγορίες ρίσκων


(συνέχ.)
Τα ρίσκα πρέπει να ταξινομηθούν έτσι ώστε τα πιο
κρίσιμα να αμβλυνθούν πρώτα
Αυτά ολοκληρώνουν τα βήματα της φάσης έναρξης
που εμπίπτουν κάτω από τη δραστηριότητα των
απαιτήσεων
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
47
Φάση Έναρξης : δραστηριότητες Ανάλυσης και Σχεδιασμού

Ένα μικρό μέρος από της δραστηριότητας της
ανάλυσης μπορεί να εκτελεστεί κατά την διάρκεια
της φάσης έναρξης


Εκμαίευση των πληροφοριών που χρειάζονται για τον
σχεδιασμό της αρχιτεκτονικής
Συνεπώς, ένα μικρό μέρος και από τη
δραστηριότητα του σχεδιασμού μπορεί να
εκτελεστεί, επίσης από αυτή τη φάση
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
48
Φάση Έναρξης : Δραστηριότητα Υλοποίησης

Συνήθως δεν παράγεται κώδικας κατά την φάση
έναρξης

Όμως, ένα πρωτότυπο που δείχνει το θέμα
(proof-of-concept prototype) μερικές φορές
κατασκευάζεται για να ελεγχθεί η δυνατότητα
επίτευξης (feasibility) του, κατασκευάζοντας ένα
τμήμα από το στοχευόμενου προϊόντος λογισμικού
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
49
Φάση Έναρξης : Δραστηριότητα Ελέγχου

Η δραστηριότητα ελέγχου αρχίζει σχεδόν από την
αρχή της φάσης έναρξης

Ο στόχος του είναι να εξασφαλίσει ότι οι απαιτήσεις
έχουν επακριβώς καθοριστεί
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
50
Φάση Έναρξης : καθορισμός Πλάνου (Planning)

Δεν υπάρχουν επαρκείς πληροφορίες στην αρχή
της φάσης έναρξης για να καθοριστεί ολόκληρο το
σχέδιο της ανάπτυξης του λογισμικού


Το μόνο σχέδιο που γίνεται στην αρχή του έργου είναι
ο σχεδιασμός της φάσης έναρξης
Για τον ίδιο λόγο, ο μόνος σχεδιασμός που μπορεί
να γίνει στο τέλος της φάσης έναρξης είναι να
σχεδιαστεί απλώς η επόμενη φάση, δηλ. η φάση
της επεξεργασίας (the elaboration phase)
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
51
Φάση Έναρξης : Τεκμηρίωση (Documentation)

Τα παραδοτέα της φάσης έναρξης περιλαμβάνουν:









Την αρχική έκδοση του μοντέλου του πεδίου (domain
model)
Την αρχική έκδοση του business model
Την αρχική έκδοση των κομματιών των απαιτήσεων
(requirements artifacts)
Μια προκαταρτική έκδοση των κομματιών για την
ανάλυση (analysis artifacts)
Μια προκαταρτική έκδοση της αρχιτεκτονικής
Την αρχική λίστα των ρίσκων
Την αρχική διάταξη των περιπτώσεων χρήσης (use
cases) (κεφ. 10)
Τα σχέδιο για την φάση της επεξεργασίας
Την αρχική έκδοση της business case
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
52
Φάση Έναρξης : The Initial Business Case


Το να πάρουμε την αρχική έκδοση της business case
είναι ο γενικός στόχος της φάσης έναρξης
Η αρχική έκδοση περιλαμβάνει



Μια περιγραφή των δυνατοτήτων που θα μπορεί να
παρέχει το προτεινόμενο προϊόν λογισμικού
Οικονομικές λεπτομέρειες
Αν το προτεινόμενο προϊόν λογισμικού είναι για να δοθεί
προς πώληση, η business case θα περιλαμβάνει επίσης


Φορολογικές προβλέψεις, εκτιμήσεις της αγοράς, εκτιμήσεις
αρχικού κόστους
Αν το θα χρησιμοποιείται in-house, η business case θα
περιλαμβάνει

Την αρχική ανάλυση κόστους-οφέλους (cost–benefit analysis)
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
53
Φάση Επεξεργασίας
Elaboration Phase
 Ο στόχος της φάσης της επεξεργασίας (elaboration
phase) είναι να εκλεπτύνει (αναλύσει σε
μεγαλύτερο βάθος) τις αρχικές απαιτήσεις





Τελειοποίηση της αρχιτεκτονικής
Επιτήρηση των ρίσκων και καθορισμός
προτεραιοτήτων μεταξύ τους
Τελειοποίηση της business case
Παραγωγή του software project management plan
Οι κύριες δραστηριότητες της φάσης της
επεξεργασίας είναι η εκλέπτυνση/τελειοποίηση (ή
επεξεργασίας) της προηγούμενης φάσης
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
54
Οι Εργασίες της Φάσης της Επεξεργασίας
The Tasks of the Elaboration Phase

Οι εργασίες (tasks) της φάσης της επεξεργασίας
αντιστοιχούν σε:



Ολοκλήρωση της δραστηριότητας των απαιτήσεων
Εικονική εκτέλεση ολόκληρης της δραστηριότητας της
ανάλυσης
Έναρξη του σχεδιασμού της αρχιτεκτονικής ( the
design of the architecture)
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
55
Φάση Επεξεργασίας : Τεκμηρίωση

Τα παραδοτέα της φάσης της επεξεργασίας
περιλαμβάνουν:








Το ολοκληρωμένο μοντέλο του πεδίου (domain model)
Το ολοκληρωμένο business model
Ολοκληρωμένα τα κομμάτια των απαιτήσεων
(requirements artifacts)
Ολοκληρωμένα τα κομμάτια της ανάλυσης (analysis
artifacts)
Μια ενημερωμένη έκδοση της αρχιτεκτονικής
Μια ενημερωμένη λίστα των ρίσκων
το project management plan (για το υπόλοιπο του
project)
Ολοκληρωμένη την business case
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
56
Φάση Κατασκευής
Construction Phase

Ο στόχος της φάσης της κατασκευής (construction
phase) είναι να παράξει την πρώτη έκδοση
λειτουργικότητας-ποιότητας (operational-quality)
του προϊόντος λογισμικού

Αυτό μερικές φορές ονομάζεται beta release
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
57
Οι Εργασίες της Φάσης Κατασκευής
The Tasks of the Construction Phase

Η έμφαση σε αυτή τη φάση είναι στα ακόλουθα:


Κωδικοποίηση (Implementation), και
Έλεγχο (Testing)



Μεμονωμένος έλεγχος των τμημάτων (Unit testing)
Έλεγχος Ενσωμάτωσης των υποσυστημάτων ή
διαφόρων τμημάτων
Έλεγχος ολόκληρου του συστήματος (Product testing)
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
58
Φάσης Κατασκευής: Τεκμηρίωση

Τα παραδοτέα της φάσης της κατασκευής
περιλαμβάνουν:






Το αρχικό εγχειρίδιο για τον χρήστη (user manual) και
άλλα κατάλληλα εγχειρίδια
Όλα τα κομμάτια (beta release versions)
Ολοκληρωμένη αρχιτεκτονική
Ενημερωμένη λίστα ρίσκων
το project management plan (για το υπόλοιπο project)
Αν χρειάζεται, ενημερωμένη η business case
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
59
Φάση Μετάβασης
The Transition Phase
 Ο στόχος της φάσης της μετάβασης (transition
phase) είναι η εξασφάλιση ότι οι απαιτήσεις
(requirements) του πελάτη έχουν ικανοποιηθεί




Λάθη (Faults) στο προϊόν λογισμικού διορθώνονται
Ολοκλήρωση όλων των εγχειριδίων
Γίνεται προσπάθεια για εύρεση ρίσκων τα οποία
μπορεί να μην έχουν εντοπιστεί νωρίτερα
Αυτή η φάση καθοδηγείται από αναδράσεις
(feedback) από τις πλευρές όπου έχει
εγκατασταθεί το beta release
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
60
Φάση Μετάβασης : Τεκμηρίωση

Τα παραδοτέα της φάσης της μετάβασης
περιλαμβάνουν:


Τελικές εκδόσεις όλων των κομματιών (artifacts)
Ολοκληρωμένα τα εγχειρίδια
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
61
One- and Two-Dimensional Life-Cycle Models
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
Figure 62
3.2
Γιατί two-Dimensional Model;

Ένας παραδοσιακός κύκλος ζωής είναι ένα
μοντέλο μιας-διάστασης (one-dimensional model)

Αναπαριστάται από ένα απλό άξονα στην
προηγούμενη διαφάνεια


Η Unified Process είναι δυο-διαστάσεων μοντέλο
(two-dimensional model)


Παράδειγμα: το μοντέλο του Καταρράκτη (Waterfall
model)
Αναπαριστάται από δύο άξονες στην προηγούμενη
διαφάνεια
Η εικόνα στο two-dimensional δείχνει


Τις δραστηριότητες (τεχνικό περιεχόμενο), και
Τις φάσεις (επιχειρηματικό περιεχόμενο)
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
63
Γιατί το Two-Dimensional Model; (συνέχ.)

Το μοντέλο του καταρράκτη
(The waterfall model)

Μιας-διάστασης
(One-dimensional)
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
Figure 2.3 (again)
64
Γιατί το Two-Dimensional Model; (συνέχ.)


Μοντέλο Δέντρου Εξέλιξης (Evolution tree model)
Δυο-διαστάσεων (Two-dimensional)
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
Figure 2.2 (again)65
Γιατί το Two-Dimensional Model; (συνέχ.)

Είναι αναγκαία η επιπλέον πολυπλοκότητα του
μοντέλου δυο-διαστάσεων (two-dimensional
model);

Σε ένα ιδεατό κόσμο, κάθε δραστηριότητα θα
ολοκληρωνόταν πριν αρχίσει η επόμενη
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
66
Γιατί το Two-Dimensional Model; (συνέχ.)

Στην πραγματικότητα, το έργο της ανάπτυξης είναι
πολύ μεγάλο για κάτι τέτοιο

Σαν συνέπεια του Miller’s Law


Η εργασία της ανάπτυξης (development task) πρέπει
να διαιρεθεί σε στάδια (increments, phases)
Σε κάθε στάδιο, εκτελούνται επαναλήψεις (iterations)
μέχρι να ολοκληρωθεί η εργασία
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
67
Γιατί το Two-Dimensional Model;

Στην αρχή της διαδικασίας, δεν υπάρχει αρκετή
πληροφορία για το προϊόν λογισμικού για να
διεξαχθεί πλήρως η δραστηριότητα των
απαιτήσεων σε ένα στάδιο



(συνέχ.)
Παρομοίως και για τις άλλες δραστηριότητες
Ένα προϊόν λογισμικού πρέπει να διαιρεθεί σε
υποσυστήματα (subsystems)
Ακόμα και τα υποσυστήματα μερικές φορές είναι
πολύ μεγάλα

Τα Τμήματα (Modules) μπορεί να είναι τα μόνα μέρη
που μπορούν να διαχειριστούν μέχρι που να δοθεί μια
πιο πλήρης κατανόηση όλων των μερών (parts) του
προϊόντος σαν σύνολο
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
68
Γιατί το Two-Dimensional Model; (συνέχ.)

Η Unified Process διαχειρίζεται τις αναπόφευκτες
αλλαγές/προβλήματα με ένα ικανοποιητικό (καλό)
τρόπο



Το πρόβλημα της αλλαγής στόχου (moving target probl.)
Τα αναπόφευκτα λάθη
Η Unified Process είναι η καλύτερη λύση που
βρέθηκε μέχρι σήμερα για το χειρισμό μεγάλων
προβλημάτων σαν ένα σύνολο από μικρότερα,
ανεξάρτητα υποπροβλήματα


Παρέχει το πλαίσιο εργασίας (framework) για επανάληψη
και σταδιακή πρόοδο (iteration and incrementation)
Στο μέλλον, είναι αναπόφευκτό ότι θα αντικατασταθεί από
καλύτερες μεθοδολογίες
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
69
Βελτιώνοντας την Διαδικασία Ανάπτυξης Λογισμικού
Software Process
 Παράδειγμα:

U.S. Department of Defense initiative

Software Engineering Institute (SEI)

Το θεμελιώδες πρόβλημα με το λογισμικό

η διαδικασία ανάπτυξης λογισμικού (software
process) διαχειρίζεται ΚΑΚΑ
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
70
Βελτιώνοντας την Διαδικασία Ανάπτυξης Λογισμικού (συνέχ.)

Πρωτοβουλίες για βελτίωση της Διαδικασία
Ανάπτυξης Λογισμικού



Μοντέλο Ωριμότητας των Ικανοτήτων (Capability
maturity model CMM)
ISO 9000-series
ISO/IEC 15504
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
71
Ικανότητες Ώριμων Μοντέλων
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)
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
72
SW–CMM

Μια στρατηγική για βελτίωση της Διαδικασία Ανάπτυξης
Λογισμικού

Άρχισε το 1986 από το SEI

Βασικές ιδέες:

Βελτίωση της Διαδικασία Ανάπτυξης Λογισμικού οδηγεί σε
 Βελτιωμένης ποιότητας λογισμικό
 Παράδοση εντός των προθεσμιών και του προϋπολογισμού
 Βελτιωμένη διαχείριση οδηγεί σε

Τεχνολογία Υπολογισμού
Βελτιωμένες τεχνικές
Δρ. Μαρία Ι. Ανδρέου
73
SW–CMM

Ορίζονται Πέντε επίπεδα Ωριμότητας (maturity)


(συνέχ.)
Ωριμότητα (Maturity) είναι ένα μέτρο (τρόπος
μέτρησης) των ικανοτήτων της διαδικασίας που
ακολουθείται
Ένας οργανισμός (εταιρία) ανάπτυξης λογισμικού
βελτιώνεται βήμα βήμα από το ένα επίπεδο στο
άλλο
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
74
Level 1. αρχικό επίπεδο (Initial Level)

Ad hoc προσέγγιση



Ολόκληρη η διαδικασία είναι άστατη
(απρόβλεπτη)
Η διαχείριση συνίσταται από κρίσεις σε κρίσεις
Πολλοί οργανισμοί σε ολόκληρο τον κόσμο
είναι στο level 1
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
75
Level 2. Επαναλαμβανόμενο επίπεδο (Repeatable Level)

Βασική διαχείριση λογισμικού




Αποφάσεις για τη διαχείριση πρέπει να λαμβάνονται
με βάση προηγούμενη εμπειρία από παρόμοια
προϊόντα
Γίνονται μετρήσεις
Αυτές μπορεί να χρησιμοποιηθούν για να γίνουν
προβλέψεις κόστους και διάρκειας επόμενων έργων
Όταν εντοπιστούν προβλήματα, λαμβάνονται άμεσα
διορθωτικές ενέργειες
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
76
Level 3. Καθορισμένο επίπεδο (Defined Level)

Η διαδικασία ανάπτυξης λογισμικού είναι πλήρως
τεκμηριωμένη




Πτυχές διοίκησης και τεχνικές πτυχές είναι ξεκάθαρα
ορισμένες
Γίνεται συνεχής προσπάθεια για βελτίωση της
ποιότητας (quality) και της παραγωγικότητας
(productivity)
Γίνονται εξετάσεις για βελτίωση της ποιότητας του
λογισμικού
Χρήση CASE tools
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
77
Level 4. Ελεγχόμενο Επίπεδο (Managed Level)

Στόχοι ποιότητας και παραγωγικότητας θέτονται για
κάθε έργο


Ποιότητα και παραγωγικότητα παρακολουθούνται
συνεχώς
Θέτονται σε εφαρμογή στατιστικοί ποιοτικοί έλεγχοι
(Statistical quality controls)
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
78
Level 5. Επίπεδο βελτιστοποίησης (Optimizing Level)

Συνεχής βελτίωση της διαδικασίας


Στατιστική μέτρηση της ποιότητας και έλεγχοι στην
διαδικασία
Αναδράσεις και γνώσεις μεταφέρονται από το ένα
έργο στο άλλο
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
79
Περίληψη
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
Figure 3.3
80
Εμπειρία από το SW–CMM

Παίρνει:



3 με 5 χρόνια για να πάμε από το level 1 στο level 2
1.5 με 3 χρόνια για να πάμε από το level 2 στο level 3
SEI ερωτηματολόγια προβάλλουν ανεπάρκειες,
εισηγούνται τρόπους βελτίωσης της διαδικασίας
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
81
Key Process Areas

Υπάρχουν περιοχές κλειδιά στην διαδικασία
(key process areas (KPAs)) σε κάθε επίπεδο
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
82
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
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
83
Στόχοι

Αρχικός στόχος (Original goal):


The U.S. Air Force ορίζει σαφώς και κατηγορηματικώς ότι
κάθε κατασκευαστής Air Force πρέπει να φτάσει στο SW–
CMM level 3 μέχρι το 1998


Υποστηρίξει συμβολαίων (Defense contracts) πρέπει να
χορηγείται μόνο από ικανές εταιρίες
Παρόμοια έπραξε και η DoD στη συνέχεια
The CMM has now gone far beyond the limited goal of
improving DoD software
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
84
Άλλες πρωτοβουλίες για βελτίωση της Software Process

Άλλες πρωτοβουλίες για βελτίωση της software
process (SPI) περιλαμβάνουν:


ISO 9000-series
ISO/IEC 15504
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
85
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
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
86
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
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
87
Κόστος και Ωφέλεια από την βελτίωση της 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
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
88
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
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
89
Results of 34 Motorola Projects

MEASL – Million equivalent assembler source lines

Motorola does not reveal productivity data


Figure 3.4
Productivity is measured relative to that of a selected level-2
project
No fault or productivity data available for level-1 projects (by
definition)
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
90
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
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου

91