ΑΡΙΣΤΟΤΕΛΕΙΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΘΕΣΣΑΛΟΝΙΚΗΣ ΣΧΟΛΗ ΘΕΤΙΚΩΝ ΕΠΙΣΤΗΜΩΝ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ

Transcript

1 ΑΡΙΣΤΟΤΕΛΕΙΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΘΕΣΣΑΛΟΝΙΚΗΣ ΣΧΟΛΗ ΘΕΤΙΚΩΝ ΕΠΙΣΤΗΜΩΝ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΔΙΑΤΜΗΜΑΤΙΚΟ ΠΡΟΓΡΑΜΜΑ ΜΕΤΑΠΤΥΧΙΑΚΩΝ ΣΠΟΥΔΩΝ «ΠΛΗΡΟΦΟΡΙΚΗ ΚΑΙ ΔΙΟΙΚΗΣΗ» ΔΙΠΛΩΜΑΤΙΚΗ ΕΡΓΑΣΙΑ «Εφαρμογή Τεχνολογίας Απαιτήσεων για την προδιαγραφή ενός Παρατηρητηρίου Ποιότητας Λογισμικού Ανοιχτού Κώδικα» Χατζηβούλγαρη Αναστασία Επιβλέπων Καθηγητής: Σταμέλος Ιωάννης Θεσσαλονίκη 2007

2 Αυτή η διπλωματική εργασία δε θα μπορούσε να ολοκληρωθεί χωρίς την καθοδήγηση του επιβλέποντα επίκουρου καθηγητή, Ι Σταμέλου και τη βοήθεια του διδάκτορα και συνεργάτη του SWENG, Ι Αντωνιάδη 2

3 ΠΕΡΙΕΧΟΜΕΝΑ 1 Εισαγωγή 5 2 Τεχνικές και Προβλήματα της Τεχνολογίας Απαιτήσεων Λογισμικού6 21 Εισαγωγή στην Τεχνολογία Απαιτήσεων Λογισμικού Λειτουργικές και μη Λειτουργικές Απαιτήσεις Λειτουργικές απαιτήσεις Μη λειτουργικές απαιτήσεις Απαιτήσεις Πεδίου Απαιτήσεις Χρήστη Απαιτήσεις Συστήματος16 22 Δραστηριότητες Διαδικασίας Τεχνολογίας Απαιτήσεων Λογισμικού Μελέτη σκοπιμότητας του συστήματος Εξαγωγή και ανάλυση των απαιτήσεων Viewpoint-oriented εξαγωγή Σενάρια Προδιαγραφή των απαιτήσεων και έγγραφο τεκμηρίωσης Επικύρωση των απαιτήσεων30 3 Τεχνικές Αξιολόγησης Ιεραρχική Ανάλυση Αποφάσεων Analytic Hierarchy Process (AHP) Aggregate Ranking Measures (ARM) 34 4 Απαιτήσεις Παρατηρητηρίου Ποιότητας Λογισμικού Ανοιχτού Κώδικα35 41 Χαρακτηριστικά Λογισμικού Ανοιχτού Κώδικα35 42 Τεχνολογία Απαιτήσεων Λογισμικού Ανοιχτού Κώδικα Παρατηρητήριο Ποιότητας Λογισμικού Ανοιχτού Κώδικα Σκοπός του Συστήματος Χρήστες του Συστήματος 49 1 Γενικοί Χρήστες που αναζητούν πληροφορίες για projecs ΛΑΚ50 2 Developers ΛΑΚ51 3 Σύμβουλοι IT 53 4 IT Managers54 5 Ερευνητές55 6 Διαχειριστής Συστήματος Λειτουργικές Απαιτήσεις Παρατηρητηρίου Ποιότητας Λογισμικού Ανοιχτού Κώδικα Αίτημα/ Παρουσίαση Αξιολόγησης Κώδικα Έργων για τα οποία ο πηγαίος κώδικας είναι διαθέσιμος στην τοπική λανθάνουσα μνήμη (cache) Αίτημα Αξιολόγησης Κώδικα Έργων για τα οποία ο πηγαίος κώδικας δεν είναι διαθέσιμος στην τοπική λανθάνουσα μνήμη (cache) Αξιολόγηση Μελλοντικής Εξέλιξης Έργων Εμφάνιση Αξιολόγησης Μελλοντικής Εξέλιξης Έργων Στατιστικά σφαλμάτων Στατιστικά για Developers Συνεργατική βαθμολόγηση Εμφάνιση σχολίων και βαθμολόγησης άλλων χρηστών Σύγκριση και αντιπαράθεση των έργων ΛΑΚ Υποστήριξη Δημιουργίας Νέων Plug-ins Παροχή ειδοποιήσεων (alert) στο χρήστη Εγγραφή Χρηστών94 3

4 4413 Εξουσιοδότηση Χρηστών (Authorisation) και Διαχείριση Λογαριασμού 98 5 Αξιολόγηση Απαιτήσεων Παρατηρητηρίου Ποιότητας Λογισμικού Ανοιχτού Κώδικα101 6 Επίλογος Συμπεράσματα Βιβλιογραφία 105 Παράρτημα Α108 Παράρτημα Β126 4

5 1 Εισαγωγή Όλα τα έργα ανάπτυξης λογισμικού ξεκινούν από τον ορισμό ενός προβλήματος του πραγματικού κόσμου Ανεξάρτητα από τον τρόπο με τον οποίο ο ορισμός αυτός αναφέρεται στις διάφορες μεθοδολογίες, στα μοντέλα κύκλου ζωής και στα πρότυπα που χρησιμοποιούνται στην ανάπτυξη του λογισμικού, πρόκειται ουσιαστικά για το ίδιο πράγμα: την περιγραφή της ανάγκης των χρηστών για κατασκευή λογισμικού που θα πραγματοποιεί κάποιες επιθυμητές σε αυτούς λειτουργίες Η Τεχνολογία Λογισμικού πρέπει να υποστηρίζει τους κατασκευαστές στην παραγωγή λογισμικού που ικανοποιεί τις απαιτήσεις των χρηστών Αφήνοντας, προς το παρόν, κατά μέρος τις άλλες απαιτήσεις, όπως η τεχνική ορθότητα, η αποφυγή σφαλμάτων και η κατασκευή εντός χρονοδιαγράμματος και προϋπολογισμού, θα εξεταστεί εδώ το θέμα της ικανοποίησης των απαιτήσεων των χρηστών Υπενθυμίζουμε δύο ουσιώδη χαρακτηριστικά της δομημένης ανάλυσης και σχεδίασης: Δεν είναι δυνατόν να προχωρήσουμε στον ορισμό της δομής προγράμματος, ακόμη και για ένα μικρό τμήμα της εφαρμογής λογισμικού, αν δεν έχουμε πλήρη ορισμό των λειτουργικών απαιτήσεων και το διάγραμμα ροής δεδομένων που αφορούν το τμήμα αυτό της εφαρμογής Οποιαδήποτε τροποποίηση των απαιτήσεων των χρηστών είναι επίπονη και συνήθως επιφέρει αναταράξεις Η τελευταία επαφή του κατασκευαστή με τις απαιτήσεις των χρηστών είναι η αποτύπωσή τους στο «έγγραφο προδιαγραφών των απαιτήσεων από το λογισμικό» και στο διάγραμμα ροής δεδομένων Από το σημείο εκείνο και μετά οι απαιτήσεις «κλειδώνουν» και η συνέχεια της ανάπτυξης γίνεται χωρίς τα συστατικά λογισμικού που παράγονται να έχουν εμφανή σύνδεση με τις συγκεκριμένες απαιτήσεις, στην ικανοποίηση των οποίων στοχεύουν Κανένα από τα δύο αυτά σημεία δε χαρακτηρίζει την ανάπτυξη του λογισμικού ανοιχτού κώδικα Η φιλοσοφία του λογισμικού ανοιχτού κώδικα είναι περισσότερο ελαστική απ' ό,τι η δομημένη [14] Στη συγκεκριμένη εργασία θα γίνει μια αναφορά στις τεχνικές και τα προβλήματα της τεχνολογίας απαιτήσεων λογισμικού, θα αναφερθούν κάποιες τεχνικές αξιολόγησης των απαιτήσεων, θα γίνει μια περιγραφή των 5

6 διαδικασιών της τεχνολογίας απαιτήσεων στο Ανοιχτό Λογισμικό και θα περιγραφεί η διαδικασία και οι ίδιες οι απαιτήσεις ενός ανοιχτού λογισμικού που αναπτύσσεται στα πλαίσια του IST, ενός παρατηρητηρίου ποιότητας Λογισμικού Ανοιχτού Κώδικα 2 Τεχνικές και Προβλήματα της Τεχνολογίας Απαιτήσεων Λογισμικού 21 Εισαγωγή στην Τεχνολογία Απαιτήσεων Λογισμικού Τα προβλήματα που πρέπει να λύσουν οι τεχνολόγοι λογισμικού είναι συχνά πολύ πολύπλοκα Η κατανόηση της φύσης των προβλημάτων μπορεί να είναι πολύ δύσκολη, ειδικά στην περίπτωση εκείνη που το σύστημα είναι καινούριο Συνεπώς είναι δύσκολο να υλοποιήσουν ακριβώς ότι χρειάζεται το σύστημα Η περιγραφή των υπηρεσιών και των περιορισμών είναι οι απαιτήσεις για το σύστημα και η διαδικασία η οποία ακολουθείται για την εύρεση, την ανάλυση, την καταγραφή και τον έλεγχο αυτών των υπηρεσιών και των περιορισμών λέγεται τεχνολογία απαιτήσεων λογισμικού Επιπλέον, η τεχνολογία απαιτήσεων λογισμικού είναι μια διαδικασία που περιλαμβάνει όλες εκείνες τις ενέργειες που απαιτούνται για τη δημιουργία και τη συντήρηση του εγγράφου απαιτήσεων ενός συστήματος Ο όρος «απαίτηση» δεν χρησιμοποιείται στη βιομηχανία λογισμικού με ένα συγκεκριμένο τρόπο Σε ορισμένες περιπτώσεις μια απαίτηση είναι μια υψηλού επιπέδου, αφηρημένη αναφορά μιας υπηρεσίας που το σύστημα θα έπρεπε να παρέχει ή ένας περιορισμός του συστήματος Στο άλλο άκρο, είναι ένας λεπτομερείς, μαθηματικός ορισμός μιας λειτουργίας του συστήματος Αυτό οφείλεται γιατί οι απαιτήσεις μπορούν να απευθυνθούν σε άτομα με διαφορετικό υπόβαθρο γνώσεων και διαφορετικά ενδιαφέροντα Μερικά από τα προβλήματα που παρουσιάζονται κατά τη διαδικασία της τεχνολογίας απαιτήσεων είναι αποτέλεσμα της αποτυχίας του διαχωρισμού μεταξύ αυτών των διαφορετικών επιπέδων περιγραφής Με τον όρο 6

7 απαιτήσεις χρήστη εννοούμε τις αφηρημένες απαιτήσεις υψηλού επιπέδου και με τον όρο απαιτήσεις συστήματος αναφερόμαστε στη λεπτομερή περιγραφή του συστήματος Μαζί με αυτά τα έγγραφα που διαφέρουν ως προς τη λεπτομέρεια θα πρέπει να παραχθεί και ένα ακόμη πιο λεπτομερές έγγραφο (η προδιαγραφή της σχεδίασης του λογισμικού) που θα γεφυρώσει την τεχνολογία απαιτήσεων με τις διαδικασίες σχεδίασης Οι απαιτήσεις χρήστη, οι απαιτήσεις συστήματος και η προδιαγραφή της σχεδίασης λογισμικού μπορούν να οριστούν ως εξής: Οι απαιτήσεις του χρήστη είναι δηλώσεις σε φυσική γλώσσα και διαγράμματα για τις υπηρεσίες που αναμένεται να προσφέρει το σύστημα και περιορισμοί υπό τους οποίους το σύστημα θα πρέπει να λειτουργεί Οι απαιτήσεις συστήματος προσδιορίζουν τις υπηρεσίες συστήματος και τους περιορισμούς με μεγαλύτερη λεπτομέρεια Το έγγραφο απαιτήσεων του συστήματος, που κάποιες φορές λέγεται προσδιορισμός λειτουργιών, πρέπει να είναι συγκεκριμένο και ακριβές Μπορεί να αποτελέσει και το συμβόλαιο μεταξύ του αγοραστή του συστήματος και του developer Η προδιαγραφή της σχεδίασης του λογισμικού είναι μια αφηρημένη περιγραφή της σχεδίασης του λογισμικού και αποτελεί βάση για τον περισσότερο λεπτομερή σχεδιασμό και την υλοποίηση Αυτό το έγγραφο προδιαγραφής προσθέτει περισσότερες λεπτομέρειες από ότι η προδιαγραφή των απαιτήσεων του συστήματος Τα διαφορετικά επίπεδα της προδιαγραφής του συστήματος είναι χρήσιμα διότι μεταδίδουν πληροφορίες για το σύστημα σε διαφορετικούς αναγνώστες Οι απαιτήσεις χρήστη θα πρέπει να γράφονται για πελάτες και για τα στελέχη διοίκησης που δεν γνωρίζουν τεχνικές λεπτομέρειες του συστήματος Οι προδιαγραφή των απαιτήσεων συστήματος θα πρέπει να στοχεύει στο ανώτερο τεχνικό προσωπικό και στους project managers Και πάλι πρόκειται για ένα έγγραφο που θα χρησιμοποιηθεί τόσο από τον πελάτη όσο και από τον εργολάβο Οι τελικοί χρήστες του συστήματος μπορούν να διαβάσουν και τα δύο έγγραφα Τέλος, η προδιαγραφή της σχεδίασης του χρήστη είναι ένα έγγραφο που είναι προσανατολισμένο στην υλοποίηση Θα πρέπει να γραφτεί για τους τεχνολόγους λογισμικού που θα αναπτύξουν το σύστημα [11] 7

8 211 Λειτουργικές και μη Λειτουργικές Απαιτήσεις Οι απαιτήσεις συστήματος συχνά κατηγοριοποιούνται σε λειτουργικές, μηλειτουργικές και απαιτήσεις πεδίου 1 Λειτουργικές Απαιτήσεις: Αυτές είναι οι δηλώσεις υπηρεσιών που θα παρέχει το σύστημα, πως το σύστημα θα αντιδρά σε συγκεκριμένες εισόδους δεδομένων και πως το σύστημα θα συμπεριφέρεται σε συγκεκριμένες καταστάσεις Σε ορισμένες περιπτώσεις, οι λειτουργικές απαιτήσεις μπορούν επίσης να αναφέρουν σαφώς τι δε θα κάνει το σύστημα 2 Μη λειτουργικές απαιτήσεις: Αυτές είναι περιορισμοί στις υπηρεσίες ή στις λειτουργίες που θα προσφέρει το σύστημα Περιλαμβάνουν χρονικούς περιορισμούς, περιορισμούς στην διαδικασία ανάπτυξης, πρότυπα που θα χρησιμοποιηθούν κτλ 3 Απαιτήσεις πεδίου: Αυτές είναι απαιτήσεις που προκύπτουν από το πεδίο που θα εφαρμοστεί το σύστημα και αντικατοπτρίζουν χαρακτηριστικά αυτού του πεδίου Μπορούν παράλληλα να ανήκουν στις προηγούμενες δύο κατηγορίες, δηλαδή να είναι λειτουργικές ή μηλειτουργικές Στην πραγματικότητα, η διάκριση μεταξύ αυτών των διαφορετικών τύπων των απαιτήσεων δεν είναι τόσο ξεκάθαρη όσο φαίνεται με τους ορισμούς Για παράδειγμα μια απαίτηση χρήστη για ασφάλεια φαίνεται να είναι μια μηλειτουργική απαίτηση Όμως όταν αυτή θα αναπτυχθεί, θα οδηγήσει σε άλλες απαιτήσεις που είναι ξεκάθαρα λειτουργικές, όπως η ανάγκη να συμπεριληφθεί στο σύστημα η εξουσιοδότηση του χρήστη Επομένως, ενώ η κατηγοριοποίηση των απαιτήσεων διευκολύνει τους αναλυτές είναι στην πραγματικότητα μια τεχνητή διάκριση 12] 2111 Λειτουργικές απαιτήσεις Οι λειτουργικές απαιτήσεις για ένα σύστημα περιγράφουν τις λειτουργίες ή τις υπηρεσίες που αναμένεται να παρέχει το σύστημα Αυτές εξαρτώνται από τον τύπο του λογισμικού που αναπτύσσεται και τους αναμενόμενους χρήστες του λογισμικού Όταν μιλάμε για απαιτήσεις χρήστη, περιγράφουμε το σύστημα με γενικό τρόπο αλλά οι λειτουργικές απαιτήσεις περιγράφουν τη λειτουργία του συστήματος με λεπτομέρειες, τις εισόδους και τις εξόδους, τις εξαιρέσεις κτλ 8

9 Οι λειτουργικές απαιτήσεις ενός λογισμικού μπορούν να περιγραφούν με διάφορους τρόπους Πολλά προβλήματα της τεχνολογίας λογισμικού προκύπτουν από ανακρίβειες στην προδιαγραφή των απαιτήσεων Είναι φυσικό για έναν developer του συστήματος να μεταφράζει μια ασαφή απαίτηση με τέτοιο τρόπο ώστε να απλοποιεί την υλοποίηση της Συχνά όμως δεν είναι αυτό που θέλει ο πελάτης Σε αυτή την περίπτωση θα πρέπει να δημιουργηθούν νέες απαιτήσεις και να γίνουν αλλαγές στο σύστημα Βέβαια αυτό καθυστερεί την παράδοση του συστήματος και αυξάνει το κόστος Κατ αρχήν, η προδιαγραφή των απαιτήσεων ενός συστήματος πρέπει να είναι πλήρης και συνεπής Πληρότητα σημαίνει ότι καθορίζονται όλες οι υπηρεσίες που απαιτούνται από το χρήστη Συνέπεια σημαίνει ότι οι απαιτήσεις δε θα πρέπει να έχουν αντίθετους ορισμούς Στην πράξη, για μεγάλα και πολύπλοκα συστήματα, είναι πρακτικά αδύνατο να επιτευχθεί πληρότητα και συνέπεια για τις απαιτήσεις Αυτό συμβαίνει λόγω της εγγενούς πολυπλοκότητας του συστήματος και λόγω των διαφορετικών «απόψεων» που έχουν αντιφατικές ανάγκες Αυτές οι αντιφάσεις μπορεί να μην είναι εμφανείς όταν οι απαιτήσεις προσδιορίζονται για πρώτη φορά Τα προβλήματα εμφανίζονται μετά από βαθύτερη ανάλυση Καθώς τα προβλήματα ανακαλύπτονται μέσω αναθεωρήσεων ή σε αργότερες φάσεις του κύκλου ζωής, τα προβλήματα στο έγγραφο των απαιτήσεων πρέπει να διορθωθούν 2112 Μη λειτουργικές απαιτήσεις Οι μη λειτουργικές απαιτήσεις, όπως δηλώνει και το όνομά τους είναι εκείνες οι απαιτήσεις οι οποίες δεν σχετίζονται άμεσα με συγκεκριμένες λειτουργίες που θα προσφέρει το σύστημα Μπορεί να έχουν σχέση με επείγουσες ιδιότητες του συστήματος όπως με την αξιοπιστία, το χρόνο απόκρισης και την χωρητικότητα αποθήκευσης Εναλλακτικά, μπορούν να καθορίζουν περιορισμούς του συστήματος που σχετίζονται για παράδειγμα με τις δυνατότητες των συσκευών εισόδου εξόδου και την αναπαράσταση των δεδομένων που χρησιμοποιούνται στη διεπαφή χρήστη 9

10 Πολλές μη λειτουργικές απαιτήσεις σχετίζονται με το σύστημα ως σύνολο παρά με μεμονωμένα χαρακτηριστικά του Αυτό σημαίνει ότι είναι περισσότερο κρίσιμες από τις μεμονωμένες λειτουργικές απαιτήσεις Ενώ η αποτυχία της υλοποίησης μιας λειτουργικής απαίτησης μπορεί να υποβαθμίσει το σύστημα, η αποτυχία μιας μη λειτουργικής απαίτησης του συστήματος μπορεί να κάνει όλο το σύστημα άχρηστο Παρόλα αυτά, οι μη-λειτουργικές απαιτήσεις δεν σχετίζονται πάντα με το σύστημα που θα αναπτυχθεί Μερικές μη λειτουργικές απαιτήσεις μπορούν να περιορίζουν την διαδικασία που θα μπορούσε να χρησιμοποιηθεί για την ανάπτυξη του συστήματος Παραδείγματα απαιτήσεων διαδικασίας περιλαμβάνουν την προδιαγραφή των προτύπων ποιότητας που θα πρέπει να χρησιμοποιηθούν για μια διαδικασία, την προδιαγραφή ότι η σχεδίαση θα πρέπει να παραχθεί με τη χρήση ενός συγκεκριμένου εργαλείου CASE και την περιγραφή της διαδικασίας που θα πρέπει να ακολουθηθεί Οι μη-λειτουργικές απαιτήσεις προκύπτουν από τις ανάγκες του χρήστη, λόγω περιορισμού του προϋπολογισμού, λόγω οργανωτικών πολιτικών, λόγω της ανάγκης συνεργασίας με άλλα συστήματα λογισμικού ή υλικού ή λόγω εξωτερικών παραγόντων όπως κανονισμών ασφάλειας, νομοθεσίας κτλ Στην Εικόνα 1 εμφανίζονται ταξινομημένοι διαφορετικοί τύποι μη λειτουργικών απαιτήσεων που μπορούν προκύψουν 1 Απαιτήσεις προϊόντος: Αυτές οι απαιτήσεις καθορίζουν τη συμπεριφορά του προϊόντος Παραδείγματα περιλαμβάνουν τις απαιτήσεις απόδοσης σχετικά με το πόσο γρήγορα θα πρέπει να ανταποκρίνεται το σύστημα και πόση μνήμη απαιτεί, απαιτήσεις αξιοπιστίας που καθορίζουν το αποδεκτό ρυθμό αποτυχίας, απαιτήσεις μεταφερσιμότητας και ευχρηστίας 2 Οργανωτικές Απαιτήσεις: Αυτές προκύπτουν από τις πολιτικές και τις διαδικασίες που ακολουθούνται στις εταιρείες των πελατών και των developers Παραδείγματα περιλαμβάνουν πρότυπες διαδικασίες οι οποίες θα πρέπει να χρησιμοποιούνται, απαιτήσεις υλοποίησης όπως η γλώσσα προγραμματισμού ή η μέθοδος σχεδίασης που θα χρησιμοποιηθεί, απαιτήσεις παράδοσης που καθορίζουν πότε το προϊόν και η τεκμηρίωση του είναι έτοιμα να παραδοθούν 10

11 3 Εξωτερικές απαιτήσεις: Αυτή η ευρεία επικεφαλίδα καλύπτει όλες τις απαιτήσεις που προκύπτουν από εξωτερικούς παράγοντες σε σχέση με το σύστημα και τη διαδικασία ανάπτυξης Αυτές περιλαμβάνουν απαιτήσεις συνεργασίας που καθορίζουν πως αντιδρά το σύστημα με συστήματα άλλων οργανισμών, νομοθετικές απαιτήσεις που θα πρέπει να ακολουθηθούν για να διασφαλίσουν την νομιμότητα του συστήματος, και ηθικές απαιτήσεις Οι ηθικές απαιτήσεις είναι απαιτήσεις που υπάρχουν σε ένα σύστημα για να διασφαλιστεί η αποδοχή του από τους χρήστες και το γενικό κοινό Ένα συχνό πρόβλημα με τις μη λειτουργικές απαιτήσεις είναι ότι μερικές φορές είναι δύσκολο να επαληθευτούν Μπορεί να είναι γραμμένες για να απεικονίζουν στόχους του πελάτη όπως η ευκολία στη χρήση, η ικανότητα του συστήματος να ανανήπτει από λάθη ή η γρήγορη απόκριση Αυτές οι απαιτήσεις προκαλούν προβλήματα στους developers του συστήματος καθώς αφήνουν μεγάλα περιθώρια κατανόησης με αποτέλεσμα να δημιουργούνται διαφωνίες κατά την παράδοση του συστήματος Ιδανικά, οι μη λειτουργικές απαιτήσεις θα έπρεπε να εκφράζονται ποσοτικά, με τη χρήση μετρικών που μπορούν να μετρηθούν αντικειμενικά (Πίνακας 1) 11

12 Μη-λειτουργικές Απαιτήσεις Απαιτήσεις Προϊόντος Οργανωτικές Απαιτήσεις Εξωτερικές Απαιτήσεις Απαιτήσεις Ευχρηστίας Απαιτήσεις Παράδοσης Απαιτήσεις Υλοποίησης Απαιτήσεις Συνεργασίας Απαιτήσεις Αποδοτικότητας Απαιτήσεις Προτύπων Ηθικές Απαιτήσεις Απαιτήσεις Αξιοπιστίας Νομικές Απαιτήσεις Απαιτήσεις Μεταφερσιμότητας Απαιτήσεις προστασίας προσωπικών δεδομένων Απαιτήσεις Ασφάλειας Εικόνα 1 Τύποι μη λειτουργικών απαιτήσεων 12

13 Πίνακας 1 Μετρικές για τον καθορισμό μη λειτουργικών απαιτήσεων Ιδιότητα Μετρική Ταχύτητα (Speed) Επεξεργασμένες συναλλαγές/ δευτερόλεπτο Χρήστης/ Χρόνος απόκρισης γεγονότος Ρυθμός ανανέωσης της οθόνης Μέγεθος (Size) KB, Αριθμός chip RAM Ευκολία Χρήσης (Ease of Use) Χρόνος εκμάθησης Αριθμός βοηθητικών πλαισίων Αξιοπιστία (Reliability) Μέσος χρόνος αποτυχίας Πιθανότητα μη διαθεσιμότητας Ρυθμός εμφάνισης αποτυχίας Διαθεσιμότητα Ρωμαλεότητα (Robustness) Χρόνος που απαιτείται για την επανεκκίνηση μετά την αποτυχία Ποσοστό γεγονότων που προκαλούν αποτυχία Πιθανότητα φθοράς δεδομένων σε περίπτωση αποτυχίας Μεταφερσιμότητα (Portability) Αριθμός των συστημάτων - στόχου Οι μετρήσεις μπορούν να γίνουν κατά τη διάρκεια του ελέγχου του συστήματος για να καθορίσουν αν το σύστημα ανταποκρίνεται σε αυτές τις απαιτήσεις ή όχι Στην πράξη, η προδιαγραφή των ποσοτικών απαιτήσεων είναι συχνά δύσκολη Οι πελάτες μπορεί να μην είναι δυνατό να μεταφράσουν τους σκοπούς τους σε ποσοτικές απαιτήσεις, για κάποιους σκοπούς όπως η συντηρησιμότητα δεν υπάρχουν μετρικές που μπορούν να χρησιμοποιηθούν, το κόστος της αντικειμενικής επαλήθευσης των ποσοτικών μη λειτουργικών απαιτήσεων μπορεί να είναι υψηλό Επομένως, τα έγγραφα απαιτήσεων συχνά θα περιλαμβάνουν στόχους μαζί με απαιτήσεις Αυτοί οι στόχοι μπορεί να είναι χρήσιμοι στους developers διότι θα δίνουν περισσότερα στοιχεία για τις προτεραιότητες των πελατών Παρόλα αυτά, οι πελάτες θα πρέπει να 13

14 ενημερωθούν ότι μπορεί οι στόχοι τους να μην κατανοηθούν πλήρως και ότι δε θα μπορέσουν να επαληθευτούν αντικειμενικά Οι μη λειτουργικές απαιτήσεις συχνά συγκρούονται και αλληλεπιδρούν με λειτουργικές απαιτήσεις άλλων συστημάτων Τυπικά, οι λειτουργικές και οι μη-λειτουργικές απαιτήσεις θα πρέπει να διαφοροποιούνται σε ένα έγγραφο απαιτήσεων Στην πράξη, αυτό είναι κάτι πολύ δύσκολο Αν οι μη λειτουργικές απαιτήσεις δηλώνονται ξεχωριστά από τις λειτουργικές απαιτήσεις, είναι συχνά δύσκολο να γίνουν αντιληπτές οι μεταξύ τους σχέσεις Αν δηλώνονται μαζί, τότε είναι δύσκολο να διαχωριστούν οι λειτουργικές και οι μη λειτουργικές και να αναγνωριστούν εκείνες οι απαιτήσεις που σχετίζονται με το συνολικό σύστημα Επομένως, θα πρέπει να βρεθεί μια ισορροπία που εξαρτάται από τον τύπο του συστήματος Οι απαιτήσεις που σχετίζονται ξεκάθαρα με επείγουσες ιδιότητες του συστήματος πρέπει να τονίζονται ρητά Αυτό μπορεί να επιτευχθεί βάζοντας τες σε ξεχωριστή ενότητα στο έγγραφο των απαιτήσεων ή διαχωρίζοντάς τες με κάποιο τρόπο από τις υπόλοιπες απαιτήσεις του συστήματος 2113 Απαιτήσεις Πεδίου Οι απαιτήσεις πεδίου προκύπτουν από το πεδίο του συστήματος παρά από συγκεκριμένες ανάγκες των χρηστών Μπορούν να αποτελούν νέες λειτουργικές απαιτήσεις, περιορισμούς στις ήδη υπάρχουσες λειτουργικές απαιτήσεις ή να καθορίζουν πώς θα διεξάγονται συγκεκριμένοι υπολογισμοί Οι απαιτήσεις πεδίου είναι σημαντικές γιατί συχνά αντικατοπτρίζουν τα θεμέλια του πεδίου της εφαρμογής Αν αυτές οι απαιτήσεις δεν ικανοποιούνται, τότε είναι αδύνατο το σύστημα να δουλεύει ικανοποιητικά Συνήθως εκφράζονται χρησιμοποιώντας γλώσσα σχετική με το πεδίο εφαρμογής και είναι δύσκολο να κατανοηθεί από τους μηχανικούς λογισμικού Οι ειδικοί σε ένα πεδίο μπορεί να μην συμπεριλάβουν στις απαιτήσεις πληροφορίες που θεωρούνται δεδομένες για αυτούς Παρόλα αυτά, αυτό δε σημαίνει ότι οι πληροφορίες αυτές είναι γνωστές και στους προγραμματιστές του συστήματος με αποτέλεσμα να μην υλοποιούνται οι απαιτήσεις με ικανοποιητικό τρόπο 14

15 212 Απαιτήσεις Χρήστη Οι απαιτήσεις χρήστη για ένα σύστημα θα πρέπει να περιγράφουν τις λειτουργικές και τις μη-λειτουργικές απαιτήσεις έτσι ώστε να είναι κατανοητές από τους χρήστες του συστήματος που δεν έχουν λεπτομερείς τεχνικές γνώσεις Θα πρέπει να προδιαγράφουν την εξωτερική συμπεριφορά του συστήματος και θα πρέπει να αποφεύγουν όσο είναι δυνατό τα χαρακτηριστικά της σχεδίασης του συστήματος Επομένως, οι απαιτήσεις του χρήστη δε θα πρέπει να ορίζονται με τη χρήση ενός μοντέλου υλοποίησης Οι απαιτήσεις χρήστη θα πρέπει να γράφονται χρησιμοποιώντας φυσική γλώσσα, φόρμες και απλά διαισθητικά διαγράμματα Παρόλα αυτά, ποικίλα προβλήματα μπορούν να παρουσιαστούν όταν οι απαιτήσεις γράφονται σε φυσική γλώσσα: 1 Έλλειψη διαύγειας: Είναι μερικές φορές δύσκολο να χρησιμοποιηθεί η φυσική γλώσσα με ακριβή και σαφή τρόπο χωρίς να γίνει το έγγραφο δύσκολο στην ανάγνωση και φλύαρο 2 Σύγχυση Απαιτήσεων: Οι λειτουργικές, μη λειτουργικές απαιτήσεις, στόχοι συστήματος και πληροφορίες σχεδίασης μπορεί να μην είναι ξεκάθαρα διαχωρισμένα 3 Συγχώνευση Απαιτήσεων: Διαφορετικές απαιτήσεις μπορούν να εκφραστούν ως μία Μια καλή πρακτική επιτάσσει τον διαχωρισμό των απαιτήσεων χρήστη από τις λεπτομερείς απαιτήσεις συστήματος σε ένα έγγραφο απαιτήσεων Σε αντίθετη περίπτωση, οι μη τεχνικά καταρτιζόμενοι αναγνώστες των απαιτήσεων χρήστη μπορεί να κατακλυστούν από λεπτομέρειες που στην πραγματικότητα αφορούν τους τεχνικούς Όταν μια απαίτηση χρήστη περιλαμβάνει πολύ πληροφορία, περιορίζει την ελευθερία του προγραμματιστή του συστήματος να δώσει καινοτόμες λύσεις στα προβλήματα του χρήστη και κάνει την κατανόηση των απαιτήσεων δυσνόητη Η απαίτηση του χρήστη θα πρέπει να επικεντρώνεται απλά σε βασικές λειτουργίες που θα παρέχονται Η ορθολογική βάση των απαιτήσεων είναι πολύ σημαντική Βοηθάει τους προγραμματιστές συστήματος και τους συντηρητές να κατανοήσουν γιατί μια απαίτηση έχει ενσωματωθεί στο σύστημα και επιτρέπει την αποτίμηση μιας αλλαγής στη συγκεκριμένη απαίτηση 15

16 Για να ελαχιστοποιηθούν περιστατικά παρεξηγήσεων κατά την συγγραφή των απαιτήσεων χρήστη, προτείνονται από τη βιβλιογραφία μερικές απλές οδηγίες: 1 Προσήλωση σε ένα πρότυπο και διασφάλιση ότι όλοι οι ορισμοί των απαιτήσεων είναι γραμμένοι σύμφωνα με αυτό το πρότυπο Η προτυποποίηση διασφαλίζει ότι θα ελαχιστοποιηθεί η πιθανότητα παραλείψεων και θα διευκολύνει τον έλεγχο 2 Χρήση της γλώσσας με συνέπεια Συγκεκριμένα, θα πρέπει να γίνει ο διαχωρισμός μεταξύ των υποχρεωτικών και των επιθυμητών απαιτήσεων 3 Χρήση έμφασης κειμένου (έντονα και πλάγια γράμματα) για να τονιστούν σημαντικά μέρη της απαίτησης 4 Αποφυγή, όσο το δυνατό περισσότερο, της χρήσης της διαλέκτου των υπολογιστών Παρόλα αυτά, είναι αναπόφευκτο και θα χρησιμοποιηθούν τεχνικοί όροι που έχουν σχέση με το πεδίο της εφαρμογής του συστήματος 213 Απαιτήσεις Συστήματος Οι απαιτήσεις συστήματος είναι περισσότερο λεπτομερείς περιγραφές σε σχέση με τις απαιτήσεις χρήστη Μπορούν να χρησιμοποιηθούν ως βάση για ένα συμβόλαιο της υλοποίησης του συστήματος και για αυτό το λόγο θα πρέπει να είναι μια πλήρης και συνεπής προδιαγραφή του συστήματος Χρησιμοποιούνται από τους μηχανικού λογισμικού ως σημείο έναρξης της σχεδίασης του συστήματος Η προδιαγραφή των απαιτήσεων του συστήματος μπορεί να περιλαμβάνει διαφορετικά μοντέλα του συστήματος όπως ένα αντικειμενοστρεφές μοντέλο ή ένα μοντέλο ροής δεδομένων Τυπικά, οι απαιτήσεις του συστήματος θα πρέπει να δηλώνουν τι θα έπρεπε να κάνει το σύστημα και πως θα έπρεπε να υλοποιηθεί Παρόλα αυτά, στο επίπεδο της λεπτομέρειας που απαιτείται για την πλήρη προδιαγραφή του συστήματος είναι ουσιαστικά αδύνατο να αποκλειστούν όλες οι σχεδιαστικές πληροφορίες Υπάρχουν διάφοροι λόγοι για αυτό: 16

17 1 Μια αρχική αρχιτεκτονική του συστήματος μπορεί να οριστεί για να βοηθήσει τη δομή της προδιαγραφής των απαιτήσεων Οι απαιτήσεις συστήματος οργανώνονται σύμφωνα με διαφορετικά υποσυστήματα 2 Στις περισσότερες περιπτώσεις, τα συστήματα πρέπει να συνεργάζονται με άλλα υπάρχοντα συστήματα Αυτά περιορίζουν τον σχεδιασμό και αυτοί οι περιορισμοί παράγουν απαιτήσεις για το νέο σύστημα 3 Η χρήση ενός συγκεκριμένου σχεδιασμού μπορεί να είναι μια εξωτερική απαίτηση του συστήματος Η φυσική γλώσσα χρησιμοποιείται συχνά για τη συγγραφή της προδιαγραφής των απαιτήσεων συστήματος Εκτός όμως από τα προβλήματα που παρουσιάστηκαν στην ενότητα 0212, όταν η φυσική γλώσσα χρησιμοποιείται για λεπτομερέστερη προδιαγραφή, παρουσιάζονται επιπλέον προβλήματα: 1 Η κατανόηση της φυσικής γλώσσας βασίζεται στο γεγονός ότι οι αναγνώστες της προδιαγραφής και οι συγγραφείς χρησιμοποιούν τις ίδιες λέξεις για τις ίδιες έννοιες Αυτό οδηγεί σε παρεξηγήσεις λόγω της ασάφειας που ενέχει η φυσική γλώσσα 2 Μια προδιαγραφή απαιτήσεων που εκφράζεται σε φυσική γλώσσα είναι υπέρ-ευέλικτη Υπάρχει η δυνατότητα να πει κανείς το ίδιο ακριβώς πράγμα με πολλούς διαφορετικούς τρόπους Εξαρτάται επομένως από τον αναγνώστη να ανακαλύψει πότε οι απαιτήσεις είναι ίδιες και πότε διαφέρουν 3 Δεν υπάρχει εύκολος τρόπος να δημιουργηθούν μονάδες για τις απαιτήσεις που εκφράζονται σε φυσική γλώσσα Μπορεί να είναι δύσκολο να βρεθούν συσχετιζόμενες απαιτήσεις Για να ανακαλυφτούν οι επιπτώσεις που θα είχε μια αλλαγή θα πρέπει να εξεταστούν προσεκτικά όλες οι απαιτήσεις και όχι μόνο μια ομάδα συσχετιζόμενων απαιτήσεων Εξαιτίας αυτών των προβλημάτων η προδιαγραφή των απαιτήσεων όταν είναι γραμμένη σε φυσική γλώσσα είναι ευαίσθητη σε παρεξηγήσεις, οι οποίες δεν γίνονται αντιληπτές παρά μόνο στα τελευταία στάδια της διαδικασίας του λογισμικού και τότε είναι πιθανό να είναι πολύ ακριβή η επίλυσή τους 17

18 Υπάρχουν διάφοροι εναλλακτικοί τρόποι όσον αφορά τη χρήση της φυσικής γλώσσας που κάνουν δομημένη την προδιαγραφή και βοηθούν στη μείωση της ασάφειας Η προδιαγραφή των απαιτήσεων μπορεί να γίνει χρησιμοποιώντας δομημένη γλώσσα, PDL 22 Δραστηριότητες Διαδικασίας Τεχνολογίας Απαιτήσεων Λογισμικού Υπάρχουν τέσσερις γενικές δραστηριότητες που σχετίζονται με την διαδικασία της τεχνολογίας απαιτήσεων λογισμικού 11] 1 Μελέτη σκοπιμότητας του συστήματος, 2 Εξαγωγή και ανάλυση των απαιτήσεων, 3 Προδιαγραφή των απαιτήσεων και το έγγραφο τεκμηρίωσης και τέλος η 4 Επικύρωση των απαιτήσεων 221 Μελέτη σκοπιμότητας του συστήματος Για όλα τα νέα συστήματα, η διαδικασία της τεχνολογίας απαιτήσεων πρέπει να ξεκινά με μια μελέτη σκοπιμότητας Η μελέτη σκοπιμότητας θα αποτελέσει μια γενική περιγραφή του συστήματος σχετικά με το πώς αυτό θα χρησιμοποιηθεί στα πλαίσια ενός οργανισμού Τα αποτελέσματα της μελέτης σκοπιμότητας είναι μια αναφορά που συνιστά στην συνέχεια ή μη της διαδικασίας της τεχνολογίας απαιτήσεων και στην περαιτέρω ανάπτυξη του συστήματος Μια μελέτη σκοπιμότητας είναι μια σύντομη και συγκεντρωμένη μελέτη που στοχεύει να δώσει απαντήσεις σε έναν αριθμό ερωτήσεων: 1 Το σύστημα ανταποκρίνεται στο σύνολο των στόχων του οργανισμού; 2 Μπορεί το σύστημα να υλοποιηθεί χρησιμοποιώντας την υπάρχουσα τεχνολογία και με τους δεδομένους περιορισμούς κόστους και προγραμματισμού; 3 Μπορεί το σύστημα να συνεργαστεί με τα υπόλοιπα συστήματα που ήδη χρησιμοποιούνται; Το θέμα του αν το σύστημα θα συνεισφέρει στους σκοπούς του οργανισμού ή όχι είναι πραγματικά κρίσιμο Αν το σύστημα δεν υποστηρίζει αυτούς τους σκοπούς, τότε δεν έχει πραγματική αξία για την επιχείρηση Ενώ αυτό μπορεί να φαίνεται ως κάτι το φυσιολογικό, στην πραγματικότητα, πολλοί οργανισμοί 18

19 αναπτύσσουν συστήματα που δεν συνεισφέρουν στους σκοπούς τους είτε επειδή αυτοί δεν είναι ξεκάθαρα δηλωμένοι ή εξαιτίας άλλων πολιτικών ή εσωτερικών παραγόντων που υποστηρίζουν την προμήθεια ενός συστήματος Η εκτέλεση μιας μελέτης σκοπιμότητας περιλαμβάνει την αξιολόγηση των πληροφοριών, τη συλλογή πληροφοριών και την συγγραφή αναφοράς Η φάση της αξιολόγησης της πληροφορίας αναγνωρίζει την πληροφορία που απαιτείται για να απαντηθούν τα τρία παραπάνω ερωτήματα Μόλις αναγνωριστεί η πληροφορία που είναι απαραίτητη, θα πρέπει να ερωτηθούν τα κατάλληλα άτομα όπως για παράδειγμα οι managers των τμημάτων που θα χρησιμοποιηθεί το σύστημα, οι μηχανικοί λογισμικού που είναι οικείοι με τον τύπο του συστήματος που προτείνεται, ειδικοί τεχνολογίας, τελικοί χρήστες του συστήματος κτλ Μέσω συνεντεύξεων, θα συγκεντρωθούν όλες οι απαραίτητες πληροφορίες και θα ετοιμαστεί η αναφορά της μελέτης σκοπιμότητας Εκεί, επιπλέον, μπορεί να προτείνονται αλλαγές για την εμβέλεια του συστήματος, αλλαγές στον προϋπολογισμό ή στο προγραμματισμό, ακόμη και να προτείνονται κάποιες υψηλού επιπέδου απαιτήσεις για το σύστημα 222 Εξαγωγή και ανάλυση των απαιτήσεων Μετά τις αρχικές μελέτες σκοπιμότητας, το επόμενο στάδιο της διαδικασίας της τεχνολογίας απαιτήσεων είναι η εξαγωγή και η ανάλυση των απαιτήσεων Σε αυτή τη δραστηριότητα, το τεχνικό προσωπικό της ανάπτυξης του λογισμικού δουλεύει με τους πελάτες και τους τελικούς χρήστες του συστήματος για να ανακαλύψουν πληροφορίες σχετικές με το πεδίο της εφαρμογής, τις υπηρεσίες που θα πρέπει να παρέχει το σύστημα, την απαιτούμενη απόδοση του συστήματος, περιορισμούς του υλικού κτλ Η εξαγωγή και η ανάλυση των απαιτήσεων μπορεί να εμπλέκει διάφορους ανθρώπους ενός οργανισμού Ο αγγλικός όρος «stakeholder» χρησιμοποιείται για να αναφέρεται σε όποιον θα έπρεπε να έχει άμεση ή έμμεση επιρροή στις απαιτήσεις του συστήματος Στους «stakeholders» περιλαμβάνονται και οι τελικοί χρήστες που θα αλληλεπιδρούν με το σύστημα και όποιος άλλος βρίσκεται σε ένα οργανισμό και θα επηρεαστεί από αυτό Οι 19

20 μηχανικοί που αναπτύσσουν ή συντηρούν άλλα σχετικά συστήματα μπορούν να είναι και αυτοί «stakeholders» του συστήματος Η εξαγωγή και η ανάλυση των απαιτήσεων είναι μια δύσκολη διαδικασία για διάφορους λόγους: 1 Οι «stakeholders» δεν γνωρίζουν πραγματικά τι επιθυμούν από το υπολογιστικό σύστημα εκτός από πολύ γενικούς όρους Μπορεί να δυσκολεύονται να εκφράσουν αυτό που θέλουν από το σύστημα, μπορεί να έχουν μη ρεαλιστικές απαιτήσεις επειδή δε συνειδητοποιούν το κόστος των αιτημάτων τους 2 Οι «stakeholders» σε ένα σύστημα εκφράζουν τις απαιτήσεις χρησιμοποιώντας δικούς τους όρους θεωρώντας και πολλές φορές ορισμένες καταστάσεις δεδομένες Από την άλλη πλευρά, οι μηχανικοί λογισμικού που δεν έχουν εμπειρία στο πεδίο των πελατών, πρέπει να κατανοήσουν αυτές τις απαιτήσεις 3 Διαφορετικοί «stakeholders» έχουν διαφορετικές απαιτήσεις και μπορεί να τις εκφράζουν με διαφορετικούς τρόπους Οι τεχνολόγοι απαιτήσεων πρέπει να ανακαλύψουν όλες τις πιθανές πηγές απαιτήσεων καθώς και τις ομοιότητες και τις συγκρούσεις 4 Πολιτικοί παράγοντες μπορεί να επηρεάσουν τις απαιτήσεις ενός συστήματος Αυτοί μπορεί να προέρχονται από τους managers που απαιτούν συγκεκριμένες απαιτήσεις συστήματος επειδή αυτές τους επιτρέπουν να αυξήσουν την επιρροή τους στον οργανισμό 5 Το οικονομικό και το επιχειρηματικό περιβάλλον στο οποίο διεξάγεται η ανάλυση είναι δυναμικό και αλλάζει αναπόφευκτα κατά τη διαδικασία της ανάλυσης Επομένως, η σημαντικότητα συγκεκριμένων απαιτήσεων μπορεί να αλλάξει Νέες απαιτήσεις μπορεί να εμφανιστούν από νέους «stakeholders» που δεν λήφθηκαν υπόψη εξ αρχής Ένα γενικό μοντέλο της διαδικασίας της εξαγωγής και της ανάλυσης των απαιτήσεων φαίνεται στην Εικόνα 2 Κάθε οργανισμός μπορεί να έχει διαφορετική εκδοχή του γενικού μοντέλου ανάλογα με τοπικούς παράγοντες όπως για παράδειγμα την ειδίκευση του προσωπικού, τον τύπο του συστήματος που αναπτύσσεται, τα πρότυπα που θα χρησιμοποιηθούν κτλ 20

21 Προδιαγραφή Απαιτήσεων Έλεγχος Απαιτήσεων Είσοδος Διαδικασίας Κατανόηση Πεδίου Αξιολόγηση Έγγραφο Απαιτήσεων Συλλογή Απαιτήσεων Επίλυση Συγκρούσεων Κατηγοριοποίηση Εικόνα 2 Η διαδικασία εξαγωγής και ανάλυσης Οι δραστηριότητες της διαδικασίας είναι: 1 Κατανόηση Πεδίου: Οι αναλυτές πρέπει να κατανοήσουν το πεδίο της εφαρμογής του συστήματος Για παράδειγμα, αν το σύστημα προορίζεται για ένα νοσοκομείο, θα χρειαστεί να κατανοήσουν κάποιες έννοιες σχετικές με την ιατρική 2 Συλλογή Απαιτήσεων: Αυτή είναι η διαδικασία αλληλεπίδρασης με τους «stakeholders» του συστήματος για να ανακαλύψουν τις απαιτήσεις Είναι φανερό ότι η κατανόηση του πεδίου αναπτύσσει περαιτέρω την δραστηριότητα 3 Κατηγοριοποίηση: Αυτή η δραστηριότητα λαμβάνει αδόμητες τις απαιτήσεις και τις οργανώνει σε συναφείς ομάδες 4 Επίλυση συγκρούσεων: Αναπόφευκτα, όπου εμπλέκονται πολλαπλοί «stakeholders», οι απαιτήσεις θα συγκρούονται Αυτή η δραστηριότητα σχετίζεται με την εύρεση και την επίλυση αυτών των συγκρούσεων 5 Αξιολόγηση: Σε οποιοδήποτε σύνολο απαιτήσεων κάποιες θα είναι περισσότερο σημαντικές από άλλες Αυτό το στάδιο συμπεριλαμβάνει την αλληλεπίδραση με «stakeholders» για να ανακαλυφθούν οι πιο σημαντικές απαιτήσεις 6 Έλεγχος απαιτήσεων: Οι απαιτήσεις ελέγχονται ως προς την πληρότητα, την συνοχή και την συμφωνία τους σε σχέση με το τι πραγματικά θέλουν οι «stakeholders» από το σύστημα 21

22 Η Εικόνα 2 δείχνει ότι η ανάλυση και η εξαγωγή των απαιτήσεων είναι μια επαναληπτική διαδικασία με συνεχόμενη ανατροφοδότηση από τη μια δραστηριότητα προς την άλλη Ο κύκλος της διεργασίας ξεκινά με την κατανόηση του πεδίου και τελειώνει με τον έλεγχο των απαιτήσεων Η κατανόηση των απαιτήσεων από τον αναλυτή βελτιώνει κάθε γύρο του κύκλου Παρακάτω, καλύπτονται δύο τεχνικές εξαγωγής και ανάλυσης απαιτήσεων Η viewpoint-oriented εξαγωγή και τα σενάρια 2221 Viewpoint-oriented εξαγωγή Για κάθε μεγάλο ή μεσαίου μεγέθους σύστημα, υπάρχουν συνήθως διαφορετικοί τύποι τελικών χρηστών και «stakeholders» Η σκοπιά με την οποία βλέπουν το σύστημα όλοι όσοι ενδιαφέρονται για αυτό ονομάζεται «viewpoint» Για ένα πρόβλημα επομένως υπάρχουν διαφορετικές σκοπιές ανάλογα με το αν για παράδειγμα κάποιος είναι τελικός χρήστης του συστήματος ή ο συντηρητής του Παρόλα αυτά, οι απόψεις του καθενός για το σύστημα δεν είναι πάντα ανεξάρτητες Συχνά, επικαλύπτονται με τέτοιο τρόπο ώστε να προκύπτουν κοινές απαιτήσεις Η συγκεκριμένη προσέγγιση για την τεχνολογία απαιτήσεων λογισμικού αναγνωρίζει ότι υπάρχουν διαφορετικές απόψεις για το σύστημα και τις χρησιμοποιούν για να δομήσουν και να οργανώσουν και την διαδικασία της εξαγωγής και τις ίδιες τις απαιτήσεις Η σημαντικότητα της viewpoint-oriented ανάλυσης έγκειται στο ότι αναγνωρίζει την ύπαρξη πολλαπλών απόψεων και παρέχει ένα πλαίσιο για τον εντοπισμό συγκρούσεων στις απαιτήσεις που προτείνονται από διάφορους «stakeholders» Διαφορετικές μέθοδοι έχουν διαφορετικές ιδέες σχετικά με την σημασία του όρου «viewpoint» Ένα «viewpoint» μπορεί να θεωρηθεί ως: 1 Μια πηγή δεδομένων ή δεξαμενή: Σε αυτή την περίπτωση τα «viewpoints» είναι υπεύθυνα για την παραγωγή ή την κατανάλωση δεδομένων Η ανάλυση περιλαμβάνει την αναγνώριση όλων αυτών των «viewpoints», την αναγνώριση των δεδομένων που παράγονται ή καταναλώνονται και της επεξεργασίας που πρέπει να γίνει 2 Ένα πλαίσιο αναπαράστασης: Σε αυτή την περίπτωση, ένα «viewpoint» θεωρείται ως ένας συγκεκριμένος τύπος μοντέλου Για παράδειγμα, 22

23 διαφορετικοί μηχανικοί μπορεί να αναπτύξουν ένα σχεσιακό μοντέλο οντοτήτων, ένα μοντέλο καταστάσεων κτλ Κάθε προσέγγιση στην ανάλυση εντοπίζει διαφορετικά στοιχεία για το σύστημα που θα αναλυθεί 3 Ένας αποδέκτης υπηρεσιών: Σε αυτή την περίπτωση, τα «viewpoints» είναι εξωτερικά και λαμβάνουν υπηρεσίες από το σύστημα Τα «viewpoints» μπορεί να παρέχουν δεδομένα για αυτές τις υπηρεσίες και να ελέγχουν σήματα Η ανάλυση εμπεριέχει την εξέταση των υπηρεσιών που λαμβάνονται από διαφορετικά «viewpoints», τη συλλογή αυτών και την επίλυση συγκρούσεων Κάθε μια από τις μεθόδους που αναφέρθηκαν παραπάνω έχει διαφορετικά πλεονεκτήματα και μειονεκτήματα Όταν τα «viewpoints» αντιμετωπίζονται ως δεξαμενές δεδομένων ή ως πλαίσια αναπαράστασης είναι ιδιαίτερα χρήσιμα γιατί επιτρέπουν τον εντοπισμό συγκρούσεων μεταξύ των απαιτήσεων Παρόλα αυτά, δεν είναι κατάλληλα για την δόμηση των απαιτήσεων αφού δεν υπάρχει απλή σχέση μεταξύ των «viewpoints» και των «stakeholders» Στην τρίτη μέθοδο που παρουσιάστηκε τα «viewpoints» αλληλεπιδρούν με το σύστημα παίρνοντας τις υπηρεσίες από αυτό και παρέχουν δεδομένα και σήματα ελέγχου σε αυτό Τα πλεονεκτήματα αυτού του τύπου των «viewpoints» είναι: 1 Τα «viewpoints» είναι εξωτερικά του συστήματος και επομένως προσφέρονται για τη δόμηση της διαδικασίας εξαγωγής των απαιτήσεων 2 Είναι σχετικά απλό να αξιολογηθεί ένα «viewpoint» Τα «viewpoints» πρέπει να αλληλεπιδρούν με το σύστημα με κάποιο τρόπο 3 Τα «viewpoints» και οι υπηρεσίες είναι επίσης ένας χρήσιμος τρόπος να δομήσει τις μη λειτουργικές απαιτήσεις Κάθε υπηρεσία μπορεί να σχετίζεται με μη λειτουργικές απαιτήσεις Πολλαπλά «viewpoints» μπορεί να επιτρέπουν στην ίδια υπηρεσία να έχει διαφορετικές μη λειτουργικές απαιτήσεις Η μέθοδος VORD (Viewpoint-Oriented Requirements Definition) (Konotoya και Sommerville, 1996, 1998) σχεδιάστηκε ως ένα πλαίσιο προσανατολισμένο στις υπηρεσίες για την εξαγωγή και ανάλυση των απαιτήσεων Τα βασικά στάδια της μεθόδου VORD είναι: 23

24 1 Αναγνώριση των «viewpoints», που περιλαμβάνει τον εντοπισμό των «viewpoints» που λαμβάνουν υπηρεσίες του συστήματος και την αναγνώριση συγκεκριμένων υπηρεσιών που παρέχονται σε κάθε ένα «viewpoint» 2 Δόμηση των «viewpoints», που περιλαμβάνει την ομαδοποίηση σχετικών «viewpoints» σε μια ιεραρχία Οι συχνές υπηρεσίες παρέχονται σε υψηλότερα επίπεδα στην ιεραρχία και κληρονομούνται από χαμηλότερου επιπέδου «viewpoints» 3 Η τεκμηρίωση των «viewpoints», που περιλαμβάνει βελτίωση της περιγραφής των αναγνωρισμένων «viewpoints» και υπηρεσιών 4 Σχεδιασμός συστήματος «viewpoints», που περιλαμβάνει την αναγνώριση αντικειμένων σε ένα σχεδιασμό αντικειμενοστρεφή χρησιμοποιώντας πληροφορία υπηρεσίας η οποία εμπεριέχεται στα «viewpoints» Οι πληροφορίες των «viewpoints» και των υπηρεσιών στην VORD συλλέγονται χρησιμοποιώντας τυποποιημένες φόρμες Επίσης, η VORD χρησιμοποιεί διάφορους συμβολισμούς, όπως για παράδειγμα τα διαγράμματα ιεραρχίας που περιγράφηκαν παραπάνω και διάφορα σενάρια γεγονότων Το πρώτο στάδιο της «viewpoint» ανάλυσης που περιλαμβάνει την αναγνώριση των «viewpoints» είναι το πιο δύσκολο Μια προσέγγιση είναι το brainstorming Οι «stakeholders» σε συναντήσεις προτείνουν πιθανά «viewpoints» τα οποία καταγράφονται σε διαγράμματα Κατά τη διάρκεια ενός brainstorming, γίνεται προσπάθεια να αναγνωριστούν πιθανά «viewpoints», υπηρεσίες του συστήματος, δεδομένα εισόδου, μη λειτουργικές απαιτήσεις, γεγονότα ελέγχου και εξαιρέσεις Σε αυτό το στάδιο της ανάλυσης, δε θα πρέπει να γίνει προσπάθεια να δομηθεί το διάγραμμα που προκύπτει Οι πηγές πληροφορίας σε αυτό το αρχικό στάδιο του συστήματος θα πρέπει να είναι έγγραφα με υψηλού επιπέδου στόχους του συστήματος, γνώσεις των μηχανικών λογισμικού από προηγούμενα έργα ή η εμπειρία που έχει κάποιος ως χρήστης του συστήματος Το επόμενο στάδιο της διαδικασίας είναι να αναγνωριστούν τα «viewpoints» και οι υπηρεσίες Οι υπηρεσίες θα πρέπει να ανατεθούν σε συγκεκριμένα «viewpoints» Οι υπηρεσίες που δεν ταιριάζουν σε υπάρχοντα «viewpoints» 24

25 μπορούν να προτείνουν νέα «viewpoints» που δεν αναγνωρίστηκαν στην αρχική φάση του brainstorming Η ίδια υπηρεσία μπορεί να ανατεθεί σε περισσότερα «viewpoints» Τα «viewpoints» επίσης παρέχουν πληροφορίες ελέγχου για να καθορίσουν αν και πότε οι υπηρεσίες παρέχονται Κατά τη διάρκεια αυτής της πρώιμης φάσης της διαδικασίας, αυτές οι πληροφορίες για τον έλεγχο καθορίζονται απλώς με το όνομά τους Οι πληροφορίες των «viewpoints» χρησιμοποιούνται για να συμπληρωθούν τυποποιημένες φόρμες και για να οργανώσουν τα «viewpoints» σε μια ιεραρχία κληρονομικότητας Η ιεραρχία κληρονομικότητας βοηθάει στον εντοπισμό ομοιοτήτων μεταξύ «viewpoints» και στην επαναχρησιμοποίηση της πληροφορίας των «viewpoints» Οι υπηρεσίες, τα δεδομένα και οι πληροφορίες ελέγχου κληρονομούνται από υπό-«viewpoints» Το επόμενο στάδιο είναι να βρεθούν περισσότερο λεπτομερείς πληροφορίες για τις υπηρεσίες που παρέχονται, τα δεδομένα που απαιτούνται και πως αυτά ελέγχονται Οι απαιτήσεις εξάγονται από τους «stakeholders» που σχετίζονται με κάθε «viewpoint» Οι υπηρεσίες που απαιτούνται για κάθε «viewpoint» συζητούνται είτε με τους τελικούς χρήστες, είτε με τους ειδικούς του «viewpoint» αν το «viewpoint» είναι ένα άλλο αυτόματο σύστημα Στις τυποποιημένες φόρμες που χρησιμοποιούνται, υπάρχει σχετικό πεδίο συμπλήρωσης για τα σενάρια που περιγράφουν πως συμπεριφέρεται το σύστημα όταν αντιδρά σε διάφορα γεγονότα Οι φόρμες των «viewpoints» και των υπηρεσιών και τα σενάρια γεγονότων αναπτύσσονται για όλα τα «viewpoints» και τις υπηρεσίες που αναγνωρίστηκαν Οι πληροφορίες αυτές εν συνεχεία διασταυρώνονται για να ανακαλυφθούν λάθη στην ανάλυση και συγκρούσεις απαιτήσεων Καθώς το πλήθος των πληροφοριών που προκύπτει είναι αρκετά μεγάλο, η μέθοδος VORD είναι χρήσιμη μόνο όταν χρησιμοποιείται σε συνδυασμό με κάποιο αντίστοιχο εργαλείο 2222 Σενάρια Οι άνθρωποι συνήθως βρίσκουν πιο εύκολα συσχετισμούς με παραδείγματα της πραγματικής ζωής παρά με αφηρημένες περιγραφές Μπορούν να καταλάβουν και να ασκήσουν κριτική σε ένα σενάριο σχετικά με το πώς 25

26 μπορεί να αλληλεπιδράσουν με το σύστημα λογισμικού Οι μηχανικοί απαιτήσεων μπορούν να χρησιμοποιήσουν αυτές τις πληροφορίες που προκύπτουν από συζητήσεις για να διαμορφώσουν τις πραγματικές απαιτήσεις του συστήματος Τα σενάρια μπορούν να είναι ιδιαίτερα χρήσιμα γιατί προσθέτουν λεπτομέρεια στις γενικές περιγραφές των απαιτήσεων Είναι οι περιγραφές από παραδείγματα αλληλεπίδρασης Κάθε σενάριο καλύπτει μία ή μικρό αριθμό αλληλεπιδράσεων Έχουν αναπτυχθεί διαφορετικοί τύποι σεναρίων και παρέχουν διαφορετικούς τύπους πληροφορίας ανάλογα με το επίπεδο λεπτομέρειας για το σύστημα Το σενάριο ξεκινά με μια γενική περιγραφή της αλληλεπίδρασης και κατά τη διάρκεια της εξαγωγής των απαιτήσεων, προστίθενται λεπτομέρειες για να δημιουργηθεί μια πλήρης περιγραφή της αλληλεπίδρασης Στην γενικότερη περίπτωση, ένα σενάριο μπορεί να περιλαμβάνει: 1 Μια κατάσταση του συστήματος στην αρχή του σεναρίου 2 Μια περιγραφή της κανονικής ροής των γεγονότων του σεναρίου 3 Μια περιγραφή σχετική με το τι μπορεί να πάει στραβά και πως αυτό αντιμετωπίζεται 4 Πληροφορίες για άλλες δραστηριότητες οι οποίες μπορεί να συμβαίνουν ταυτόχρονα 5 Μια περιγραφή της κατάστασης του συστήματος μετά την ολοκλήρωση του σεναρίου Η εξαγωγή των απαιτήσεων όταν βασίζεται στα σενάρια μπορεί να διεξαχθεί ανεπίσημα, και ο μηχανικός απαιτήσεων να συνεργάζεται με τους «stakeholders» για να αναγνωρίσουν τα σενάρια και να συλλάβουν τις πληροφορίες αυτών των σεναρίων Εναλλακτικά, θα μπορούσε να χρησιμοποιηθεί μια περισσότερο δομημένη προσέγγιση, όπως τα σενάρια γεγονότων ή οι περιπτώσεις χρήσης Τα σενάρια γεγονότων χρησιμοποιούνται στη VORD για την τεκμηρίωση της συμπεριφοράς του συστήματος όταν παρουσιάζονται με συγκεκριμένα γεγονότα Κάθε σενάριο περιλαμβάνει μια περιγραφή από ροές δεδομένων και ενέργειες και τεκμηριώνει τις εξαιρέσεις που μπορεί να προκύψουν Η περίπτωση χρήσης είναι μια τεχνική που βασίζεται στα σενάρια για την εξαγωγή των απαιτήσεων Σήμερα έχει γίνει ένα από τα βασικά 26

27 χαρακτηριστικά του συμβολισμού της UML για την περιγραφή αντικειμενοστρεφών μοντέλων Στην απλούστερη μορφή της, μια περίπτωση χρήσης αναγνωρίζει τους χειριστές που αναμειγνύονται σε μια αλληλεπίδραση και τα ονόματα των αλληλεπιδράσεων (Βλ Παράρτημα Β) Το σύνολο των περιπτώσεων χρήσης αναπαριστά όλες τις δυνατές αλληλεπιδράσεις που θα πραγματοποιούνται με το σύστημα 223 Προδιαγραφή των απαιτήσεων και έγγραφο τεκμηρίωσης Το έγγραφο απαιτήσεων λογισμικού (Software Requirements Specification SRS) είναι μια επίσημη δήλωση προς τους προγραμματιστές του συστήματος που περιγράφει ό,τι ακριβώς χρειάζεται να υλοποιήσουν Πρέπει να περιλαμβάνει ταυτόχρονα τις απαιτήσεις των χρηστών για ένα σύστημα και μια λεπτομερή προδιαγραφή των απαιτήσεων συστήματος Σε ορισμένες περιπτώσεις οι απαιτήσεις χρήστη και συστήματος μπορεί να ολοκληρώνονται σε μια μοναδική περιγραφή Σε άλλες περιπτώσεις οι απαιτήσεις χρηστών ορίζονται σε μια εισαγωγή των απαιτήσεων συστήματος Αν υπάρχει μεγάλος αριθμός απαιτήσεων, οι λεπτομερείς απαιτήσεις συστήματος μπορούν να παρουσιαστούν σε ένα ξεχωριστό έγγραφο Το έγγραφο απαιτήσεων έχει ένα ευρύ σύνολο χρηστών που ποικίλλει από την διοίκηση του οργανισμού που πληρώνει για το σύστημα μέχρι τους μηχανικούς λογισμικού που είναι υπεύθυνοι να το αναπτύξουν Η Εικόνα 3 απεικονίζει τους πιθανούς χρήστες ενός εγγράφου απαιτήσεων και πως το χρησιμοποιούν Για ένα έγγραφο απαιτήσεων υπάρχουν έξι απαιτήσεις που πρέπει να ικανοποιούνται: Πρέπει να προδιαγράφει μόνο την εξωτερική συμπεριφορά του συστήματος Πρέπει να προδιαγράφει τους περιορισμούς της υλοποίησης Πρέπει να επιτρέπει εύκολα τις αλλαγές Πρέπει να λειτουργεί ως εργαλείο αναφοράς για τους συντηρητές του συστήματος Πρέπει να καταγράφονται πληροφορίες σχετικά με τον κύκλο ζωής του συστήματος 27

28 Πρέπει να περιγράφει αποδεκτές αποκρίσεις σε ανεπιθύμητα γεγονότα Είναι μερικές φορές δύσκολο να προδιαγράφονται συστήματα με την έννοια του τι ακριβώς θα κάνουν (δηλαδή να προδιαγράφεται η εξωτερική συμπεριφορά) Αναπόφευκτα, εξαιτίας περιορισμών που επιβάλλουν ήδη υπάρχοντα συστήματα, ο σχεδιασμός του συστήματος περιορίζεται και αυτό πρέπει να απεικονίζεται και στο έγγραφο απαιτήσεων Η απαίτηση που σχετίζεται με τον κύκλο ζωής του συστήματος είναι κοινά αποδεκτή αλλά όχι πάντα εφαρμόσιμη κατά τη συγγραφή εγγράφου απαιτήσεων Για την προδιαγραφή των απαιτήσεων συστημάτων έχουν προταθεί διάφορα πρότυπα όπως αυτό του προτύπου IEEE/ANSI 830/1993 (IEEE, 1993) [19] Το πρότυπο της IEEE προτείνει την παρακάτω δομή για το έγγραφο απαιτήσεων: 1) Εισαγωγή a) Σκοπός του έγγραφου απαιτήσεων b) Εμβέλεια του προϊόντος c) Ορισμοί, Ακρωνύμια και συντομεύσεις d) Αναφορές e) Επισκόπηση του υπόλοιπου εγγράφου 28

29 Πελάτες Συστήματος Προδιαγράφουν τις απαιτήσεις και τις διαβάζουν για να ελέγξουν αν όντως ανταποκρίνονται στις ανάγκες τους Αυτοί καθορίζουν τις τυχόν αλλαγές στις απαιτήσεις Managers Χρησιμοποιούν το έγγραφο απαιτήσεων για να σχεδιάσουν προσφορά για το σύστημα και να σχεδιάσουν τη διαδικασία της ανάπτυξης του συστήματος Μηχανικοί Συστήματος Χρησιμοποιούν τις απαιτήσεις για να κατανοήσουν τι χρειάζεται για το υπό ανάπτυξη σύστημα Μηχανικοί Ελέγχου Συστήματος Χρησιμοποιούν τις απαιτήσεις για να αναπτύξουν ελέγχους επικύρωσης για το σύστημα Μηχανικοί Συντήρησης Συστήματος Χρησιμοποιούν τις απαιτήσεις για να βοηθήσουν στην κατανόηση του συστήματος και των σχέσεων μεταξύ των μερών του Εικόνα 3 Χρήστες του εγγράφου απαιτήσεων 2) Γενική Περιγραφή a) Προϊόν b) Λειτουργίες Προϊόντος c) Χαρακτηριστικά Χρήστη d) Γενικοί Περιορισμοί e) Υποθέσεις και Εξαρτήσεις 3) Συγκεκριμένες απαιτήσεις που καλύπτουν τις λειτουργικές απαιτήσεις, τις μη λειτουργικές απαιτήσεις και τις απαιτήσεις διεπαφής Είναι προφανώς το περισσότερο ουσιαστικό μέρος του εγγράφου αλλά εξαιτίας της μεγάλης μεταβλητότητας στην πράξη, δεν ενδείκνυται μια 29

30 συγκεκριμένη τυποποιημένη δομή Οι απαιτήσεις πρέπει να τεκμηριώνουν την εξωτερική διεπαφή, να περιγράφουν τη λειτουργικότητα και την απόδοση του συστήματος, να σχεδιάσουν περιορισμούς, επείγουσες ιδιότητες του συστήματος και χαρακτηριστικά ποιότητας (Παράρτημα Α) 4) Παραρτήματα 5) Περιεχόμενα Επεξηγήσεις για τις ενότητες του εγγράφου προδιαγραφής απαιτήσεων κατά την IEEE δίνονται στο Παράρτημα Α Παρόλο που το συγκεκριμένο πρότυπο δεν είναι ιδανικό, περιέχει καλές συμβουλές σχετικά με το πώς γράφονται οι απαιτήσεις και πως αποφεύγονται προβλήματα Το πρότυπο της IEEE είναι αρκετά γενικό και δεν μπορεί να αποτελέσει μόνο του ένα πρότυπο που θα χρησιμοποιείται από έναν οργανισμό Παρόλα αυτά, μπορεί να παραμετροποιηθεί και να προσαρμοστεί ώστε να ταιριάζει στις ανάγκες ενός συγκεκριμένου οργανισμού Φυσικά οι πληροφορίες που θα περιλαμβάνονται σε ένα έγγραφο απαιτήσεων θα πρέπει να εξαρτώνται από τον τύπο του λογισμικού που πρόκειται να αναπτυχθεί και την προσέγγιση που θα χρησιμοποιηθεί για την ανάπτυξή του Είναι πιθανό ένα έγγραφο απαιτήσεων να μην περιγράφει με απόλυτη λεπτομέρεια το προϊόν με σκοπό να αφήσει περιθώρια στους προγραμματιστές και στους σχεδιαστές να χρησιμοποιήσουν την κρίση τους και να αποφασίσουν αυτοί οι ίδιοι μια λύση που θα ικανοποιεί τις ανάγκες του χρήστη Αντίθετα, στην περίπτωση εκείνη που το σύστημα θα πρέπει να αλληλεπιδρά με άλλα συστήματα λογισμικού ή υλικού, είναι απαραίτητο και αναγκαίο να ορίζονται οι απαιτήσεις με περισσότερες λεπτομέρειες Αυτό σημαίνει πως θα περιλαμβάνονται όλες οι ενότητες του προτύπου στο έγγραφο απαιτήσεων και ότι το μέγεθος του εγγράφου τεκμηρίωσης θα είναι μεγάλο Σε μεγάλα έγγραφα, είναι ιδιαίτερα χρήσιμο να υπάρχει πίνακας περιεχομένων που θα μπορεί να παραπέμπει τους χρήστες στην πληροφορία που χρειάζονται 224 Επικύρωση των απαιτήσεων Η επικύρωση των απαιτήσεων επιβεβαιώνει ότι οι απαιτήσεις που ορίζουν το σύστημα είναι αυτές που στην πραγματικότητα θέλει και ο πελάτης Έχει πολλά κοινά στοιχεία με την ανάλυση καθώς πρέπει να βρεθούν προβλήματα 30

31 που προκύπτουν από τις απαιτήσεις Παρόλα αυτά, υπάρχουν καθορισμένες διαδικασίες που πρέπει να ακολουθηθούν, καθώς η επικύρωση των απαιτήσεων σχετίζεται με ένα πλήρες σχέδιο των απαιτήσεων ενώ η ανάλυση ασχολείται με μη πλήρεις απαιτήσεις [2] Η επικύρωση των απαιτήσεων είναι σημαντική διότι αν τα λάθη στο έγγραφο απαιτήσεων ανακαλυφθούν ετεροχρονισμένα κατά τη διάρκεια της ανάπτυξης ή αφού το σύστημα τεθεί σε λειτουργία, μπορούν να οδηγήσουν σε τεράστια κόστη αναθεωρήσεων Το κόστος της αλλαγής ενός συστήματος που επιβάλλεται από πρόβλημα στις απαιτήσεις είναι πολύ μεγαλύτερο από την επιδιόρθωση του σχεδιασμού ή τα λάθη στον κώδικα Ο λόγος που συμβαίνει κάτι τέτοιο είναι ότι μια αλλαγή στις απαιτήσεις συνήθως σημαίνει ότι θα πρέπει να αλλάξει και ο σχεδιασμός του συστήματος και η υλοποίηση του, ενώ το σύστημα θα πρέπει να ξαναπεράσει από ελέγχους Κατά τη διάρκεια της διαδικασίας της επικύρωσης των απαιτήσεων, θα πρέπει να γίνουν διαφορετικοί τύποι ελέγχων στις απαιτήσεις που έχουν καταγραφεί στο αντίστοιχο έγγραφο Αυτοί οι έλεγχοι περιλαμβάνουν: 1 Έλεγχοι εγκυρότητας: Οι χρήστες μπορεί να έχουν στο μυαλό τους ότι το σύστημα χρειάζεται να εκτελεί συγκεκριμένες λειτουργίες Παρόλα αυτά, περαιτέρω σκέψη και ανάλυση μπορούν να ανιχνεύσουν επιπρόσθετες και διαφορετικές λειτουργίες που μπορεί να είναι εξίσου απαραίτητες Τα συστήματα, έχουν διάφορους χρήστες, με διαφορετικές ανάγκες και κάθε σύνολο απαιτήσεων είναι αναπόφευκτα ένας συμβιβασμός ανάμεσα στην κοινότητα των χρηστών 2 Έλεγχοι συνοχής: Οι απαιτήσεις μέσα στο έγγραφο δε θα πρέπει να αντικρούονται Αυτό σημαίνει ότι δε θα πρέπει να υπάρχουν αντικρουόμενοι περιορισμοί ή διαφορετικές περιγραφές για την ίδια λειτουργία του συστήματος 3 Έλεγχοι Πληρότητας: Το έγγραφο απαιτήσεων θα πρέπει να περιλαμβάνει απαιτήσεις που θα ορίζουν όλες τις λειτουργίες και τους περιορισμούς που επιβάλλονται από το χρήστη του συστήματος 4 Έλεγχοι Ρεαλισμού: Χρησιμοποιώντας τις γνώσεις της υπάρχουσας τεχνολογίας, οι απαιτήσεις θα πρέπει να ελέγχονται για να επιβεβαιώσουν ότι μπορούν να υλοποιηθούν πραγματικά Αυτοί οι 31

32 έλεγχοι θα μπορούσαν να λάβουν υπόψη τους τον προϋπολογισμό και το πρόγραμμα της ανάπτυξης του συστήματος 5 Επαληθευσιμότητα: Για να ελαχιστοποιηθούν οι διαφωνίες μεταξύ του πελάτη και του συμβαλλομένου, οι απαιτήσεις του συστήματος θα πρέπει πάντα να καταγράφονται με έναν επαληθεύσιμο τρόπο Αυτό σημαίνει πως πρέπει να σχεδιαστεί ένα σύνολο ελέγχων το οποίο θα αποδεικνύει ότι το παραδοτέο σύστημα ανταποκρίνεται στις απαιτήσεις Υπάρχει ένα σύνολο τεχνικών επικύρωσης των απαιτήσεων οι οποίες θα μπορούσαν να χρησιμοποιηθούν μεμονωμένα ή συνδυαστικά 1 Αναφορές απαιτήσεων: Οι απαιτήσεις αναλύονται συστηματικά από ομάδες κριτικών τα μέλη των οποίων αποτελούνται τόσο από την πλευρά του οργανισμού που θα αναλάβει την ανάπτυξη του λογισμικού όσο και από την πλευρά του πελάτη 2 Δημιουργία πρωτοτύπων: Σε αυτή την προσέγγιση της επικύρωσης των απαιτήσεων, γίνεται επίδειξη ενός εκτελέσιμου μοντέλου του συστήματος στους τελικούς χρήστες και στους πελάτες Οι τελευταίοι μπορούν να πειραματιστούν με το μοντέλο και να κρίνουν αν ανταποκρίνεται στις πραγματικές τους ανάγκες 3 Δημιουργία ελέγχων περιπτώσεων: Οι απαιτήσεις, ιδανικά, θα πρέπει να μπορούν να υποστούν ελέγχους Αν οι έλεγχοι, για τις απαιτήσεις σχεδιάζονται για την διαδικασία της επικύρωσης, τότε συχνά αποκαλύπτονται προβλήματα που υπάρχουν με τις απαιτήσεις Αν ένας τέτοιος έλεγχος είναι δύσκολο ή αδύνατο να σχεδιαστεί, αυτό στην πραγματικότητα σημαίνει ότι οι απαιτήσεις είναι δύσκολο να υλοποιηθούν και θα πρέπει ίσως να επαναπροσδιοριστούν 4 Αυτοματοποιημένη ανάλυση συνέπειας: Αν οι απαιτήσεις εκφράζονται ως ένα μοντέλο συστήματος με δομημένους και επίσημους συμβολισμούς τότε ένα εργαλείο CASE μπορεί να χρησιμοποιηθεί για να ελέγξει την συνοχή του μοντέλου Για να ελέγξει την συνοχή, ένα εργαλείο CASE θα πρέπει να δημιουργήσει μια βάση απαιτήσεων και χρησιμοποιώντας τους κανόνες της μεθόδου ή του συμβολισμού να ελέγχει όλες τις απαιτήσεις που βρίσκονται μέσα στη βάση Όλες τις 32

33 ασυνέπειες που ανακάλυψε το εργαλείο, τις συγκεντρώνει ένας αναλυτής απαιτήσεων σε αναφορά Οι δυσκολίες στην επικύρωση των απαιτήσεων δε θα πρέπει να υποτιμούνται Η απόδειξη ότι ένα σύνολο απαιτήσεων ανταποκρίνεται στις ανάγκες των χρηστών είναι δύσκολη Οι χρήστες πρέπει να σκιαγραφήσουν τη λειτουργία του συστήματος και να φανταστούν πώς το σύστημα θα προσαρμόζεται στις αντίστοιχες εργασίες που πρέπει να διεκπεραιώσει Είναι δύσκολο για τους έμπειρους προγραμματιστές να πρέπει να εκτελέσουν τέτοιου είδους αφηρημένης ανάλυσης και ακόμη δυσκολότερο για τους χρήστες του συστήματος Αυτό έχει ως αποτέλεσμα, η επικύρωση των απαιτήσεων να μην μπορεί να ανακαλύψει όλα τα προβλήματα των απαιτήσεων και αλλαγές που αφορούν παραλείψεις και κακές συνεννοήσεις αφού συμφωνηθεί το έγγραφο απαιτήσεων είναι αναπόφευκτες 3 Τεχνικές Αξιολόγησης Από τη στιγμή που θα καθοριστεί ένα σύνολο λειτουργικών απαιτήσεων, αυτές θα χρειαστεί να αξιολογηθούν Λόγω χρονικών και οικονομικών περιορισμών είναι πιθανό να είναι δύσκολο να υλοποιηθούν όλες οι απαιτήσεις που προέκυψαν κατά τη διαδικασία της εξαγωγής και της ανάλυσης των απαιτήσεων Ένας άλλος λόγος που επιτάσσει την ιεράρχηση των απαιτήσεων είναι ότι οι απαιτήσεις θα πρέπει να υλοποιηθούν σε στάδια οπότε η ιεράρχηση μπορεί να καθορίσει ποιες απαιτήσεις θα υλοποιηθούν πρώτες 31 Ιεραρχική Ανάλυση Αποφάσεων Analytic Hierarchy Process (AHP) Η Analytic Hierarchy Process (AHP) είναι μια πολυκριτηριακή μέθοδος για λήψη αποφάσεων που επιτρέπει να ληφθούν υπόψη τόσο αντικειμενικοί όσο και υποκειμενικοί παράγοντες στην επιλογή της καλύτερης εναλλακτικής λύσης Η προσέγγιση χρησιμοποιείται για να δημιουργηθεί μια διαβάθμιση των εναλλακτικών λύσεων με βάση αναλογιών ώστε να δοθεί λύση σε προβλήματα λήψης απόφασης που επηρεάζονται από πολλές παραμέτρους Η AHP παρουσιάστηκε από τον Thomas Saaty στα μέσα της δεκαετίας του 33

34 1970 (Saaty, 1977, 1980, 1994) Από την ανάπτυξή της, η AHP εφαρμόστηκε σε πολλές πρακτικές εφαρμογές όπως για παράδειγμα αυτές που σχετίζονται με οικονομικό σχεδιασμό, ενεργειακές πολιτικές, υγεία, επίλυση συγκρούσεων, επιλογή έργων, κατανομή προϋπολογισμού και χρόνου κτλ Στην πραγματικότητα η AHP είναι η πιο δημοφιλής πολυκριτηριακή μέθοδος για την λήψη αποφάσεων Η δημοτικότητα της μεθόδου οφείλεται στην ευελιξία και την ευχρηστία της καθώς επίσης και στην ύπαρξη ενός πακέτου λογισμικού του Expert Choice Η AHP μέθοδος εφαρμόστηκε στην τεχνολογία λογισμικού από τους Joachim Karlsson και Kevin Ryan, το 1997 [810] Η μέθοδος χρησιμοποιεί συγκρίσεις των στοιχείων απόφασης ανά δύο για να υπολογίσει τη σχετική τιμή και το κόστος της κάθε μιας απαίτησης έναντι της άλλης Με τη χρήση της AHP, ο μηχανικός απαιτήσεων μπορεί επίσης να επιβεβαιώσει την συνέπεια του αποτελέσματος Η AHP μπορεί να αποφύγει υποκειμενικά λάθη της κρίσης και αυξάνει την αξιοπιστία των αποτελεσμάτων Υπάρχουν πέντε βήματα για την διεκπεραίωση της μεθόδου: 1 Ανασκόπηση των υποψήφιων απαιτήσεων ώστε να είναι πλήρεις 2 Εφαρμογή συγκρίσεων ανά δύο για να υπολογιστεί η σχετική τιμή (σημαντικότητα) της κάθε υποψήφιας απαίτησης 3 Εφαρμογή συγκρίσεων ανά δύο για να υπολογιστεί το σχετικό κόστος των υποψήφιων απαιτήσεων 4 Υπολογισμός της κάθε σχετικής τιμής και του κόστους υλοποίησης των υποψήφιων απαιτήσεων και τοποθέτηση της κάθε μίας σε ένα διάγραμμα κόστους σημαντικότητας 5 Χρήση του διαγράμματος κόστους σημαντικότητας ως χάρτη για την ανάλυση και την κατάταξη της υποψήφιας απαίτησης 32 Aggregate Ranking Measures (ARM) Η μέθοδος Aggregate Ranking Measures (ARM) προτάθηκε από τους Fagin and Kumar το 2001 Σύμφωνα με αυτή τη μέθοδο, υποθέτουμε ότι υπάρχει ένα σύνολο αντικειμένων (στοιχεία δεδομένων) S = {si} που ταξινομείται από Q = {qi} διαφορετικούς ανθρώπους με αποτέλεσμα να δημιουργηθεί ένα σύνολο διαφορετικών ταξινομημένων λιστών R(S, qi) Σκοπός είναι να 34

35 παραχθεί μια τελική ταξινομημένη λίστα, με όλα τα αντικείμενα συνδυάζοντας τις βαθμολογίες που δόθηκαν από κάθε άτομο ξεχωριστά 1] Το συνολικό σκορ για κάθε στοιχείο δεδομένων υπολογίζεται με βάση τα μερικά σκορ που παρέχονται από τις μεμονωμένες λίστες για το συγκεκριμένο στοιχείο δεδομένου Για να συνδυαστούν αυτά τα μεμονωμένα σκορ (Individual Scores - IS) στο τελικό για κάθε στοιχείο δεδομένου, αναθέτεται σε κάθε IS ένα βάρος w i που υποδεικνύει τη σχετική σημαντικότητα Στη συνέχεια, το τελικό αποτέλεσμα για το κάθε στοιχείο δεδομένου καθορίζεται από ένα σταθμικό άθροισμα του IS Η απόδοση του βάρους εξαρτάται από τις προδιαγραφές της εφαρμογής 4 Απαιτήσεις Παρατηρητηρίου Ποιότητας Λογισμικού Ανοιχτού Κώδικα 41 Χαρακτηριστικά Λογισμικού Ανοιχτού Κώδικα Το Λογισμικό Ανοιχτού Κώδικα (ΛΑΚ) είναι ένα εναλλακτικό μοντέλο ανάπτυξης, διάδοσης και χρήσης λογισμικού Κάποιος developer μπορεί να δημιουργήσει ένα πρόγραμμα Ανοιχτού Λογισμικού για να ικανοποιηθούν κάποιες ανάγκες του και στη συνέχεια μπορεί να το διανέμει ελεύθερα στα υπόλοιπα μέλη της κοινότητας και αυτοί θα έχουν την δυνατότητα να το χρησιμοποιήσουν Αυτό το είδος προγράμματος δεν είναι απαραιτήτως Ανοιχτό Λογισμικό Είναι το Ελεύθερο Λογισμικό Ένα πρόγραμμα ανοιχτού λογισμικού διανέμεται μαζί με τον πηγαίο κώδικα στη δυαδική έκδοση του και καθένας μπορεί να ελέγξει τον κώδικα πριν τον μεταγλωττίσει και τον τρέξει Κατά την διάρκεια των χρόνων, ο όρος Ανοιχτό Λογισμικό έχει ερμηνευτεί με διαφορετικούς τρόπους Η Πρωτοβουλία Ανοιχτού Λογισμικού (Open Source Initiative -OSI) δημιουργήθηκε για να προσπαθήσει να τυποποιήσει τον ορισμό και τις άδειες των προγραμμάτων Σύμφωνα με τον ορισμό της OSI, για να είναι ένα λογισμικό Ανοιχτού Κώδικα, θα πρέπει να χαρακτηρίζεται από τα εξής: 17] - Ελεύθερη διανομή - Συμπερίληψη του πηγαίου κώδικα πηγής 35

36 - Δυνατότητα τροποποιήσεων του προγράμματος/ προϊόντος αρκεί αυτό να διανέμεται υπό τους ίδιους όρους με αρχικό - Περιορισμένη διανομή του τροποποιημένου πηγαίου κώδικα σε διανομές διορθώσεων - Καμία διάκριση έναντι σε άτομα ή ομάδες - Καμία διάκριση έναντι σε ειδικούς τομείς - Διανομή της άδειας Η άδεια με την οποία συνοδεύεται το προϊόν, αφορά όλα τα τμήματα του και δεν εξαρτάται από ένα πρόγραμμα που αποτελεί τη συγκεκριμένη διανομή λογισμικού Ένα από τα βασικά σημεία που απαριθμούνται παραπάνω, είναι ότι το ΛΑΚ επιτρέπει τις τροποποιήσεις στον πηγαίο κώδικα ενός προγράμματος που γράφεται από άλλους Ένας προγραμματιστής γράφει ένα (μερικές φορές μικρό) πρόγραμμα και το διανέμει, συνήθως με την αποστολή του σε news groups και από εκείνη τη θέση καθίσταται προσβάσιμο Άλλοι το «κατεβάζουν», το χρησιμοποιούν, το διορθώνουν (εάν επιτρέπεται), και προσθέτουν κάποια χαρακτηριστικά γνωρίσματα έτσι ώστε γίνει πιο χρήσιμο Η δημιουργία είναι μια ομαδική προσπάθεια, και το πρόγραμμα εξελίσσεται (μερικές φορές κατά τη διάρκεια ενός πολύ σύντομου χρονικού διαστήματος) Αυτό το είδος ανάπτυξης έχει παράγει καλά και δημοφιλή προγράμματα Μερικά είναι τόσο δημοφιλή που εμπορικές επιχειρήσεις έχουν αρχίσει να τα υποστηρίζουν Το κοινό έχει αποκριθεί και αποδέχτηκε το λογισμικό ανοιχτού κώδικα Για παράδειγμα, το Linux, ένα από τα δημοφιλέστερα λειτουργικά συστήματα Ανοιχτού Κώδικα, έχει αυξήσει τους χρήστες του σε περισσότερους από 7 εκατομμύρια ανθρώπους Με τη συνεχόμενη αύξηση της δημοτικότητας των προγραμμάτων Ανοιχτού Κώδικα, όλο και περισσότεροι νέοι χρήστες θα προστίθενται, οι οποίοι δε θα είναι απαραίτητα και προγραμματιστές Εντούτοις, αυτοί οι τελικοί χρήστες θέλουν και χρειάζονται προγράμματα εύχρηστα και λειτουργικά και επιθυμούν να διαβιβάσουν τις ανάγκες τους, στην κοινότητα των developers ανοιχτού λογισμικού Οι χρήστες μπορούν πάντα να συμμετέχουν στις συζητήσεις των forums, αλλά συχνά οι συζητήσεις είναι τεχνικού περιεχομένου με αποτέλεσμα να χάνονται ή να μην αισθάνονται άνετοι 22] 36

37 Στον εικονικό κόσμο των έργων ανάπτυξης ανοικτού λογισμικού, δεν υπάρχει γενικά κανένας εταιρικός εργασιακός χώρος ή ενιαία θέση όπου αναπτύσσεται το έργο λογισμικού Κατά συνέπεια, η παραδοσιακή διαπροσωπική επαφή και παρατήρηση των συμμετεχόντων είναι ένα εξαιρετικά σπάνιο φαινόμενο Αυτό που συμβαίνει στην πραγματικότητα γίνεται online (δηλ, σε έναν ιστοχώρο ή αμφίδρομα μέσω των μηχανισμών του Διαδικτύου), δημοσίως διαθέσιμο, και διασκορπισμένο σε διαφορετικές γεωγραφικές και χρονικές ζώνες Οι άτυπες συνομιλίες, καθώς επίσης και οργανωμένες και σχεδιασμένες συναντήσεις (παρόλο που συμβαίνουν σπάνια), πραγματοποιούνται γενικά online με τρόπο ηλεκτρονικό και δημόσια ορατό Παράλληλα, χωρίς να είναι αντιληπτό διεξάγεται και η διαδικασία εξαγωγής των απαιτήσεων Εναλλακτικά, κάποιος θα μπορούσε να αναζητά πληροφορίες που τον ενδιαφέρουν (πχ, ανακοινώσεις έκδοσης λογισμικού ή αναφορές προβλημάτων) σε μηνύματα ηλεκτρονικού ταχυδρομείου, σε πίνακες δελτίων των κοινοτήτων (bulletin boards), ή σε μηνύματα σε σχετικά sites Αυτοί οι τρόποι συμμετοχής σε ένα έργο ανοιχτού λογισμικού δεν είναι καθόλου ασυνήθιστοι, και προτείνονται σε νέα μέλη ως ένα τρόπος να συμμετέχουν στα έργα, να μάθουν τη γλώσσα και τα διάφορα θέματα που σχετίζονται με το αντικείμενο του έργου, χωρίς να ενοχλούν ή να αποσπούν την προσοχή αυτών που ασχολούνται με την ανάπτυξη του έργου Η κοινωνική αλληλεπίδραση μεταξύ των συμμετεχόντων ενός έργου ανοιχτού λογισμικού είναι σπάνια διαπροσωπική στις περισσότερες διεργασίες ανάπτυξης του ελεύθερου λογισμικού Εντούτοις, τα γεγονότα που συμβαίνουν στον πραγματικό κόσμο και όχι στον εικονικό, όπως επαγγελματικά συνέδρια, μπορούν να επιτρέψουν στους απομακρυσμένους συνεργάτες να συναντηθούν, να αλληλεπιδράσουν μεταξύ τους, και να μάθουν ο ένας τον άλλο, αλλά τέτοια γεγονότα μπορούν να πραγματοποιηθούν μόνο μία φορά το χρόνο, ή να είναι απρόσιτα λόγω της απόμακρης θέσης τους Στα έργα ανοικτού λογισμικού, η κοινωνική και τεχνική αλληλεπίδραση εμφανίζεται πρώτιστα σε ένα δικτυωμένο υπολογιστικό περιβάλλον που απαρτίζεται από φυλλομετρητές, ηλεκτρονικό ταχυδρομείο/ bulletin boards (και μερικές φορές προγράμματα άμεσων μηνυμάτων), από editors πηγαίου κώδικα, και από άλλα εργαλεία ανάπτυξης λογισμικού (πχ, μεταγλωττιστές, debuggers, και συστήματα ελέγχου εκδόσεων) Κάθε πρόγραμμα/ εργαλείο 37

38 τρέχει ασύγχρονα στις διαφορετικές διεργασίες των τελικών χρηστών σε γραφικό περιβάλλον χρήστη, ή αποθηκεύεται και διανέμεται σε ένα ή περισσότερα repositories Ο εργασιακός χώρος της ανάπτυξης ανοιχτού λογισμικού είναι η οθόνη μαζί με τα έπιπλα και τον υπόλοιπο περιβάλλοντα χώρο Αυτός ο εργασιακός χώρος γίνεται αντιληπτός μέσω πληκτρολογήσεων και μετακίνησης των ποντικιών σε συνδυασμό με ότι εμφανίζεται στην οθόνη ή δακτυλογραφείται Κατά συνέπεια, για να παρατηρήσει, να συμμετέχει, και να κατανοήσει κάποιος τι συμβαίνει σε ένα έργο ανοικτού λογισμικού, είναι απαραίτητο να τοποθετηθεί και να ενσωματωθεί ως συνεργάτης ή κριτικός, να συμμετέχει σε συζητήσεις ή να γίνει αναγνώστης ενός τέτοιου προγράμματος, ενός τέτοιου δικτυωμένου υπολογιστικού περιβάλλοντος και εργασιακού χώρου [8] 42 Τεχνολογία Απαιτήσεων Λογισμικού Ανοιχτού Κώδικα Στην παραδοσιακή ανάπτυξη λογισμικού υπάρχουν συνολικά 5 διαδικασίες που ακολουθούνται στα πλαίσια της τεχνολογίας απαιτήσεων λογισμικού 1 Η εξαγωγή των απαιτήσεων 2 Η ανάλυση των απαιτήσεων 3 Η προδιαγραφή των απαιτήσεων και η μοντελοποίηση τους 4 Η επικύρωση των απαιτήσεων και τέλος 5 Η διαχείριση των απαιτήσεων Αυτές οι 5 διαδοχικές διαδικασίες στην τεχνολογία απαιτήσεων που αφορούν στο ανοιχτό λογισμικό αντικαθίστανται με 5 νέες διεργασίες 1 Μεταγενέστερες Δηλώσεις 2 Ανάγνωση, κατανόηση και υπευθυνότητα 3 Συνεχόμενα δίκτυα συζητήσεων 4 Συμπυκνωμένες και αυστηρές συζητήσεις 5 Ανοιχτή πρόσβαση στις συζητήσεις Οι διεργασίες αυτές αντιστοιχούν στις διεργασίες της παραδοσιακής ανάπτυξης λογισμικού και αναλύονται παρακάτω Όπως φαίνεται, οι απαιτήσεις ανοιχτού λογισμικού εκφράζονται με πολυάριθμους τρόπους μέσω του Web Οι απαιτήσεις ανοιχτού λογισμικού μπορούν να εμφανιστούν ή να υπονοηθούν μέσα σε ένα μήνυμα ηλεκτρονικού ταχυδρομείου ή μέσα σε μια σειρά συνομιλιών που εστάλη σε 38

39 ένα bulletin board ενός έργου λογισμικού για ανοιχτή κριτική, επεξεργασία, ανασκευή ή τελειοποίηση Οι δηλωμένες δυνατότητες του συστήματος είναι μεταγενέστερες απαιτήσεις που χαρακτηρίζουν μια λειτουργική δυνατότητα που έχει ήδη υλοποιηθεί Οι αρμόδιοι developers αντιστοιχούν τις απαιτήσεις τους με την προσπάθεια που καταβάλλουν για να προγραμματίσουν και να καταστήσουν τις δυνατότητες αυτές λειτουργικές Τα ανώτερα μέλη ή οι βασικοί developers της κοινότητας στη συνέχεια ψηφίζουν ή συμφωνούν μέσω συζητήσεων να συμπεριλάβουν τις δηλωμένες δυνατότητες στο σύστημα Το ιστορικό τεκμήριο θα υπάρχει είτε μέσα σε αρχεία των ή των συζητήσεων που διεξάγονται σε bulletin boards και θα αποδεικνύει ποιος ζήτησε τί, πού, πότε και πώς Παρόλα αυτά, από τη στιγμή που θα δηλωθεί μια φορά, γενικά, δεν γίνεται περαιτέρω προσπάθεια να καταγραφούν επίσημα αυτές οι δυνατότητες ως απαιτήσεις του συστήματος Αυτό έχει ως αποτέλεσμα οι δηλωμένες δυνατότητες να αφομοιώνονται και να θεωρούνται δεδομένες απαιτήσεις και να αντιμετωπίζονται ως προφανείς από αυτούς που ασχολούνται με την ανάπτυξη του συστήματος Η αντίστοιχη διαδικασία της ανάλυσης των απαιτήσεων είναι η ανάγνωση και η κατανόηση των απαιτήσεων και του σχετικού πεδίου Τις περισσότερες φορές οι developers πρέπει να διαβάσουν έρευνες και να ανακτήσουν προηγούμενες γνώσεις τους και εμπειρίες σχετικές με το πεδίο στο οποίο θα αναπτύξουν το σύστημα Η προσεκτική μελέτη μπορεί να περιλαμβάνει πολλαπλές αναγνώσεις άρθρων και κατανόηση που εξαρτάται από την ειδίκευση του κάθε ένα και την προηγούμενη εμπειρία ανάπτυξης αντίστοιχων συστημάτων Η ανάλυση των απαιτήσεων ανοιχτού λογισμικού δεν περιλαμβάνει σχεδόν καθόλου αυτοματοποιημένη ανάλυση, λογική ή οπτική αναπαράσταση των προδιαγραφών απαιτήσεων Παρόλα αυτά, οι συμμετέχοντες σε ένα έργο ανάπτυξης ανοιχτού λογισμικού είναι σε θέση να κατανοούν ποιες είναι οι λειτουργικές και ποιες οι μη λειτουργικές απαιτήσεις ώστε να καθοδηγούνται σε συνεχής ανάπτυξη και χρήση ρουτινών από διάφορα είδη ανοιχτού λογισμικού Η διαδικασία της προδιαγραφής των απαιτήσεων και της μοντελοποίησης αντιστοιχεί στην συνεχόμενη εμφάνιση δικτύων συζητήσεων Οι απαιτήσεις μπορούν να προκύψουν από τις εμπειρίες των μελών των κοινοτήτων μέσω των ηλεκτρονικών μηνυμάτων τους και των μηνυμάτων σε bulletin boards 39

40 Αυτές οι επικοινωνίες με τη σειρά τους δίνουν ώθηση στην ανάπτυξη επιπλέον περιγραφών που προσδιορίζουν με λακωνικότητα και περιεκτικότητα τις λειτουργικές και μη λειτουργικές απαιτήσεις μέσα από δίκτυα συζητήσεων Αυτές οι συζητήσεις προσφέρουν περιγραφές και μπορούν να βρεθούν σε μηνύματα ηλεκτρονικού ταχυδρομείου, σε αρχεία φόρουμ συζητήσεων, σε ιστοσελίδες που συγκεντρώνονται πληροφορίες σχετικές για τις κοινότητες και σε άλλες ανεπίσημες περιγραφές λογισμικού που αποστέλλονται, ή αναφέρονται άρρητα, μέσω υποθέσεων κοινής λογικής, που τα μέλη μιας κοινότητας αναμένουν να έχουν οι υποστηρικτές τους Τα δίκτυα συζητήσεων που αναπτύσσονται οι απαιτήσεις ανοιχτού λογισμικού είναι: - Σειρά μηνυμάτων ηλεκτρονικού ταχυδρομείου ή συνομιλιών σε bulletin boards - Δηλώσεις για το αναμενόμενο σύστημα - Ιδέες σχετικά με τη λειτουργικότητα του συστήματος - Προωθητική ενθάρρυνση να προδιαγραφούν και να αναπτυχθούν όλες οι λειτουργίες που χρειάζονται με κατάληξη μιας θέσης εργασίας - Ακαδημαϊκές επιστημονικές ερευνητικές δημοσιεύσεις που υπογραμμίζουν πως οι απαιτήσεις του συγκεκριμένου λογισμικού, παρόλο που είναι πολύπλοκες κατανοούνται, χωρίς περαιτέρω εξηγήσεις αφού βασίζονται σε προηγούμενη επιστημονική γνώση και σε ανοιχτή επιστημονικής μελέτη Κάθε ένα είδος αυτών των συζητήσεων, όπως και η web προδιαγραφή είναι μια συνεχής πηγή απαιτήσεων ανοιχτού λογισμικού από νέους συνεργάτες, ή συμμετέχοντες, νέες ιδέες, νέες επαγγελματικές ευκαιρίες και νέες επιστημονικές δημοσιεύσεις Οι απαιτήσεις λογισμικού επικυρώνονται ανάλογα με την υλοποίηση του λογισμικού Οι απαιτήσεις για το ανοικτό λογισμικό δεν είναι ξεχωριστή και ανεξάρτητη διαδικασία αλλά συμβαίνει παράλληλα με το σχεδιασμό, την υλοποίηση, και τις περιγραφές ελέγχου, καθώς επίσης και με τη συγγραφή των εγχειριδίων των χρηστών και τις περιγραφές χρήσης (πχ, δεδομένα εισόδου κτλ) Ομοίως, οι απαιτήσεις διαδίδονται στα διαφορετικά είδη ηλεκτρονικών εγγράφων συμπεριλαμβανομένων αυτών των ιστοσελίδων, των υπερσυνδέσμων, των καταλόγων πηγαίου κώδικα, των μηνυμάτων 40

41 ηλεκτρονικού ταχυδρομείου, και άλλων Σε κάθε κοινότητα, οι απαιτήσεις περιγράφονται, βεβαιώνονται, ή υπονοούνται ανεπίσημα Οι απαιτήσεις λογισμικού εξελίσσονται σε τέτοια μορφή ώστε να γίνονται κατάλληλες για την επικύρωση Η επικύρωση των απαιτήσεων είναι ένα υπονοούμενο υποπροϊόν, παρά ένας ρητός στόχος, και σχετίζεται με το πώς αυτές κατασκευάζονται, περιγράφονται, συζητούνται, αναφέρονται από άλλες και συνδέονται με άλλες ανεπίσημες περιγραφές του συστήματος και της υλοποίησής τους Ένα ιδιαίτερο χαρακτηριστικό γνώρισμα του ανοικτού λογισμικού είναι ότι οι απαιτήσεις του, καθώς είναι ανεπίσημες, οργανώνονται και αποθηκεύονται συνεχώς σε μια μορφή που είναι μόνιμα προσβάσιμη από όλους (ανοιχτή) Το ίδιο ισχύει για τους ιστοχώρους των κοινοτήτων, το περιεχόμενο και τους υπερσυνδέσμους των ιστοχώρων, τους καταλόγους του πηγαίου κώδικα, τα μηνύματα ηλεκτρονικού ταχυδρομείου και των συζητήσεων στα bulletin boards, στις περιγραφές των γνωστών σφαλμάτων και στις επιθυμητές βελτιώσεις των συστημάτων, στα αρχεία των διαφόρων εκδόσεων των συστημάτων, και αλλού Η επιμονή, η οργάνωση με υπερκείμενο, και η ανοιχτή πρόσβαση στις περιγραφές που εμφανίζονται στο ανοιχτό λογισμικό δεν έχουν τόσο μεγάλη αποδοχή στις κλασικές προσεγγίσεις της τεχνολογίας απαιτήσεων, εκτός από λίγες εξαιρέσεις Κάθε ένα από τα χαρακτηριστικά που αναφέρθηκαν παραπάνω βοηθά στην επικοινωνία των ανοικτών απαιτήσεων λογισμικού Αυτά τα χαρακτηριστικά συμβάλλουν επίσης στη δυνατότητα των συμμετεχόντων να παρακολουθούν την ανάπτυξη και την εξέλιξη των απαιτήσεων λογισμικού και μέσα στις περιγραφές ανάπτυξης λογισμικού, καθώς επίσης και μεταξύ των συμμετεχόντων στην κοινότητα 43 Παρατηρητήριο Ποιότητας Λογισμικού Ανοιχτού Κώδικα Το Παρατηρητήριο Ποιότητας Λογισμικού Ανοιχτού Κώδικα (Software Quality Observatory for Open Source Software SQO-OSS) είναι μια διεθνής συνεργασία των κυρίαρχων ευρωπαϊκών έργων λογισμικού ανοιχτού κώδικα, συμβούλων και ερευνητών από την Ελλάδα, την Μεγάλη Βρετανία, την Γερμανία και την Σουηδία που σκοπό έχει την ανάπτυξη μιας ευρείας σουίτας εργαλείων για την αξιολόγηση της ποιότητας του λογισμικού Αυτά τα εργαλεία θα δημιουργήσουν αντικειμενικές βάσεις για την ανάλυση και την αξιολόγηση 41

42 του Λογισμικού Ανοιχτού Κώδικα (ΛΑΚ) Σύμφωνα με το χρονοδιάγραμμά του, αναμένεται να ολοκληρωθεί το Φεβρουάριο του 2009 Σκοπός του SQO-OSS είναι να υποστηρίξει τους ευρωπαίους developers λογισμικού ώστε να βελτιώσουν την ποιότητα του κώδικά τους και να απομακρύνει ένα από τα εμπόδια που υπάρχουν για την συμμετοχή στο ΛΑΚ με την επιστημονική απόδειξη της ποιότητάς του [23] Το έργο θα δημιουργήσει ένα νέο υπόβαθρο για την εισαγωγή μιας ποικιλίας καινοτόμων μετρικών ποιότητας λογισμικού και για τον συνδυασμό αυτών των μετρικών μέσω της χρήσης της εξόρυξης δεδομένων και της τεχνητής νοημοσύνης για να παράγει ξεκάθαρες ποιοτικές αξιολογήσεις τόσο για τους χρήστες του λογισμικού όσο και για τους developers Το project θα δημιουργήσει μια plug-in πλατφόρμα για την αξιολόγηση της ποιότητας με web και IDE front-end Θα αναπτύξει ένα σύνολο μετρικών λογισμικού που θα λαμβάνουν υπόψη τους δείκτες ποιότητας που βρίσκονται μέσα στα repositories των έργων ανοιχτού κώδικα Θα δημοσιεύσει ένα πίνακα με εφαρμογές Ανοιχτού Κώδικα που θα ταξινομείται σύμφωνα με την ποιότητά τους Θα διαθέσει ένα λογισμικό με BSD άδεια για να επιτρέψει την περαιτέρω ανάπτυξη από τις κοινότητες και τη βιομηχανία του Ανοιχτού Κώδικα 431 Σκοπός του Συστήματος Οι άνθρωποι που εμπλέκονται με κάποιο τρόπο σε μια διαδικασία λήψης απόφασης με σκοπό την επιλογή του σωστού λογισμικού που χρησιμοποιείται για έναν συγκεκριμένο σκοπό, αναλύουν την ποιότητα των υποψήφιων συστημάτων - μερικές φορές χωρίς καν να το γνωρίζουν Εντούτοις, δεδομένου ότι κάθε πρόσωπο που βρίσκεται σε αυτήν την θέση δεν είναι απαραίτητο να είναι developer ή μηχανικός λογισμικού, η ποιότητα ενός συστήματος λογισμικού αξιολογείται με βάση την ευχρηστία του Στη σπάνια περίπτωση, που ασχολούνται με την επιλογή ενός λογισμικού άνθρωποι που έχουν το σχετικό υπόβαθρο, και μπορούν να καταλάβουν τον πηγαίο κώδικα και να υποθέσουν το σχεδιασμό του λογισμικού, ο πηγαίος κώδικας δεν είναι διαθέσιμος επειδή το λογισμικό διατίθεται με «κλειστή» 42

43 άδεια Η εκτίμηση της ποιότητας των προϊόντων περιπλέκεται ακόμη περισσότερο Κάτω από αυτές τις περιστάσεις, το λογισμικό που χρησιμοποιείται ούτε κατανοείται πλήρως ούτε αξιολογείται, έχει όμως επιπτώσεις στην καθημερινή ζωή μας Μπορούμε να αποδεχτούμε ένα επίπεδο ποιότητας αν αυτή ανταποκρίνεται στις προδιαγραφές που έχουν οριστεί, αν το λογισμικό καλύπτει ορισμένες ανάγκες, ανάλογα με το βαθμό της σαφήνειας και της κατανόησης του πηγαίου κώδικα ή το βαθμό της απόδοσής του Η ποιότητα επιπλέον μπορεί να υπολογιστεί λαμβάνοντας υπόψη τον ανθρώπινο παράγοντα ανάλογα με το βαθμό που ένα λογισμικό ικανοποιεί τον πελάτη ή τις ανάγκες ή τις προσδοκίες των χρηστών Ανεξάρτητα από το πόσο εξετάζουμε την ποιότητα κάθε φορά, αυτή δεν παύει να είναι σημαντικός παράγοντας Τα πλεονεκτήματα και τα αποτελέσματα ενός καλού σχεδιασμού λογισμικού είναι πολλαπλά έναντι μιας κακώς σχεδιασμένης λύσης Από ένα καλό σχεδιασμό, προκύπτει λογισμικό που ικανοποιεί τις ανάγκες των χρηστών περισσότερο, αναπτύσσεται σε λιγότερο χρόνο, λειτουργεί με μεγαλύτερη αξιοπιστία, και κοστίζει πολύ λιγότερα χρήματα σε όλα τα στάδια της διάρκειας της ζωής του Επομένως από την πλευρά του μηχανικού λογισμικού είναι σημαντικό να είναι σε θέση να διακρίνει έναν καλό ή κακό σχεδιασμό και να συσχετίσει κάποια χαρακτηριστικά του πηγαίου κώδικα και των αρχιτεκτονικών σχεδίων με την ποιότητα λογισμικού προκειμένου να είναι σε θέση να επαναχρησιμοποιήσει την εμπειρία του στο σχεδιασμό καλύτερων συστημάτων στο μέλλον Στην τεχνολογία λογισμικού συχνά, εξωτερικά ποιοτικά χαρακτηριστικά συσχετίζονται με εσωτερικά ποιοτικά χαρακτηριστικά και έτσι μετρήσεις του πηγαίου κώδικα παρέχουν χρήσιμα στοιχεία για την αξιολόγηση της ποιότητάς του Σε αντίθεση με το ιδιόκτητο λογισμικό του οποίου ο πηγαίος κώδικας δεν είναι δημόσια διαθέσιμος, το ΛΑΚ μας επιτρέπει να εξετάσουμε και να αναλύσουμε τον πραγματικό κώδικα και να εκτελέσουμε δοκιμές Εκτός από τον πηγαίο κώδικα, τα έργα ΛΑΚ επιτρέπουν τη δημόσια πρόσβαση στα συστήματα ελέγχου εκδόσεων, στις λίστες ηλεκτρονικού ταχυδρομείου και στις διάφορες βάσεις δεδομένων Εκεί μπορούν να βρεθούν πολλές πληροφορίες για τη διαδικασία ανάπτυξης και διαχείρισης Η εκρηκτική αύξηση της κίνησης 43

44 προς το ΛΑΚ παρέχει μια πολύ μεγάλη συλλογή πηγαίου κώδικα που πρέπει να αναλυθεί και να αξιολογηθεί Ο σκοπός του συστήματος SQO- OSS είναι να αξιολογήσει τα εσωτερικά ποιοτικά χαρακτηριστικά των έργων ΛΑΚ με τρόπο αυτόματο, παραγωγικό και αντικειμενικό και να τα παρουσιάσει στο χρήστη κατά τρόπο κατάλληλο Τα ποιοτικά χαρακτηριστικά θα προέλθουν όχι μόνο από τον πηγαίο κώδικα των έργων ΛΑΚ, αλλά και από πρόσθετα στοιχεία που είναι αποκλειστικά διαθέσιμα στα έργα ΛΑΚ, όπως από τις λίστες ηλεκτρονικού ταχυδρομείου, ιστορικά στοιχεία ανάπτυξης, πληροφορίες ανίχνευσης λαθών και μηνύματα των φόρουμ Το σύνολο των μετρικών που υπολογίζονται από το ΛΑΚ θα είναι διαθέσιμο μέσω μιας δημόσιας διεπαφής Μακροπρόθεσμα, οι μετρικές που θα συλλεχθούν, θα επιτρέψουν στους developers του ΛΑΚ να εφαρμόσουν τις προσπάθειές τους σε εκείνα τα μέρη του λογισμικού που έχουν ανάγκη από βελτίωση της ποιότητας και να επιτρέψουν στους τελικούς χρήστες του ΛΑΚ να επιλέξουν μεταξύ των διάφορων έργων ΛΑΚ με βάση την αντικειμενική υπολογισμένη ποιότητά τους Το πακέτο λογισμικού που θα αναπτυχθεί από το SQO - OSS ονομάζεται «Αλήθεια» Με αυτό τον ελληνικό όρο οι συντελεστές του project προσπαθούν να δείξουν την ακριβή αλήθεια την οποία στοχεύει να παρέχει για το ΛΑΚ Το λογισμικό αποτελείται από έναν βασικό πυρήνα που ενεργεί ως βάση για τις όχι τόσο αυστηρά συνδεμένες pluggable ενότητες Αυτές οι ενότητες (plugins) θα παράσχουν τη βασική λειτουργία του συστήματος σε άλλα plugins που θα χειριστούν τη συλλογή των στοιχείων από έργα ΛΑΚ και την ανάλυση των στοιχείων αυτών Ο πυρήνας δεν εκτελεί κανένα υπολογισμό αλλά συντονίζει τη λειτουργία των plugins και παρέχει τα βασικά κανάλια επικοινωνίας μεταξύ των plugins και οποιωνδήποτε εξωτερικών οντοτήτων, όπως για παράδειγμα ένας δημόσιος ιστοχώρος του project Σκοπός του συστήματος δεν είναι μόνο να δημιουργηθεί μια μεγάλη αρχειακή συλλογή των στοιχείων που συλλέγονται από τα έργα ΛΑΚ Μερικά από αυτά τα δεδομένα μπορούν να ληφθούν από εξωτερικές πηγές του συστήματος, όπως η βάση δεδομένων του προγράμματος FLOSSMetrics Το λογισμικό Alitheia θα υπολογίσει ένα σύνολο βασικών μετρικών ποσοτικοποιώντας τα εσωτερικά ποιοτικά χαρακτηριστικά ενός έργου ΛΑΚ, αλλά θα επεκταθεί με περισσότερα plugins μετρικών Το SQO-OSS θα παράσχει ένα περιβάλλον 44

45 που θα επιτρέψει τη δημιουργία και την επικύρωση των μεθοδολογιών ποιοτικής αξιολόγησης λογισμικού Προκειμένου να επιτευχθεί αυτό, το σύστημα θα προσφέρει ένα module που μπορεί να χρησιμοποιηθεί μέσα από ένα δημοφιλές ενσωματωμένο περιβάλλον ανάπτυξης λογισμικού και θα ενεργήσει όχι μόνο ως στρώμα παρουσίασης παρόμοιο με το δημόσιο ιστοχώρο που προσφέρει περισσότερο αναλυτικές πληροφορίες, αλλά και ως δοκιμή για νέα modules που οι χρήστες έχουν αναπτύξει και επιθυμούν να δοκιμάσουν προτού τα υποβάλλουν και τα συμπεριλάβουν στο σύστημα Στο SQO-OSS, το σύστημα «Αλήθεια» θα προσφέρει μια κεντρική αποθήκη δεδομένων (repository) όπου θα αποθηκεύονται οι πληροφορίες που εξάγονται από τα έργα ΛΑΚ Αυτές οι πληροφορίες θα συγκεντρώνονται χρησιμοποιώντας μια πλατφόρμα λογισμικού πυρήνων που θα χαρακτηρίζεται από μια pluggable αρχιτεκτονική και θα της επιτρέψει να είναι επεκτάσιμη, να ενσωματώσει τους διάφορους τύπους πηγών δεδομένων και να είναι προσβάσιμη μέσω διάφορων interfaces Κάθε pluggable τμήμα (plugin) θα υλοποιεί μια συγκεκριμένη εργασία, είτε σχετική με την απόκτηση και την επεξεργασία των δεδομένων είτε με την ανάλυση και την παρουσίαση τους Τα ξεχωριστά υποσυστήματα που θα περιλάβουν το σύστημα παρουσιάζονται στο σχήμα, και περιλαμβάνουν: Εικόνα 4 Υποσυστήματα SQO-OSS 45

46 Το υποσύστημα απόκτησης δεδομένων, το οποίο θα χειριστεί την εισαγωγή και την προεπεξεργασία των μη δομημένων και των ημιδομημένων δεδομένων που είναι διαθέσιμα για τα έργα ΛΑΚ, καθώς επίσης και η αποθήκευση των κανονικοποιημένων δεδομένων στη διαμοιραζόμενη αποθήκη συστημάτων Στην πράξη, αυτό σημαίνει ότι το σύστημα SQO-OSS θα αποθηκεύσει ένα πλήρες αντίγραφο των δεδομένων του project (αποθήκη πηγαίου κώδικα, αρχεία λιστών ηλεκτρονικού ταχυδρομείου και ενδεχομένως και άλλες πηγές δεδομένων) για κάθε έργο ΛΑΚ που μελετάται Τα plugins για αυτό το υποσύστημα είναι αρμόδια να προσκομίσουν και να κανονικοποιήσουν δεδομένα που προέρχονται από έργα ΛΑΚ και να αποθηκεύσουν τα κανονικοποιημένα δεδομένα στον κεντρικό υπολογιστή του SQO- OSS Το υποσύστημα ανάλυσης δεδομένων, το οποίο θα εκτελέσει τις διάφορες αναλύσεις στα συλλεχθέντα δεδομένα και θα αποθηκεύσει τα αποτελέσματα με μια δομημένη μορφή μέσα στο κοινό repository του συστήματος Τα plugins, για αυτό το υποσύστημα, υπολογίζουν τις ποιοτικές μετρικές βασισμένες σε τμήματα των δεδομένων έργων ΛΑΚ που είναι διαθέσιμα στο σύστημα του SQO- OSS Οι τύποι των τιμών των μετρικών είναι επεκτάσιμοι, ώστε να μη περιοριστεί κάθε μετρική (παραδείγματος χάριν σε ένα διάστημα A [ 0 1 ]) Τα plugins στο υποσύστημα ανάλυσης δεδομένων μπορούν να λαμβάνουν υπόψη τους όλα όσα ξέρει το SQO- OSS για ένα συγκεκριμένο ΛΑΚ ή να είναι ένα plugin που εξετάζει ένα ενιαίο αρχείο που είναι μέρος ενός έργου ΛΑΚ Τα Plugins, όπου είναι δυνατόν, θα παράσχουν αναλυτικές πληροφορίες για τις τιμές κάποιων συγκεκριμένων μετρικών Τα πρόσθετα plugins στο υποσύστημα ανάλυσης θα είναι αρμόδια για τη συγκέντρωση όλων των μετρικών σε μια συνολική μετρική ποιότητας για ένα ΛΑΚ Το υποσύστημα αλληλεπίδρασης χρήστη, που θα χρησιμοποιηθεί για να επιτηρήσει και να ελέγξει τη λειτουργία όλων των άλλων υποσυστημάτων, καθώς επίσης και να χειριστεί την παρουσίαση των αποτελεσμάτων που θα προκύπτουν από την ανάλυση των πληροφοριών στους χρήστες του συστήματος 46

47 Τα plugins για το υποσύστημα αλληλεπίδρασης χρηστών θα αντιμετωπίσουν πρώτιστα τα ζητήματα της παρουσίασης: κάθε τύπος μετρικής (που ενδεχομένως θα συνοδεύεται από τη λεπτομερή αναφορά του) πρέπει να παρουσιαστεί χωριστά Ένα πρόσθετο μέρος του υποσυστήματος αλληλεπίδρασης χρηστών θα εξετάσει την ανατροφοδότηση χρηστών και τα αιτήματα που θα υποβάλλονται για το σύστημα SQO- OSS Οι μετρικές που υπολογίζονται από το SQO- OSS εφαρμόζονται όχι μόνο στα αποτελέσματα των έργων (δηλαδή στα προϊόντα) αλλά και στη μεθοδολογία και στη διαδικασία που χρησιμοποιήθηκε για να αναπτυχθούν Τέτοιες μετρικές μπορούν να δέχονται αιτήματα χρηστών που ενδιαφέρονται για ποιοτικά χαρακτηριστικά ενός συγκεκριμένου έργου ΛΑΚ ή μπορούν να χρησιμοποιηθούν ως είσοδος σε προβλεπτικά μοντέλα Οι υπολογισμένες μετρικές θα χρησιμοποιηθούν για να τροφοδοτήσουν μοντέλα που προβλέπουν διάφορες πτυχές της εξέλιξης των έργων που εξετάζονται Αυτά τα βήματα θα επαναληφθούν προκειμένου να αντιμετωπιστούν οι αλλαγές που εμφανίζονται στα προγράμματα που αναλύονται Η έκβαση των ανωτέρω βημάτων θα χρησιμοποιηθεί για να απαντηθούν τα ερωτήματα των χρηστών που επιθυμούν να συγκρίνουν έργα ΛΑΚ ή να αναζητήσουν πληροφορίες σχετικά με τα χαρακτηριστικά γνωρίσματα που παρέχονται από τα συγκεκριμένα projects Το σύστημα «Αλήθεια», έχει τέσσερις διαφορετικές πτυχές Υιοθετούμε μια διπλή προσέγγιση για την παροχή των μετρικών των έργων ΛΑΚ και για την δυνατότητα επέκτασης και την παροχή νέων μετρικών Οι ίδιες οι μετρικές παρουσιάζονται είτε με λεπτομέρεια (και αφορούν τους developers) είτε σε σύνολο (παρουσίαση περισσότερο προσανατολισμένη στο project) Κατ' αυτό τον τρόπο η ακριβής αξιολόγηση των εσωτερικών ποιοτικών χαρακτηριστικών των έργων ΛΑΚ μπορεί να χρησιμοποιηθεί και από τους developers για να βελτιώσουν την ποιότητα των projects, αλλά και από το ευρύ κοινό για να αξιολογήσει και να επιλέξει τα εκείνα τα προγράμματα ΛΑΚ για τη χρήση στη βιομηχανία και στις μικρομεσαίες επιχειρήσεις (Small Medium Enterprise - SME) Σκοπός του συστήματος από την πλευρά των χρηστών είναι να παρασχεθεί μια πλατφόρμα για την αξιολόγηση της ποιότητας του ΛΑΚ Προκειμένου να 47

48 επιτευχθεί αυτός, το σύστημα συλλέγει πληροφορίες για έργα ΛΑΚ που παρατίθενται στα δημοφιλή sites που σχετίζονται με τη διαχείριση της διαμόρφωσης λογισμικού, τις λίστες ηλεκτρονικού ταχυδρομείου, και τις υπηρεσίες ανίχνευσης σφαλμάτων Η λίστα του λογισμικού που εξετάζεται από το σύστημα «Αλήθεια» του SQO- OSS μπορεί να επεκταθεί μετά από αίτημα των χρηστών Μόλις προστεθεί ένα έργο ΛΑΚ στο SQO- OSS, οι χρήστες - ανάλογα με το επίπεδο της γνώσης και της εμπειρίας τους - μπορούν να χρησιμοποιήσουν το σύστημα με διάφορους τρόπους και να συμβάλουν ακόμη και στην προώθηση του ΛΑΚ που χρησιμοποιούν ή αναπτύσσουν Η πλειοψηφία των χρηστών επιθυμεί να πληροφορηθεί γενικά για ένα έργο, προκειμένου να αξιολογήσει την ποιότητά του Τέτοιες γενικές πληροφορίες μπορούν να περιλάβουν τον αριθμό των λαθών που περιλαμβάνονται στην πιο πρόσφατη έκδοσή, ή τον αριθμό των developers που συνεισφέρουν ενεργά Προκειμένου να επιτευχθεί αυτό χρησιμοποιούν μια απλή, web-based διεπαφή χρήστη που τους επιτρέπει να εκτελέσουν τις ακόλουθες ενέργειες: Εάν δεν υπάρχουν διαθέσιμα δεδομένα στο σύστημα για το λογισμικό που αναζητούν, οι χρήστες μπορούν να παρέχουν στο σύστημα ένα αίτημα προς επεξεργασία Κατά την υποβολή του αιτήματός τους μπορούν να ζητήσουν να ενημερωθούν για το πέρας της επεξεργασίας από το σύστημα Στην περίπτωση που είναι χρήστες ενός προγράμματος ΛΑΚ, είναι σε θέση να παρέχουν μια βαθμολογία για κάποια γενικά χαρακτηριστικά γνωρίσματα που θα πρέπει να έχει ένα πρόγραμμα ΛΑΚ, βασισμένη στις προσωπικές εκτιμήσεις τους Κάθε βαθμολογία, μπορεί να συνοδεύεται από μια ελεύθερη αιτιολόγηση σχετικά με τους λόγους που οδήγησαν το χρήστη να επιλέξει το συγκεκριμένο βαθμό Η βαθμολογία και ο σχολιασμός συλλέγονται και τίθενται στη διάθεση όχι μόνο άλλων χρηστών αλλά και στους developers, που αν λάβουν υπόψη τους τα παραπάνω μπορούν να βελτιώσουν το λογισμικό που δημιουργούν Επομένως υπάρχει μια γενική ανατροφοδότηση προς τις κοινότητες ανάπτυξης του λογισμικού Οι περισσότερο προχωρημένοι και πεπειραμένοι χρήστες μπορούν να εκτελέσουν οποιεσδήποτε από τις ανωτέρω εργασίες Συνήθως όμως η αναζήτησή τους αφορά σε περισσότερο αναλυτικές πληροφορίες και γι αυτό 48

49 έχουν τη δυνατότητα να επιλέξουν τον «προχωρημένο» τρόπο λειτουργίας, προκειμένου: Να λάβουν πληροφορίες για συγκεκριμένες μετρήσεις και μετρικές που είναι διαθέσιμες σε διαφορετικό επίπεδο (ανά module ή αρχείο) Να συγκρίνουν διαφορετικές εκδόσεις του ίδιου project σε διαφορετικά επίπεδα (αρχείο, module, συνολικό) όσον αφορά ένα σύνολο μετρικών Να εντοπίσουν χαρακτηριστικά στον πηγαίο κώδικα ενός project με τη χρησιμοποίηση λέξεων κλειδιών απλού κειμένου ή τυποποιημένα πρότυπα από μια λίστα με προκαθορισμένες επιλογές Κατά συνέπεια, τα διαθέσιμα δεδομένα παρουσιάζονται με έναν τρόπο που είναι χρήσιμος για τις διαφορετικές ομάδες-στόχους χρηστών που περιγράφονται παρακάτω( Βλ 432) Τέλος, οι developers των έργων ΛΑΚ έχουν πρόσβαση σε όλη την ανωτέρω λειτουργία μέσω μιας διαφορετικής διεπαφής που είναι ενσωματωμένο στο περιβάλλον ανάπτυξής που χρησιμοποιούν Οι developers έχουν τη δυνατότητα να δημιουργήσουν προσαρμοσμένα plugins που μπορούν να χρησιμοποιήσουν τοπικά προκειμένου να εκτελεσθούν μετρήσεις και υπολογισμοί μετρικών ή κάποια προσαρμοσμένη ανάλυση των έργων τους, ακολουθώντας ένα Application Programming Interface (API) που έχει τεθεί στην διάθεση τους Εάν θεωρήσουν ότι το plugin τους είναι χρήσιμο και σταθερό, μπορούν να το υποβάλουν στο σύστημα, έτσι ώστε θα εκτελεσθεί σε όλο το λογισμικό που έχει εξεταστεί ή αναλύεται ανά τακτά χρονικά διαστήματα, καθιστώντας κατά συνέπεια τα αποτελέσματά του διαθέσιμα σε όλους τους χρήστες του συστήματος 432 Χρήστες του Συστήματος Το σύστημα λογισμικού που θα δημιουργηθεί στα πλαίσια του SQO-OSS προορίζεται να χρησιμοποιηθεί από πολλές διαφορετικές κατηγορίες χρηστών, οι οποίες ποικίλλουν όσο αφορά το εκπαιδευτικό υπόβαθρο, τη σχέση τους με τους υπολογιστές και με την ανάπτυξη ΛΑΚ, και τους λόγους για τους οποίους αλληλεπιδρούν με το σύστημα Οι σημαντικότερες ομάδες χρηστών του συστήματος που έχουν προσδιοριστεί και έχουν ταξινομηθεί περιλαμβάνουν τους: 1 Γενικούς χρήστες που αναζητούν πληροφορίες για projects ΛΑΚ 2 Developers ΛΑΚ 49

50 3 Συμβούλους IT 4 IT Managers 5 Ερευνητές 6 Διαχειριστή συστήματος Τα συγκεκριμένα χαρακτηριστικά κάθε μιας από τις προαναφερθείσες ομάδες παρουσιάζονται στις ακόλουθες παραγράφους 1 Γενικοί Χρήστες που αναζητούν πληροφορίες για projecs ΛΑΚ Αυτή η ομάδα χρηστών περιέχει τους ανθρώπους που θα χρησιμοποιήσουν γενικά το σύστημα σποραδικά ως εργαλείο που θα τους επιτρέψει να αξιολογήσουν τις διάφορες λύσεις ΛΑΚ για μια συγκεκριμένη και πιθανότατα επαναλαμβανόμενη ανάγκη Αυτό σημαίνει ότι θα χρησιμοποιούν το σύστημα όταν έχουν μια συγκεκριμένη ανάγκη και ψάχνουν ένα σύστημα λογισμικού για να την καλύψουν, έτσι ώστε μπορούν να το χρησιμοποιήσουν άμεσα Τα χαρακτηριστικά τους συνοψίζονται ακολούθως: Μόρφωση: Από απόφοιτους λυκείου ως και πτυχιούχους και Διδάκτορες Πανεπιστημίου Αυτή η κατηγορία μπορεί να περιέχει οποιοδήποτε πρόσωπο που είναι σε θέση να χρησιμοποιεί έναν προσωπικό υπολογιστή Εξοικείωση με τους υπολογιστές: Από βασικές γνώσεις λειτουργίας ενός προσωπικού υπολογιστή μέχρι καθημερινής χρήσης ενός υπολογιστή είτε στο σπίτι είτε στην εργασία Εξοικείωση με το ΛΑΚ: Μπορεί να κυμανθεί από την πλήρη έλλειψη εμπειρίας ως την πλήρη υποστήριξη του ΛΑΚ Ηλικία: Μπορεί να περιέχει τους ανθρώπους όλων των ομάδων ηλικίας Αναμενόμενη συχνότητα χρήσης: Περιστασιακή Λόγοι της χρήσης: Οι άνθρωποι σε αυτήν την ομάδα θα χρησιμοποιούν το σύστημα προκειμένου να γίνει μια (γρήγορη) αξιολόγηση της ποιότητας των συστημάτων λογισμικού που μπορούν να εκπληρώσουν μια από τις άμεσες ανάγκες τους, και να επιλεχτεί η λύση που ταιριάζει καλύτερα στις απαιτήσεις τους Με άλλα λόγια, είναι πιθανοί χρήστες ΛΑΚ Κριτήρια αξιολόγησης: Τα κριτήρια που θα εφαρμόσουν οι χρήστες για την επιλογή ενός συστήματος λογισμικού έναντι ενός άλλου είναι συνήθως εξωτερικά ποιοτικά κριτήρια, όπως η ευχρηστία και ο σχεδιασμός της διεπαφής του συστήματος λογισμικού, ή η δυσκολία (από την άποψη του 50

51 χρόνου και του κόστους) υποστήριξης για ένα πρόβλημα που θα εμφανιστεί κατά τη διάρκεια της χρήσης του Επίπεδο αλληλεπίδρασης: Οι χρήστες σε αυτήν την ομάδα θα αλληλεπιδράσουν με το σύστημα μόνο στο επίπεδο της παρουσίασης Στην ουσία θα χρησιμοποιήσουν πιθανώς το σύστημα στην αναζήτηση λογισμικού που εκπληρώνει κάποια ανάγκη και θα συγκρίνουν τις διάφορες λύσεις, ή θα ζητήσουν από το σύστημα να αναλυθεί ένα λογισμικό οπότε θα ειδοποιούνται όταν η επεξεργασία έχει ολοκληρωθεί και θα είναι διαθέσιμα τα αποτελέσματα της επεξεργασίας Η αλληλεπίδραση θα βασίζεται σε ένα Web interface, πχ ο δημόσιος ιστοχώρος του SQO-OSS 2 Developers ΛΑΚ Αυτή η ομάδα περιέχει τους ανθρώπους που είναι ενεργοί συμμετέχοντες στην κοινότητα ΛΑΚ Περιλαμβάνει τους ανθρώπους που είναι με οποιοδήποτε τρόπο ενεργά μέλη των κοινοτήτων ΛΑΚ Σύμφωνα με αυτόν τον ορισμό, οι άνθρωποι που ανήκουν σε αυτήν την ομάδα είναι software developers και μεταφραστές, συντάκτες εγγράφων τεκμηρίωσης, διαχειριστές και moderators ιστοχώρων, λιστών ηλεκτρονικού ταχυδρομείου, βάσεων δεδομένων σφαλμάτων, άνθρωποι που παρέχουν online υποστήριξη για ένα ΛΑΚ μέσω λιστών ηλεκτρονικού ταχυδρομείου, φόρουμ και wikis, και γενικά καθένας που βοηθά στην προώθηση του ΛΑΚ με οποιοδήποτε τρόπο Τόσο οι άνθρωποι που πληρώνονται από τους εργοδότες τους για να εργαστούν σε έργα ΛΑΚ κατά τη διάρκεια της ημέρας τους στη δουλειά όσο και εκείνοι που αφιερώνουν μέρος του ελεύθερου χρόνου τους σε ένα ή περισσότερα έργα ΛΑΚ συμπεριλαμβάνονται επίσης σε αυτήν την κατηγορία Αυτοί οι άνθρωποι μπορούν συνολικά να περιγραφούν ως «μυημένα μέλη», δεδομένου ότι συμμετέχουν ενεργά στην ανάπτυξη του ΛΑΚ, στην εξέλιξή του και στην ωρίμανσή του Αυτό σημαίνει ότι έχουν μια άποψη σχετικά με OSS που είναι αρκετά διαφορετική σε σχέση με αυτήν που έχουν τα μέλη της προηγούμενης κατηγορίας Τα χαρακτηριστικά τους μπορούν να συνοψιστούν παρακάτω: Μόρφωση: Εξαρτάται από το ρόλο που διαδραματίζουν στην κοινότητα Οι developers έχουν βαθιά γνώση των υπολογιστών, των λειτουργικών συστημάτων και κάποιων γλωσσών προγραμματισμού, και είναι συνήθως πληροφορικοί, μηχανικοί λογισμικού, ή σπουδαστές ή πτυχιούχοι σχετικοί με IT Οι μεταφραστές έχουν πολύ καλή γνώση μερικών γλωσσών και μπορούν 51

52 επίσης να είναι πτυχιούχοι, ενώ παράλληλα έχουν ένα καλό επίπεδο εμπειρίας χρήσης υπολογιστών Οι administrators και moderators των ιστοχώρων, του wiki, των φόρουμ και των λιστών ηλεκτρονικού ταχυδρομείου είναι αρκετά έμπειροι και τεχνικά καταρτισμένοι από δημόσια ή ιδιωτικά ιδρύματα μεταδευτεροβάθμιας εκπαίδευσης, ενώ οι άνθρωποι που προσφέρουν την on-line υποστήριξη συνήθως έχουν πολύ καλή εμπειρία στα συγκεκριμένα συστήματα ΛΑΚ που είναι άσχετη με το γενικό εκπαιδευτικό υπόβαθρό τους Εξοικείωση με τους υπολογιστές: Ποικίλλει από την απλή ικανότητα χρήσης υπολογιστών (όπως στην περίπτωση των συμμετεχόντων στις λίστες ηλεκτρονικού ταχυδρομείου και στα forums) μέχρι την πολύ βαθιά γνώση των υπολογιστών και των λειτουργικών συστημάτων, των γλωσσών προγραμματισμού και των τεχνικών τεχνολογίας λογισμικού Εξοικείωση με το ΛΑΚ: Η μεγάλη πλειοψηφία των ανθρώπων σε αυτήν την ομάδα είναι ενεργοί χρήστες ΛΑΚ Ηλικία: Αυτή η ομάδα μπορεί να περιέχει τους ανθρώπους όλων των ηλικιών Αναμενόμενη συχνότητα χρήσης: Ποικίλλει ανάλογα με το ρόλο τους στην ανάπτυξη ΛΑΚ Οι developers και οι υπεύθυνοι έργων ΛΑΚ αναμένεται να χρησιμοποιήσουν το σύστημα πολύ συχνά ή σε τακτική βάση Αντίθετα, οι μεταφραστές και τα άλλα μέλη των κοινοτήτων δεν αναμένεται να χρησιμοποιήσουν το σύστημα συχνά Λόγοι της χρήσης: Οι developers και οι υπεύθυνοι των έργων ΛΑΚ μπορούν να χρησιμοποιήσουν το σύστημα για να αξιολογήσουν τον κώδικα του συστήματος που συμμετέχουν Οι developers μπορούν να το χρησιμοποιήσουν για να αξιολογήσουν την ποιότητα και τη κίνηση των διάφορων έργων με σκοπό να επιλέξουν σε ποιο έργο θα συμμετέχουν ή να αναζητήσουν ένα σύστημα Ανοιχτού Κώδικα που να υλοποιεί μια συγκεκριμένη λειτουργία προκειμένου να επαναχρησιμοποιηθεί ο κώδικας του, ή ακόμα και να χρησιμοποιήσουν κάποια μέρη του συστήματος για να αναπτύξουν το δικό τους module με μετρικές Κριτήρια αξιολόγησης: Αυτή η ομάδα θα χρησιμοποιήσει τις περισσότερες από τις μετρικές που θα παρασχεθούν από το σύστημα, προκειμένου να ολοκληρωθεί μια τουλάχιστον από τις ανωτέρω εργασίες 52

53 Επίπεδο αλληλεπίδρασης: Οι άνθρωποι σε αυτήν την ομάδα θα χρησιμοποιήσουν τις διαθέσιμες δημόσιες διεπαφές για την πρόσβαση των πληροφοριών (πχ ιστοχώρος του SQO-OSS) και τα τμήματα πυρήνων του συστήματος (πχ υπηρεσίες Ιστού, βιβλιοθήκες API) 3 Σύμβουλοι IT Αυτή η ομάδα χρηστών είναι σε άμεση επικοινωνία με τον εταιρικό κόσμο Στόχος τους είναι να προτείνουν λύσεις IT στους ανθρώπους που είναι υπεύθυνοι για τη διαδικασία λήψης απόφασης για την επιλογή λογισμικού το οποίο θα χρησιμοποιηθεί σε μια οργάνωση Προκειμένου να γίνει αυτό, πρέπει να έχουν μια πολύ καλή επισκόπηση του διαθέσιμου λογισμικού και τη δυνατότητα να ανιχνεύσουν το ποιοτικό λογισμικό, ενώ βρίσκονται σε τέτοια θέση ώστε να μπορέσουν να το ενσωματώσουν στις διαδικασίες της επιχείρησης Αναμένονται να είναι από τους συχνότερους χρήστες του συστήματος Μόρφωση: Ανώτερου επιπέδου εκπαίδευση σχετική με IT Θα μπορούσαν να ειδικευτούν στην παροχή των λύσεων σε συγκεκριμένες ανάγκες οργανισμών, όπως η ασφάλεια ή οι επικοινωνίες Εξοικείωση με τους υπολογιστές: Υπάρχει μεγάλη εξοικείωση με τα υπολογιστικά συστήματα, αποτελούν μέρος της καθημερινής ζωής τους Εξοικείωση με το ΛΑΚ: Μερικοί χρησιμοποιούν και προωθούν μόνο το εμπορικό λογισμικό, άλλοι μπορούν να χρησιμοποιήσουν ΛΑΚ για τις ανάγκες τους αλλά προτιμούν το εμπορικό λογισμικό όταν πρόκειται για επιχείρηση Η πλειοψηφία των χρηστών χρησιμοποιεί ένα μίγμα ΛΑΚ και εμπορικού λογισμικού, ενώ κάποιοι χρησιμοποιούν και προωθούν μόνο το ΛΑΚ Ηλικία: Εδώ ανήκουν όσοι είναι εργασιακά ενεργοί Αναμενόμενη συχνότητα χρήσης: Πολύ υψηλή Λόγοι της χρήσης: Τα άτομα που ανήκουν σε αυτή την κατηγορία αναμένεται να χρησιμοποιήσουν το σύστημα προκειμένου να συγκρίνουν λύσεις ΛΑΚ μεταξύ τους και σε σχέση με εμπορικές λύσεις σε εξειδικευμένους τομείς (πχ συστήματα βάσεων δεδομένων ή VoIP) Με αυτό τον τρόπο, τα άτομα αυτά θα είναι σε θέση να προωθήσουν το καλύτερο προϊόν κάθε είδους στους πελάτες τους Κριτήρια αξιολόγησης: Οι σύμβουλοι IT εστιάζονται όχι μόνο στα χαρακτηριστικά γνωρίσματα κάθε συστήματος (αν και αυτό παραμένει το 53

54 αρχικό κριτήριό τους) αλλά επεκτείνονται και στην υποστήριξη, στα θέματα των αδειών, στα περιθώρια κέρδους και στο κόστος της εκπαίδευσης Επίπεδο αλληλεπίδρασης: Θα χρησιμοποιηθούν δημόσιες διαθέσιμες διεπαφές για την πρόσβαση στις πληροφορίες (πχ ιστοχώρος του SQO- OSS) προκειμένου να συγκριθούν οι λύσεις ΛΑΚ προτού να τις προτείνουν στους πελάτες τους Αναμένονται να χρησιμοποιήσουν τη δυνατότητα των ερωτημάτων προς το σύστημα στο μέγιστο βαθμό 4 IT Managers Αυτή η κατηγορία περιέχει τους ανθρώπους του εταιρικού κόσμου Είναι οι υπεύθυνοι για τη διαδικασία λήψης απόφασης και την υιοθέτηση των λύσεων λογισμικού στον οργανισμό (επιχείρηση, βιομηχανία, κλπ) που απασχολούνται Διαχειρίζονται συνήθως έναν προϋπολογισμό για τις σχετικές IT δαπάνες και η υποχρέωσή τους είναι να εκτελέσουν όλες τις απαραίτητες ενέργειες προκειμένου να εξασφαλιστεί ότι η υποδομή IT του οργανισμού τους είναι πάντα διαθέσιμη και βελτιστοποιημένη Σε διάφορες περιπτώσεις απευθύνονται σε συμβούλους IT (είτε ως υπεργολάβους είτε ως εξωτερικούς φορείς παροχής υπηρεσιών) και τους ζητούν να προτείνουν λύσεις που θα καλύψουν τις ανάγκες τους Σε άλλες περιπτώσεις εκτελούν την αξιολόγηση διαφορετικών λύσεων και εφαρμόζουν τις απαραίτητες ενέργειες οι ίδιοι ή με τη βοήθεια του τεχνικού προσωπικού τους, και σε μερικές περιπτώσεις απευθύνονται σε εξωτερικούς φορείς παροχής υπηρεσιών για την εφαρμογή των απαραίτητων διαδικασιών Μόρφωση: Πιο υψηλού επιπέδου υπόβαθρο σε θέματα σχετικά με IT Σε αυτή την κατηγορία ανήκουν, σε διάφορες περιπτώσεις, άτομα που εξελίσσονται από άλλες θέσεις μέσα στον οργανισμό όπως developers ή αρχιτέκτονες λογισμικού Εξοικείωση με τους υπολογιστές: Πολύ μεγάλη εξοικείωση με τους υπολογιστές, ειδικά αν λάβουμε υπόψη μας ότι μερικοί από αυτούς προέρχονται από τις θέσεις ανάπτυξης λογισμικού Εξοικείωση με το ΛΑΚ: Ποικίλλει, ανάλογα με τη φιλοσοφία και πολιτικές του οργανισμού που εργάζονται καθώς επίσης και από το προσωπικό ενδιαφέρον τους Μερικοί από αυτούς δεν χρησιμοποιούν ΛΑΚ καθόλου, άλλοι χρησιμοποιούν ΛΑΚ για προσωπικούς σκοπούς αλλά επεκτείνουν λύσεις βασισμένες στο εμπορικό λογισμικό στους οργανισμούς που απασχολούνται, 54

55 και μερικοί (πιθανώς η πλειοψηφία) προωθούν και χρησιμοποιούν ένα μίγμα ΛΑΚ και εμπορικών εφαρμογών Ηλικία: Μέσης ηλικίας συνήθως Αναμενόμενη συχνότητα χρήσης: Υψηλή Λόγοι της χρήσης: Αναμένεται να χρησιμοποιήσουν το σύστημα (όταν δεν απευθύνονται σε εξωτερικά άτομα) για να βρουν το λογισμικό που μπορεί να καλύψει τις ανάγκες του οργανισμού τους και να περιορίσουν τις λειτουργικές δαπάνες και το συνολικό κόστος ιδιοκτησίας (Total Cost of Ownership - TCO) για την υποδομή ΙΤ Κριτήρια αξιολόγησης: Το ενδιαφέρον τους δεν επικεντρώνεται τόσο στα χαρακτηριστικά γνωρίσματα των συστημάτων (αν και αυτά παίζουν έναν σημαντικό ρόλο) αλλά στη διαθεσιμότητα της υποστήριξης σε εταιρικό επίπεδο Δεδομένου ότι είναι υπεύθυνοι για όλη την υποδομή ενός οργανισμού, ζητήματα όπως η δυσκολία και το κόστος ενός νέου συστήματος λογισμικού, οι συμφωνίες με τους προμηθευτές και το TCO, και - προ πάντων - η εμπιστοσύνη ότι ένα λογισμικό ή μια τεχνολογική λύση θα είναι σε θέση να υποστηρίξει τις διαδικασίες του οργανισμού για τα επόμενα έτη παίζουν πολύ σημαντικό ρόλο για τον τρόπο που αξιολογούν το λογισμικό Επίπεδο αλληλεπίδρασης: Αυτή η κατηγορία χρηστών θα χρησιμοποιήσει τις διαθέσιμες δημόσιες διεπαφές για πρόσβαση στις πληροφορίες (πχ ιστοχώρος του προγράμματος) προκειμένου να συγκριθούν οι λύσεις ΛΑΚ (ότι έχουν προτείνει πιθανώς οι σύμβουλοι IT) πριν τις εισάγουν στον οργανισμό τους Αναμένεται να χρησιμοποιήσουν τις δυνατότητες υποβολής ερωτημάτων προς το σύστημα σε πολύ υψηλό βαθμό 5 Ερευνητές Μόρφωση: Πιο υψηλού επιπέδου εκπαίδευση, μεταπτυχιακό και υψηλότερος Εξοικείωση με τους υπολογιστές: Πολύ καλή ως άριστη σχέση με τους υπολογιστές, ποικίλλει ανάλογα με τη σχέση που υπάρχει μεταξύ του ερευνητικού τομέα και της τεχνολογίας λογισμικού του Εξοικείωση με το ΛΑΚ: Ποικίλλει Θα μπορούσαν να χρησιμοποιήσουν ΛΑΚ στην έρευνά τους ή στα πλαίσια της χρήσης του προσωπικού υπολογιστή τους Ηλικία: Συνήθως 20 με 40 ετών 55

56 Αναμενόμενη συχνότητα χρήσης: Ποικίλλει, ανάλογα με το επίπεδο στο οποίο θα αλληλεπιδράσουν με το σύστημα Λόγοι της χρήσης: Αναμένεται να χρησιμοποιήσουν το σύστημα για δοκιμές για την επαλήθευση των θεωριών και των προτύπων, χωρίς να πρέπει να συλλεχθούν τα στοιχεία που θα τροφοδοτήσουν τα πειράματά τους Κριτήρια αξιολόγησης: Μη εφαρμόσιμα Επίπεδο αλληλεπίδρασης: Εάν πρέπει να αξιολογήσουν τη σχέση μεταξύ της ποιότητας λογισμικού και άλλων ανεξάρτητων παραγόντων (πχ στην περίπτωση μελέτης την επίδραση της ανάπτυξης του ΛΑΚ στην οικονομία) οι διαθέσιμες δημόσιες διεπαφές για την πρόσβαση στις πληροφορίες (πχ ο ιστοχώρος του SQO-OSS) αρκεί Αφ' ετέρου, εάν επιθυμούν να δημιουργήσουν νέες μετρικές ή μεθοδολογίες για την ποιοτική αξιολόγηση λογισμικού, τότε θα πρέπει να χρησιμοποιήσουν και βασικά τμήματα του συστήματος (πχ υπηρεσίες Ιστού, βιβλιοθήκη APIs) 6 Διαχειριστής Συστήματος Αυτή η κατηγορία αναφέρεται στα άτομα εκείνα που θα χειριστούν για την τεχνική υποστήριξη του συστήματος και θα εργάζονται για την εξασφάλιση της διαθεσιμότητας, της ασφάλειας και της απόδοσής του Θα είναι επίσης αυτοί που θα χειρίζονται εργασίες όπως η διαχείριση των plugins που θα εκτελούνται από το σύστημα Αυτοί οι άνθρωποι δεν θα είναι απαραιτήτως developers ή contributors σε έργα ΛΑΚ αλλά θα πρέπει έχουν εξαιρετική εμπειρία με υπολογιστές και λογισμικό γενικά Τα συγκεκριμένα χαρακτηριστικά τους μπορούν να συνοψιστούν ως εξής: Μόρφωση: Υψηλό επίπεδο εκπαίδευσης, πιθανότατα σχετική με την πληροφορική, την τεχνολογία λογισμικού, τα συστήματα πληροφοριών, τα δίκτυα υπολογιστών ή άλλα θέματα IT Εξοικείωση με τους υπολογιστές: Ακραία εξοικείωση με υπολογιστές, μέρος της καθημερινής ζωής τους εξελίσσεται γύρω από τους Εξοικείωση με το ΛΑΚ: Ποικίλλει, και μπορεί να κυμανθεί από καμία χρήση του ΛΑΚ και την απλή χρήση προγραμμάτων ΛΑΚ και την συμμετοχή σε online κοινότητές (πχ φόρουμ), ως την πλήρη υιοθέτηση του ΛΑΚ για τις καθημερινές εργασίες Ηλικία: Άτομα εργασιακά ενεργά Αναμενόμενη συχνότητα χρήσης: Καθημερινή χρήση 56

57 Λόγοι της χρήσης: Θα ελέγχουν το σύστημα και το υλικό στο οποίο τρέχει προκειμένου να εξασφαλιστούν η διαθεσιμότητα και η ασφάλειά του, καθώς επίσης θα παρέχουν και μια πρώτου επιπέδου υποστήριξη στους developers Θα είναι αρμόδιοι για τη δημιουργία και την ανάπτυξη των εφεδρικών μεθόδων και των διαδικασιών αποκατάστασης καταστροφής ή αποτυχίας Κριτήρια αξιολόγησης: Μη εφαρμόσιμα Επίπεδο αλληλεπίδρασης: Τα άτομα που ανήκουν σε αυτή την κατηγορία θα έχουν άμεση και απεριόριστη πρόσβαση σε όλους τους πόρους (υλικό και λογισμικό) και στον πηγαίο κώδικα του συστήματος Θα αλληλεπιδρούν με το σύστημα μέσω της διεπαφής του διαχειριστή και θα έχουν άμεση πρόσβαση στα αρχεία ημερολογίου και τις διαδρομές ελέγχου 44 Λειτουργικές Απαιτήσεις Παρατηρητηρίου Ποιότητας Λογισμικού Ανοιχτού Κώδικα Για την προδιαγραφή των απαιτήσεων του παρατηρητηρίου ποιότητας λογισμικού ανοιχτού κώδικα χρησιμοποιήθηκε το πρότυπο IEEE/ANSI 830/1993 (IEEE, 1993) Οι λειτουργικές απαιτήσεις του συστήματος οργανώθηκαν ανά χαρακτηριστικό του συστήματος Τα περισσότερα χαρακτηριστικά αναφέρονται μόνο σε μια κατηγορία χρηστών αλλά μερικά χαρακτηριστικά προορίζονται για περισσότερες της μίας κατηγορίες χρήστη Στην τελευταία περίπτωση, όποτε υπάρχουν διαφορές στις απαιτήσεις για ένα συγκεκριμένο χαρακτηριστικό ανάλογα με την κατηγορία χρηστών, αυτό δηλώνεται με σαφήνεια Για το σκοπό της συγκεκριμένης εργασίας, οι απαιτήσεις λογισμικού του Παρατηρητηρίου Ποιότητας Λογισμικού, οργανώθηκαν σε περιπτώσεις χρήσης Ενώ για κάθε περίπτωση χρήσης υπάρχει και ένα διάγραμμα δραστηριοτήτων 57

58 441 Αίτημα/ Παρουσίαση Αξιολόγησης Κώδικα Έργων για τα οποία ο πηγαίος κώδικας είναι διαθέσιμος στην τοπική λανθάνουσα μνήμη (cache) Κατηγορία χρηστών: Developers ΛΑΚ Σύντομη Περιγραφή: Οι χρήστες θα είναι σε θέση να δουν τα αποτελέσματα αξιολόγησης κώδικα (μετρικές κώδικα) των έργων ΛΑΚ, εάν αυτά τα αποτελέσματα υπάρχουν ήδη στη βάση δεδομένων του συστήματος, ή να ζητήσουν την αξιολόγηση του κώδικα ενός συγκεκριμένου έργου, εάν δεν υπάρχουν καθόλου στοιχεία αξιολόγησης για αυτό το έργο στη βάση δεδομένων του συστήματος Και στις δύο περιπτώσεις υποτίθεται ότι τα αρχεία κώδικα του έργου λογισμικού είναι διαθέσιμα στη λανθάνουσα μνήμη (cache) του συστήματος Η αξιολόγηση κώδικα θα πραγματοποιηθεί χρησιμοποιώντας τις πρότυπες μετρικές λογισμικού (παραδείγματος χάριν, μετρικές πολυπλοκότητας) Ως ελάχιστο σύνολο μετρικών που θα υποστηρίζονται από το σύστημα θεωρούνται κάποιες μετρικές μεγέθους και πολυπλοκότητας, όπως αυτές δηλώνονται σε άλλο παραδοτέο έγγραφο Κατά συνέπεια, οι developers ΛΑΚ θα είναι σε θέση να παρατηρήσουν την ποιότητα του κώδικα των έργων ΛΑΚ που επιθυμούν Επιπλέον, αυτή η λειτουργία του παρατηρητηρίου προορίζεται να υποστηρίξει τη διαδικασία λήψης απόφασης ενός προγραμματιστή ως προς το εάν θα συμμετέχει ή όχι σε ένα συγκεκριμένο έργο ΛΑΚ ενεργά Βασική Ροή Γεγονότων: 1 Το σύστημα εμφανίζει τη λίστα των projects στη μορφή ενός δέντρου αρχείων με πηγαίο κώδικα 2 Ο χειριστής «Developer ΛΑΚ» επιλέγει κάποιο/ α project από τη λίστα που εμφανίστηκε 3 Επιπλέον, ο χειριστής «Developer ΛΑΚ» επιλέγει μια σειρά αρχείων που θα αξιολογηθούν 4 Το σύστημα εμφανίζει τις μετρικές για τις οποίες υπάρχει η δυνατότητα να υπολογιστούν 58

59 5 Ο χειριστής «Developer ΛΑΚ», επιλέγει τις μετρικές για τις οποίες ενδιαφέρεται 6 Το σύστημα, προτού συνεχίσει παρακάτω ελέγχει αν υπάρχει προηγούμενη αξιολόγηση 7 Εάν δεν υπάρχουν πληροφορίες προηγούμενης αξιολόγησης, τότε εμφανίζεται κάποιο ειδοποιητήριο μήνυμα στον χειριστή 8 Ο χειριστής «Developer ΛΑΚ» εισέρχεται στο σύστημα 9 Το αίτημα του χειριστή «Developer ΛΑΚ» αποστέλλεται στο σύστημα 10 Εμφανίζεται στη συνέχεια, ειδοποιητήριο μήνυμα που ενημερώνει το χειριστή «Developer ΛΑΚ» ότι το αίτημά του βρίσκεται υπό επεξεργασία Το σύστημα πρέπει να παρέχει στο χρήστη μια προσέγγιση του χρόνου που απαιτείται για τους υπολογισμούς των μετρικών 11 O χειριστής «Developer ΛΑΚ» παραμένει συνδεδεμένος στο σύστημα 12 Το σύστημα υπολογίζει τις μετρικές 13 Τα αποτελέσματα των μετρικών αποθηκεύονται στη βάση δεδομένων του συστήματος Στην περίπτωση που έχει προηγηθεί ο ίδιος υπολογισμός αποθηκεύονται στη θέση των προηγούμενων αποτελεσμάτων 14 Τα αποτελέσματα των μετρήσεων εμφανίζονται 15 Η περίπτωση χρήσης τερματίζεται ομαλά Εναλλακτική Ροή Γεγονότων Ι: 7 α Εάν υπάρχουν πληροφορίες προηγούμενης αξιολόγησης, τότε εμφανίζονται αυτά τα αποτελέσματα 8 α Η περίπτωση χρήσης τερματίζεται ομαλά Εναλλακτική Ροή Γεγονότων ΙΙ: 8 β Η περίπτωση χρήσης τερματίζεται ομαλά Εναλλακτική Ροή Γεγονότων ΙΙΙ: 11 α O χειριστής «Developer ΛΑΚ» αποσυνδέεται από το σύστημα 12 α Η περίπτωση χρήσης τερματίζεται ομαλά 59

60 Μη Λειτουργικές απαιτήσεις 1 Εάν είναι διαθέσιμες περισσότερες της μιας, εκδόσεις για ένα συγκεκριμένο πρόγραμμα, αυτές θα επιδεικνύονται χωριστά, σαν να ήταν διαφορετικά έργα ΛΑΚ 2 Η λίστα με τα προγράμματα θα είναι χωρισμένη σε δύο κατηγορίες έργων λογισμικού: i Έργα ΛΑΚ για τα οποία τα δεδομένα των μετρικών είναι ήδη διαθέσιμα στη βάση δεδομένων του συστήματος, όπου θα επιδεικνύονται και οι ημερομηνίες της τελευταίας ανανέωσης των δεδομένων των μετρικών και η έκδοση του προγράμματος στην οποία αναφέρονται οι μετρικές ii Έργα ΛΑΚ για τα οποία κανένα στοιχείο αξιολόγησης δεν υπάρχει στη βάση δεδομένων του συστήματος Αυτές οι δύο κατηγορίες θα παρουσιάζονται με διαφορετικό τρόπο 3 Εξ ορισμού, όλες οι μετρικές θα είναι επιλεγμένες Κατάσταση εισόδου: Ο χειριστής «Developer ΛΑΚ» πρέπει να επιλέξει συγκεκριμένη ομάδα αρχείων Κατάσταση εξόδου: 1 Το σύστημα εμφανίζει τα αποτελέσματα με μορφή πίνακα, όπου τα projects βρίσκονται στη μια διάσταση (σειρά ή στήλη) και οι μετρικές βρίσκονται στην άλλη (στήλη ή σειρά) 2 Το σύστημα εμφανίζει τα αποτελέσματα μιας συνολικής αξιολόγησης για κάθε project Τα αποτελέσματα βασίζονται στο ποιοτικό πρότυπο που θα προκύψει από το 7 ο Παραδοτέο 3 Το σύστημα θα παρέχει μια σύντομη εξήγηση για κάθε μετρική που θα εμφανίζεται με συνδέσεις για τεκμηρίωση και αναφορές στη βιβλιογραφία Αυτά τα στοιχεία θα προέλθουν από τη βάση δεδομένων του συστήματος 60

61 4 Το σύστημα θα εκθέτει επίσης μια ερμηνεία των αριθμητικών αποτελεσμάτων για κάθε μια μετρική, σύμφωνα με τη βιβλιογραφία προκειμένου να υποστηρίξει το χρήστη και να καταλάβει την έννοια των αποτελεσμάτων Αυτά τα στοιχεία θα προέλθουν επίσης από τη βάση δεδομένων του συστήματος 61

62 Εικόνα 5 Διάγραμμα δραστηριοτήτων για το αίτημα/ παρουσίαση αξιολόγησης κώδικα έργων για τα οποία ο πηγαίος κώδικα είναι διαθέσιμος στην τοπική λανθάνουσα μνήμη (cache) 62

63 442 Αίτημα Αξιολόγησης Κώδικα Έργων για τα οποία ο πηγαίος κώδικας δεν είναι διαθέσιμος στην τοπική λανθάνουσα μνήμη (cache) Κατηγορία Χρηστών: Developers ΛΑΚ, Διαχειριστές του συστήματος SQO- OSS Σύντομη Περιγραφή: Οι χρήστες θα είναι σε θέση να ζητήσουν την αξιολόγηση κώδικα ενός συγκεκριμένου έργου ΛΑΚ για το οποίο δεν υπάρχει κανένα αρχείο πηγαίου κώδικα στην cache του συστήματος Ο σκοπός είναι όχι μόνο να παρασχεθεί μια πρόσθετη υπηρεσία στους χρήστες του SQO-OSS αλλά και να παρασχεθεί ένας πρόσθετος τρόπος για τη συλλογή δεδομένων σχετικά με τις διαδρομές των αρχείων πηγαίου κώδικα των έργων ΛΑΚ Αυτή η λειτουργία θα είναι διαθέσιμη μόνο στους εγγεγραμμένους χρήστες που έχουν συνδεθεί στο σύστημα του SQO-OSS Βασική Ροή Γεγονότων: 1 Ο χειριστής «Developer ΛΑΚ» θα πρέπει να συνδεθεί στο σύστημα 2 Ο χειριστής «Developer ΛΑΚ» παρέχει στο σύστημα τις απαραίτητες πληροφορίες για τις διαδρομές για ένα ή περισσότερα πηγαία αρχεία ενός μόνο έργου ΛΑΚ, συμπεριλαμβανομένων και των απαραίτητων πληροφοριών αυθεντικότητας, εφόσον αυτό είναι απαραίτητο 3 Εάν τα δεδομένα είναι σωστά, τότε αποστέλλεται στο σύστημα το αίτημα του χειριστή «Developer ΛΑΚ» 4 Ο χειριστής «Διαχειριστής του συστήματος SQO-OSS» εγκρίνει το αίτημα του χρήστη 5 Ο χειριστής «Διαχειριστής του συστήματος SQO-OSS» θα κατεβάσει τα πηγαία αρχεία και θα τα αποθηκεύσει στην μνήμη cache του συστήματος 6 Ο χειριστής «Διαχειριστής του συστήματος SQO-OSS» θα ελέγξει αν τα αρχεία είναι συμπιεσμένα targz, tarbz, WinZip και Winrar είναι οι τύποι των αρχείων που υποστηρίζονται 7 Εάν είναι συμπιεσμένα, ο χειριστής «Διαχειριστής του συστήματος SQO- OSS» θα αποσυμπιέσει τα αντίστοιχα δεδομένα 63

64 8 Ο χειριστής «Διαχειριστής του συστήματος SQO-OSS» θα αξιολογήσει τον κώδικα κάνοντας υπολογισμούς των μετρικών 9 Ο χειριστής «Developer ΛΑΚ» θα παραλάβει ένα μήνυμα κατάστασης που θα τον ενημερώνει ότι το αίτημά του θα υποβληθεί σε επεξεργασία και ότι θα ειδοποιηθεί μέσω ηλεκτρονικού ταχυδρομείου εάν και όταν τα αποτελέσματα αξιολόγησης είναι διαθέσιμα 10 Με την ολοκλήρωση των υπολογισμών, ο χειριστής «Developer ΛΑΚ» θα λάβει ένα ειδοποιητήριο 11 Θα εμφανιστούν στον χειριστή «Developer ΛΑΚ», τα αποτελέσματα της αξιολόγησης 12 Η περίπτωση χρήσης θα τερματιστεί Εναλλακτική Ροή Γεγονότων Ι: 3 α Εάν υπάρξει κάποιο σφάλμα, τότε αποστέλλεται στο χειριστή «Developer ΛΑΚ» ειδοποιητήριο μήνυμα 4 α Η περίπτωση χρήσης θα τερματιστεί Εναλλακτική Ροή Γεγονότων II: 4 β Ο χειριστής «Διαχειριστής του συστήματος SQO-OSS» δεν θα εγκρίνει το αίτημα του χρήστη 5 α Η περίπτωση χρήσης θα τερματιστεί Εναλλακτική Ροή Γεγονότων III: 7 α Εάν δεν είναι συμπιεσμένα, ο έλεγχος προχωράει στο βήμα 8 Μη Λειτουργικές απαιτήσεις Δεν υπάρχουν για αυτή την περίπτωση χρήσης Κατάσταση εισόδου: Παρέχονται οι κατάλληλες διαδρομές για ένα ή περισσότερα πηγαία αρχεία ενός μόνο έργου ΛΑΚ, συμπεριλαμβανομένων των απαραίτητων πληροφοριών αυθεντικότητας 64

65 Κατάσταση εξόδου: Τα αποτελέσματα θα εμφανιστούν έπειτα όπως περιγράφεται στην παράγραφο

66 Εικόνα 6 Διάγραμμα δραστηριοτήτων για το αίτημα/ παρουσίαση αξιολόγησης κώδικα έργων για τα οποία ο πηγαίος κώδικα δεν είναι διαθέσιμος στην τοπική λανθάνουσα μνήμη (cache) 66

67 443 Αξιολόγηση Μελλοντικής Εξέλιξης Έργων Κατηγορία Χρηστών: Διαχειριστές του συστήματος SQO-OSS Σύντομη Περιγραφή: Το σύστημα θα είναι σε θέση να υπολογίσει τη μελλοντική εξέλιξη ενός έργου ΛΑΚ με βάση κάποια πρότυπα προσομοίωσης που έχουν εμφανιστεί στη διεθνή βιβλιογραφία 7] Το σύστημα θα είναι σε θέση να ανακτήσει αυτόματα τα απαραίτητα δεδομένα για το επιλεγμένο έργο, όπως ορίζεται από το πρότυπο προσομοίωσης Χρησιμοποιώντας αυτά τα δεδομένα, το σύστημα του SQO-OSS θα υπολογίσει τη χρονική εξέλιξη των βασικών παραγόντων ενός έργου, όπως η πυκνότητα σφαλμάτων ανά γραμμές κώδικα κτλ Βασική Ροή Γεγονότων: 1 Ο χειριστής «Διαχειριστής του συστήματος SQO-OSS» θα πρέπει να συγχρονίσει τα δεδομένα της τοπικής cache του έργου με την απομακρυσμένη, πριν την εκτέλεση του πρότυπου plugin εργαλείου 2 Ο χειριστής «Διαχειριστής του συστήματος SQO-OSS» θα αναλύσει τον πηγαίο κώδικα των repositories και τις πληροφορίες που συλλέγει από τα συστήματα ανίχνευσης λαθών Τα έργα που χρησιμοποιούν Subversion Protocol (SVN) και Concurrent Versions System (CVS) ως αποθήκες έργων και τα έργα που χρησιμοποιούν Bugzilla ως σύστημα ανίχνευσης σφαλμάτων θα υποστηρίζονται, ως ελάχιστη απαίτηση 3 Ο χειριστής «Διαχειριστής του συστήματος SQO-OSS» θα χρησιμοποιεί το plug in εργαλείο 67

68 4 Ο χειριστής «Διαχειριστής του συστήματος SQO-OSS» θα αποθηκεύει τα αποτελέσματα στην τοπική βάση δεδομένων Τα δεδομένα που λαμβάνονται από την ιστορική ανάλυση των αποθηκευμένων αποθηκών πηγαίων αρχείων και των συστημάτων ανίχνευσης σφαλμάτων, θα αποθηκευτούν στη βάση δεδομένων του SQO-OSS και θα ενημερώνονται τακτικά Για λόγους σύγκρισης, το σύστημα θα αποθηκεύει επίσης στην τοπική βάση δεδομένων την πραγματική ιστορική χρονική σειρά των ανωτέρω βασικών παραγόντων ενός έργου, που θα μπορούν εύκολα να υπολογιστούν από εργαλεία όπως το CVSAnalY και εργαλεία ανίχνευσης σφαλμάτων που θα αναπτυχθούν για αυτόν το λόγο 5 Η περίπτωση χρήσης θα τερματιστεί Μη Λειτουργικές απαιτήσεις Το σύστημα θα παράσχει μια πλήρη τεκμηρίωση για το πρότυπο εργαλείο προσομοίωσης έτσι ώστε οι διαχειριστές του SQO-OSS συστήματος να είναι σε θέση να ακολουθήσουν μια απλή διαδικασία για να λάβουν κάθε απαιτούμενη παράμετρο εισόδου Κατάσταση εισόδου: Η είσοδος του εργαλείου θα είναι παράμετροι, οι οποίες θα εξαρτώνται από το έργο και θα λαμβάνονται από: ιστορική ανάλυση των αποθηκευμένων πηγαίων δεδομένων Οι διαχειριστές του SQO-OSS θα χρησιμοποιήσουν το CVSAnalY για την ανάλυση των αποθηκών ή ισοδύναμο εργαλείο, εάν είναι διαθέσιμο Το CVSAnalY είναι ένα εργαλείο ανάλυσης των αποθηκών CVS και παράγει στατιστικές πληροφορίες ως αποτελέσματα όπως τις LOC που γράφονται ανά ημέρα, ανά ενότητα και ανά developer, τον αριθμό των commits κλπ Αυτό το εργαλείο θα παρέχει τα απαραίτητα δεδομένα εισόδου στο πρότυπο εργαλείο προσομοίωσης 68

69 ανάλυση των δεδομένων των συστημάτων ανίχνευσης σφαλμάτων Ο χειριστής «Διαχειριστής του συστήματος SQO-OSS» θα χρησιμοποιήσει ειδικό εργαλείο ανάλυσης δεδομένων συστήματος ανίχνευσης σφαλμάτων που θα παράγει ως ελάχιστη απαίτηση τα εξής αποτελέσματα: Αριθμός ανοικτών σφαλμάτων και ημερομηνία έναρξης του σφάλματος, αριθμός των τακτοποιημένων σφαλμάτων και στατιστικά για την κατανομή του χρόνου που παρήλθε μεταξύ των ημερομηνιών ανοίγματος και κλεισίματος για κάθε σφάλμα Αυτό το εργαλείο θα παρέχει τα απαραίτητα δεδομένα εισόδου στο πρότυπο εργαλείο προσομοίωσης Άλλα αριθμητικά στοιχεία τιμής που απαιτούνται ως είσοδος στο μοντέλο πρόβλεψης θα υπολογιστούν και θα εισαχθούν από ένα διαχειριστή του SQO- OSS σύμφωνα με τις προδιαγραφές του προτύπου που περιγράφεται στην βιβλιογραφία Κατάσταση εξόδου: Στην έξοδο, το πρότυπο εργαλείο προσομοίωσης θα εκθέτει τη χρονική εξέλιξη των βασικών παραγόντων του έργου όπως: Χιλιάδες γραμμές κώδικα (KLOC) Πυκνότητα σφαλμάτων Αριθμός ενεργών συμμετεχόντων Δραστηριότητα ανά τύπο εργασίας (γράψιμο κώδικα, διόρθωση σφαλμάτων, έλεγχος και αναφορά σφαλμάτων) Η έξοδος που παράγεται από κάθε «τρέξιμο» του εργαλείου, θα αποτελείται και από στοιχεία χρονικής σειράς (διανυσματικά δεδομένα) καθώς επίσης και από τιμές μιας μεταβλητής που θα αποθηκεύονται στη βάση δεδομένων του συστήματος Το αντίστοιχο διάστημα εμπιστοσύνης, για κάθε τιμή στη χρονική σειρά, θα παραχθεί από το πρότυπο εργαλείο προσομοίωσης και θα αποθηκευτεί και αυτό στη βάση δεδομένων του συστήματος 69

70 Εικόνα 7 Διάγραμμα δραστηριοτήτων για αξιολόγηση μελλοντικής εξέλιξης έργων 444 Εμφάνιση Αξιολόγησης Μελλοντικής Εξέλιξης Έργων Κατηγορία Χρηστών: Developers ΛΑΚ, Σύμβουλοι IT, Διαχειριστής Συστήματος SQO-OSS Σύντομη Περιγραφή: Οι χρήστες θα είναι σε θέση να δουν την εκτίμηση για τη μελλοντική εξέλιξη των βασικών παραγόντων ενός έργου ΛΑΚ με βάση τα αποτελέσματα του προτύπου προσομοίωσης που περιγράφονται στην προηγούμενη περίπτωση χρήσης Βασική Ροή Γεγονότων: 1 Το σύστημα εμφανίζει μια λίστα με τα έργα ΛΑΚ 2 Ο χειριστής «Developer ΛΑΚ» ή «Σύμβουλος IT» ελέγχει αν το έργο ΛΑΚ που τον ενδιαφέρει βρίσκεται στη λίστα 70

71 3 Αν το έργο βρίσκεται στη λίστα, τότε ο χειριστής «Developer ΛΑΚ» ή «Σύμβουλος IT» επιλέγει το έργο ΛΑΚ από τη λίστα 4 Ο χειριστής «Developer ΛΑΚ» ή «Σύμβουλος IT» ελέγχει αν υπάρχουν τα δεδομένα εκτίμησης της εξέλιξης του έργου κι εάν είναι πρόσφατα 5 Εάν τα δεδομένα δεν υπάρχουν ή ο χειριστής επιθυμεί ενημερωμένη εκτίμηση, στέλνει ένα αίτημα προς το σύστημα 6 Ο χειριστής «Διαχειριστής συστήματος SQO-OSS» θα εκτιμήσει τη μελλοντική εξέλιξη του ζητούμενου έργου 7 Ο χειριστής «Developer ΛΑΚ» ή «Σύμβουλος IT» θα λάβει ένα προειδοποιητικό μήνυμα ηλεκτρονικού ταχυδρομείου 8 Εάν η διαδικασία εκτίμησης ολοκληρώθηκε επιτυχώς, θα εμφανιστούν τα αποτελέσματα και θα είναι διαθέσιμα για όλους τους χειριστές 9 Η περίπτωση χρήσης θα τερματιστεί Εναλλακτική Ροή Γεγονότων Ι: 3 α Εάν το έργο δεν βρίσκεται στη λίστα, ο χειριστής «Developer ΛΑΚ» ή «Σύμβουλος IT» θα παράσχει τις απαραίτητες πληροφορίες για το έργο σύνδεση με την αποθήκη πηγαίων αρχείων (CVS ή SVN), σύνδεση με το σύστημα ανίχνευσης σφαλμάτων του έργου (Bugzilla μόνο) 4 α Ο χειριστής «Διαχειριστής συστήματος SQO-OSS» θα λάβει το αίτημα 5 α Ο χειριστής «Διαχειριστής συστήματος SQO-OSS» θα εκτιμήσει τη μελλοντική εξέλιξη του ζητούμενου έργου 6 α Ο έλεγχος επανέρχεται στο βήμα 7 Εναλλακτική Ροή Γεγονότων ΙI: 5 β Εάν τα δεδομένα υπάρχουν και ο χειριστής «Developer ΛΑΚ» ή «Σύμβουλος IT» επιλέξει να τα δει, εμφανίζονται τα αποτελέσματα 6 β Η περίπτωση χρήσης θα τερματιστεί 71

72 Εναλλακτική Ροή Γεγονότων ΙII: 8 α Εάν η διαδικασία εκτίμησης δεν ολοκληρώθηκε με επιτυχία, η περίπτωση χρήσης θα τερματιστεί Μη Λειτουργικές απαιτήσεις Η λίστα των έργων ΛΑΚ θα περιέχει κάθε αποθηκευμένο project και θα εμφανίζει με διαφορετικό τρόπο τα έργα εκείνα για τα οποία ήδη υπάρχουν τα αποτελέσματα πρόβλεψης στη βάση δεδομένων του συστήματος Κατάσταση εισόδου: Παρέχονται, όταν είναι απαραίτητο, οι κατάλληλες διαδρομές για ένα ή περισσότερα πηγαία αρχεία ενός μόνο έργου ΛΑΚ, συμπεριλαμβανομένων των απαραίτητων πληροφοριών αυθεντικότητας Κατάσταση εξόδου: Και η θεωρητική και η πραγματική χρονική σειρά των βασικών παραγόντων των έργων όπως: KLOC, πυκνότητα σφαλμάτων, αριθμός ενεργών συμμετεχόντων η δραστηριότητα ανά τύπο εργασίας θα δοθεί γραφικά και ο χρήστης θα είναι σε θέση να συγκρίνει τα στοιχεία πρόβλεψης με τα πραγματικά στοιχεία για την εξέλιξη του προγράμματος 72

73 Εικόνα 8 Διάγραμμα δραστηριοτήτων για εμφάνιση της αξιολόγησης μελλοντικής εξέλιξης έργων 73

74 445 Στατιστικά σφαλμάτων Κατηγορία Χρηστών: Developers ΛΑΚ, Διαχειριστές συστήματος SQO-OSS Σύντομη Περιγραφή: Οι χρήστες θα έχουν τη δυνατότητα να δουν στατιστικά σφαλμάτων για τα έργα ΛΑΚ Το σύστημα θα παρέχει χρονικά στατιστικά για την επιδιόρθωση των λαθών και το ρυθμό της απομάκρυνσης των σφαλμάτων Επιπρόσθετα, το σύστημα θα καταγράφει σφάλματα μεγάλης διάρκειας (long-lived defects) ως δείκτη της ποιότητας του έργου Βασική Ροή Γεγονότων: 1 Το σύστημα εμφανίζει μια λίστα με έργα ΛΑΚ 2 Αν τα αρχεία του έργου δεν βρίσκονται στη μνήμη cache του συστήματος τότε ο χειριστής «Developer ΛΑΚ» παρέχει τις απαραίτητες πληροφορίες για το σύστημα ανίχνευσης σφαλμάτων του έργου Το σύστημα θα πρέπει κατ ελάχιστο να υποστηρίζει τον Bugzilla 3 Το αίτημα του χειριστή «Developer ΛΑΚ» αποστέλλεται στο σύστημα 4 Εάν ο χειριστής «Διαχειριστής συστήματος SQO-OSS» εγκρίνει το αίτημα, θα «κατεβάσει» τα δεδομένα του συστήματος ανίχνευσης σφαλμάτων 5 Τα δεδομένα του συστήματος ανίχνευσης σφαλμάτων θα αποθηκευτούν στο σύστημα 6 Ο χειριστής «Διαχειριστής συστήματος SQO-OSS» θα υπολογίσει τα στατιστικά Το σύστημα θα μπορεί να αναγνωρίζει και να καταγράφει τα σφάλματα μεγάλης διάρκειας Ένα σφάλμα καταγράφεται ως μακράς διάρκειας αν συμβαίνει μία από τις ακόλουθες περιπτώσεις: Το σφάλμα δεν έχει σημειωθεί σαν λυμένο, διπλοεγγεγραμμένο, άκυρο ή WONTFIX (δεν πρόκειται να λυθεί) για περίοδο μεγαλύτερη από 3 μήνες μετά την καταχώρησή του Το σφάλμα δεν έχει σημειωθεί ως λυμένο, διπλοεγγεγραμμένο, άκυρο ή WONTFIX πριν η κύρια έκδοση του έργου αλλάξει δύο φορές 74

75 Το σφάλμα έχει σημειωθεί σαν επαναδιαθέσιμο (reopened) και η συνολική περίοδος που παρέμεινε άλυτο (η περίοδος ανάμεσα στην αρχική καταχώρηση και στην ημερομηνία που σημειώθηκε ως λυμένο συν την περίοδο ανάμεσα στην ημερομηνία που άνοιξε ξανά) δεν είναι μεγαλύτερη από 4 μήνες Το σύστημα θα υπολογίζει την κατανομή των χρόνων για ανάλυση σφαλμάτων δηλαδή το ποσοστό των σφαλμάτων που έκλεισαν/ επιβεβαιώθηκαν μέσα σε μια συγκεκριμένη χρονική περίοδο από το πρώτο άνοιγμα και θα παράγει στην έξοδο γραφήματα Το σύστημα θα πρέπει επίσης να υπολογίζει και να εμφανίζει με μορφή διαγράμματος ράβδων την κατανομή της πυκνότητας των σφαλμάτων μέσα στο έργο δηλαδή το ποσοστό των συστατικών που έχουν πυκνότητα σφαλμάτων πάνω από κάποιες τιμές 7 Ο χειριστής «Developer ΛΑΚ» θα λάβει ένα ενημερωτικό 8 Εάν διεκπεραιωθεί ο υπολογισμός, εμφανίζονται τα αποτελέσματα 9 Η περίπτωση χρήσης θα τερματιστεί Εναλλακτική Ροή Γεγονότων Ι: 2 α Αν τα αρχεία του έργου βρίσκονται στη μνήμα cache του συστήματος τότε ο χειριστής «Developer ΛΑΚ» θα επιλέξει το έργο για το οποίο ενδιαφέρεται 3 α Ο χειριστής «Developer ΛΑΚ» θα επιλέξει το module για το οποίο ενδιαφέρεται (προϊόν, component, έκδοση) 4 α Ο χειριστής «Διαχειριστής συστήματος SQO-OSS» θα ανακτήσει τις απαραίτητες πληροφορίες από την cache του συστήματος 5 α Ο χειριστής «Διαχειριστής συστήματος SQO-OSS» θα υπολογίσει τα στατιστικά των σφαλμάτων 6 α Το σύστημα εμφανίζει στο χειριστή «Developer ΛΑΚ» τα αποτελέσματα της στατιστικής ανάλυσης 7 α Η περίπτωση χρήσης θα τερματιστεί Εναλλακτική Ροή Γεγονότων ΙI: 4 β Εάν ο χειριστής «Διαχειριστής συστήματος SQO-OSS», δεν εγκρίνει το αίτημα, η περίπτωση χρήσης θα τερματιστεί 75

76 Εναλλακτική Ροή Γεγονότων ΙII: 1 α Εάν δεν διεκπεραιωθεί ο υπολογισμός, η περίπτωση χρήσης θα τερματιστεί Μη Λειτουργικές απαιτήσεις Δεν υπάρχουν για αυτή την περίπτωση χρήσης Κατάσταση εισόδου: Από την βάση ανίχνευσης σφαλμάτων είναι απαραίτητα τα ακόλουθα: ημερομηνία υποβολής, αναγνωριστικό ID, περίληψη σφάλματος, ημερομηνία ανάθεσης, κατάσταση, σχετικό/επηρεαζόμενο module, (προϊόν/ component/ έκδοση), αναφορά επίλυσης σφάλματος, διάρκεια διόρθωσης, αριθμός σφαλμάτων που έχουν λυθεί, αριθμός σφαλμάτων που δεν έχουν λυθεί Κατάσταση εξόδου: Το σύστημα θα πρέπει να παράγει γραφικά πληροφορίες σφαλμάτων για επιλεγμένα έργα ή τμήματα (προϊόντα / συστατικά / εκδόσεις) με τη μορφή γραφήματος Ως ελάχιστη απαίτηση θα πρέπει να αναπαριστώνται γραφικά τα επόμενα: σφάλματα / χιλιάδες γραμμές κώδικα vs χρόνο (σε μέρες) Αριθμός ανοικτών (άλυτων) σφαλμάτων vs χρόνο (σε μέρες), αριθμός των κλειστών σφαλμάτων vs χρόνος (σε μέρες), αριθμός κρίσιμων σφαλμάτων vs χρόνο (σε μέρες) κτλ 76

77 Εικόνα 9 Διάγραμμα δραστηριοτήτων για στατιστικά σφαλμάτων 77

78 446 Στατιστικά για Developers Κατηγορία Χρηστών: Developers ΛΑΚ, Διαχειριστές συστήματος SQO-OSS Σύντομη Περιγραφή: Οι χρήστες θα έχουν τη δυνατότητα να δουν στατιστικά για τους developers διαφορετικών έργων Τα στατιστικά αυτά υπολογίζονται λαμβάνοντας υπ όψη τους τη συμμετοχή ενός developer σε ένα έργο με τρεις διαφορετικές διαδικασίες: Προγραμματισμό (Coding): Συνολικός αριθμός KLOC (χιλιάδων γραμμών κώδικα) που έχει γράψει και καταχωρήσει σε ένα SVN ή CVS repository Υποστήριξη (Μaintenance): Συνολικός αριθμός των bugs που διόρθωσε και έκλεισε Δραστηριότητα των developers στην mailing list: Συνολικός αριθμός των s που απέστειλε και συνολικός αριθμός των απαντήσεων που απέστειλε σε που στάλθηκαν στην mailing list Βασική Ροή Γεγονότων: 1 Εμφανίζεται στο χειριστή «Developer ΛΑΚ» η λίστα με έργα ΛΑΚ του συστήματος 2 Εάν τα δεδομένα που είναι απαραίτητα για τον υπολογισμό των στατιστικών των developers (πηγαίος κώδικας, δεδομένα συστήματος ανίχνευσης σφαλμάτων, πληροφορίες των mailing lists) δεν βρίσκονται στη μνήμη cache του συστήματος τότε ο χειριστής «Developer ΛΑΚ» θα παράσχει στο σύστημα τις ελλιπείς πληροφορίες εισάγοντας το όνομα του έργου, τη διεύθυνση των εργαλείων του έργου (αποθήκη πηγαίου κώδικα (source repository), σύστημα ανίχνευσης σφαλμάτων (BTS), mailing list των developers) και το μέσο πρόσβασης Υποστηριζόμενα εργαλεία: CVS, SVN, Bugzilla, mailman 3 Το αίτημα του χειριστή «Developer ΛΑΚ» αποστέλλεται στο σύστημα 4 Ο «Διαχειριστής του συστήματος SQO-OSS» εγκρίνει το αίτημα του χειριστή «Developer ΛΑΚ» 78

79 5 Ο χειριστής «Διαχειριστής του συστήματος SQO-OSS» ανακτά τις πληροφορίες που ήδη υπάρχουν ή «κατεβάζει» τα ελλιπή στοιχεία και τα αποθηκεύει 6 Ο χειριστής «Διαχειριστής του συστήματος SQO-OSS» θα εκτελέσει την στατιστική ανάλυση 7 Ο χειριστής «Developer ΛΑΚ» θα λάβει ένα ενημερωτικό 8 Αν η στατιστική ανάλυση διεκπεραιώθηκε, εμφανίζονται τα αποτελέσματα 9 Η εργασία θα τερματιστεί Εναλλακτική Ροή Γεγονότων Ι: 3 α Εάν τα δεδομένα που είναι απαραίτητα για τον υπολογισμό των στατιστικών των developers (πηγαίος κώδικας, δεδομένα συστήματος ανίχνευσης σφαλμάτων, πληροφορίες των mailing lists) βρίσκονται στη μνήμη cache του συστήματος, τότε ο χειριστής «Διαχειριστής του συστήματος SQO-OSS» θα ανακτήσει αυτά τα στοιχεία 2 α Ο «Διαχειριστής του συστήματος SQO-OSS» θα εκτελέσει την στατιστική ανάλυση 3 α Θα εμφανιστούν τα αποτελέσματα της στατιστικής ανάλυσης και η εργασία θα τερματιστεί Εναλλακτική Ροή Γεγονότων ΙI: 4 β Ο «Διαχειριστής του συστήματος SQO-OSS» δεν εγκρίνει το αίτημα του χειριστή «Developer ΛΑΚ» και η εργασία θα τερματιστεί Εναλλακτική Ροή Γεγονότων ΙII: 8 α Αν η στατιστική ανάλυση δεν διεκπεραιώθηκε, η εργασία θα τερματιστεί Μη Λειτουργικές απαιτήσεις Δεν υπάρχουν γι αυτή την περίπτωση χρήσης Κατάσταση εισόδου: Όσον αφορά τον προγραμματισμό, τα στατιστικά θα υπολογίζονται από τα δεδομένα της αποθήκης κώδικα (code repository) 79

80 Σε σχέση με την υποστήριξη, τα στατιστικά θα υπολογίζονται από τη συνεισφορά του developer στο σύστημα ανίχνευσης σφαλμάτων και από τον αριθμό των σφαλμάτων (που διόρθωσε/ έκλεισε/ επιβεβαίωσε/ ανέφερε) Σε σχέση με την υποστήριξη χρηστών ή άλλων developers τα στατιστικά θα υπολογίζονται από την δραστηριότητα του developer στις mailing lists Το σύστημα θα πρέπει να διαβάζει τα αρχεία των mailing lists (η μορφή μπορεί να είναι HTML, mbox ή mdir) διαφόρων έργων Κατάσταση εξόδου: Δεν υπάρχουν ιδιαίτερες απαιτήσεις εξόδου γι αυτή την περίπτωση χρήσης 80

81 Εικόνα 10 Διάγραμμα δραστηριοτήτων για στατιστικά των developers 81

82 447 Συνεργατική βαθμολόγηση Κατηγορία Χρηστών: Όλοι οι χρήστες Σύντομη Περιγραφή: Το σύστημα υποστηρίζει τη δυνατότητα συλλογής της γνώμης των χρηστών σχετικά με την ποιότητα των έργων ΛΑΚ με μορφή βαθμολόγησης και σχολίων ελεύθερου κειμένου Εκεί θα βρίσκεται η άποψη του χρήστη σχετικά με την ποιότητα και θα μας παρέχει δεδομένα έτσι ώστε να συγκρίνουμε την ποιότητα όπως αυτή μετρήθηκε από το μοντέλο μας με την ποιότητα που έγινε αντιληπτή από τον χρήστη Βασική Ροή Γεγονότων: 1 Οι χρήστες θα πρέπει να εισέλθουν στο σύστημα 2 Το σύστημα θα ελέγξει τα δικαιώματα του χρήστη 3 Θα εμφανιστεί η λίστα με τα έργα ΛΑΚ 4 Οι χρήστες θα έχουν τη δυνατότητα να επιλέξουν κάποιο από τα έργα ΛΑΚ που υπάρχει στη λίστα 5 Οι χρήστες θα μπορούν να σχολιάσουν σε ελεύθερο κείμενο το συγκεκριμένο έργο ΛΑΚ 6 Το σύστημα θα αποθηκεύσει το σχόλιο του χρήστη 7 Η εργασία θα τερματιστεί Εναλλακτική Ροή Γεγονότων Ι: 5 α Ο χρήστης θα αξιολογεί το συγκεκριμένο έργο ΛΑΚ χρησιμοποιώντας ένα σύστημα αξιολόγησης πέντε επιπέδων για κάθε μία από τις επόμενες σχετικές κατηγορίες ποιότητας προϊόντος: Λειτουργικότητα (Functionality), Αξιοπιστία (Reliability), Ευχρηστία (Usability), Αποδοτικότητα (Efficiency), Διατηρισιμότητα (Maintainability), Φορητότητα (Portability) 6 α Το σύστημα θα αποθηκεύσει τη βαθμολογία του χρήστη 7 α Η εργασία θα τερματιστεί 82

83 Μη Λειτουργικές απαιτήσεις Για την κατηγορία των απλών χρηστών θα παρέχεται επίσης μια σύντομη περιγραφή των χαρακτηριστικών ποιότητας όπως περιγράφονται στο βήμα 5α Κατάσταση εισόδου: Δεν υπάρχουν ιδιαίτερες απαιτήσεις εισόδου στην περίπτωση χρήσης Κατάσταση εξόδου: Το σύστημα θα πρέπει να διατηρεί ξεχωριστά τη βαθμολογία των συμβούλων IT, των developers ΛΑΚ, και των απλών χρηστών 83

84 Εικόνα 11 Διάγραμμα δραστηριοτήτων για συνεργατική βαθμολόγηση 84

85 448 Εμφάνιση σχολίων και βαθμολόγησης άλλων χρηστών Κατηγορία Χρηστών: Όλοι οι χρήστες Σύντομη Περιγραφή: Οι χρήστες θα μπορούν να αξιολογήσουν τα σχόλια άλλων χρηστών υπό την έννοια του κατά πόσο χρήσιμα ήταν και ενδεχομένως να σχολιάζουν τα σχόλια των άλλων χρηστών χρησιμοποιώντας ένα πεδίο ελεύθερου κειμένου Επίσης, ο χρήστης θα πρέπει να έχει τη δυνατότητα να δει τις αξιολογήσεις άλλων χρηστών για ένα συγκεκριμένο έργο ΛΑΚ ή για μια συλλογή έργων ΛΑΚ της ίδιας κατηγορίας λογισμικού Βασική Ροή Γεγονότων: 1 Εμφανίζεται στους χρήστες η λίστα με τα έργα ΛΑΚ 2 Οι χρήστες θα πρέπει να επιλέξουν κάποιο από τα έργα ΛΑΚ 3 Το σύστημα θα ανακτήσει τις βαθμολογίες και τα σχόλια των χρηστών 4 Εμφανίζονται στους χρήστες τα σχόλια πάνω σε έργα ΛΑΚ και οι βαθμολογίες των σχολίων 5 Γίνεται από το σύστημα έλεγχος για την εγγραφή του χρήστη 6 Αν ο χρήστης είναι συνδεδεμένος, μπορεί να βαθμολογήσει τα σχόλια των άλλων χρηστών 7 Το σύστημα θα αποθηκεύσει τις βαθμολογίες 8 Η εργασία θα τερματιστεί Εναλλακτική Ροή Γεγονότων Ι: 6 α Αν ο χρήστης δεν είναι συνδεδεμένος, μπορεί να κάνει είσοδο στο σύστημα και ο έλεγχος να επανέλθει στο βήμα 5 Εναλλακτική Ροή Γεγονότων IΙ: 6 β Αν ο χρήστης δεν είναι συνδεδεμένος, μπορεί να ζητήσει τερματισμό της εργασίας 7 α Η εργασία θα τερματιστεί 85

86 Εναλλακτική Ροή Γεγονότων IΙI: 4 α Υπολογίζονται από το σύστημα τα στατιστικά βαθμολογιών 5 α Εμφανίζονται στους χρήστες τα στατιστικά των βαθμολογιών και η εργασία τερματίζεται Μη Λειτουργικές απαιτήσεις Δεν υπάρχουν γι αυτή την περίπτωση χρήσης Κατάσταση εισόδου: Δεν υπάρχουν ιδιαίτερες απαιτήσεις εισόδου στην περίπτωση χρήσης Κατάσταση εξόδου: Για κάθε έργο ΛΑΚ και για κάθε μία από τις κατηγορίες ποιότητας το σύστημα θα αναφέρει i) τον αριθμό των υπαρχόντων αξιολογήσεων ii) τη μέση τιμή όλων των βαθμών iii) μέγιστη, ελάχιστη βαθμολογία Ακόμη μπορεί να παρουσιαστεί η μέση συνολική βαθμολογία από όλες τις κατηγορίες 86

87 Εικόνα 12 Διάγραμμα δραστηριοτήτων για εμφάνιση σχολίων και βαθμολόγησης άλλων χρηστών 87

88 449 Σύγκριση και αντιπαράθεση των έργων ΛΑΚ Κατηγορία Χρηστών: Σύμβουλος IT, γενικός χρήστης Σύντομη Περιγραφή: Οι χρήστες θα μπορούν να συγκρίνουν και να αντιπαραθέτουν τα έργα ΛΑΚ σε σχέση με την ποιότητα Βασική Ροή Γεγονότων: 1 Ο χειριστής «Σύμβουλος IT» ή «Γενικός Χρήστης» θα συνδεθούν στο σύστημα SQO-OSS 2 Το σύστημα θα ελέγξει τα δικαιώματα που έχει ο χρήστης που εισήλθε 3 Το σύστημα αναγνωρίζει ότι ο χρήστης που συνδέθηκε είναι ο «Γενικός Χρήστης» 4 Θα εμφανιστεί στο χειριστή «Γενικός Χρήστης» μια λίστα με τα έργα ΛΑΚ 5 Ο χειριστής «Γενικός Χρήστης» θα επιλέξει το έργο ΛΑΚ που τον ενδιαφέρει 6 Το σύστημα θα ελέγξει αν υπάρχουν βαθμολογίες και σχόλια για το συγκεκριμένο έργο 7 Εάν υπάρχουν τα στοιχεία, τότε το σύστημα θα ανακτήσει τα στατιστικά των βαθμολογιών και τα σχόλια 8 Θα εμφανιστούν τα σχόλια και τα στατιστικά των βαθμολογιών των Γενικών Χρηστών και των Συμβούλων IT 9 Η εργασία θα τερματιστεί Εναλλακτική Ροή Γεγονότων Ι: 6 α Εάν δεν υπάρχουν τα στοιχεία, θα εμφανιστεί στο χειριστή «Γενικό Χρήστη» ειδοποιητήριο μήνυμα Εναλλακτική Ροή Γεγονότων IΙ: 3 α Το σύστημα αναγνωρίζει ότι ο χρήστης που συνδέθηκε είναι «Σύμβουλος IT» 4 α Θα εμφανιστεί η λίστα με τα έργα ΛΑΚ 5 α Ο χειριστής «Σύμβουλος IT» θα επιλέξει ένα ή περισσότερα έργα ΛΑΚ που τον ενδιαφέρουν 88

89 6 β Ο χειριστής «Σύμβουλος IT» θα επιλέξει τις μετρικές που τον ενδιαφέρουν 7 α Το σύστημα θα εκτιμήσει τις μετρικές που επέλεξε ο χειριστής «Σύμβουλος IT» 8 α Θα εμφανιστούν τα αποτελέσματα του χειριστή «Σύμβουλος IT» 9 α Ο χειριστής «Σύμβουλος IT» έχει τη δυνατότητα να ταξινομήσει τα αποτελέσματα Εναλλακτική Ροή Γεγονότων IΙI: 9 β Η εργασία τερματίζεται Μη Λειτουργικές απαιτήσεις Οι μετρικές θα είναι ομαδοποιημένες σύμφωνα με τις κατηγορίες ποιότητας που ορίζει το ISO/IEC 9126 Κατάσταση εισόδου: Δεν υπάρχουν ιδιαίτερες απαιτήσεις εισόδου στην περίπτωση χρήσης Κατάσταση εξόδου: Οι τιμές - αποτελέσματα των μετρικών θα αναφέρονται σε μορφή πίνακα Το σύστημα θα πρέπει να αναφέρει τις στατιστικές βαθμολογικές κατατάξεις των απλών χρηστών και των συμβούλων IT ξεχωριστά 89

90 Εικόνα 13 Διάγραμμα δραστηριοτήτων για σύγκριση και αντιπαράθεση των έργων ΛΑΚ 90

91 4410 Υποστήριξη Δημιουργίας Νέων Plug-ins Κατηγορία Χρηστών: Ερευνητές, Developer ΛΑΚ Σύντομη Περιγραφή: Οι χρήστες θα έχουν τη δυνατότητα να κατεβάσουν και να χρησιμοποιήσουν τα plug ins μετρικών για αξιολόγηση Οι χρήστες θα μπορούν να προσθέτουν plug-ins τρίτων στο σύστημα Μη Λειτουργικές απαιτήσεις Το σύστημα θα πρέπει να προσφέρει αναλυτική περιγραφή για κάθε ένα από τα υπάρχοντα APIs των plug-ins Το σύστημα θα πρέπει να παρέχει λεπτομερή τεκμηρίωση των απαιτήσεων του SQO-OSS και λεπτομερείς τεχνικές προδιαγραφές για την δημιουργία και ενσωμάτωση νέων plug-ins στην πλατφόρμα του SQO-OSS Η λήψη και η δοκιμή ενός plug in (ως πηγαίο κώδικα) από το σύστημα θα μπορεί να είναι δυνατή από όλους Κατάσταση εισόδου: Δεν υπάρχουν ιδιαίτερες απαιτήσεις εισόδου στην περίπτωση χρήσης Κατάσταση εξόδου: Δεν υπάρχουν ιδιαίτερες απαιτήσεις εξόδου στην περίπτωση χρήσης 4411 Παροχή ειδοποιήσεων (alert) στο χρήστη Κατηγορία Χρηστών: Όλοι οι χρήστες, Συντονιστής έργου ΛΑΚ Σύντομη Περιγραφή: Ένας χρήστης θα μπορεί να λαμβάνει διάφορα ηλεκτρονικά μηνύματα ειδοποίησης από το σύστημα του SQO-OSS σχετικά με έργα ΛΑΚ για τα οποία αυτός ενδιαφέρεται Για παράδειγμα, ο χρήστης θα μπορούσε να ειδοποιείται όταν μία νέα έκδοση ενός έργου έχει υποβληθεί, ή όταν ένας νέος μηχανισμός μετρικής έχει υλοποιηθεί για όλα τα έργα 91

92 Βασική Ροή Γεγονότων: 1 Ο χειριστής συνδέεται στο σύστημα του SQO-OSS 2 Το σύστημα ελέγχει τα δικαιώματα του χρήστη 3 Αν ο χρήστης δεν είναι Συντονιστής έργου ΛΑΚ, του εμφανίζεται μια λίστα με έργα ΛΑΚ 4 Ο χρήστης επιλέγει ένα ή περισσότερα έργα ΛΑΚ 5 Αναγνωρίζεται ότι ο χρήστης δεν έχει εγγραφεί στη συγκεκριμένη υπηρεσία 6 Ο χρήστης εγγράφεται στην υπηρεσία 7 Ο χρήστης λαμβάνει ηλεκτρονικό μήνυμα ενημέρωσης 8 Η εργασία τερματίζει Εναλλακτική Ροή Γεγονότων Ι: 5 α Αναγνωρίζεται ότι ο χρήστης είναι εγγεγραμμένος 6 α Ο χρήστης μπορεί να ακυρώσει την παραλαβή ειδοποιήσεων αν διαγραφεί από την υπηρεσία Εναλλακτική Ροή Γεγονότων IΙ: 3 α Αν ο χρήστης είναι Συντονιστής έργου ΛΑΚ, μπορεί να υποβάλει το κείμενο που θα σταλεί ως ειδοποίηση 4 β Η εργασία τερματίζει Μη Λειτουργικές απαιτήσεις Δεν υπάρχουν για αυτή την περίπτωση χρήσης Κατάσταση εισόδου: Δεν υπάρχουν ιδιαίτερες απαιτήσεις εισόδου στην περίπτωση χρήσης Κατάσταση εξόδου: Δεν υπάρχουν ιδιαίτερες απαιτήσεις εξόδου στην περίπτωση χρήσης 92

93 Εικόνα 14 Διάγραμμα δραστηριοτήτων για παροχή ειδοποιήσεων (alert) στο χρήστη 93

94 4412 Εγγραφή Χρηστών Κατηγορία Χρηστών: Όλοι οι χρήστες Σύντομη Περιγραφή: Το SQO-OSS θα πρέπει να υποστηρίζει μία web-based διαδικασία εγγραφής χρηστών, για τους χρήστες που επιθυμούν να χρησιμοποιήσουν τις υπηρεσίες του Προτού ο χρήστης είναι σε θέση να υποβάλει ερωτήματα προς το σύστημα θα πρέπει να εγγραφεί, «βγάζοντας» ένα όνομα χρήστη και ένα κωδικό πρόσβασης Βασική Ροή Γεγονότων: 1 Ο χρήστης εισάγει προσωπικές πληροφορίες 2 Το σύστημα ελέγχει το προφίλ του χρήστη 3 Αν ο χρήστης είναι ένας Συντονιστής έργου ΛΑΚ τότε εισάγει επιπλέον δεδομένα 4 Ο χειριστής «Διαχειριστής Συστήματος SQO-OSS» λαμβάνει το αίτημα του Συντονιστή έργου ΛΑΚ 5 Ο χειριστής «Διαχειριστής Συστήματος SQO-OSS» ελέγχει για την εγκυρότητα των πληροφοριών που παρείχε ο Συντονιστής του έργου ΛΑΚ 6 Ο χειριστής «Διαχειριστής Συστήματος SQO-OSS» πιστοποιεί τον Συντονιστή του έργου ΛΑΚ 7 Ο Συντονιστής του έργου ΛΑΚ λαμβάνει ένα ενημερωτικό ενώ τα στοιχεία του αποθηκεύονται στο σύστημα 8 Η εργασία τερματίζει Εναλλακτική Ροή Γεγονότων Ι: 3 α Αν ο χρήστης δεν είναι Συντονιστής έργου ΛΑΚ, τότε αποθηκεύονται τα προσωπικά του στοιχεία 4 α Η εργασία τερματίζει 94

95 Εναλλακτική Ροή Γεγονότων IΙ: 6 α Οι πληροφορίες που παρείχε ο Συντονιστής έργου ΛΑΚ δεν είναι έγκυρες και η εργασία τερματίζεται Μη Λειτουργικές απαιτήσεις Οι χρήστες θα πρέπει να αποδεχτούν το συμφωνητικό (disclaimer) του SQO- OSS περί της προστασίας των προσωπικών τους δεδομένων Κατάσταση εισόδου: Ο ελάχιστος αριθμός πληροφοριών που απαιτούνται για την εγγραφή (υποχρεωτικά πεδία) θα είναι: Η ηλεκτρονική διεύθυνση Ο κωδικός πρόσβασης Το προφίλ Οι κωδικοί πρέπει να έχουν ελάχιστο μήκος 5 χαρακτήρων Το σύστημα θα πρέπει να ζητά δύο φορές την εισαγωγή του κωδικού από τον χρήστη και τα περιεχόμενα του πεδίου στο οποίο αυτός θα καταχωρείται δεν θα πρέπει να είναι ορατά Εάν η είσοδος του χρήστη δεν ταιριάζει στα δύο πεδία τότε το σύστημα θα πρέπει να του ζητήσει την εισαγωγή του κωδικού του εκ νέου Η ηλεκτρονική διεύθυνση θα πρέπει να συμπληρωθεί με μία έγκυρη διεύθυνση από τον χρήστη Η ηλεκτρονική διεύθυνση θα είναι το κύριο μέσο επικοινωνίας με τους χρήστες Το σύστημα θα πρέπει να ελέγχει το περιεχόμενο αυτού του πεδίου Αν το περιεχόμενο δεν είναι έγκυρο τότε θα ζητείται από τον χρήστη να συμπληρώσει την ηλεκτρονική διεύθυνση εκ νέου Στην περιοχή του προφίλ ο χρήστης θα πρέπει να επιλέξει ανάμεσα στις επόμενες κατηγορίες: developer ΛΑΚ Σύμβουλος IT IT Manager Ερευνητής Απλός Χρήστης Η ρύθμιση αυτή καθορίζει τον τρόπο με τον οποίο το σύστημα παρουσιάζει εξ ορισμού τα δεδομένα σε κάθε χρήστη 95

96 Ένα προαιρετικό πεδίο θα ρωτά τον χρήστη αν έχει ποτέ συμμετάσχει σε κάποια εφαρμογή ΛΑΚ και με ποιο τρόπο (πχ προγραμματισμός, διατήρηση, υποστήριξη άλλων developers ή χρηστών) Κατάσταση εξόδου: Δεν υπάρχουν ιδιαίτερες απαιτήσεις εξόδου στην περίπτωση χρήσης 96

97 Εικόνα 15 Διάγραμμα δραστηριοτήτων για εγγραφή χρηστών 97

98 4413 Εξουσιοδότηση Χρηστών (Authorisation) και Διαχείριση Λογαριασμού Κατηγορία Χρηστών: Όλοι οι χρήστες Σύντομη Περιγραφή: Οι χρήστες εισάγοντας το όνομα χρήστη (διεύθυνση ) και τον κωδικό πρόσβασης αναγνωρίζονται από το σύστημα Επιπλέον, έχουν τη δυνατότητα να διαχειρίζονται το λογαριασμό τους Βασική Ροή Γεγονότων: 1 Ο χρήστης θυμάται το όνομα χρήστη και τον κωδικό πρόσβασης 2 Ο χρήστης εισάγει το όνομα χρήστη και τον κωδικό πρόσβασης 3 Το σύστημα πιστοποιεί και εξουσιοδοτεί το χρήστη 4 Εμφανίζεται η κατάσταση των εκκρεμών ερωτημάτων του χρήστη 5 Ο χρήστης έχει τη δυνατότητα να μεταβάλλει τα προσωπικά του στοιχεία εκτός από την διεύθυνση ηλεκτρονικού ταχυδρομείου 6 Το σύστημα ενημερώνει τη βάση δεδομένων με τα νέα στοιχεία 7 Η εργασία τερματίζεται Εναλλακτική Ροή Γεγονότων Ι: 1 α Ο χρήστης δεν θυμάται το όνομα χρήστη και τον κωδικό πρόσβασης 2 α Ο χρήστης στέλνει αίτημα υπενθύμισης προς το σύστημα 3 α Το σύστημα αποστέλλει στο χρήστη με το νέο κωδικό πρόσβασης 4 α Η εργασία τερματίζει Εναλλακτική Ροή Γεγονότων IΙ: 5 α Η εργασία τερματίζεται Εναλλακτική Ροή Γεγονότων IΙI: 5 β Ο χρήστης έχει τη δυνατότητα να διαγράψει τον λογαριασμό του 6 α Το σύστημα ενημερώνει τη βάση δεδομένων 7 α Η εργασία τερματίζεται 98

99 Μη Λειτουργικές απαιτήσεις Δεν υπάρχουν για αυτή την περίπτωση χρήσης Κατάσταση εισόδου: Δεν υπάρχουν ιδιαίτερες απαιτήσεις εξόδου στην περίπτωση χρήσης Κατάσταση εξόδου: Δεν υπάρχουν ιδιαίτερες απαιτήσεις εξόδου στην περίπτωση χρήσης 99

100 Εικόνα 16 Διάγραμμα δραστηριοτήτων για σύνδεση στο σύστημα 100

101 5 Αξιολόγηση Απαιτήσεων Παρατηρητηρίου Ποιότητας Λογισμικού Ανοιχτού Κώδικα Οι λειτουργικές απαιτήσεις για την πλατφόρμα του SQO-OSS, αναγνωρίστηκαν, διαμορφώθηκαν και τελειοποιήθηκαν από μια διαδικασία ανοιχτή τόσο στις ομάδες που συνεργάστηκαν για το SQO-OSS όσο και για το κοινό Για αυτό το σκοπό, συμπεριλήφθηκε μέσα στο SQO-OSS wiki server μια ενότητα με τον τίτλο wish list για την αποστολή προτάσεων σχετικών με τα λειτουργικά χαρακτηριστικά του SQO-OSS Το Αριστοτέλειο Πανεπιστήμιο Θεσσαλονίκης απέστειλε αρχικές προτάσεις, και στη συνέχεια ακολούθησαν οι υπόλοιποι εταίροι με περισσότερες προτάσεις [24] Όλα τα παραπάνω παρουσιάστηκαν και συζητήθηκαν στη δεύτερη συνάντηση του project στη Θεσσαλονίκη, στην Ελλάδα Καθώς, πάντα υπάρχει η περίπτωση να εμφανιστούν χρονικοί και οικονομικοί περιορισμοί μέσα στη φάση υλοποίησης ενός project με αποτέλεσμα να μην υλοποιηθούν όλα τα χαρακτηριστικά του λογισμικού που προτάθηκαν, η διεθνής εταιρική συνεργασία αποφάσισε να διεξαχθεί μια τυπική διαδικασία αξιολόγησης των απαιτήσεων όπως επίσης και μια εκτίμηση του κόστους που θα μπορούσε να καθορίσει ένα ιεραρχημένο σύνολο απαιτήσεων προς εφαρμογή Για τη διαδικασία αξιολόγησης υπεύθυνο ήταν το Αριστοτέλειο Πανεπιστήμιο Θεσσαλονίκης και ξεκίνησε στη συνάντηση της Θεσσαλονίκης, αρχικά με την ιεράρχηση των κατηγοριών χρηστών που είχαν αναγνωριστεί σε προηγούμενο στάδιο μέσω του wiki στο server του SQO-OSS Δημιουργήθηκε λοιπόν ένα εκτυπωμένο έγγραφο που περιείχε μια λίστα με τις 6 κατηγορίες χρηστών (Γενικός Χρήστης, OSS developers, σύμβουλοι IT, IT managers, Ερευνητές, Διαχειριστές συστήματος) Οι συμμετέχοντες στη συνάντηση κλήθηκαν να ιεραρχήσουν αυτές τις κατηγορίες στόχους με τον ακόλουθο τρόπο: Δεδομένου ότι έχουμε διαθέσιμους 24 ανθρωπομήνες για να διαμοιραστεί η προσπάθεια της ικανοποίησης των απαιτήσεων των χρηστών, ο κάθε συμμετέχοντας (ανεξάρτητα) θα πρέπει να αποδώσει αυτούς τους ανθρωπομήνες σε αυτές τις κατηγορίες 101

102 Ανακεφαλαιώνοντας, η προσπάθεια ανθρωπομηνών που προτάθηκε από τους συνεργάτες ανά κατηγορία χρήστη είναι η εξής: Πίνακας 2 Απόδοση ανθρωπομηνών σε κατηγορίες χρήστη ανάλογα με τη σημαντικότητά τους Κατηγορία Χρήστη OSS developer 152 IT manager 51 IT consultant 49 Researcher 45 General User 35 System Administrator 28 Ανθρωπομήνας Τα παραπάνω αποτελέσματα χρησιμοποιήθηκαν ως βάρη για τις απαιτήσεις (καθώς κάθε απαίτηση ανήκει σε μια κατηγορία χρηστών) Προκειμένου να ιεραρχηθούν οι απαιτήσεις, ένας απλός τρόπος είναι να δοθεί υψηλότερη προτεραιότητα στις απαιτήσεις του χαμηλότερου εκτιμώμενου κόστους εφαρμογής Στο SQO- OSS, ακολουθήθηκε μια συστηματικότερη και σύνθετη προσέγγιση καθορισμού προτεραιοτήτων για να λάβει υπόψη τη σημαντικότητα μιας απαίτησης παρά το κόστος ή την προσπάθεια που απαιτήθηκε για την εφαρμογή της Το κόστος και ο χρόνος υπολογίστηκαν αλλά εξετάστηκαν ως εξής: Η αθροιστική εκτιμώμενη προσπάθεια για τις απαιτήσεις ταξινομημένη ως προς τη προτεραιότητα, δεν πρέπει να υπερβεί τη συνολική προσπάθεια που είναι διαθέσιμη για την ανάπτυξης μέσα στη φάση προγράμματος Για το σκοπό αυτό μελετήθηκαν οι δύο προσεγγίσεις που παρουσιάστηκαν στην ενότητα 3 Εξαιτίας του αριθμού των συνεργατών και της δυσκολίας στη συλλογή pairwise συγκρίσεων, από τις δύο μεθόδους επιλέχθηκε η ARM Για το σκοπό αυτό διανεμήθηκε στους συνεργάτες του project ένα έγγραφο όπου θα έπρεπε να ταξινομήσουν το σύνολο των απαιτήσεων Κάθε κατηγορία χρήστη ταξινομήθηκε ανεξάρτητα Κάθε συνεργάτης επέστρεψε το έγγραφό του με τα εξής στοιχεία: 102

103 Πίνακας 3 Ταξινόμηση συνόλου απαιτήσεων ανά συνεργάτη Προκειμένου να καθοριστεί το βάρος κάθε λίστας, όπως απαιτείται από την μέθοδο ARM, εφαρμόζουμε ένα απλό ευρετικό βήμα προεπεξεργασίας Για κάθε λίστα l (δηλ για κάθε άτομο που ταξινομεί), βρίσκουμε τον αριθμό στοιχείων συνόλου που τέθηκαν στις απαιτήσεις (n t, L }, οι οποίες καταλαμβάνουν την ίδια θέση σε οποιοδήποτε άλλη λίστα Κανονικοποιούμε το {n t, λ } έτσι ώστε συνολικά να προκύπτει το 1 και χρησιμοποιούμε τις προκύπτουσες τιμές ως βάρη στη διαδικασία της συνάθροισης της ταξινόμησης Στόχος του ευρετικού βήματος είναι να αυξηθεί η σημαντικότητα των αξιολογήσεων που αντιπροσωπεύουν μια συναίνεση σε σχέση με την ταξινόμηση ενός αντικειμένου Τέλος, έχοντας ως δεδομένα, 1 Την ιεράρχηση από κάθε συνεργάτη για κάθε κατηγορία χρήστη και εφαρμόζοντας 2 Τα βάρη για την κάθε κατηγορία χρήστη που ψηφίστηκε και 103

104 3 (περισσότερο σημαντικά) Το κόστος σε ανθρωπομήνες που εκτιμήθηκε από το SENSE και την PROSYST προκύπτει η τελική λίστα απαιτήσεων που είναι ταξινομημένη και μπορεί να υλοποιηθεί μέσα στη φάση του έργου όπως φαίνεται παρακάτω: Πίνακας 4 Τελική Λίστα ταξινομημένων απαιτήσεων Απαίτηση Βαθμολογία View/Request Code Evaluation 1 Defect Statistics 2 View/Estimate Future Evolution of 3 Project Developer Statistics 4 Compare and Contrast OSS projects 5 Collaborative Scoring 6 Support Creating New Plugins 7 Provide User Alerts 8 Statistical Representation of OSS runtime 9 Η τελευταία απαίτηση (Statistical representation of OSS runtime) δε θα υλοποιηθεί κατά τη διάρκεια της φάσεις του έργου 6 Επίλογος Συμπεράσματα Η εργασία αυτή ερεύνησε τις διαδικασίες τεχνολογίας απαιτήσεων και τις εφάρμοσε στο Παρατηρητήριο Ποιότητας Λογισμικού Ανοικτού Κώδικα Προέκυψε λοιπόν ότι η ανάπτυξη απαιτήσεων ανοιχτού λογισμικού είναι διαφορετική από την τεχνολογία απαιτήσεων, όχι καλύτερη ή χειρότερη, αλλά διαφορετική, καινούρια, περισσότερο κοινωνική, προσβάσιμη, ζωντανή 104

105 Οι διαδικασίες των απαιτήσεων δεν συμβαίνουν ανεξάρτητα και μεμονωμένα αλλά συμβαίνουν παράλληλα με την υλοποίηση και με τα επόμενα στάδια κύκλου ζωής του Λογισμικού χωρίς όμως αυτό να επιδιώκεται Οι διαδικασίες αυτές πραγματοποιούνται αλλά με έναν τρόπο ανεπίσημο και όχι απόλυτα διαχωρισμένο από τις διαδικασίες ανάπτυξης του λογισμικού Γενικά, οι πρακτικές που εφαρμόζονται στην ανάπτυξη του λογισμικού συνεχώς αναπτύσσονται και διαδίδονται και ίσως θα μπορούσαν να επεκταθούν και σε περισσότερο σύνθετα συστήματα λογισμικού Η άτυπη καταγραφή των απαιτήσεων και τα εργαλεία που χρησιμοποιούνται θα μπορούσαν να ενσωματωθούν σε παραδοσιακά πακέτα λογισμικού τεχνολογίας απαιτήσεων Η ανάπτυξη των απαιτήσεων ενός συστήματος ΛΑΚ ενυπάρχει με ένα σύνθετο δίκτυο κοινωνικοτεχνικών διαδικασιών, με καταστάσεις ανάπτυξης και δυναμικά εμφανιζόμενα περιβάλλοντα Με αυτό τον τρόπο, οι απαιτήσεις για συστήματα ΛΑΚ συνεχώς αναπτύσσονται μέσω ενός δικτύου αφηγήσεων των κοινοτήτων Αυτές οι αφηγήσεις προκύπτουν από συζητήσεις στις οποίες υπάρχει ανοικτή πρόσβαση 7 Βιβλιογραφία 1 R Fagin, R Kumar, M Mahdian, D Sivakumar, E Vee, Comparing and Aggregating Rankings with Ties, ACM PODS Lulu he, Jeffrey C Carver and Rayford B Vaugh, Using Inspection to Teach Requirements Validation, Department of Computer Science and Engineering, Mississippi State University, Sulayman Sowe, Ioannis Stamelos, Lefteris Angelis, Identifying knowledge brokers that yield software engineering knowledge in OSS projects, ScienceDirect, Information and Software Technology , Bart Massey, Where Do Open Source Requirements Come From (And What Should We Do About It)?, Second ICSE Workshop on Open Source Software Engineering, Gerard Holzmann, Software Verification at Bell Labs: one line of development, ACM,

106 6 Thomas Thelin and Per Runeson, Claes Wohlin, Prioritized Use Cases as a Vehicle for Software Inspections, IEEE software, Ioannis P Antoniades, Ioannis Samoladas, Ioannis Stamelos, Lefteris Angelis and George Bleris, Dynamical Simulation Models of the Open Source Development Process, Chapter 8, pag , Idea Group Inc Walt Scacch, Understanding the Requirements for Developing Open Source Software Systems, IEEE Proceedings Software, Mark Aberdour, Achieving Quality in OSS, IEEE Computer Society software, Mansoureh Mollaghasemi, Julia Pet-Edwards, Making Multiple Objective Decisions, IEEE Computer Society, Technical Briefing, Ian Sommerville, Software Engineering 6 th Edition, Addison Wesley, Shari Lawrence Pfleeger, Software Engineering Theory and Practice, Second Edition, Prentice Hall, Shari Lawrence Pfleeger, Τεχνολογία Λογισμικού Θεωρία και Πράξη Δεύτερη Αμερικάνικη Έκδοση, Εκδόσεις Κλειδάριθμος, Βασίλειος Βεσκούκης, Αρχές Τεχνολογίας Λογισμικού, Τεχνολογία Λογισμικού IΙ, Ελληνικό Ανοιχτό Πανεπιστήμιο 15 Κλεάνθης Θραμπουλίδης, Γλώσσες Προγραμματισμού ΙΙ (Αντικειμενοστρεφής προγραμματισμός), Ελληνικό Ανοιχτό Πανεπιστήμιο 16 Αφροδίτη Τσαλγατίδου, Γιάννης Κοτρώνης, Σημειώσεις Τεχνολογίας Λογισμικού, Πανεπιστημιακές σημειώσεις, Εθνικό Καποδιστριακό Πανεπιστήμιο Αθηνών, Ιωάννης Σαμολαδάς, Ελεύθερο Λογισμικο/ Λογισμικό Ανοιχτού Κώδικα (ΕΛΛΑΚ) Πανεπιστημιακές Σημειώσεις ΑΠΘ, Δημήτρης Δεσπότης, Ιεραρχική Ανάλυση Αποφάσεων, Recommended Practice for Software Requirements Specifications ({IEEE }), Rob Purdie, Requirements prioritization,

107 21 Qualitative study critique: open source requirements development, Lisa G R Henderson, Requirements Elicitation in Open-Source Programs,

108 Παράρτημα Α 108

109 Στο συγκεκριμένο παράρτημα περιγράφονται τα περιεχόμενα των ενοτήτων που προτείνει η IEEE στο πρότυπο για το έγγραφό προδιαγραφής απαιτήσεων 1 Introduction (Section 1 of the SRS) The introduction of the SRS should provide an overview of the entire SRS It should contain the following subsections: a) Purpose; b) Scope; c) Definitions, acronyms, and abbreviations; d) References; e) Overview 11 Purpose (11 of the SRS) This subsection should a) Delineate the purpose of the SRS; b) Specify the intended audience for the SRS 12 Scope (12 of the SRS) This subsection should a) Identify the software product(s) to be produced by name (eg, Host DBMS, Report Generator, etc); b) Explain what the software product(s) will, and, if necessary, will not do; c) Describe the application of the software being specified, including relevant benefits, objectives, and goals; d) Be consistent with similar statements in higher-level specifications (eg, the system requirements specification), if they exist 13 Definitions, acronyms, and abbreviations (13 of the SRS) This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the SRS This information may be provided by reference to one or more appendixes in the SRS or by reference to other documents 14 References (14 of the SRS) This subsection should a) Provide a complete list of all documents referenced elsewhere in the SRS; b) Identify each document by title, report number (if applicable), date, and publishing organization; c) Specify the sources from which the references can be obtained This information may be provided by reference to an appendix or to another document 15 Overview (15 of the SRS) This subsection should a) Describe what the rest of the SRS contains; b) Explain how the SRS is organized 2 Overall description (Section 2 of the SRS) 109

110 This section of the SRS should describe the general factors that affect the product and its requirements This section does not state specific requirements Instead, it provides a background for those requirements, which are defined in detail in Section 3 of the SRS, and makes them easier to understand This section usually consists of six subsections, as follows: a) Product perspective; b) Product functions; c) User characteristics; d) Constraints; e) Assumptions and dependencies; f) Apportioning of requirements 21 Product perspective (21 of the SRS) This subsection of the SRS should put the product into perspective with other related products If the product is independent and totally self-contained, it should be so stated here If the SRS defines a product that is a component of a larger system, as frequently occurs, then this subsection should relate the requirements of that larger system to functionality of the software and should identify interfaces between that system and the software A block diagram showing the major components of the larger system, interconnections, and external interfaces can be helpful This subsection should also describe how the software operates inside various constraints For example, these constraints could include a) System interfaces; b) User interfaces; c) Hardware interfaces; d) Software interfaces; e) Communications interfaces; f) Memory; g) Operations; h) Site adaptation requirements 211 System interfaces This should list each system interface and identify the functionality of the software to accomplish the system requirement and the interface description to match the system 212 User interfaces This should specify the following: a) The logical characteristics of each interface between the software product and its users This includes those configuration characteristics (eg, required screen formats, page or window layouts, content of any reports or menus, or availability of programmable function keys) necessary to accomplish the software requirements b) All the aspects of optimizing the interface with the person who must use the system This may simply comprise a list of do s and don ts on how the system will appear to the user One example may be a requirement for the option of long or short error messages Like all 110

111 others, these requirements should be verifiable, eg, a clerk typist grade 4 can do function X in Z min after 1 h of training rather than a typist can do function X (This may also be specified in the Software System Attributes under a section titled Ease of Use) 213 Hardware interfaces This should specify the logical characteristics of each interface between the software product and the hardware components of the system This includes configuration characteristics (number of ports, instruction sets, etc) It also covers such matters as what devices are to be supported, how they are to be supported, and protocols For example, terminal support may specify full-screen support as opposed to line-by-line support 214 Software interfaces This should specify the use of other required software products (eg, a data management system, an operating system, or a mathematical package), and interfaces with other application systems (eg, the linkage between an accounts receivable system and a general ledger system) For each required software product, the following should be provided: - Name; - Mnemonic; - Specification number; - Version number; - Source For each interface, the following should be provided: - Discussion of the purpose of the interfacing software as related to this software product - Definition of the interface in terms of message content and format It is not necessary to detail any well-documented interface, but a reference to the document defining the interface is required 215 Communications interfaces This should specify the various interfaces to communications such as local network protocols, etc 216 Memory constraints This should specify any applicable characteristics and limits on primary and secondary memory 217 Operations This should specify the normal and special operations required by the user such as a) The various modes of operations in the user organization (eg, user-initiated operations); b) Periods of interactive operations and periods of unattended operations; c) Data processing support functions; d) Backup and recovery operations NOTE - This is sometimes specified as part of the User Interfaces section 218 Site adaptation requirements This should 111

112 a) Define the requirements for any data or initialization sequences that are specific to a given site, mission, or operational mode (eg, grid values, safety limits, etc); b) Specify the site or mission-related features that should be modified to adapt the software to a particular installation 22 Product functions (22 of the SRS) This subsection of the SRS should provide a summary of the major functions that the software will perform For example, an SRS for an accounting program may use this part to address customer account maintenance, customer statement, and invoice preparation without mentioning the vast amount of detail that each of those functions requires Sometimes the function summary that is necessary for this part can be taken directly from the section of the higher-level specification (if one exists) that allocates particular functions to the software product Note that for the sake of clarity a) The functions should be organized in a way that makes the list of functions understandable to the customer or to anyone else reading the document for the first time b) Textual or graphical methods can be used to show the different functions and their relationships Such a diagram is not intended to show a design of a product, but simply shows the logical relationships among variables 23 User characteristics (23 of the SRS) This subsection of the SRS should describe those general characteristics of the intended users of the product including educational level, experience, and technical expertise It should not be used to state specific requirements, but rather should provide the reasons why certain specific requirements are later specified in Section 3 of the SRS 24 Constraints (24 of the SRS) This subsection of the SRS should provide a general description of any other items that will limit the developer s options These include a) Regulatory policies; b) Hardware limitations (eg, signal timing requirements); c) Interfaces to other applications; d) Parallel operation; e) Audit functions; f) Control functions; g) Higher-order language requirements; h) Signal handshake protocols (eg, XON-XOFF, ACK-NACK); i) Reliability requirements; j) Criticality of the application; k) Safety and security considerations 25 Assumptions and dependencies (25 of the SRS) This subsection of the SRS should list each of the factors that affect the requirements stated in the SRS 112

113 These factors are not design constraints on the software but are, rather, any changes to them that can affect the requirements in the SRS For example, an assumption may be that a specific operating system will be available on the hardware designated for the software product If, in fact, the operating system is not available, the SRS would then have to change accordingly 26 Apportioning of requirements (26 of the SRS) This subsection of the SRS should identify requirements that may be delayed until future versions of the system 3 Specific requirements (Section 3 of the SRS) This section of the SRS should contain all of the software requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements, and testers to test that the system satisfies those requirements Throughout this section, every stated requirement should be externally perceivable by users, operators, or other external systems These requirements should include at a minimum a description of every input (stimulus) into the system, every output (response) from the system, and all functions performed by the system in response to an input or in support of an output As this is often the largest and most important part of the SRS, the following principles apply: a) Specific requirements should be stated in conformance with all the characteristics described in 43 b) Specific requirements should be cross-referenced to earlier documents that relate c) All requirements should be uniquely identifiable d) Careful attention should be given to organizing the requirements to maximize readability Before examining specific ways of organizing the requirements it is helpful to understand the various items that comprise requirements as described in 531 through External interfaces This should be a detailed description of all inputs into and outputs from the software system It should complement the interface descriptions in 52 and should not repeat information there It should include both content and format as follows: a) Name of item; b) Description of purpose; c) Source of input or destination of output; d) Valid range, accuracy, and/or tolerance; e) Units of measure; f) Timing; g) Relationships to other inputs/outputs; h) Screen formats/organization; i) Window formats/organization; j) Data formats; k) Command formats; l) End messages 32 Functions 113

114 Functional requirements should define the fundamental actions that must take place in the software in accepting and processing the inputs and in processing and generating the outputs These are generally listed as shall statements starting with The system shall These include a) Validity checks on the inputs b) Exact sequence of operations c) Responses to abnormal situations, including 1) Overflow 2) Communication facilities 3) Error handling and recovery d) Effect of parameters e) Relationship of outputs to inputs, including 1) Input/output sequences 2) Formulas for input to output conversion It may be appropriate to partition the functional requirements into subfunctions or subprocesses This does not imply that the software design will also be partitioned that way 33 Performance requirements This subsection should specify both the static and the dynamic numerical requirements placed on the software or on human interaction with the software as a whole Static numerical requirements may include the following: a) The number of terminals to be supported; b) The number of simultaneous users to be supported; c) Amount and type of information to be handled Static numerical requirements are sometimes identified under a separate section entitled Capacity Dynamic numerical requirements may include, for example, the numbers of transactions and tasks and the amount of data to be processed within certain time periods for both normal and peak workload conditions All of these requirements should be stated in measurable terms For example, 95% of the transactions shall be processed in less than 1 s rather than, An operator shall not have to wait for the transaction to complete NOTE - Numerical limits applied to one specific function are normally specified as part of the processing subparagraph description of that function 34 Logical database requirements This should specify the logical requirements for any information that is to be placed into a database This may include the following: a) Types of information used by various functions; b) Frequency of use; c) Accessing capabilities; d) Data entities and their relationships; e) Integrity constraints; f) Data retention requirements 114

115 35 Design constraints This should specify design constraints that can be imposed by other standards, hardware limitations, etc 351 Standards compliance This subsection should specify the requirements derived from existing standards or regulations They may include the following: a) Report format; b) Data naming; c) Accounting procedures; d) Audit tracing For example, this could specify the requirement for software to trace processing activity Such traces are needed for some applications to meet minimum regulatory or financial standards An audit trace requirement may, for example, state that all changes to a payroll database must be recorded in a trace file with before and after values 36 Software system attributes There are a number of attributes of software that can serve as requirements It is important that required attributes be specified so that their achievement can be objectively verified Subclauses 5361 through 5365 provide a partial list of examples 361 Reliability This should specify the factors required to establish the required reliability of the software system at time of delivery 362 Availability This should specify the factors required to guarantee a defined availability level for the entire system such as checkpoint, recovery, and restart 363 Security This should specify the factors that protect the software from accidental or malicious access, use, modification, destruction, or disclosure Specific requirements in this area could include the need to a) Utilize certain cryptographical techniques; b) Keep specific log or history data sets; c) Assign certain functions to different modules; d) Restrict communications between some areas of the program; e) Check data integrity for critical variables 364 Maintainability This should specify attributes of software that relate to the ease of maintenance of the software itself There may be some requirement for certain modularity, interfaces, complexity, etc Requirements should not be placed here just because they are thought to be good design practices 365 Portability This should specify attributes of software that relate to the ease of porting the software to other host machines and/or operating systems This may include the following: 115

116 a) Percentage of components with host-dependent code; b) Percentage of code that is host dependent; c) Use of a proven portable language; d) Use of a particular compiler or language subset; e) Use of a particular operating system 37 Organizing the specific requirements For anything but trivial systems the detailed requirements tend to be extensive For this reason, it is recommended that careful consideration be given to organizing these in a manner optimal for understanding There is no one optimal organization for all systems Different classes of systems lend themselves to different organizations of requirements in Section 3 of the SRS Some of these organizations are described in 5371 through System mode Some systems behave quite differently depending on the mode of operation For example, a control system may have different sets of functions depending on its mode: training, normal, or emergency When organizing this section by mode, the outline in A1 or A2 should be used The choice depends on whether interfaces and performance are dependent on mode 372 User class Some systems provide different sets of functions to different classes of users For example, an elevator control system presents different capabilities to passengers, maintenance workers, and fire fighters When organizing this section by user class, the outline in A3 should be used 373 Objects Objects are real-world entities that have a counterpart within the system For example, in a patient monitoring system, objects include patients, sensors, nurses, rooms, physicians, medicines, etc Associated with each object is a set of attributes (of that object) and functions (performed by that object) These functions are also called services, methods, or processes When organizing this section by object, the outline in A4 should be used Note that sets of objects may share attributes and services These are grouped together as classes 374 Feature A feature is an externally desired service by the system that may require a sequence of inputs to effect the desired result For example, in a telephone system, features include local call, call forwarding, and conference call Each feature is generally described in a sequence of stimulus-response pairs When organizing this section by feature, the outline in A5 should be used 375 Stimulus Some systems can be best organized by describing their functions in terms of stimuli For example, the functions of an automatic aircraft landing system may be organized into sections for loss of power, wind shear, sudden change in roll, vertical velocity excessive, etc When organizing this section by stimulus, the outline in A6 should be used 376 Response 116

117 Some systems can be best organized by describing all the functions in support of the generation of a response For example, the functions of a personnel system may be organized into sections corresponding to all functions associated with generating paychecks, all functions associated with generating a current list of employees, etc The outline in A6 (with all occurrences of stimulus replaced with response) should be used 377 Functional hierarchy When none of the above organizational schemes prove helpful, the overall functionality can be organized into a hierarchy of functions organized by either common inputs, common outputs, or common internal data access Data flow diagrams and data dictionaries can be used to show the relationships between and among the functions and data When organizing this section by functional hierarchy, the outline in A7 should be used 38 Additional comments Whenever a new SRS is contemplated, more than one of the organizational techniques given in 5377 may be appropriate In such cases, organize the specific requirements for multiple hierarchies tailored to the specific needs of the system under specification For example, see A8 for an organization combining user class and feature Any additional requirements may be put in a separate section at the end of the SRS There are many notations, methods, and automated support tools available to aid in the documentation of requirements For the most part, their usefulness is a function of organization For example, when organizing by mode, finite state machines or state charts may prove helpful; when organizing by object, object-oriented analysis may prove helpful; when organizing by feature, stimulus-response sequences may prove helpful; and when organizing by functional hierarchy, data flow diagrams and data dictionaries may prove helpful In any of the outlines given in A1 through A8, those sections called Functional Requirement may be described in native language (eg, English), in pseudocode, in a system definition language, or in four subsections titled: Introduction, Inputs, Processing, and Outputs A1 Template of SRS Section 3 organized by mode: Version 1 3 Specific requirements 31 External interface requirements 311 User interfaces 312 Hardware interfaces 313 Software interfaces 314 Communications interfaces 32 Functional requirements 321 Mode Functional requirement

118 321n Functional requirement 1n 322 Mode 2 32m Mode m 32m1 Functional requirement m1 32mn Functional requirement mn 33 Performance requirements 34 Design constraints 35 Software system attributes 36 Other requirements A2 Template of SRS Section 3 organized by mode: Version 2 3 Specific requirements 31 Functional requirements 311 Mode External interfaces User interfaces Hardware interfaces Software interfaces Communications interfaces 3112 Functional requirements Functional requirement n Functional requirement n 3113 Performance 312 Mode 2 31m Mode m 32 Design constraints 33 Software system attributes 34 Other requirements A3 Template of SRS Section 3 organized by user class 3 Specific requirements 118

119 31 External interface requirements 311 User interfaces 312 Hardware interfaces 313 Software interfaces 314 Communications interfaces 32 Functional requirements 321 User class Functional requirement n Functional requirement 1n 322 User class 2 32m User class m 32m1 Functional requirement m1 32mn Functional requirement mn 33 Performance requirements 34 Design constraints 35 Software system attributes 36 Other requirements A4 Template of SRS Section 3 organized by object 3 Specific requirements 31 External interface requirements 311 User interfaces 312 Hardware interfaces 313 Software interfaces 314 Communications interfaces 32 Classes/Objects 321 Class/Object Attributes (direct or inherited) Attribute 1 119

120 3211n Attribute n 3212 Functions (services, methods, direct or inherited) Functional requirement m Functional requirement 1m 3213 Messages (communications received or sent) 322 Class/Object 2 32p Class/Object p 33 Performance requirements 34 Design constraints 35 Software system attributes 36 Other requirements A5 Template of SRS Section 3 organized by feature 3 Specific requirements 31 External interface requirements 311 User interfaces 312 Hardware interfaces 313 Software interfaces 314 Communications interfaces 32 System features 321 System Feature Introduction/Purpose of feature 3212 Stimulus/Response sequence 3213 Associated functional requirements Functional requirement n Functional requirement n 322 System feature 2 32m System feature m 120

121 33 Performance requirements 34 Design constraints 35 Software system attributes 36 Other requirements A6 Template of SRS Section 3 organized by stimulus 3 Specific requirements 31 External interface requirements 311 User interfaces 312 Hardware interfaces 313 Software interfaces 314 Communications interfaces 32 Functional requirements 321 Stimulus Functional requirement n Functional requirement 1n 322 Stimulus 2 32m Stimulus m 32m1 Functional requirement m1 32mn Functional requirement mn 33 Performance requirements 34 Design constraints 35 Software system attributes 36 Other requirements A7 Template of SRS Section 3 organized by functional hierarchy 3 Specific requirements 31 External interface requirements 311 User interfaces 312 Hardware interfaces 121

122 313 Software interfaces 314 Communications interfaces 32 Functional requirements 321 Information flows 3211 Data flow diagram Data entities Pertinent processes Topology 3212 Data flow diagram Data entities Pertinent processes Topology 321n Data flow diagram n 321n1 Data entities 321n2 Pertinent processes 321n3 Topology 322 Process descriptions 3221 Process Input data entities Algorithm or formula of process Affected data entities 3222 Process Input data entities Algorithm or formula of process Affected data entities 322m Process m 322m1 Input data entities 322m2 Algorithm or formula of process 322m3 Affected data entities 323 Data construct specifications 3231 Construct Record type Constituent fields 3232 Construct Record type 122

123 32322 Constituent fields 323p Construct p 323p1 Record type 323p2 Constituent Þelds 324 Data dictionary 3241 Data element Name Representation Units/Format Precision/Accuracy Range 3242 Data element Name Representation Units/Format Precision/Accuracy Range 324q Data element q 324q1 Name 324q2 Representation 324q3 Units/Format 324q4 Precision/Accuracy 324q5 Range 33 Performance requirements 34 Design constraints 35 Software system attributes 36 Other requirements A8 Template of SRS Section 3 showing multiple organizations 3 Specific requirements 31 External interface requirements 311 User interfaces 312 Hardware interfaces 313 Software interfaces 314 Communications interfaces 123

124 32 Functional requirements 321 User class Feature Introduction/Purpose of feature Stimulus/Response sequence Associated functional requirements 3212 Feature Introduction/Purpose of feature Stimulus/Response sequence Associated functional requirements 321m Feature 1m 321m1 Introduction/Purpose of feature 321m2 Stimulus/Response sequence 321m3 Associated functional requirements 322 User class 2 32n User class n 33 Performance requirements 34 Design constraints 35 Software system attributes 36 Other requirements 4 Supporting information The supporting information makes the SRS easier to use It includes the following: a) Table of contents; b) Index; c) Appendixes 41 Table of contents and index The table of contents and index are quite important and should follow general compositional practices 42 Appendixes The appendixes are not always considered part of the actual SRS and are not always necessary They may include 124

125 a) Sample input/output formats, descriptions of cost analysis studies, or results of user surveys; b) Supporting or background information that can help the readers of the SRS; c) A description of the problems to be solved by the software; d) Special packaging instructions for the code and the media to meet security, export, initial loading, or other requirements When appendixes are included, the SRS should explicitly state whether or not the appendixes are to be considered part of the requirements 125

126 Παράρτημα Β 126

127 Στο συγκεκριμένο παράρτημα περιγράφονται κάποιες βασικές έννοιες σχετικά με τις περιπτώσεις χρήσης για την αναπαράσταση των λειτουργικών απαιτήσεων χρησιμοποιώντας συμβολισμούς της UML 1 Τι είναι «Περίπτωση Χρήσης» Η ικανοποίηση κάθε λειτουργικής απαίτησης από μία εφαρμογή λογισμικού υλοποιείται ως μια αλληλουχία ενεργειών που εκτελούνται από το λογισμικό, αλληλεπιδρώντας είτε με κάποιον χρήστη (φυσικό πρόσωπο), είτε μ' άλλα συστήματα (λχ άλλες εφαρμογές λογισμικού, εξωτερικές συσκευές, εξωτερικές πηγές δεδομένων) Μια τέτοια αλληλεπίδραση παράγει ένα αποτέλεσμα επιθυμητό για το χρήστη της εφαρμογής λογισμικού, δηλαδή ικανοποιεί μια λειτουργική απαίτησή του και ονομάζεται Περίπτωση Χρήσης Μια Περίπτωση Χρήσης (Use Case) είναι μια αλληλουχία ενεργειών που εκτελεί το λογισμικό αλληλεπιδρώντας με το χρήστη ή με εξωτερικά συστήματα, προκειμένου να ικανοποιήσει μία λειτουργική απαίτηση Κάθε περίπτωση χρήσης μπορεί να περιγράφεται με μεγαλύτερη ή μικρότερη λεπτομέρεια, όπως άλλωστε και κάθε απαίτηση από το λογισμικό Στο σημείο αυτό δεν έχει μεγάλη σημασία το επίπεδο λεπτομέρειας, όσο ένα άλλο χαρακτηριστικό του ορισμού της περίπτωσης χρήσης, το οποίο μπορεί εύκολα να περάσει απαρατήρητο: Μια περίπτωση χρήσης χαρακτηρίζεται τόσο από την αλληλουχία των ενεργειών που εκτελεί το λογισμικό, όσο και από το μέρος εκείνο με το οποίο αλληλεπιδρά, δηλαδή ένα χρήστη φυσικό πρόσωπο ή ένα εξωτερικό σύστημα Το μέρος αυτό ονομάζεται Χειριστής Ένας Χειριστής (Actor) είναι μια κατηγορία χρηστών ή μια εξωτερική οντότητα με την οποία αλληλεπιδρά το λογισμικό κατά την εκτέλεση των ενεργειών μιας Περίπτωσης Χρήσης Στην περίπτωση που ένας Χειριστής αντιστοιχεί σε χρήστη φυσικό πρόσωπο, κάνουμε λόγο για μια κατηγορία φυσικών προσώπων και όχι για κάποιο συγκεκριμένο πρόσωπο Αυτό συμβαίνει, διότι μας απασχολεί ο καθορισμός της αλληλεπίδρασης ενός χρήστη με το λογισμικό και όχι η ταυτότητά του χρήστη αυτού ως φυσικό πρόσωπο (την οποία συνήθως δεν είμαστε σε θέση να γνωρίζουμε) Αυτή η αλληλεπίδραση μπορεί να ιδωθεί ως ρόλος που παίζει ένα φυσικό πρόσωπο όταν χρησιμοποιεί το λογισμικό, οπότε μπορεί να διατυπωθεί η ακόλουθη θέση: Όταν ένας Χειριστής αντιστοιχεί σε κατηγορία χρηστών λογισμικού φυσικών προσώπων, τότε η έννοια του Χειριστή είναι ισοδύναμη με την έννοια ενός Ρόλου (role) των χρηστών του λογισμικού 127

128 Στην περίπτωση που ο Χειριστής αντιστοιχεί σε εξωτερικό σύστημα (λογισμικό, συσκευή), τότε συνήθως το σύστημα αυτό είναι συνήθως συγκεκριμένο και πρέπει, σε επόμενη φάση της ανάπτυξης, να προδιαγραφεί πλήρως η διαπροσωπία (interface) του λογισμικού με αυτό Εξαίρεση σ' αυτό αποτελεί η περίπτωση όπου το λογισμικό που κατασκευάζεται προορίζεται να παρέχει υπηρεσίες σε άλλα συστήματα λογισμικού, οπότε ο Χειριστής δεν αντιστοιχεί σε γνωστό εκ των προτέρων εξωτερικό σύστημα Κάθε περίπτωση χρήσης ενεργοποιείται από ένα Χειριστή Όταν εκτελούνται οι ενέργειες που περιλαμβάνονται στην περίπτωση χρήσης, τότε μπορούμε να λέμε ότι «εκτελείται η περίπτωση χρήσης» Γενικά, αναζητούμε τις λειτουργικές απαιτήσεις ως εργασίες συνυφασμένες με τους ωφελούμενους από αυτές και όχι γενικά και αόριστα ως εργασίες που «καλό θα ήταν να κάνει το λογισμικό» Εικόνα 17 Συμβολισμοί UML για τις περιπτώσεις χρήσης και τους χειριστές Στην Εικόνα 17 φαίνονται οι συμβολισμοί που χρησιμοποιεί η UML για την παράσταση των περιπτώσεων χρήσης Μια απεικόνιση περιπτώσεων χρήσης με τους συμβολισμούς αυτούς αποτελεί ένα διάγραμμα περιπτώσεων χρήσης (Use Case Diagram) Το σύνολο των διαγραμμάτων περιπτώσεων χρήσης αποτελεί το μοντέλο περιπτώσεων χρήσης της εφαρμογής (Use Case Model), το οποίο είναι ένα μοντέλο παράστασης λογισμικού 128

129 Οι λειτουργικές απαιτήσεις από μια εφαρμογή λογισμικού αποτελούν περιπτώσεις χρήσης Είναι κατανοητό, ότι σε μια πραγματική εφαρμογή λογισμικού το πλήθος των περιπτώσεων χρήσης μπορεί να είναι πολύ μεγάλο για να μπορεί να απεικονιστεί με τη βοήθεια ενός και μόνο διαγράμματος το οποίο να είναι πρακτικό και αναγνώσιμο Στη γενική περίπτωση ένα μοντέλο περιπτώσεων χρήσης αποτελείται από πολλά διαγράμματα τα οποία μπορούν να εκτείνονται σε βάθος και να ομαδοποιούνται σε πακέτα (packages) συναφών για τον κατασκευαστή ή για το πρόβλημα, περιπτώσεων χρήσης 2 Πώς προδιαγράφεται μια περίπτωση χρήσης Μέχρι το σημείο αυτό είδαμε ότι μια περίπτωση χρήσης χαρακτηρίζεται από έναν σύντομο τίτλο Έχοντας κατά νου ότι οι περιπτώσεις χρήσης αντιστοιχούν στις λειτουργικές απαιτήσεις αναμένουμε ότι η πλήρης προδιαγραφή των περιπτώσεων χρήσης είναι αντίστοιχη με αυτή των λειτουργικών απαιτήσεων Παρακάτω φαίνεται η δομή της προδιαγραφής μιας περίπτωσης χρήσης Με πλάγιους χαρακτήρες δίνεται μια σύντομη περιγραφή των περιεχομένων κάθε ενότητας της προδιαγραφής 129

130 ΠΡΟΔΙΑΓΡΑΦΗ ΠΕΡΙΠΤΩΣΗΣ ΧΡΗΣΗΣ 1 Τίτλος περίπτωσης χρήσης Αναγράφεται ο τίτλος της περίπτωσης χρήσης 2 Σύντομη περιγραφή Δίνεται μια πολύ σύντομη περιγραφή της περίπτωσης χρήσης σε 2 3 προτάσεις 3 Ροή γεγονότων 31 Βασική ροή Κάθε περίπτωση χρήσης ξεκινά με μια ενέργεια ενός Χειριστή Στην παράγραφο αυτή περιγράφεται τι κάνει ο χειριστής και ποια είναι η ακολουθία των ενεργειών του λογισμικού με τις οποίες επιτυγχάνεται ο σκοπός της περίπτωσης χρήσης, χωρίς να περιγράφεται το γιατί ή το πώς πραγματοποιούνται οι ενέργειες αυτές Μπορούν να χρησιμοποιηθούν σχήματα ή εικόνες που συμβάλουν στην κατανόηση της ροής 32 Εναλλακτικές ροές 321 Εναλλακτική ροή Εναλλακτική ροή 2 Εδώ περιγράφονται τυχόν εναλλακτικές ροές ενεργειών που μπορεί να συμβούν κατά την υλοποίηση της περίπτωσης χρήσης, όπως η απαιτούμενη συμπεριφορά του λογισμικού σε περίπτωση κάποιου σφάλματος 4 Μη λειτουργικές απαιτήσεις 41 Απαίτηση 1 42 Απαίτηση 2 Εδώ περιγράφονται οι μη λειτουργικές απαιτήσεις που σχετίζονται με την περίπτωση χρήσης, όπως απαιτήσεις επίδοσης ή περιβάλλοντος 5 Κατάσταση Εισόδου 51 Συνθήκη Εισόδου 1 52 Συνθήκη Εισόδου 2 Στην ενότητα αυτή αναφέρονται οι συνθήκες που θα πρέπει να ισχύουν (προαπαιτήσεις, preconditions) για την εφαρμογή της περίπτωσης χρήσης, όπως τα αναγκαία δικαιώματα χρήστη ή οι συσκευές που πρέπει να είναι διαθέσιμες 6 Κατάσταση εξόδου 61 Συνθήκη Εξόδου 1 62 Συνθήκη Εξόδου 2 Στην ενότητα αυτή αναφέρονται οι συνθήκες που ισχύουν (αποτελέσματα, post conditions) μετά την εφαρμογή της περίπτωσης χρήσης, όπως μεταβολές στην κατάσταση πόρων του συστήματος, συσκευών, κά 130

131 Η προδιαγραφή μιας περίπτωσης χρήσης πρέπει να καθορίζει την κύρια ακολουθία (και ενδεχομένως και τις εναλλακτικές, εφόσον υπάρχουν) των λειτουργιών του συστήματος οι οποίες αποτελούν την περίπτωση χρήσης, χωρίς να περιλαμβάνει καθόλου κατασκευαστικές λεπτομέρειες για τον τρόπο πραγματοποίησης των λειτουργιών αυτών Το μοντέλο περιπτώσεων χρήσης μαζί με το σύνολο των προδιαγραφών αυτών, πρέπει να είναι κατανοητά τόσο από τον κατασκευαστή, όσο και από τον πελάτη Μερικές χρήσιμες παρατηρήσεις σχετικά με τον ορισμό και την προδιαγραφή των περιπτώσεων χρήσης είναι οι ακόλουθες - Μια περίπτωση χρήσης οριοθετείται από την ικανοποίηση μιας απαίτησης ενός Χειριστή Δεν αφορά «μερική ικανοποίηση» της απαίτησης, ούτε ικανοποίηση ενός «συνόλου απαιτήσεων» του Χειριστή και δεν ορίζεται έχοντας κατά νου τα συστατικά στοιχεία λογισμικού που θα την υλοποιήσουν - Αν για το σαφή προσδιορισμό της περίπτωσης χρήσης απαιτούνται διαγράμματα και εικόνες, όπως λχ για την περιγραφή της διαπροσωπείας με το χρήστη ή των εναλλακτικών ροών, αυτά θα πρέπει να χρησιμοποιούνται αφειδώς και να ακολουθούν συμβολισμούς που ορίζει η UML Ένα τέτοιο διάγραμμα είναι το διάγραμμα δραστηριοτήτων που θα εισάγουμε στη συνέχεια - Τονίζεται ότι κατά την προδιαγραφή των περιπτώσεων χρήσης, γίνεται λόγος μόνο για τις ενέργειες που θα πραγματοποιούνται από το λογισμικό Όχι για το πώς, ούτε για το γιατί αυτές θα πραγματοποιούνται - Υπάρχουν αρκετές περιπτώσεις, όπου η περιγραφή των περιπτώσεων χρήσης με τη βοήθεια της δομής που δόθηκε είναι πλεονασμός Αν μια περίπτωση χρήσης είναι πολύ απλή, τότε μπορεί να περιγράφεται από τις δύο πρώτες ενότητες που αναφέρονται παραπάνω Συμβολισμοί UML Ένα χρήσιμο εργαλείο για την περιγραφή της ροής των εργασιών σε μια περίπτωση χρήσης, είναι το διάγραμμα δραστηριότητας (activity diagram) της UML Το διάγραμμα αυτό μπορεί να χρησιμοποιηθεί συμπληρωματικά με την περιγραφή κειμένου για να προδιαγράψει μια περίπτωση χρήσης Στη συνέχεια θα το χρησιμοποιούμε και για την περιγραφή της ροής εργασιών ανάπτυξης λογισμικού Οι συμβολισμοί του διαγράμματος δραστηριότητας δίνονται στην Εικόνα 18 και εισάγονται ασφαλώς με χρήση UML 131

132 Εικόνα 18 Συμβολισμοί UML για το διάγραμμα δραστηριοτήτων (activity diagram) 132