Μάθημα «Υπηρεσίες Ηλεκτρονικής Υγείας» M. Σπανάκης, Μ. Τσικνάκης Εαρινό Εξάμηνο 2014 Μάθημα 1 Παρουσίαση Εργασίας και Εισαγωγή στην ανάλυση απαιτήσεων
Εισαγωγή Αρχική συζήτηση αναφορικά με την ανάλυση απαιτήσεων του συστήματος Βασικές έννοιες της Μηχανικής Απαιτήσεων (Requirements Engineering) Σημασία της στην όλη διαδικασία Διεθνείς εμπειρίες Εγχειρίδιο Προδιαγραφής Απαιτήσεων Περιεχόμενα Συζήτηση επί των απαιτήσεων του Συστήματος
Τι είναι αρχιτεκτονική ενός συστήματος Η αρχιτεκτονική είναι μια τυπική περιγραφή ενός πληροφοριακού συστήματος, που οργανώνεται με τρόπο που να υποστηρίζει την αιτιολογία (reasoning) σχετικά με τις δομικές ιδιότητες του συστήματος. Καθορίζει τα δομικά στοιχεία (components or building blocks) που συνθέτουν το συνολικό πληροφοριακό σύστημα, και Παρέχει ένα σχέδιο μέσω του οποίου μπορούν είτε να προμηθευτούν έτοιμα προϊόντα-υποσυστήματα είτε να αναπτυχθούν τα (υπο)συστήματα, που θα συνεργαστούν για την υλοποίηση του συνολικού συστήματος.
Πώς περιγράφουμε την αρχιτεκτονική ενός συστήματος Μία από τις δοκιμασμένες μεθοδολογίες είναι η γνωστή σαν 4+1 View Model P. Kruchten. The 4+1 View Model of Architecture. In IEEE Software, vol. 12, no. 6, November 1995, pp. 42-50, IEEE 1995 Μέσω της τεκμηρίωσης διαφόρων «όψεων»του συστήματος Μία όψη είναι οι περιπτώσεις χρήσης (Use Case view)
Τι καθοδηγεί την αρχιτεκτονική Απαιτήσεις & περιορισμοί (Requirements and Constraints) Απαιτήσεις Περιορισμοί - Constraints Συχνά αναφέρονται σαν Τεχνολογικοί περιορισμοί (technology constraints) Μη-λειτουργικές απαιτήσεις (non-functional requirements) Διάφορες όψεις
Γενικές Έννοιες Μάθημα 1 Παρουσίαση Εργασίας και Εισαγωγή στην ανάλυση απαιτήσεων 6
Μηχανική Απαιτήσεων (Requirements Engineering) Ιδέα για ένα Νέο προϊόν (Επίλυση κάποιου πρακτικού προβλήματος) Ανάλυση των απαιτήσεων (η διαδικασία ανάπτυξης των απαιτήσεων του συστήματος) Προδιαγραφή απαιτήσεων (ένα εγχειρίδιο που περιγράφει Τι θα πρέπει να υλοποιηθέι και όχι το Πως)
Τυπική διαδικασία (μεθοδολογία) ανάπτυξης συστημάτων λογισμικού Typical Software Development (Engineering) Process One cycle
The Standish report The figures for failure were equally disheartening in companies of all sizes. Only 9% of projects in large companies were successful. At 16.2% and 28% respectively, medium and small companies were somewhat more successful. A whopping 61.5% of all large company projects were challenged compared to 46.7% for medium companies and 50.4% for small companies. The most projects, 37.1%, were impaired and subsequently cancelled in medium companies, compared to 29.5% in large companies and 21.6% in small companies.
Τα λάθη κοστίζουν
Βασικοί Λόγοι Αποτυχίας Έργων Λογισμικού 11
Κατηγοριοποίηση της Μηχανικής Απαιτήσεων Μηχανική Απαιτήσεων Ανάπτυξη Απαιτήσεων Διαχείριση Απαιτήσεων Εξόρυξη Ανάλυση Προδιαγραφή Επιβεβαίωση
Τι είναι Απαίτηση σε ένα Έργο Λογισμικού Τρεις βασικές κατηγορίες απαιτήσεων: Λειτουργικές απαιτήσεις (functional requirements): Τι πρέπει να κάνει ένα σύστημα - Οι λειτουργίες του συστήματος Ορίζουν το λόγους ύπαρξης του συστήματος Μη-λειτουργικές απαιτήσεις (non-functional requirements): Πια χαρακτηριστικά πρέπει να έχει το σύστημα Ποιοτικά χαρακτηριστικά, ιδιότητες, κλπ. Ορίζουν το λόγους σύμφωνα με τους οποίους θα θεωρήσουμε το σύστημα επιτυχημένο Περιορισμοί (constraints): Απαιτήσεις που έχουν γενική εμβέλεια στο σύστημα Ουσιαστικά οι απαιτήσεις για ένα σύστημα υπάρχουν διότι είτε Η κατηγορία του προϊόντος τις απαιτεί, είτε Ο χρήστης τις θέλει
Χαρακτηριστικά Στοιχεία Απαιτήσεων Λογισμικού Σαφήνεια: Το νόημα και η σημασία είναι ορισμένα με σαφήνεια Συνέπεια: Μια απαίτηση δεν πρέπει να είναι ανακόλουθη με κάποια άλλη Πληρότητα: Η απαίτηση ορίζεται σε όλο της το εύρος (σχετίζεται με τη σαφήνεια) Επαληθευσιμότητα (verification): Η απαίτηση μπορεί να ελεγχθεί σε σχέση με την τελική υλοποίηση Ανεξαρτησία από τεχνολογικές αποφάσεις: Απαλλαγμένη από προκαταλήψεις που σχετίζονται με πιθανές σχεδιαστικές αποφάσεις που θα θέλαμε να πάρουμε Απαίτηση (τι θέλουμε το σύστημα να κάνει) Υλοποίηση (πως το σύστημα ικανοποιεί τις απαιτήσεις)
Τα κριτήρια που χρησιμοποιούμε για την επιβεβαίωση των απαιτήσεων περιλαμβάνουν: Επιβεβαίωση ορθότητας απαιτήσεων (Correctness): Το μοντέλο της απαίτησης είναι σωστό σε σχέση με την ιδέα που έχει ο χρήστης Επιβεβαίωση πληρότητας απαιτήσεων (Completeness): Όλες οι πιθανές χρήσεις και σενάρια του συστήματος έχουν καταγραφεί και μοντελοποιηθεί σαν απαιτήσεις και οι απαιτήσεις δεν είναι ανακόλουθες μεταξύ τους Επιβεβαίωση ρεαλιστικής υλοποίησης (Realism): Οι απαιτήσεις μπορούν να υλοποιηθούν με την διαθέσιμη τεχνολογία Επιβεβαίωση σχέσης υλοποιημένων λειτουργιών και μοντελοποιημένων απαιτήσεων (Traceability): Κάθε υλοποιημένη λειτουργία του συστήματος μπορεί να καθοριστεί σε σχέση με κάποια απαίτηση Επιβεβαίωση Απαιτήσεων (Requirements Validation)
Κέλυφος (Template) Απαίτησης Περιγράφει τα δομικά στοιχεία μιας απαίτησης Μονοσήμαντα ορισμένος κωδικός απαίτησης Τύπος απαίτησης Κωδικός σχετικής περίπτωσης χρήσης Συνοπτική περιγραφή Σκεπτικό: Γιατί η απαίτηση είναι απαραίτητη Πηγή: Ποιοι θέλουν την συγκεκριμένη απαίτηση Κριτήρια ικανοποιησιμότητας: Μια μετρική που θα μας βοηθήσει να επιβεβαιώσουμε ότι η τελική λύση ικανοποιεί την απαίτηση Σημασία / Σπουδαιότητα για τον χρήστη: Βαθμός που θέλει ο χρήστης να υλοποιηθεί η απαίτηση και βαθμός που ο χρήστης θα δυσαρεστηθεί εάν δεν ικανοποιηθεί η συγκεκριμένη απαίτηση Εξάρτηση / Συνάφεια από άλλες απαιτήσεις Αντίφαση με άλλες απαιτήσεις Σχετικό υλικό υποστήριξης Ιστορικά στοιχεία και διαχείριση αλλαγών της απαίτησης Σχετικό Template θα ανέβει στο eclass
Διαδικασία Εξόρυξης Απαιτήσεων Διαδικασία που απαιτεί οργάνωση και συνέπεια. Υπάρχουν διάφορες προσεγγίσεις στο θέμα Οι βασικοί συμμέτοχοι σε αυτή τη διαδικασία είναι οι: Χρήστες του συστήματος με γνώση του αντικειμένου της εφαρμογής Μηχανικοί λογισμικού με γνώση της μοντελοποίησης και επίλυσης του προβλήματος Το αντικείμενο αυτής της διαδικασίας είναι να γεφυρώσουμε το σημασιολογικό χάσμα ανάμεσα στους χρήστες του συστήματος και στους σχεδιαστές του συστήματος. Αυτό επιτυγχάνεται με τη συγγραφή Σεναρίων Λειτουργίας και Περιπτώσεων Χρήσης: Σενάριο Λειτουργίας: Συγκεκριμένο παράδειγμα λειτουργίας του συστήματος και η αλληλεπίδρασή του με άλλα συστήματα Περίπτωση Χρήσης: Ορίζει και περιγράφει μια κατηγορία σεναρίων
Σενάρια σαν Μέθοδος Εξόρυξης Απαιτήσεων Σενάριο: Περιγραφή μιας συγκεκριμένης περίπτωσης λειτουργίας του συστήματος Τύποι Σεναρίων: Τρέχοντα: Περιγράφουν λειτουργίες του συστήματος στην τρέχουσά του μορφή Μελλοντικά: Περιγράφουν πιθανές μελλοντικές λειτουργίες του συστήματος Αξιολόγησης: Περιγράφουν λειτουργίες με τις οποίες θα αξιολογηθεί το σύστημα Επιμόρφωσης: Περιγράφουν τα βήματα με τα οποίες θα επιμορφωθεί για τις λειτουργίες του συστήματος ένας νέος χρήστης Εύρεση Σεναρίων Ρωτάμε τις παρακάτω ερωτήσεις: Ποιες είναι οι βασικές λειτουργίες του συστήματος Ποια δεδομένα θα παράγουν, τροποποιήσουν ή θα αποθηκεύσουν οι «χρήστες» (δράστες) του συστήματος Παρατηρούμε τους χρήστες να διεκπεραιώνουν μια εργασία σχετική με το σύστημα Σύσκεψη για ανταλλαγή ιδεών ανάμεσα στους αναλυτές και τους χρήστες
Περιπτώσεις Χρήσης Περίπτωση Χρήσης (Use Case) Μια περίπτωση χρήσης ορίζει και περιγράφει την αλληλεπίδραση ανάμεσα στους Δράστες (actors) και Συγκεκριμένα σημεία της εφαρμογής (υπηρεσίες του συστήματος) Δηλαδή μια περίπτωση χρήσης περιγράφει συστηματικά και μεθοδικά πως μια εφαρμογή θα χρησιμοποιηθεί σε κάποια συγκεκριμένη κατηγορία σεναρίων Πολλές περιπτώσεις χρήσεις καλύπτουν τελικά όλες τις απαιτήσεις και την επιθυμητή συμπεριφορά της εφαρμογής Έχουμε σενάρια τα οποία είναι σενάρια ομαλής λειτουργίας του συστήματος, και παθολογικά σενάρια που ορίζουν ακραίες και μη ομαλές καταστάσεις του συστήματος 19
Παράδειγμα Περίπτωσης Χρήσης: Αλλαγή Ώρας Πτήσης Δράστες: ταξιδιώτης, βάση δεδομένων, σύστημα κράτησης θέσεων Αεροπορικής Εταιρίας Προαπαιτούμενα (Preconditions): Ο Ταξιδιώτης έχει ήδη εγγραφεί στο σύστημα και έχει επιλέξει «αλλαγή ταξιδιού» Βασική Πορεία Χρήσης: Το σύστημα ανακτά τις πληροφορίες του λογαριασμού και τη πτήση (πτήσεις) του ταξιδιώτη από τη βάση δεδομένων Το σύστημα ρωτά τον ταξιδιώτη να επιλέξει κάποιο συγκεκριμένη πτήση; Ο ταξιδιώτης επιλέγει συγκεκριμένη πτήση Το σύστημα ρωτά τον ταξιδιώτη για την προτεινόμενη νέα ώρα αναχώρησης; Ο ταξιδιώτης δίνει την συγκεκριμένη πληροφορία Εάν η πτήση είναι διαθέσιμη... Το σύστημα παρουσιάζει τη περίληψη της συναλλαγής. Εναλλακτικές πορείες χρήσης: Εάν η πτήση δεν είναι διαθέσιμη τότε
Περιεχόμενα Εγχειριδίου Προδιαγραφής Απαιτήσεων Σκοπός του συστήματος Κατηγορίες χρηστών (stakeholders) Εμβέλεια του συστήματος (τι είναι εντός και τι είναι εκτός του συστήματος, και σημεία δι-επαφής με άλλα συστήματα) Περιορισμοί Σχετικά δεδομένα Παραδοχές Απαιτήσεις Λειτουργικές Μη-λειτουργικές
Στόχοι για το επόμενο μάθημα Δημιουργία της λίστας των βασικών απαιτήσεων του συστήματος (δείτε το Slide 17) Προσπάθεια για διεξοδική ανάλυση 1-2 από τις βασικές αυτές απαιτήσεις (δείτε το Slide 22)
Q&A