Απαιτήσεις
REQUIREMENTS
Δρ. Μαρία Ι. Ανδρέου
Περιεχόμενα








Κατανόηση των αναγκών του πελάτη
Η δραστηριότητα των απαιτήσεων
Κατανόηση του πλαισίου (domain)
Το επιχειρησιακό μοντέλο (business model)
Αρχικές απαιτήσεις (Initial requirements)
Αρχική κατανόηση πλαισίου στο: Osbert Oglesby
case study
Το αρχικό επιχειρησιακό μοντέλο του: Osbert
Oglesby case study
Αρχικές απαιτήσεις: στο Osbert Oglesby case
study
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
2
Περιεχόμενο (συνέχ.)









Συνεχίζοντας τη δραστηριότητα των απαιτήσεων:
στο Osbert Oglesby case study
Δραστηριότητα Ελέγχου: στο Osbert Oglesby case
study
Η ΚΑΛΣΙΚΗ φάση Απαιτήσεων
Γρήγορο Πρωτότυπο (Rapid prototyping)
Ανθρώπινοι παράγοντες (Human factors)
Επαναχρησιμοποίηση του rapid prototype
Εργαλεία στη δραστηριότητα των απαιτήσεων
(CASE tools για το requirements workflow)
Μετρικές για τη δραστηριότητα των απαιτήσεων
Προκλήσεις στη δραστηριότητα των απαιτήσεων
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
3
Ο στόχος της Δραστηριότητας των Απαιτήσεων
Requirements Workflow

Κύριος στόχος της πρώτης δραστηριότητας στο
κύκλο ζωής ενός λογισμικού είναι να απαιτηθεί η
ερώτηση

Τι πρέπει να είναι ικανό να κάνει το προϊόν;
(What must the product be able to do?)
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
4
Καθορίζουμε ΤΙ χρειάζεται ο πελάτης
(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!”
Πρέπει να καθορίσουμε ΤΙ χρειάζεται ο πελάτης
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
5
Καθορίζουμε ΤΙ χρειάζεται ο πελάτης

Είναι δύσκολο για ένα αναλυτή συστημάτων
(systems analyst) να φανατιστεί (to visualize) ένα
προϊόν λογισμικού και της λειτουργικότητας τους



(συνεχ.)
Το πρόβλημα είναι πολύ χειρότερο για τον πελάτη
Χρειάζεται ένας έμπειρος αναλυτή συστημάτων
για να μπορέσει να εκμαιεύσει κατάλληλες
πληροφορίες από τον πελάτη.
Ο πελάτης είναι η μόνη πυγή για αυτή τη
πληροφόρηση
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
6
Καθορίζουμε ΤΙ χρειάζεται ο πελάτης

(συνεχ.)
Η λύση :
1.
2.
3.
Παίρνουμε τις πρώτες πληροφορίες από το πελάτη
Χρησιμοποιούμε τις αρχικές πληροφορίες σαν είσοδο
στην Unified Process
Ακολουθούμε τα βήματα της Unified Process για να
καθορίσουμε τις ΠΡΑΓΜΑΤΙΚΕΣ ανάγκες του πελάτη
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
7
Η Δραστηριότητα των Απαιτήσεων

Πρώτο, κατανοούμε το πλαίσιο της εφαρμογής
application domain (ή πλαίσιο για συντομία) την οποία
καλούμαστε να αναπτύξουμε


Δεύτερο, χτίζουμε το επιχειρησιακό μοντέλο (business
model)



Δηλ. το συγκεκριμένο περιβάλλον στο οποίο το
στοχευόμενο προϊόν θα λειτουργήσει
Είναι το μοντέλο (ο τρόπος) με τον οποίο λειτουργεί η
επιχείρηση του πελάτη
Τρίτο, χρησιμοποιούμε το επιχειρησιακό μοντέλο για να
κατανοήσουμε και να καθορίσουμε τις ανάγκες και τις
απαιτήσεις του πελάτη
Επανάληψη και σταδιακή εκλέπτυνση των πιο πάνω
βημάτων
Τεχνολογία Υπολογισμού
8
Δρ. Μαρία Ι. Ανδρέου
Ορισμοί

Ανακάλυψη των Απαιτήσεων του πελάτη

Εκμαίευση των Απαιτήσεων


Μέθοδοι: συνεντεύξεις και δημοσκοπήσεις
Εκλέπτυνση και επέκταση των αρχικών
απαιτήσεων

Ανάλυση Απαιτήσεων
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
9
Κατανόηση του Πεδίου

Κάθε μέλος της ομάδας ανάπτυξης ενός
συγκεκριμένου λογισμικού πρέπει να είναι γνώστης
σε μεγάλο βαθμό του πεδίου της εφαρμογής


Είναι ουσιαστικής (καθοριστικής) σημασίας η
διόρθωση της ονοματολογίας (terminology) που
χρησιμοποιείται
Δημιουργία Γλωσσάριου (glossary)

Μια λίστα από τεχνικούς όρους (technical words) που
χρησιμοποιούνται στο πεδίο εφαρμογής του
ζητούμενου λογισμικού και η σημασία τους
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
10
Επιχειρησιακό Μοντέλο
Business Model

Το επιχειρησιακό μοντέλο (business model) είναι μια
περιγραφή της επιχειρησιακής διαδικασίας (business
processes) ενός οργανισμού

Το επιχειρησιακό μοντέλο δείχνει το πως κατανοήσαμε την
επιχείρησης του πελάτη σας σύνολο


Αυτή η γνώση είναι ουσιαστική έτσι ώστε να είναι δυνατό να
συμβουλεύσουμε το πελάτη μας σε σχέση με θέματα
μηχανογράφησης της επιχείρησης του
Ο αναλυτής του συστήματος πρέπει να κατανοεί σε βάθος
και με κάθε λεπτομέρεια όλες τις επιμέρους επιχειρηματικές
λειτουργίες

Χρησιμοποιεί διάφορες τεχνικές για να το επιτύχει αυτό, κυρίως
συνεντεύξεις
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
11
Συνεντεύξεις

Η ομάδα η οποία έχει αναλάβει να εκμαιεύσει τις
απαιτήσεις συναντάται με το πελάτη και με τελικούς
χρήστες του συστήματος για να εξάξει όλες τις
σχετικές πληροφορίες
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
12
Συνεντεύξεις

Υπάρχουν δυο ειδών ερωτήσεις



(συνέχ.)
Κλειστού τύπου ερωτήσεις (Close-ended questions)
 Απαιτούν συγκεκριμένη απάντηση
Ανοικτού τύπου ερωτήσεις (Open-ended questions)
 Ερωτούνται για να ενθαρρύνουν το άτομο το οποίο δίνει τη
συνέντευξη να μιλήσεις ελεύθερα και να εκφράσει όλα όσα
θέλει
Υπάρχουν δυο τύποι Συνεντεύξεων

Δομημένη Συνέντευξη (structured interview)
 Ερωτούνται συγκεκριμένες και προσχεδιασμένες ερωτήσεις


Συχνά κλειστού τύπου ερωτήσεις
Αδόμητη Συνέντευξη (unstructured interview)
 Οι ερωτήσεις θέτονται σε σχέση με τις απαντήσεις που δίνει ο
ερωτώμενος

Τεχνολογία Υπολογισμού
Συχνά είναι ανοικτού τύπου ερωτήσεις
Δρ. Μαρία Ι. Ανδρέου
13
Συνεντεύξεις

Η διαδικασία ετοιμασία και λήψεις μια συνέντευξης
Δεν είναι εύκολη



(συνέχ.)
Μια εντελώς αδόμητη συνέντευξη δεν θα εκμαιεύσει
πολλές χρήσιμες και σχετικές με το έργο πληροφορίες
Το άτομο που παίρνει τη συνέντευξη (και το άτομο που
δίνει τη συνέντευξη) πρέπει να είναι πλήρως γνώστης
του πεδίου της εφαρμογής και να είναι σε εγρήγορση
όλη την ώρα
Μετά την συνέντευξη


το άτομο που πήρε τη συνέντευξη, πρέπει να
ετοιμάσει μια γραπτή αναφορά (written report)
Συνίσταται να δώσει την αναφορά και στο άτομο που
έδωσε την συνέντευξη (για λόγους ελέγχου)
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
14
Άλλες Τεχνικές

Οι συνεντεύξεις είναι η πρωτεύων τεχνική

Τα ερωτηματολόγια είναι μια δεύτερη τεχνική και
είναι χρήσιμη όταν πρέπει να ληφθεί υπόψη η
γνώμη πολλών (εκατοντάδων) διαφορετικών
ανθρώπων
Μελέτη (εξέταση) των εντύπων της επιχείρησης για
να κατανοήσουμε πως ο πελάτης μας κάνει μέχρι
τώρα τη δουλειά του

Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
15
Άλλες Τεχνικές

(συνέχ.)
Η Απευθείας παρακολούθηση των εργαζομένων
κατά την διάρκεια εκτέλεσης των καθηκόντων τους
είναι πολλές φορές χρήσιμη στο να κατανοήσουμε
πλήρως την επιχειρηματική διαδικασία

Οι βιντεοκάμερες (Videotape cameras) είναι η
μοντέρνα (σύγχρονη) μορφή της τεχνικής
παρακολούθησης


Όμως, παίρνει πολύ χρόνο να αναλυθούν οι ταινίες (cd)
Οι εργαζόμενοι μπορεί να θεωρούν ότι οι κάμερες
παραβιάζουν με απαράδεκτο τρόπο τα ατομικά τους
δικαιώματα
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
16
Περιπτώσεις Χρήσης (ενός λογισμικού)
Use Cases
 Μια περίπτωση χρήσης (use case) μοντελοποιεί
μια αλληλεπίδραση ανάμεσα στο προϊόν
λογισμικού και στους χρήστες του (που είναι οι
ηθοποιοί -actors)
 Παράδειγμα:
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
17
Περιπτώσεις Χρήσης (ενός λογισμικού)
(συνέχ.)

Ένας ηθοποιός (actor) είναι ένα μέλος του κόσμου έξω από
το (ζητούμενο) προϊόν λογισμικού

Συχνά είναι εύκολο να αναγνωρίσουμε τους ηθοποιούς


Ένας ηθοποιός είναι συχνά ένας χρήστης του λογισμικού
Γενικά, ένας ηθοποιός παίζει κάποιο ρόλο σε σχέση με το
λογισμικό. Ο ρόλος αυτός μπορεί να αφορά



Ένα χρήστη, ή
Κάποιο που κάνει αρχικοποίηση ή
Κάποιο που έχει ένα σημαντικό (καθοριστικό) ρόλο σε κάποια use
case του λογισμικού
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
18
Περιπτώσεις Χρήσης (ενός λογισμικού)
(συνέχ.)

Ένας χρήστης του συστήματος μπορεί να παίξει
περισσότερο από ένα ρόλους

Παράδειγμα: Ένας πελάτης μιας τράπεζας μπορεί
να είναι


A Borrower or
A Lender
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
19
Περιπτώσεις Χρήσης (ενός λογισμικού)
(συνέχ.)

Αντιστρόφως, ένας ηθοποιός μπορεί να συμμετέχει
σε πολλές περιπτώσεις χρήσης του λογισμικού

Παράδειγμα: ένας Borrower μπορεί να είναι
ηθοποιός στις ακόλουθες use cases




The Borrow Money use case;
The Pay Interest on Loan use case; and
The Repay Loan Principal use case
Επίσης, ο ηθοποιός Borrower μπορεί να
αντιπροσωπεύει πολλές χιλιάδες πελατών μιας
τράπεζας
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
20
Περιπτώσεις Χρήσης (ενός λογισμικού)
(συνέχ.)

Ο ηθοποιός σε ένα προϊόν λογισμικού ΔΕΝ
χρειάζεται να είναι πάντα άνθρωπος

παράδειγμα: ένα e-commerce information system
πρέπει να αλληλεπιδρά με ένα credit card
company information system


το credit card company information system είναι ένας
ηθοποιός αν το βλέπουμε από την σκοπιά του ecommerce information system
Το e-commerce information system είναι ένας
ηθοποιός αν το βλέπουμε από την σκοπιά του credit
card company information system
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
21
Περιπτώσεις Χρήσης (ενός λογισμικού)

Ένα ενδεχόμενο πρόβλημα όταν αναγνωρίζουμε
τους ηθοποιούς είναι η:


(συνέχ.)
Επικάλυψη ηθοποιών
Παράδειγμα: προϊόν λογισμικού για νοσοκομεία



Μια περίπτωση χρήσης (use case) έχει σαν ηθοποιό
μια νοσοκόμα (Nurse)
Μια άλλη use case έχει σαν ηθοποιό Ιατρικό
προσωπικό (Medical Staff)
Είναι καλύτερα οι ηθοποιοί να ήταν οι εξής:

Ηθοποιοί: Physician and Nurse
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
22
Περιπτώσεις Χρήσης (ενός λογισμικού)

(συνέχ.)
Εναλλακτικά:

Ο ηθοποιός θα ήταν το Medical Staff με δυο
ιδιόκτητες : Physician and Nurse
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
23
Αρχικές Απαιτήσεις
Initial Requirements
 Οι αρχικές απαιτήσεις βασίζονται στο αρχικό
επιχειρησιακό μοντέλο

Στη συνέχεια εκλεπτύνονται

Οι απαιτήσεις είναι δυναμικές — αλλάζουν συχνά

Διατηρείτε μια λίστα από ενδεχόμενες απαιτήσεις, μαζί
με τις περιπτώσεις χρήσης (use cases) που έχουν
εγκριθεί από τον πελάτη
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
24
Αρχικές Απαιτήσεις


Υπάρχουν δυο κατηγορίες απαιτήσεων
Μια λειτουργική απαίτηση (functional requirement)
καθορίζει μια ενέργεια που το προϊόν λογισμικού
πρέπει να είναι ικανό να εκτελεί


(συνέχ.)
Συχνά εκφράζεται σε σχέση με όρους που αφορούν
είσοδο δεδομένων και έξοδο πληροφοριών από το
σύστημα
Μια Μη-λειτουργική απαίτηση (nonfunctional
requirement) καθορίζει Ιδιότητες του λογισμικού,
όπως


Χρόνος απόκρισης (Response times)
Αξιοπιστία (Reliability)
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
25
Αρχικές Απαιτήσεις
(συνέχ.)

Οι λειτουργικές απαιτήσεις χειρίζονται σας μέρος
των δραστηριοτήτων απαιτήσεων και ανάλυσης
(requirements and analysis workflows)

Μερικές μη-λειτουργικές απαιτήσεις θα πρέπει να
περιμένουν (για να διαχειριστούν) μέχρι τη
δραστηριότητα του σχεδιασμού

Λεπτομερείς πληροφορίες για μερικές από αυτές Δεν
είναι διαθέσιμες πριν το τέλος της δραστηριότητας της
ανάλυσης
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
26
Αρχική Κατανόηση του Πεδίου : The Osbert Oglesby Case Study




Ο Osbert Oglesby, είναι ένας έμπορος έργων
τέχνης (Art Dealer), και χρειάζεται ένα προϊόν
λογισμικού για να τον βοηθά στην αγορά και
πώληση πινάκων.
Αρχικά, θα πρέπει να αποκτήσουμε γνώσεις
αναφορικά με το πεδίο της εφαρμογής.
Στη συνέχεια μέσω συνεντεύξεων ο Osbert δίνει
σχετικές πληροφορίες.
Σε ένα γλωσσάρι καταγράφονται ανάμεσα σε άλλα
ορισμοί και όροι που χρησιμοποιεί ο Osbert στην
συνέντευξη.
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
27
Γλωσσάρι: The Osbert Oglesby Case Study
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
28
Τα αρχικό επιχειρησιακό μοντέλο: The Osbert Oglesby
Case Study

Ο Osbert θέλει ένα προϊόν λογισμικού, που να
εκτελείται στο laptop του, και θα



Υπολογίζει την μέγιστη τιμή του ποσού που θα πρέπει
να πληρώσει για την αγορά ενός πίνακα
Ανιχνεύει όσο το δυνατό πιο νωρίς νέες τάσεις στην
αγορά τέχνης
Για επίτευξη ικανοποίησης των απαιτήσεων του
Osbert, το λογισμικό που θα αναπτυχθεί θα πρέπει
να διατηρεί μια εγγραφή για κάθε αγορά και για μια
για κάθε πώληση.
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
29
Τα αρχικό επιχειρησιακό μοντέλο: The Osbert Oglesby
Case Study
(συνέχ.)

Μέχρι τώρα, ο Osbert δημιουργεί στο χέρι
αναφορές σχετικά με τις ετήσιες πωλήσεις και
αγορές του


Με μικρό πρόσθετο κόστος, το λογισμικό που θα
αναπτυχθεί μπορεί να δημιουργεί και να τυπώνει
αυτές τις δυο αναφορές όταν τις ζητήσει ο Osbert
Είναι ΠΟΛΥ σημαντικό να κατανοήσετε και να
καθορίσετε τις ΠΡΑΓΜΑΤΙΚΕΣ ανάγκες του πελάτη
από την αρχή, και όχι μετά την παράδοση του
προϊόντος λογισμικού
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
30
Τα αρχικό επιχειρησιακό μοντέλο: The Osbert Oglesby
Case Study
(συνεχ.)

Ο Osbert έχει τρις επιχειρηματικές δραστηριότητες:



Αγοράζει πίνακες
Πουλά πίνακες
Παράγει (ετοιμάζει) αναφορές (reports)
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
31
Τα αρχικό επιχειρησιακό μοντέλο: The Osbert Oglesby
Case Study
(συνεχ.)
 Buy a Painting use case
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
32
Τα αρχικό επιχειρησιακό μοντέλο: The Osbert Oglesby
Case Study
(συνεχ.)
 Sell a Painting use case
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
33
Τα αρχικό επιχειρησιακό μοντέλο: The Osbert Oglesby
Case Study
(συνέχ.)
 Produce a Report use case
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
34
Τα αρχικό επιχειρησιακό μοντέλο: The Osbert Oglesby
Case Study
(συνεχ.)
 For conciseness, all three use cases are combined
into a use-case diagram
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
35
Τα αρχικό επιχειρησιακό μοντέλο: The Osbert Oglesby
Case Study
(συνέχ.)

Το μόνο άτομο που χρησιμοποιεί το τρέχον σύστημα
(χειροποίητο) είναι ο Osbert



Ο Osbert είναι λοιπών ηθοποιός σε όλες τις
περιπτώσεις χρήσης (use cases)
Ο πελάτης πουλητής αρχικοποιεί την Buy a
Painting περίπτωση χρήσης και ο πελάτης αγοραστής
την Sell a Painting περίπτωση χρήσης
Ο πελάτης παίζει κρίσιμο ρόλο και στις δυο
περιπτώσεις χρήσης παρέχοντας δεδομένα που
εισάγονται στο προϊόν λογισμικό από τον Osbert

Ο πελάτης είναι λοιπόν ηθοποιός και στις δυο αυτές use
cases
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
36
Τα αρχικό επιχειρησιακό μοντέλο: The Osbert Oglesby
Case Study
(συνέχ.)
 Buy a Painting use case
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
37
Τα αρχικό επιχειρησιακό μοντέλο: The Osbert Oglesby
Case Study
(συνέχ.)

Sell a Painting use case
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
38
Τα αρχικό επιχειρησιακό μοντέλο: The Osbert Oglesby
Case Study
(συνέχ.)

Produce a Report use case
Figure 10.10
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
39
Αρχικές Απαιτήσεις : The Osbert Oglesby Case Study

Το αρχικό επιχειρησιακό μοντέλο (δηλ., οι τρις use cases)
δείχνει πως κάνει ο Osbert τη δουλεία του μέχρι τώρα

Στη συνέχεια πρέπει να παρθεί απόφαση για το ποιες από
αυτές τις use cases είναι επίσης απαιτήσεις του προϊόντος
λογισμικού που θα αναπτυχθεί


Είναι ξεκάθαρο ότι και οι τρις αυτές use cases είναι απαιτήσεις
Το επόμενο βήμα είναι εκλέπτυνση των αρχικών
απαιτήσεων

Οι περιγραφές των use cases πρέπει να επεκταθούν και να
εκλεπτυνθούν
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
40
Αρχικές Απαιτήσεις : The Osbert Oglesby Case Study

(συνέχ.)
Buy a Painting use case
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
41
Αρχικές Απαιτήσεις : The Osbert Oglesby Case Study

(συνέχ.)
Sell a Painting use case
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
42
Αρχικές Απαιτήσεις : The Osbert Oglesby Case Study

(συνέχ.)
Produce a Report use case
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
43
Αρχικές Απαιτήσεις : The Osbert Oglesby Case Study
(συνέχ.)

Και οι τρις περιγραφές είναι ακόμα ασαφείς



Είναι συνέπεια της επαναλαμβανόμενης φύσης της
Unified Process
Για παράδειγμα, οι λεπτομέρειες του αλγόριθμου
υπολογισμού της μέγιστης τιμής αγοράς δεν μας
ενδιαφέρουν στο παρόν στάδιο
Βασική αρχή: Να καθυστερείτε να λαμβάνεται
υπόψη σας λεπτομέρειες όσο περισσότερο
μπορείτε

Αυτό θα ευκολύνει τη διαχείριση αλλαγών που θα
προκύψουν στην επόμενη επανάληψη
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
44
Συνέχεια της Δραστηριότητας των Απαιτήσεων : The Osbert Oglesby Case Study

Τώρα χρειάζονται περισσότερες λεπτομέρειες για
κάθε use case

Αρχικά μελετούμε τις use cases



Buy a Painting, και
Sell a Painting
Για να εκλεπτύνουμε, καθορίζουμε ΠΟΙΑ
χαρακτηριστικά πρέπει να εισαχθούν στο σύστημα
(στο λογισμικό) όταν ένας πίνακας αγοράζεται ή
πωλείται
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
45
Χαρακτηριστικά: 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)
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
46
Χαρακτηριστικά: The Osbert Oglesby Case Study (συνέχ.)
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
Figure 10.14
47
Συνέχεια της Δραστηριότητας των Απαιτήσεων : The Osbert Oglesby Case Study

Τώρα (στην δεύτερη επανάληψη), λαμβάνουμε
υπόψη μας τον αλγόριθμο υπολογισμού της
μέγιστής τιμής αγοράς

Κατηγοριοποίηση των πινάκων ως:



Masterpiece
Masterwork, or
Other painting
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
48
Μέγιστη τιμή για ένα Masterpiece: The Osbert Oglesby Case Study

Ψάξε παγκοσμίως σε αγοραπωλησίες πινάκων τα
τελευταία 25 χρόνια για την εύρεση της πιο
παρόμοιας δουλείας από τον ίδιο καλλιτέχνη

Χρησιμοποιεία την τελευταία τιμή αγοράς της πιο
παρόμοιας δουλείας σαν βασική τιμή για τον
υπολογισμό της τιμής αγοράς κάποιου πίνακα

Η μέγιστη τιμή αγοράς βρίσκεται προσθέτοντας
8.5% στη βασική τιμή (υπολογιζόμενη κάθε χρόνο),
για κάθε χρόνο που πέρασε από τη χρονιά
τελευταίας πώλησης του πιο παρόμοιου πίνακα
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
49
Μέγιστη τιμή για ένα Masterwork: The Osbert Oglesby Case Study

Υπολόγισε την μέγιστη τιμή αγοράς του πίνακα σας
να ήταν masterpiece από τον ίδιο καλλιτέχνη

Αν ο πίνακας ζωγραφίστηκε τον 21ο αιώνα,
πολλαπλασίασε τη τιμή επί 0.25

διαφορετικά, πολλαπλασίασε με (21 – c)/(22 – c),
όπου c είναι ο αιώνας που το έργο ζωγραφίστηκε
(12 < c < 21)
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
50
Μέγιστη τιμή για ένα for an Other Painting: The Osbert Oglesby Case Study


Μετρήστε τις διαστάσει του καμβά
Η μέγιστη τιμή αγοράς δίνεται τότε από τον τύπο F  A,
όπου



F είναι μια σταθερά σχετική με τον καλλιτέχνη, είναι ο
συντελεστής δημοφιλότητας (fashionability coefficient), and
A είναι το εμβαδόν του καμβά σε τετραγωνικά εκατοστά
Αν δεν είναι γνωστός ο συντελεστής δημοφιλότητας του
καλλιτέχνη, ο Osbert δεν αγοράζει τον πίνακα
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
51
Συντελεστής Ομοιότητας : The Osbert Oglesby Case Study

Για ένα masterpiece ή masterwork, ο συντελεστής
ομοιότητας ανάμεσα σε δυο πίνακες υπολογίζεται
να ακολούθως :




Score 1 για ταίριασμα στο μέσο, διαφορετικά 0
Score 1 για ταίριασμα στο θέμα , διαφορετικά 0
Προσθέστε αυτούς τους δυο αριθμούς,
πολλαπλασιάστε με το εμβαδόν του μικρότερου
πίνακα και διαιρέστε με το εμβαδόν του μεγαλύτερου
Ο αριθμός που θα προκύψει είναι ο συντελεστής
ομοιότητας
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
52
Συντελεστής Ομοιότητας: The Osbert Oglesby Case Study (contd)

Αν ο συντελεστής ομοιότητας ανάμεσα στον πίνακα
που μας ενδιαφέρει και σε όλους τους πίνακες στο
αρχείο με δεδομένα για πουλήσεις τα τελευταία
χρόνια είναι 0, τότε ο Osbert δεν αγοράζει τον
πίνακα masterwork or masterpiece
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
53
Συντελεστής Δημοφιλότητας : The Osbert Oglesby Case Study

Το προϊόν λογισμικού πρέπει να περιλαμβάνει μια
λίστα καλλιτεχνών και τις αντίστοιχες τιμές για το F

Οι τιμές του F μπορούν αν αλλάζουν από μήνα σε
μήνα, σε σχέση με την τρέχουσα δημοφιλότητα
κάθε καλλιτέχνη

Ο Osbert καθορίζει τη τιμή του F με βάση τις
γνώσεις και την εμπειρία του

Αλλάζει την τιμή ανάλογα με το αν ανεβαίνουν οι τιμές
για ένα καλλιτέχνη ή αν πέφτουν
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
54
Auction Data: The Osbert Oglesby Case Study

Το προϊόν λογισμικού θα πρέπει να χρησιμοποιεί
πληροφορίες από ενέργειες πώλησης σε
παγκόσμιο επίπεδο masterpieces τα τελευταία 25
χρόνια

Κάθε μήνα ο Osbert λαμβάνει ένα CD με
ενημερωμένες αυτές τις τιμές πολώσεων. Οι τιμές
αυτές ΔΕΝ μεταβάλλονται από τον Osbert
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
55
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)
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
56
Updated Use Cases: The Osbert Oglesby Case Study

The description of the Sell a Painting use case:
Figure 10.15
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
57
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):
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
58
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
59
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
60
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
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
61
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)
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
62
Updated Use Cases: The Osbert Oglesby Case Study (contd)
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
Figure 10.19
63
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
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
64
Second Iteration of the Use-Case Diagram: The Osbert Oglesby Case Study

Incorporate all four use cases
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
Figure 10.22
65
The Test Workflow: The Osbert Oglesby Case Study (contd)

The description of the use case Update a
Fashionability Coefficient
Figure 10.21
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
66
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
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
67
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
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
68
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
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
69
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
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
70
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
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
71
Rapid Prototyping (contd)

A rapid prototype is built for change

Languages for rapid prototyping include 4GLs and
interpreted languages
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
72
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
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
73
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
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
74
Reusing the Rapid Prototype

Reusing a rapid prototype is essentially code-andfix

Changes are made to a working product

Expensive

Maintenance is hard without specification and
design documents

Real-time constraints are hard to meet
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
75
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
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
76
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
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
77
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)
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
78
Metrics for the Requirements Workflow

Volatility and speed of convergence are measures
of how rapidly the client’s needs are determined
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
79
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
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
80
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
Τεχνολογία Υπολογισμού
Δρ. Μαρία Ι. Ανδρέου
81