Εθνικό και Καποδιστριακό Πανεπιστήμιο ΑθηνώνΤμήμα Πληροφορικής & Τηλεπικοινωνιών

Τεχνολογία Λογισμικού8ο Εξάμηνο 2019-20

Ανάλυση απαιτήσεων

Δρ. Κώστας Σαΐδης (saiko@di.uoa.gr)

Ανάλυση απαιτήσεων1. Οι απαιτήσεις λογισμικού και τα είδη τους2. Από την ανάλυση απαιτήσεων στη σύνταξη των

προδιαγραφών και ο ρόλος του επικεφαλής μηχανικού(ΕΜ)

2

1. Ανάλυση απαιτήσεων

3

Απαιτήσεις λογισμικούΣυνήθως είναι ανεξάρτητες από την τεχνολογία υλοποίησης.

Απαίτηση: Τι θέλουμε να κάνει το λογισμικόΙκανοποίηση απαίτησης: Πώς το λογισμικό καλύπτει τηναπαίτηση (σχεδιαστική απόφαση και υλοποίηση).

Εκτός, βέβαια, αν η υποστήριξη κάποιας τεχνολογίας είναι ρητήαπαίτηση

4

Είδη απαιτήσεωνΛειτουργικές απαιτήσειςΜη λειτουργικές απαιτήσειςΑπαιτήσεις συστήματοςΑναδυόμενες απαιτήσεις

5

Λειτουργικές απαιτήσειςΟι απαιτήσεις της λειτουργίας του λογισμικού (συνήθωςη νέα λειτουργικότητα που πρέπει να αναπτυχθεί στοπλαίσιο του έργου)

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

6

Διαπίστευση χρηστών (userauthentication)

Σημεία εισόδου στο σύστημα (entry-points) - μηχανισμοίδιαπίστευσης χρηστώνΕπιβεβαίωση ότι ο χρήστης είναι:

"υπαρκτός" (π.χ. ο λογαριασμός του είναιεγγεγραμμένος στον "πίνακα" των χρηστών της ΒΔ)"έγκυρος" (π.χ. γνωρίζει το προσωπικό του"μυστικό" που έχει συνδεθεί με το λογαριασμό του)"ενεργός" (π.χ. δεν έχει απενεργοποιηθεί από τοδιαχειριστή)

7

Δικαιοδοσία χρηστών (userauthorization)

Διαχείριση δικαιωμάτων: ποιος χρήστης επιτρέπεται ναεκτελέσει ποια ενέργεια.

Στατική ή δυναμική ανάθεση/ανάκληση δικαιωμάτων;ΡόλοιAccess Control Lists (ACLs)Guards

8

Επιχειρησιακή λογική (business logic)Οι επιχειρησιακές διαδικασίες (business processes)Οι επιχειρησιακοί κανόνες (business rules)

Μερική ή πλήρης "ηλεκτρονικοποίηση" των λειτουργιώντου οργανισμού

9

Πιο απλάΟι λειτουργίες που περιλαμβάνονται σταυποστηριζόμενα σενάρια και περιπτώσεις χρήσης (usecases) του λογισμικούΟι ενέργειες, λειτουργίες και διαδικασίες που εκτελούν οιχρήστες μέσω του συστήματος

Τα user stories σε ένα Agile backlog

10

Διαχειριστικές λειτουργίες(administrative functions)

Ποιες είναι οι διαχειριστικές λειτουργίες;Πώς εκτελούνται;

Θα παραμετροποιούνται από το χρήστη και πόσο;

11

Λειτουργίες αναφορών (reportingrequirements)

Τι αναφορές απαιτούνται ;Πόσο παραμετροποιήσιμες πρέπει να είναι;

Ποιος έχει δικαίωμα να τις προσπελαύνει;

12

Μη λειτουργικές απαιτήσειςΑπαιτήσεις για ποιοτικά χαρακτηριστικά του λογισμικού

Διαθεσιμότητα - Ανάνηψη από καταστροφέςΑσφάλεια - ΑκεραιότηταΕυελιξία - Επεκτασιμότητα

Απόδοση - ΑπροκρισιμότηταΥποστήριξη διεθνών προτύπων

Καθορίζουν σε μεγάλο βαθμό την επιτυχία του έργου

13

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

14

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

15

Στην πράξηΣτην πράξη, κάποιες απαιτήσεις μπορεί να βρίσκονται"κάπου ανάμεσα" στα παραπάνω είδηΑλλά αυτό ποικίλει ανάλογα με το υπό ανάπτυξηλογισμικό, το περιβάλλον λειτουργίας του και τουςεμπλεκόμενους φορείς - χρήστες του

Ας δούμε μερικά παραδείγματα

16

Τήρηση ημερολογίων (audit tracking)Ποιες ενέργεις καταγράφονται σε ημερολόγια;Σε ποιο βαθμό λεπτομέρειας;Για ποιο σκοπό και με ποια τελική χρήση;

17

Μαζική εισαγωγή / εξαγωγήδεδομένων (Data import / export)

Απατείται η μαζική εισαγωγή / εξαγωγή δεδομένων;Θα παραμετροποιείται από το χρήστη και πόσο;Ποιοι μορφότυποι αρχείων / δεδομένων θα πρέπει ναυποστηρίζονται;

18

Υποστήριξη διεθνούς προτύπουΑνάλογα με την περίπτωση, μπορεί να επηρεάζει:

Ένα συγκεκριμένο συστατικόΈνα υποσύνολο των συστατικών

Το σχεδιασμό συνολικά

19

Διαλειτουργικότητα (interoperability)Το υπό ανάπτυξη σύστημα θα διαλειτουργεί με τρίτασυστήματα;Τι είδους δεδομένα θα ανταλλάσονται;

Με ποιους μηχανισμούς, μορφότυπους και πρωτόκολλα;

20

Νομικές ή κανονιστικές απαιτήσειςΤο υπό ανάπτυξη σύστημα θα πρέπει να είναι σύννομο(προσωπικά δεδομένα, πνευματικά δικαιώματα, κτλ.)Το υπό ανάπτυξη σύστημα μπορεί να διέπεται απόσυγκεκριμένο νομικό ή κανονιστικό πλαίσιο (γιαπαράδειγμα, πληροφοριακά συστήματα δημοσίουτομέα).

21

Ορισμός των απαιτήσεωνΣαφήνεια (η απαίτηση είναι σαφώς διατυπωμένη)Συνέπεια (η μία απαίτηση δεν αντιβαίνει με την άλλη)

Πληρότητα (η απαίτηση καλύπτει όλες τις περιπτώσεις)Επαληθευσιμότητα (η απαίτηση μπορεί να ελεγχθεί σεσχέση με την υλοποίηση)

22

ΕπίσηςΣε μεγάλα έργα

Καταγωγή/γενεαλογία απαίτησηςΠοιος τη ζήτησεΠοιον επιχειρησιακό στόχο εξυπηρετεί

Για παράδειγμα, θα πρέπει να γνωρίζει η ομάδα του έργου αν "τοζητάει ο διευθυντής"

23

Έγγραφο ανάλυσης απαιτήσεωνΠεριγραφή σε φυσική γλώσσα:

Σκοπός του συστήματοςΚατηγορίες χρηστών (users & stakeholders)Εμβέλεια του συστήματος

ΠεριορισμοίΠαραδοχέςΑπαιτήσεις (λειτουργικές ή μη)

24

2. Από την ανάλυση απαιτήσεων στησύνταξη των προδιαγραφών και ορόλος του επικεφαλής μηχανικού

25

Ζητούμενα από το κείμενο τωντεχνικών προδιαγραφών

Να προσδιορίσουν τον τρόπο με τον οποίο το λογισμικόθα ικανοποιήσει τις απαιτήσεις

26

ΣυγκεκριμέναΑρχιτεκτονικός σχεδιασμός και συστατικά τουλογισμικού

Σαφής περιγραφή της αλληλεπίδρασης του λογισμικούμε το παραγωγικό του περιβάλλον (productionenvironment)Λεπτομερής προδιαγραφή των λειτουργιών και τωνδιαδικασιών που υποστηρίζονται από το λογισμικόΣύνδεση των προδιαγραφών με τις απαιτήσεις (πηγή/προέλευση προδιαγραφής)Καθορισμός κριτηρίων αποδοχής / απόρριψης(τμημάτων ή όλου) του συστήματος

27

Έλεγχοι αποδοχής (acceptance tests)Έλεγχοι που καθορίζουν την αποδοχή ή την απόρριψησυστατικών ή λειτουργιών ή "οθονών" του λογισμικούΕίναι καλή πρακτική να έχουν προβλεφθεί (μερικώς ήπλήρως) στις προδιαγραφές

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

28

Σχεδιαστικές αποφάσειςΓια να μετατραπούν οι υψηλού επιπέδου απαιτήσεις τουλογισμικούΣε χαμηλού επιπέδου τεχνικές προδιαγραφές αυτούΘα πρέπει να παρθούν συγκεκριμένες σχεδιαστικέςαποφάσεις

29

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

Από την άλλη δεν είναι αποδεκτό να προκύψει στηνπορεία υλοποίησης μιας προδιαγραφής ένα ζήτημα πουθα "ακυρώσει" το σχεδιασμόΤο ότι θα τον αλλάξει είναι (σχεδόν) βέβαιο!

30

Σχεδιαστικές αποφάσειςΟι αποφάσεις σχετικά με κάποια πτυχή του λογισμικού πουείναι "ακριβό" ή "δύσκολο" να αλλάξουν άπαξ καιπαγιωθούν.

31

Θυμηθείτε

32

Κοινός τόποςΗ ανάλυση των απαιτήσεων πρέπει να καταλήξει σε ένακοινά αποδεκτό ζητούμενοΚάτι που μπορεί να είναι δύσκολο στην πράξη για μητεχνικούς λόγους (επικοινωνίας, οργάνωσης,διαφορετικήςκουλτούρας, παγίωσης μη βέλτιστων πρακτικών, κτλ.)

33

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

ΧρήστεςΠελάτεςΔιοίκηση (ακόμα και Μέτοχοι ή Επενδυτές)

ΑναλυτέςΠρογραμματιστέςΔοκιμαστέςΣχεδιαστές διεπαφών

Υπεύθυνοι έργουκτλ.

34

Ο ρόλος του EM

Διαχείριση της πολυπλοκότητας

50% αρχιτεκτονική (ουσιώδης πολυπλοκότητα)50% επικοινωνία (τεχνητή πολυπλοκότητα)

με τους stakeholdersμε την επιχειρησιακή ομάδα έργου (ProjectManager, Business Analyst, κ.ά)με την ομάδα ανάπτυξης (engineers)

35

Κοινή γλώσσαΚάθε ένας από τους συμμετέχοντες έχει διαφορετικέςεμπειρίες, βιώματα, αφετηρίες, στόχους και επιδιώξειςαπό την υλοποίηση του έργουΗ ομάδα ανάπτυξης, η επιχειρησιακή ομάδα και οιstakeholders του έργου μάλλον "θα μιλάνε" σεδιαφορετικές γλώσσες

Ο EM θα πρέπει να κάνει το διερμηνέα και να "μιλάει" τηγλώσσα και των τριών

36

Ιεράρχηση απαιτήσεωνΔεν είναι όλες οι απαιτήσεις εξίσου σημαντικέςΜια μικρή -θεωρητικά- απαίτηση μπορεί να οδηγήσει τοέργο εκτός δρόμου/στόχου

Η ομάδα ανάπτυξης ή η επιχειρησιακή ομάδαμπορεί να μη δώσουν προσοχή ("αφού το ζητάει οπελάτης")

Ο stakeholder ενδέχεται να μην το καταλάβειΟ EM πρέπει να το διαγνώσει έγκαιρα και να προτείνειεναλλακτικές

37

ΑντίστοιχαΜια "ακριβή" απαίτηση μπορεί να έχει πιο "φθηνή"εναλλακτικήΜια "σύνθετη" απαίτηση μπορεί να έχει πιο "απλή"εναλλακτικήκ.ο.κ

38

ΠροσοχήΟ ασφαλέστερος τρόπος να αποτύχει ένα έργο είναι ναεπιτραπεί στις "λάθος" απαιτήσεις να γίνουνπροδιαγραφές!

39

ΣυμπέρασμαΟ EM θα πρέπει να έχει απευθείας επαφή με τουςstakeholders

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

Ενώ παράλληλα σχεδιάζει το σύστημαΓια να είναι σε θέση να φιλτράρει τις "λάθος"απαιτήσειςΚαι να μεταφράσει τις υπόλοιπες σε προδιαγραφέςγια την ομάδα ανάπτυξης

40

The belief that complex systems require armies ofprogrammers and designers is wrong. A system that isnot understood in its entirety, or at least to a significantdegree of detail by a single individual, should probablynot be built.

N. Wirth

41

Superman

By J.Schulenklopper, E. Rommes](https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=436431 42

Για να γίνεις Superman!Ενσυναίσθηση (empathy): Για τις ανάγκες και τουςπροβληματισμούς όλων των εμπλεκόμενωνΤεχνική αρτιότητα: Γι την επιλογή αρχιτεκτονικής /τεχνολογίας που να είναι συμβατή με τις ανάγκες τουέργου και τις ικανότητες της ομάδαςΕπικοινωνιακή ικανότητα: Για τη συνεχή επικοινωνία μεόλους τους εμπλεκόμενους για την εύρεση τωνβέλτιστων συμβιβασμών (trade-offs)Εμπειρία: Για να μπορούν να γίνουν καλά όλα ταπαραπάνω

Ενδεικτικά 43