Απαιτήσεις REQUIREMENTS Δρ. Μαρία Ι. Ανδρέου. Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 2 Περιεχόμενα Κατανόηση των αναγκών του πελάτη Η δραστηριότητα.

Παρουσίαση με θέμα: "Απαιτήσεις REQUIREMENTS Δρ. Μαρία Ι. Ανδρέου. Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 2 Περιεχόμενα Κατανόηση των αναγκών του πελάτη Η δραστηριότητα."— Μεταγράφημα παρουσίασης:

1 Απαιτήσεις REQUIREMENTS Δρ. Μαρία Ι. Ανδρέου

2 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 2 Περιεχόμενα Κατανόηση των αναγκών του πελάτη Η δραστηριότητα των απαιτήσεων Κατανόηση του πλαισίου (domain) Το επιχειρησιακό μοντέλο (business model) Αρχικές απαιτήσεις (Initial requirements) Αρχική κατανόηση πλαισίου στο: Osbert Oglesby case study Το αρχικό επιχειρησιακό μοντέλο του: Osbert Oglesby case study Αρχικές απαιτήσεις: στο Osbert Oglesby case study

3 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 3 Περιεχόμενο (συνέχ.) Συνεχίζοντας τη δραστηριότητα των απαιτήσεων: στο Osbert Oglesby case study Δραστηριότητα Ελέγχου: στο Osbert Oglesby case study Η ΚΑΛΣΙΚΗ φάση Απαιτήσεων Γρήγορο Πρωτότυπο (Rapid prototyping) Ανθρώπινοι παράγοντες (Human factors) Επαναχρησιμοποίηση του rapid prototype Εργαλεία στη δραστηριότητα των απαιτήσεων (CASE tools για το requirements workflow) Μετρικές για τη δραστηριότητα των απαιτήσεων Προκλήσεις στη δραστηριότητα των απαιτήσεων

4 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 4 Ο στόχος της Δραστηριότητας των Απαιτήσεων Requirements Workflow Κύριος στόχος της πρώτης δραστηριότητας στο κύκλο ζωής ενός λογισμικού είναι να απαιτηθεί η ερώτηση  Τι πρέπει να είναι ικανό να κάνει το προϊόν; (What must the product be able to do?)

5 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 5 Καθορίζουμε ΤΙ χρειάζεται ο πελάτης (Determining What the Client Needs) Misconception  Πρέπει να καθορίσουμε ΤΙ θέλει ο πελάτης “I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant!” Πρέπει να καθορίσουμε ΤΙ χρειάζεται ο πελάτης

6 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 6 Καθορίζουμε ΤΙ χρειάζεται ο πελάτης (συνεχ.) Είναι δύσκολο για ένα αναλυτή συστημάτων (systems analyst) να φανατιστεί (to visualize) ένα προϊόν λογισμικού και της λειτουργικότητας τους  Το πρόβλημα είναι πολύ χειρότερο για τον πελάτη Χρειάζεται ένας έμπειρος αναλυτή συστημάτων για να μπορέσει να εκμαιεύσει κατάλληλες πληροφορίες από τον πελάτη. Ο πελάτης είναι η μόνη πυγή για αυτή τη πληροφόρηση

7 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 7 Καθορίζουμε ΤΙ χρειάζεται ο πελάτης (συνεχ.) Η λύση : 1. Παίρνουμε τις πρώτες πληροφορίες από το πελάτη 2. Χρησιμοποιούμε τις αρχικές πληροφορίες σαν είσοδο στην Unified Process 3. Ακολουθούμε τα βήματα της Unified Process για να καθορίσουμε τις ΠΡΑΓΜΑΤΙΚΕΣ ανάγκες του πελάτη

8 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 8 Η Δραστηριότητα των Απαιτήσεων Πρώτο, κατανοούμε το πλαίσιο της εφαρμογής application domain (ή πλαίσιο για συντομία) την οποία καλούμαστε να αναπτύξουμε  Δηλ. το συγκεκριμένο περιβάλλον στο οποίο το στοχευόμενο προϊόν θα λειτουργήσει Δεύτερο, χτίζουμε το επιχειρησιακό μοντέλο (business model)  Είναι το μοντέλο (ο τρόπος) με τον οποίο λειτουργεί η επιχείρηση του πελάτη Τρίτο, χρησιμοποιούμε το επιχειρησιακό μοντέλο για να κατανοήσουμε και να καθορίσουμε τις ανάγκες και τις απαιτήσεις του πελάτη Επανάληψη και σταδιακή εκλέπτυνση των πιο πάνω βημάτων

9 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 9 Ορισμοί Ανακάλυψη των Απαιτήσεων του πελάτη  Εκμαίευση των Απαιτήσεων Μέθοδοι: συνεντεύξεις και δημοσκοπήσεις Εκλέπτυνση και επέκταση των αρχικών απαιτήσεων  Ανάλυση Απαιτήσεων

10 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 10 Κατανόηση του Πεδίου Κάθε μέλος της ομάδας ανάπτυξης ενός συγκεκριμένου λογισμικού πρέπει να είναι γνώστης σε μεγάλο βαθμό του πεδίου της εφαρμογής  Είναι ουσιαστικής (καθοριστικής) σημασίας η διόρθωση της ονοματολογίας (terminology) που χρησιμοποιείται Δημιουργία Γλωσσάριου (glossary)  Μια λίστα από τεχνικούς όρους (technical words) που χρησιμοποιούνται στο πεδίο εφαρμογής του ζητούμενου λογισμικού και η σημασία τους

11 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 11 Επιχειρησιακό Μοντέλο Business Model Το επιχειρησιακό μοντέλο (business model) είναι μια περιγραφή της επιχειρησιακής διαδικασίας (business processes) ενός οργανισμού Το επιχειρησιακό μοντέλο δείχνει το πως κατανοήσαμε την επιχείρησης του πελάτη σας σύνολο  Αυτή η γνώση είναι ουσιαστική έτσι ώστε να είναι δυνατό να συμβουλεύσουμε το πελάτη μας σε σχέση με θέματα μηχανογράφησης της επιχείρησης του Ο αναλυτής του συστήματος πρέπει να κατανοεί σε βάθος και με κάθε λεπτομέρεια όλες τις επιμέρους επιχειρηματικές λειτουργίες  Χρησιμοποιεί διάφορες τεχνικές για να το επιτύχει αυτό, κυρίως συνεντεύξεις

12 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 12 Συνεντεύξεις Η ομάδα η οποία έχει αναλάβει να εκμαιεύσει τις απαιτήσεις συναντάται με το πελάτη και με τελικούς χρήστες του συστήματος για να εξάξει όλες τις σχετικές πληροφορίες

13 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 13 Συνεντεύξεις (συνέχ.) Υπάρχουν δυο ειδών ερωτήσεις  Κλειστού τύπου ερωτήσεις (Close-ended questions) Απαιτούν συγκεκριμένη απάντηση  Ανοικτού τύπου ερωτήσεις (Open-ended questions) Ερωτούνται για να ενθαρρύνουν το άτομο το οποίο δίνει τη συνέντευξη να μιλήσεις ελεύθερα και να εκφράσει όλα όσα θέλει Υπάρχουν δυο τύποι Συνεντεύξεων  Δομημένη Συνέντευξη (structured interview) Ερωτούνται συγκεκριμένες και προσχεδιασμένες ερωτήσεις  Συχνά κλειστού τύπου ερωτήσεις  Αδόμητη Συνέντευξη (unstructured interview) Οι ερωτήσεις θέτονται σε σχέση με τις απαντήσεις που δίνει ο ερωτώμενος  Συχνά είναι ανοικτού τύπου ερωτήσεις

14 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 14 Συνεντεύξεις (συνέχ.) Η διαδικασία ετοιμασία και λήψεις μια συνέντευξης Δεν είναι εύκολη  Μια εντελώς αδόμητη συνέντευξη δεν θα εκμαιεύσει πολλές χρήσιμες και σχετικές με το έργο πληροφορίες  Το άτομο που παίρνει τη συνέντευξη (και το άτομο που δίνει τη συνέντευξη) πρέπει να είναι πλήρως γνώστης του πεδίου της εφαρμογής και να είναι σε εγρήγορση όλη την ώρα Μετά την συνέντευξη  το άτομο που πήρε τη συνέντευξη, πρέπει να ετοιμάσει μια γραπτή αναφορά (written report)  Συνίσταται να δώσει την αναφορά και στο άτομο που έδωσε την συνέντευξη (για λόγους ελέγχου)

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

16 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 16 Άλλες Τεχνικές (συνέχ.) Η Απευθείας παρακολούθηση των εργαζομένων κατά την διάρκεια εκτέλεσης των καθηκόντων τους είναι πολλές φορές χρήσιμη στο να κατανοήσουμε πλήρως την επιχειρηματική διαδικασία  Οι βιντεοκάμερες (Videotape cameras) είναι η μοντέρνα (σύγχρονη) μορφή της τεχνικής παρακολούθησης Όμως, παίρνει πολύ χρόνο να αναλυθούν οι ταινίες (cd) Οι εργαζόμενοι μπορεί να θεωρούν ότι οι κάμερες παραβιάζουν με απαράδεκτο τρόπο τα ατομικά τους δικαιώματα

17 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 17 Περιπτώσεις Χρήσης (ενός λογισμικού) Use Cases Μια περίπτωση χρήσης (use case) μοντελοποιεί μια αλληλεπίδραση ανάμεσα στο προϊόν λογισμικού και στους χρήστες του (που είναι οι ηθοποιοί -actors) Παράδειγμα:

18 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 18 Περιπτώσεις Χρήσης (ενός λογισμικού)(συνέχ.) Ένας ηθοποιός (actor) είναι ένα μέλος του κόσμου έξω από το (ζητούμενο) προϊόν λογισμικού Συχνά είναι εύκολο να αναγνωρίσουμε τους ηθοποιούς  Ένας ηθοποιός είναι συχνά ένας χρήστης του λογισμικού Γενικά, ένας ηθοποιός παίζει κάποιο ρόλο σε σχέση με το λογισμικό. Ο ρόλος αυτός μπορεί να αφορά  Ένα χρήστη, ή  Κάποιο που κάνει αρχικοποίηση ή  Κάποιο που έχει ένα σημαντικό (καθοριστικό) ρόλο σε κάποια use case του λογισμικού

19 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 19 Περιπτώσεις Χρήσης (ενός λογισμικού)(συνέχ.) Ένας χρήστης του συστήματος μπορεί να παίξει περισσότερο από ένα ρόλους Παράδειγμα: Ένας πελάτης μιας τράπεζας μπορεί να είναι  A Borrower or  A Lender

20 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 20 Περιπτώσεις Χρήσης (ενός λογισμικού)(συνέχ.) Αντιστρόφως, ένας ηθοποιός μπορεί να συμμετέχει σε πολλές περιπτώσεις χρήσης του λογισμικού Παράδειγμα: ένας Borrower μπορεί να είναι ηθοποιός στις ακόλουθες use cases  The Borrow Money use case;  The Pay Interest on Loan use case; and  The Repay Loan Principal use case Επίσης, ο ηθοποιός Borrower μπορεί να αντιπροσωπεύει πολλές χιλιάδες πελατών μιας τράπεζας

21 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 21 Περιπτώσεις Χρήσης (ενός λογισμικού)(συνέχ.) Ο ηθοποιός σε ένα προϊόν λογισμικού ΔΕΝ χρειάζεται να είναι πάντα άνθρωπος παράδειγμα: ένα e-commerce information system πρέπει να αλληλεπιδρά με ένα credit card company information system  το credit card company information system είναι ένας ηθοποιός αν το βλέπουμε από την σκοπιά του e- commerce information system  Το e-commerce information system είναι ένας ηθοποιός αν το βλέπουμε από την σκοπιά του credit card company information system

22 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 22 Περιπτώσεις Χρήσης (ενός λογισμικού)(συνέχ.) Ένα ενδεχόμενο πρόβλημα όταν αναγνωρίζουμε τους ηθοποιούς είναι η:  Επικάλυψη ηθοποιών Παράδειγμα: προϊόν λογισμικού για νοσοκομεία  Μια περίπτωση χρήσης (use case) έχει σαν ηθοποιό μια νοσοκόμα (Nurse)  Μια άλλη use case έχει σαν ηθοποιό Ιατρικό προσωπικό (Medical Staff)  Είναι καλύτερα οι ηθοποιοί να ήταν οι εξής: Ηθοποιοί: Physician and Nurse

23 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 23 Περιπτώσεις Χρήσης (ενός λογισμικού)(συνέχ.) Εναλλακτικά:  Ο ηθοποιός θα ήταν το Medical Staff με δυο ιδιόκτητες : Physician and Nurse

24 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 24 Αρχικές Απαιτήσεις Initial Requirements Οι αρχικές απαιτήσεις βασίζονται στο αρχικό επιχειρησιακό μοντέλο Στη συνέχεια εκλεπτύνονται Οι απαιτήσεις είναι δυναμικές — αλλάζουν συχνά  Διατηρείτε μια λίστα από ενδεχόμενες απαιτήσεις, μαζί με τις περιπτώσεις χρήσης (use cases) που έχουν εγκριθεί από τον πελάτη

25 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 25 Αρχικές Απαιτήσεις(συνέχ.) Υπάρχουν δυο κατηγορίες απαιτήσεων Μια λειτουργική απαίτηση (functional requirement) καθορίζει μια ενέργεια που το προϊόν λογισμικού πρέπει να είναι ικανό να εκτελεί  Συχνά εκφράζεται σε σχέση με όρους που αφορούν είσοδο δεδομένων και έξοδο πληροφοριών από το σύστημα Μια Μη-λειτουργική απαίτηση (nonfunctional requirement) καθορίζει Ιδιότητες του λογισμικού, όπως  Χρόνος απόκρισης (Response times)  Αξιοπιστία (Reliability)

26 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 26 Αρχικές Απαιτήσεις(συνέχ.) Οι λειτουργικές απαιτήσεις χειρίζονται σας μέρος των δραστηριοτήτων απαιτήσεων και ανάλυσης (requirements and analysis workflows) Μερικές μη-λειτουργικές απαιτήσεις θα πρέπει να περιμένουν (για να διαχειριστούν) μέχρι τη δραστηριότητα του σχεδιασμού  Λεπτομερείς πληροφορίες για μερικές από αυτές Δεν είναι διαθέσιμες πριν το τέλος της δραστηριότητας της ανάλυσης

27 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 27 Αρχική Κατανόηση του Πεδίου : The Osbert Oglesby Case Study Ο Osbert Oglesby, είναι ένας έμπορος έργων τέχνης (Art Dealer), και χρειάζεται ένα προϊόν λογισμικού για να τον βοηθά στην αγορά και πώληση πινάκων. Αρχικά, θα πρέπει να αποκτήσουμε γνώσεις αναφορικά με το πεδίο της εφαρμογής. Στη συνέχεια μέσω συνεντεύξεων ο Osbert δίνει σχετικές πληροφορίες. Σε ένα γλωσσάρι καταγράφονται ανάμεσα σε άλλα ορισμοί και όροι που χρησιμοποιεί ο Osbert στην συνέντευξη.

28 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 28 Γλωσσάρι: The Osbert Oglesby Case Study

29 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 29 Τα αρχικό επιχειρησιακό μοντέλο: The Osbert Oglesby Case Study Ο Osbert θέλει ένα προϊόν λογισμικού, που να εκτελείται στο laptop του, και θα  Υπολογίζει την μέγιστη τιμή του ποσού που θα πρέπει να πληρώσει για την αγορά ενός πίνακα  Ανιχνεύει όσο το δυνατό πιο νωρίς νέες τάσεις στην αγορά τέχνης Για επίτευξη ικανοποίησης των απαιτήσεων του Osbert, το λογισμικό που θα αναπτυχθεί θα πρέπει να διατηρεί μια εγγραφή για κάθε αγορά και για μια για κάθε πώληση.

30 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 30 Τα αρχικό επιχειρησιακό μοντέλο: The Osbert Oglesby Case Study(συνέχ.) Μέχρι τώρα, ο Osbert δημιουργεί στο χέρι αναφορές σχετικά με τις ετήσιες πωλήσεις και αγορές του  Με μικρό πρόσθετο κόστος, το λογισμικό που θα αναπτυχθεί μπορεί να δημιουργεί και να τυπώνει αυτές τις δυο αναφορές όταν τις ζητήσει ο Osbert Είναι ΠΟΛΥ σημαντικό να κατανοήσετε και να καθορίσετε τις ΠΡΑΓΜΑΤΙΚΕΣ ανάγκες του πελάτη από την αρχή, και όχι μετά την παράδοση του προϊόντος λογισμικού

31 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 31 Τα αρχικό επιχειρησιακό μοντέλο: The Osbert Oglesby Case Study(συνεχ.) Ο Osbert έχει τρις επιχειρηματικές δραστηριότητες:  Αγοράζει πίνακες  Πουλά πίνακες  Παράγει (ετοιμάζει) αναφορές (reports)

32 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 32 Τα αρχικό επιχειρησιακό μοντέλο: The Osbert Oglesby Case Study(συνεχ.) Buy a Painting use case

33 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 33 Τα αρχικό επιχειρησιακό μοντέλο: The Osbert Oglesby Case Study(συνεχ.) Sell a Painting use case

34 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 34 Τα αρχικό επιχειρησιακό μοντέλο: The Osbert Oglesby Case Study(συνέχ.) Produce a Report use case

35 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 35 Τα αρχικό επιχειρησιακό μοντέλο: The Osbert Oglesby Case Study(συνεχ.) For conciseness, all three use cases are combined into a use-case diagram

36 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 36 Τα αρχικό επιχειρησιακό μοντέλο: The Osbert Oglesby Case Study(συνέχ.) Το μόνο άτομο που χρησιμοποιεί το τρέχον σύστημα (χειροποίητο) είναι ο Osbert  Ο Osbert είναι λοιπών ηθοποιός σε όλες τις περιπτώσεις χρήσης (use cases) Ο πελάτης πουλητής αρχικοποιεί την Buy a Painting περίπτωση χρήσης και ο πελάτης αγοραστής την Sell a Painting περίπτωση χρήσης Ο πελάτης παίζει κρίσιμο ρόλο και στις δυο περιπτώσεις χρήσης παρέχοντας δεδομένα που εισάγονται στο προϊόν λογισμικό από τον Osbert  Ο πελάτης είναι λοιπόν ηθοποιός και στις δυο αυτές use cases

37 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 37 Τα αρχικό επιχειρησιακό μοντέλο: The Osbert Oglesby Case Study(συνέχ.) Buy a Painting use case

38 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 38 Τα αρχικό επιχειρησιακό μοντέλο: The Osbert Oglesby Case Study(συνέχ.) Sell a Painting use case

39 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 39 Τα αρχικό επιχειρησιακό μοντέλο: The Osbert Oglesby Case Study(συνέχ.) Produce a Report use case Figure 10.10

40 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 40 Αρχικές Απαιτήσεις : The Osbert Oglesby Case Study Το αρχικό επιχειρησιακό μοντέλο (δηλ., οι τρις use cases) δείχνει πως κάνει ο Osbert τη δουλεία του μέχρι τώρα Στη συνέχεια πρέπει να παρθεί απόφαση για το ποιες από αυτές τις use cases είναι επίσης απαιτήσεις του προϊόντος λογισμικού που θα αναπτυχθεί  Είναι ξεκάθαρο ότι και οι τρις αυτές use cases είναι απαιτήσεις Το επόμενο βήμα είναι εκλέπτυνση των αρχικών απαιτήσεων  Οι περιγραφές των use cases πρέπει να επεκταθούν και να εκλεπτυνθούν

41 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 41 Αρχικές Απαιτήσεις : The Osbert Oglesby Case Study (συνέχ.) Buy a Painting use case

42 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 42 Αρχικές Απαιτήσεις : The Osbert Oglesby Case Study (συνέχ.) Sell a Painting use case

43 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 43 Αρχικές Απαιτήσεις : The Osbert Oglesby Case Study (συνέχ.) Produce a Report use case

44 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 44 Αρχικές Απαιτήσεις : The Osbert Oglesby Case Study (συνέχ.) Και οι τρις περιγραφές είναι ακόμα ασαφείς  Είναι συνέπεια της επαναλαμβανόμενης φύσης της Unified Process  Για παράδειγμα, οι λεπτομέρειες του αλγόριθμου υπολογισμού της μέγιστης τιμής αγοράς δεν μας ενδιαφέρουν στο παρόν στάδιο Βασική αρχή: Να καθυστερείτε να λαμβάνεται υπόψη σας λεπτομέρειες όσο περισσότερο μπορείτε  Αυτό θα ευκολύνει τη διαχείριση αλλαγών που θα προκύψουν στην επόμενη επανάληψη

45 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 45 Συνέχεια της Δραστηριότητας των Απαιτήσεων : The Osbert Oglesby Case Study Τώρα χρειάζονται περισσότερες λεπτομέρειες για κάθε use case Αρχικά μελετούμε τις use cases  Buy a Painting, και  Sell a Painting Για να εκλεπτύνουμε, καθορίζουμε ΠΟΙΑ χαρακτηριστικά πρέπει να εισαχθούν στο σύστημα (στο λογισμικό) όταν ένας πίνακας αγοράζεται ή πωλείται

46 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 46 Χαρακτηριστικά : The Osbert Oglesby Case Study Χαρακτηριστικά για αγορά πίνακα περιλαμβάνουν :  Τίτλο της δουλειάς, όνομα καλλιτέχνη, ημερομηνία δημιουργίας, κατηγοριοποίηση, μέσο, τιμή αγοράς, όνομα και διεύθυνση πουλητή (Title of work, name of artist, date of painting, classification, medium, purchase price, name and address of seller) Χαρακτηριστικά όταν ένας πίνακας πωλείται :  Ημερομηνία πώλησης, όνομα αγοραστή, διεύθυνση αγοραστή, πραγματική τιμή πώλησης (Date of sale, name of buyer, address of buyer, actual selling price)

47 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 47 Χαρακτηριστικά : The Osbert Oglesby Case Study (συνέχ.) Figure 10.14

48 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 48 Συνέχεια της Δραστηριότητας των Απαιτήσεων : The Osbert Oglesby Case Study Τώρα (στην δεύτερη επανάληψη), λαμβάνουμε υπόψη μας τον αλγόριθμο υπολογισμού της μέγιστής τιμής αγοράς Κατηγοριοποίηση των πινάκων ως:  Masterpiece  Masterwork, or  Other painting

49 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 49 Μέγιστη τιμή για ένα Masterpiece: The Osbert Oglesby Case Study Ψάξε παγκοσμίως σε αγοραπωλησίες πινάκων τα τελευταία 25 χρόνια για την εύρεση της πιο παρόμοιας δουλείας από τον ίδιο καλλιτέχνη Χρησιμοποιεία την τελευταία τιμή αγοράς της πιο παρόμοιας δουλείας σαν βασική τιμή για τον υπολογισμό της τιμής αγοράς κάποιου πίνακα Η μέγιστη τιμή αγοράς βρίσκεται προσθέτοντας 8.5% στη βασική τιμή (υπολογιζόμενη κάθε χρόνο), για κάθε χρόνο που πέρασε από τη χρονιά τελευταίας πώλησης του πιο παρόμοιου πίνακα

50 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 50 Μέγιστη τιμή για ένα Masterwork: The Osbert Oglesby Case Study Υπολόγισε την μέγιστη τιμή αγοράς του πίνακα σας να ήταν masterpiece από τον ίδιο καλλιτέχνη Αν ο πίνακας ζωγραφίστηκε τον 21 ο αιώνα, πολλαπλασίασε τη τιμή επί 0.25 διαφορετικά, πολλαπλασίασε με (21 – c)/(22 – c), όπου c είναι ο αιώνας που το έργο ζωγραφίστηκε (12 < c < 21)

51 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 51 Μέγιστη τιμή για ένα for an Other Painting: The Osbert Oglesby Case Study Μετρήστε τις διαστάσει του καμβά Η μέγιστη τιμή αγοράς δίνεται τότε από τον τύπο F  A, όπου  F είναι μια σταθερά σχετική με τον καλλιτέχνη, είναι ο συντελεστής δημοφιλότητας (fashionability coefficient), and  A είναι το εμβαδόν του καμβά σε τετραγωνικά εκατοστά Αν δεν είναι γνωστός ο συντελεστής δημοφιλότητας του καλλιτέχνη, ο Osbert δεν αγοράζει τον πίνακα

52 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 52 Συντελεστής Ομοιότητας : The Osbert Oglesby Case Study Για ένα masterpiece ή masterwork, ο συντελεστής ομοιότητας ανάμεσα σε δυο πίνακες υπολογίζεται να ακολούθως :  Score 1 για ταίριασμα στο μέσο, διαφορετικά 0  Score 1 για ταίριασμα στο θέμα, διαφορετικά 0  Προσθέστε αυτούς τους δυο αριθμούς, πολλαπλασιάστε με το εμβαδόν του μικρότερου πίνακα και διαιρέστε με το εμβαδόν του μεγαλύτερου  Ο αριθμός που θα προκύψει είναι ο συντελεστής ομοιότητας

53 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 53 Συντελεστής Ομοιότητας: The Osbert Oglesby Case Study (contd) Αν ο συντελεστής ομοιότητας ανάμεσα στον πίνακα που μας ενδιαφέρει και σε όλους τους πίνακες στο αρχείο με δεδομένα για πουλήσεις τα τελευταία χρόνια είναι 0, τότε ο Osbert δεν αγοράζει τον πίνακα masterwork or masterpiece

54 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 54 Συντελεστής Δημοφιλότητας : The Osbert Oglesby Case Study Το προϊόν λογισμικού πρέπει να περιλαμβάνει μια λίστα καλλιτεχνών και τις αντίστοιχες τιμές για το F Οι τιμές του F μπορούν αν αλλάζουν από μήνα σε μήνα, σε σχέση με την τρέχουσα δημοφιλότητα κάθε καλλιτέχνη Ο Osbert καθορίζει τη τιμή του F με βάση τις γνώσεις και την εμπειρία του  Αλλάζει την τιμή ανάλογα με το αν ανεβαίνουν οι τιμές για ένα καλλιτέχνη ή αν πέφτουν

55 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 55 Auction Data : The Osbert Oglesby Case Study Το προϊόν λογισμικού θα πρέπει να χρησιμοποιεί πληροφορίες από ενέργειες πώλησης σε παγκόσμιο επίπεδο masterpieces τα τελευταία 25 χρόνια Κάθε μήνα ο Osbert λαμβάνει ένα CD με ενημερωμένες αυτές τις τιμές πολώσεων. Οι τιμές αυτές ΔΕΝ μεταβάλλονται από τον Osbert

56 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 56 Updated Use Cases: The Osbert Oglesby Case Study The use-case descriptions must reflect this information The resulting description of the Buy a Painting use case is shown in Figure 10.14 (see 9 slides back)

57 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 57 Updated Use Cases: The Osbert Oglesby Case Study The description of the Sell a Painting use case: Figure 10.15

58 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 58 Reports: The Osbert Oglesby Case Study There are three reports:  Purchases during the past year  Sales during the past year  Detection of new trends Sample reports show Osbert’s needs are as follows (question marks in the first or last name of artist, or in the title or date of the work are to be included in all reports):

59 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 59 Report of Purchases during the Past Year: The Osbert Oglesby Case Study A report is needed to display all the paintings purchased during the past year  The average ratio of the purchase price to the suggested maximum price is required at the end of the report Figure 10.16

60 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 60 Report of Sales during the Past Year: The Osbert Oglesby Case Study A report is needed to display all the paintings sold during the past year  The average ratio of the actual selling price to the target selling price is required at the end of the report Figure 10.17

61 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 61 Report of Trends during the Past Year: The Osbert Oglesby Case Study A report showing artists whose works Osbert has sold at a price that has exceeded the target selling price in every instance during the past year  To appear in this report, at least two of the artist’s works must have been sold by Osbert during that period Figure 10.18

62 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 62 Updated Use Cases: The Osbert Oglesby Case Study The updated description of the Produce a Report use case, incorporating the details listed earlier, appears in Figure 10.19 (see over)

63 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 63 Updated Use Cases: The Osbert Oglesby Case Study (contd) Figure 10.19

64 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 64 The Test Workflow: The Osbert Oglesby Case Study There is a serious omission  The use case for updating a fashionability coefficient has been overlooked Missing use case Update a Fashionability Coefficient Figure 10.20

65 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 65 Second Iteration of the Use-Case Diagram: The Osbert Oglesby Case Study Incorporate all four use cases Figure 10.22

66 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 66 The Test Workflow: The Osbert Oglesby Case Study (contd) The description of the use case Update a Fashionability Coefficient Figure 10.21

67 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 67 The Test Workflow: The Osbert Oglesby Case Study (contd) A fault was detected  There was a missing use case  The existing artifacts did not need to be changed Two additional artifacts had to be added  A use case, and  Its description

68 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 68 The Test Workflow: The Osbert Oglesby Case Study (contd) The Unified Process is iterative and incremental  Members of the development team must always be aware that changes and extensions to the current version of the software product may have to made at any time

69 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 69 The Classical Requirements Phase There is no such thing as “object-oriented requirements”  The requirements workflow has nothing to do with how the product is to be built However, the approach presented in this chapter is  Model oriented, and therefore  Object oriented

70 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 70 The Classical Requirements Phase (contd) The classical approach to requirements  Requirements elicitation  Requirements analysis  Construction of a rapid prototype  Client and future users experiment with the rapid prototype

71 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 71 Rapid Prototyping Hastily built (“rapid”)  Imperfections can be ignored Exhibits only key functionality Emphasis on only what the client sees  Error checking, file updating can be ignored Aim:  To provide the client with an understanding of the product

72 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 72 Rapid Prototyping (contd) A rapid prototype is built for change  Languages for rapid prototyping include 4GLs and interpreted languages

73 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 73 Human Factors The client and intended users must interact with the user interface Human-computer interface (HCI)  Menu, not command line  “Point and click”  Windows, icons, pull-down menus

74 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 74 Human Factors (contd) Human factors must be taken into account  Avoid a lengthy sequence of menus  Allow the expertise level of an interface to be modified  Uniformity of appearance is important  Advanced psychology vs. common sense? Rapid prototype of the HCI of every product is obligatory

75 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 75 Reusing the Rapid Prototype Reusing a rapid prototype is essentially code-and- fix Changes are made to a working product  Expensive Maintenance is hard without specification and design documents Real-time constraints are hard to meet

76 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 76 Reusing the Rapid Prototype (contd) One way to ensure that the rapid prototype is discarded  Implement it in a different language from that of the target product Generated code can be reused We can safely retain (parts of) a rapid prototype if  This is prearranged  Those parts pass SQA inspections  However, this is not “classical” rapid prototyping

77 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 77 CASE Tools for the Requirements Workflow We need graphical tools for UML diagrams  To make it easy to change UML diagrams  The documentation is stored in the tool and therefore is always available Such tools are sometimes hard to use The diagrams may need considerable “tweaking” Overall, the strengths outweigh the weaknesses

78 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 78 CASE Tools for the Requirements Workflow (contd) Graphical CASE environments extended to support UML include  System Architect  Software through Pictures Object-oriented CASE environments include  Rose  Together  ArgoUML (open source)

79 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 79 Metrics for the Requirements Workflow Volatility and speed of convergence are measures of how rapidly the client’s needs are determined

80 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 80 Metrics for the Requirements Workflow (contd) The number of changes made during subsequent phases Changes initiated by the developers  Too many changes can mean the process is flawed Changes initiated by the client  Moving target problem

81 Τεχνολογία Υπολογισμού Δρ. Μαρία Ι. Ανδρέου 81 Challenges of the Requirements Phase Employees of the client organization often feel threatened by computerization The requirements team members must be able to negotiate  The client’s needs may have to be scaled down Key employees of the client organization may not have the time for essential in-depth discussions Flexibility and objectivity are essential