Σχολή Θετικών Επιστημών & Τεχνολογίας
Μεταπτυχιακή Εξειδίκευση στα Πληροφοριακά Συστήματα
Διπλωματική Εργασία
Ιεράρχηση Απαιτήσεων Λογισμικού με Τεχνικές των Ασαφών Συνόλων
(Υποστηριζόμενες από Μεθόδους των Συστημάτων Συστάσεων)
(Software Requirements Prioritization with Fuzzy Sets Methods ( Supported by Recommender Systems Methods ))
Απόστολος Μαρτίνης
Επιβλέπων καθηγητής: Γερογιάννης Βασίλειος
Πάτρα, Ιούνιος 2020
Η παρούσα εργασία αποτελεί πνευματική ιδιοκτησία του φοιτητή («συγγραφέας/δημιουργός») που την εκπόνησε. Στο πλαίσιο της πολιτικής ανοικτής πρόσβασης ο συγγραφέας/δημιουργός εκχωρεί στο ΕΑΠ, μη αποκλειστική άδεια χρήσης του δικαιώματος αναπαραγωγής, προσαρμογής, δημόσιου δανεισμού, παρουσίασης στο κοινό και ψηφιακής διάχυσής τους διεθνώς, σε ηλεκτρονική μορφή και σε οποιοδήποτε μέσο, για διδακτικούς και ερευνητικούς σκοπούς, άνευ ανταλλάγματος και για όλο το χρόνο διάρκειας των δικαιωμάτων πνευματικής ιδιοκτησίας. Η ανοικτή πρόσβαση στο πλήρες κείμενο για μελέτη και ανάγνωση δεν σημαίνει καθ’ οιονδήποτε τρόπο παραχώρηση δικαιωμάτων διανοητικής ιδιοκτησίας του συγγραφέα/δημιουργού ούτε επιτρέπει την αναπαραγωγή, αναδημοσίευση, αντιγραφή, αποθήκευση, πώληση, εμπορική χρήση, μετάδοση, διανομή, έκδοση, εκτέλεση, «μεταφόρτωση» (downloading),
«ανάρτηση» (uploading), μετάφραση, τροποποίηση με οποιονδήποτε τρόπο, τμηματικά ή περιληπτικά της εργασίας, χωρίς τη ρητή προηγούμενη έγγραφη συναίνεση του συγγραφέα/δημιουργού. Ο συγγραφέας/δημιουργός διατηρεί το σύνολο των ηθικών και περιουσιακών του δικαιωμάτων.
Ιεράρχηση Απαιτήσεων Λογισμικού με Τεχνικές των Ασαφών Συνόλων
(Υποστηριζόμενες από Μεθόδους των Συστημάτων Συστάσεων)
Απόστολος Μαρτίνης
Επιτροπή Επίβλεψης Διπλωματικής Εργασίας Επιβλέπων Καθηγητής:
Γερογιάννης Βασίλειος
Καθηγητής Πανεπιστημίου Θεσσαλίας
Συν-Επιβλέπων Καθηγητής:
Καρυώτης Βασίλειος
Αν. Καθηγητής Ιονίου Πανεπιστημίου
Η όμορφη διαδρομή της προσπάθειας για μάθηση στο ΕΑΠ, έφτασε στο τέλος της. Το ταξίδι συνεχίζεται.
Θα ήθελα να ευχαριστήσω τους καθηγητές μου για τη συμβολή τους στην προσπάθεια αυτή.
Θα ήθελα επίσης να ευχαριστήσω τον καθηγητή μου κο Γερογιάννη Βασίλη για την υποδειγματική, υπομονετική και καθοριστική καθοδήγηση του στη διαδικασία εκπόνησης της Διπλωματικής Εργασίας.
Αφιερώνω την παρούσα εργασία στη σύζυγο μου Μαρία και την κόρη μου Κωνσταντίνα, στην οποία εύχομαι το δικό της ταξίδι για μάθηση να είναι συναρπαστικό και ευτυχισμένο.
Περίληψη
Η μεταπτυχιακή εργασία έχει ως αντικείμενο τη διερεύνηση της εφαρμογής των Διαισθητικά Ασαφών Συνόλων (Intuitionistic Fuzzy Sets IFSs), προκειμένου να αντιμετωπιστεί ο δισταγμός που χαρακτηρίζει τους συμμετέχοντες κατά την αξιολόγηση της επίδοσης ενός συνόλου υποψηφίων απαιτήσεων λογισμικού σε μια διαδικασία ιεράρχησης υποψηφίων απαιτήσεων.
Μια διαδικασία ιεράρχησης απαιτήσεων έχει ως στόχο να αξιολογηθούν οι υποψήφιες προς υλοποίηση απαιτήσεις ενός συστήματος λογισμικού ως προς διάφορα κριτήρια (αξία, κόστος ανάπτυξης, ρίσκο, βαθμός μεταβλητότητας κλπ.) που αφορούν τη σημαντικότητα της κάθε απαίτησης. Η ιεράρχηση των απαιτήσεων σε ένα έργο ανάπτυξης λογισμικού πραγματοποιείται συνήθως επαναληπτικά από τους συμμετέχοντες (συμμετέχοντες που μπορεί να είναι εκπρόσωποι των τελικών χρηστών, αναλυτές απαιτήσεων, προγραμματιστές κλπ.), προκειμένου να καθοριστούν οι προτεραιότητες των υποψήφιων προς υλοποίηση απαιτήσεων. Οι προτεραιότητες αυτές υποδεικνύουν ποιες απαιτήσεις θα επιλεγούν να υλοποιηθούν στην επόμενη έκδοση του λογισμικού.
Στη σχετική βιβλιογραφία έχει προταθεί ένα πλήθος τεχνικών για την ιεράρχηση των απαιτήσεων ενός λογισμικού. Οι περισσότερες όμως από τις προτεινόμενες τεχνικές δεν λαμβάνουν επαρκώς υπόψη το δισταγμό των συμμετεχόντων κατά την αξιολόγηση της επίδοσης των απαιτήσεων ως προς τα διάφορα κριτήρια αξιολόγησης. Ο δισταγμός θα μπορούσε να ληφθεί υπόψη εάν υιοθετηθούν τεχνικές από το πεδίο των ασαφών συνόλων.
Στην παρούσα εργασία θα διερευνηθεί η αξιοποίηση συγκεκριμένων επεκτάσεων των ασαφών συνόλων σε προβλήματα ιεράρχησης απαιτήσεων λογισμικού. Συγκεκριμένα, θα διερευνηθεί η εφαρμογή των Διαισθητικά Ασαφών Συνόλων (IFSs). Τα IFSs ενσωματώνουν τιμές συμμετοχής και μη συμμετοχής σε ένα σύνολο (όπως τα κλασσικά Fuzzy Sets) καθώς και τιμές διστακτικότητας προκειμένου να αναπαραστήσουν την αβεβαιότητα και το δισταγμό των συμμετεχόντων σε ένα πρόβλημα αξιολόγησης.
Για την υποστήριξη των διαδικασιών ιεράρχησης των απαιτήσεων στην προτεινόμενη προσέγγιση θα γίνει χρήση των Συστημάτων Συστάσεων (Recommender Systems). Τα Συστήματα Συστάσεων αποτελούν εφαρμογή λογισμικού που καθοδηγούν το χρήστη με εξατομικευμένο τρόπο από ένα μεγάλο χώρο πιθανών επιλογών σε χρήσιμες υποδείξεις.
Συντελεστής Συσχέτισης Kendall και οι Συναρτήσεις Συνάθροισης (Aggregation Functions).
Λέξεις – Κλειδιά
Ιεράρχηση Απαιτήσεων, Εκμαίευση Απαιτήσεων, Συμμετέχοντες, Ασαφής Λογική, Διαισθητικά Ασαφή Σύνολα, Συστήματα Συστάσεων, Συντελεστής Συσχέτισης Kendall.
Software Requirements Prioritization with Fuzzy Sets Methods ( Supported by Recommender Systems Methods )
Apostolos Martinis
Abstract
The postgraduate thesis aims to explore the application of Intuitionistic Fuzzy Sets (IFSs), in order to address the hesitation of stakeholders to evaluate the priority of a set of candidate software requirements in a requirements prioritization process.
A requirements prioritization process aims to evaluate the candidate for implementation requirements of a software system with respect to various criteria that concern the importance of each requirement. The prioritization of requirements of a software development project is usually an iterative process carried out by the stakeholders (participants who may be end-user representatives, requirements analysts, developers, etc), in order to determine the requirements priorities. These priorities indicate which requirements will be selected for implementation in the next software release.
A number of techniques concerning software requirements prioritization have been proposed in the literature. However, most of the proposed techniques do not sufficiently take into consideration the hesitation of stakeholders in evaluating the performance of the requirements with respect to the various evaluation criteria. The hesitation could be taken into consideration if methods from the fuzzy sets field were adopted.
This paper will explore the use of specific extensions of fuzzy sets into software requirements hierarchy problems. In particular, the application of Intuitionistic Fuzzy Sets (IFSs) will be explored. IFSs incorporate participation and non-participation values in a set (as classical Fuzzy Sets do) as well as hesitation values to represent stakeholders' uncertainty in an evaluation problem.
On the proposed approach, Recommendation Systems will be used to support the effort for requirements prioritization. Recommendation Systems are software applications that guide the user in a personalized way to useful suggestions from a wide range of possible
options. In addition, specialized mathematical tools such as the Generalized Kendall’s Correlation Coefficient and Aggregation Functions will be exploited.
Keywords
Requirements Prioritization, Requirements Elicitation, Stakeholders, Fuzzy Logic, Intuitionistic Fuzzy Sets (IFSs), Recommender Systems, Kendall’s Coefficient of Concordance.
Περιεχόμενα
Περίληψη... v
Abstract ... vii
Κατάλογος Εικόνων / Σχημάτων ... xi
Κατάλογος Γραφημάτων / Πινάκων ... xii
1. Εισαγωγή ... 1
2. Υπόβαθρο - Επισκόπηση Βιβλιογραφίας ... 5
2.1 Ιεράρχηση Απαιτήσεων Λογισμικού ... 5
2.1.1 Μηχανική των Απαιτήσεων ... 5
2.1.2 Ιεράρχηση των Απαιτήσεων ... 7
2.1.3 Συμμετέχοντες Στην Ιεράρχηση των Απαιτήσεων ... 12
2.1.4 Κριτήρια για την Ιεράρχηση των Απαιτήσεων ... 14
2.1.5 Τεχνικές Ιεράρχησης των Απαιτήσεων ... 17
2.1.6 Συγκριτική Αξιολόγηση των Τεχνικών Ιεράρχησης Απαιτήσεων ... 24
2.2 Τεχνικές της Ασαφούς Λογικής για την Ιεράρχηση των Απαιτήσεων ... 30
2.2.1 Εισαγωγή στην Ασαφή Λογική και στα Ασαφή Σύνολα ... 30
2.2.2 Επεκτάσεις των Ασαφών Συνόλων ... 34
2.2.3 Ιεράρχηση Απαιτήσεων με Τεχνικές των Ασαφών Συνόλων ... 37
2.3 Συστήματα Συστάσεων (Recommender Systems) ... 39
2.3.1 Εισαγωγή στα Συστήματα Συστάσεων ... 39
2.3.2 Συστήματα Συστάσεων στο πεδίο της Μηχανικής των Απαιτήσεων και της Ιεράρχησης των Απαιτήσεων ... 43
2.4 Μαθηματικά Εργαλεία στη Λήψη Αποφάσεων ... 46
2.4.1 Συντελεστές Συσχέτισης Kendall και Spearman ... 47
2.4.2 Συναρτήσεις Συνάθροισης και Βελτιστοποίηση υπό Περιορισμούς ... 50
3. Προτεινόμενη Μέθοδος Ιεράρχησης των Απαιτήσεων ... 51
3.1 Παρουσίαση Μεθόδου Ιεράρχησης των Απαιτήσεων ... 52
3.2 Στοιχεία Συμμετεχόντων - Απαιτήσεων ... 56
3.3 Απεικόνιση Στοιχείων με τη χρήση IFSs ... 58
3.4 Συναρτήσεις Συνάθροισης και Ιεράρχηση των Απαιτήσεων ... 61
3.5 Γενικευμένος Συντελεστής Συσχέτισης Kendall και Βελτιστοποίηση υπό Περιορισμούς ... 63
4. Περίπτωση Μελέτης Εφαρμογής της Μεθόδου ... 67
4.1 Συγκέντρωση Στοιχείων ... 67
4.1.1 Περιγραφή του Έργου ... 67
4.1.2 Αναγνώριση Συμμετεχόντων ... 68
4.1.3 Εκμαίευση Απαιτήσεων ... 70
4.1.4 Επιλογή Δεδομένων ... 72
4.2 Εφαρμογή της Μεθόδου ... 74
4.2.1 Στοιχεία Συμμετεχόντων – Απαιτήσεων ... 74
4.2.2 Απεικόνιση Στοιχείων με τη χρήση IFSs ... 79
4.2.3 Συναρτήσεις Συνάθροισης και Ιεράρχηση των Απαιτήσεων ... 82
4.2.4 Γενικευμένος Συντελεστής Συσχέτισης Kendall ... 83
5. Συμπεράσματα ... 89
Βιβλιογραφία ... 94
Παράρτημα Α: Στοιχεία ... 107
Παράρτημα Β: Αποτελέσματα ... 125
Παράρτημα Α : Στοιχεία………..………107
Α1. Κατάλογος των συμμετεχόντων και των ρόλων τους στη βάση δεδομένων PointP - Req του project RALIC 108 Α2. Κατάλογος των απαιτήσεων στη βάση δεδομένων PointP- Req του project RALIC 111 Α3. Απόσπασμα Αντικειμενικού Καταλόγου Συμμετεχόντων 112 Α4. Απόσπασμα Αντικειμενικού Καταλόγου Στόχων και Απαιτήσεων 112 A5. Κατάλογος των 18 σημαντικότερων συμμετεχόντων (ως προς το ρόλο και το πλήθος των εκτιμήσεων τους), εκτιμήσεις των απαιτήσεων και μετατροπή σε ιεραρχημένη μορφή 113 Α6. Συγκεντρωτικός Πίνακας των 51 σημαντικότερων συμμετεχόντων (ως προς το ρόλο και το πλήθος των εκτιμήσεων τους), η τάξη σημαντικότητας του ρόλου τους, το πλήθος των απαιτήσεων που εκτίμησαν και το εύρος των εκτιμήσεων 121 Α7. Διάταξη των εκτιμήσεων των 18 συμμετεχόντων επί των 12 απαιτήσεων που τελικά χρησιμοποιήθηκαν για την εφαρμογή της μεθόδου ιεράρχησης των απαιτήσεων 19 Παράρτημα Β: Αποτελέσματα………..……..…125 Β1. Απεικονίσεις των συναρτήσεων συμμετοχής 𝜇𝑠𝑖(𝑟𝑖) και μη συμμετοχής
𝑢𝑠𝑖(𝑟𝑖), όπως και του βαθμού διστακτικότητας 𝜋𝑠𝑖(𝑟𝑖) στην κατάταξη των 12 απαιτήσεων από τους 18 συμμετέχοντες
126 Β2. Συγκεντρωτική κατάσταση υπολογισμού των συναρτήσεων
συμμετοχής, μη συμμετοχής και συναρτήσεων συνάθροισης 130 Β3. Συγκεντρωτική κατάσταση υπολογισμού των συναρτήσεων συμμετοχής,
μη συμμετοχής και συναρτήσεων συνάθροισης για βελτιστοποίηση υπό περιορισμούς 0.9 × 𝑀𝑂𝑖.
132 Β4. Συγκεντρωτική κατάσταση υπολογισμού των συναρτήσεων συμμετοχής,
μη συμμετοχής και συναρτήσεων συνάθροισης για βελτιστοποίηση υπό περιορισμούς 0.8 × 𝑀𝑂𝑖.
134
Κατάλογος Εικόνων / Σχημάτων
Εικόνα 2-1 Κριτήρια Ιεράρχησης Απαιτήσεων Λογισμικού και συχνότητα
χρήσης τους 17
Εικόνα 2-2 Τεχνικές Ιεράρχησης και συχνότητα εμφάνισης στη σχετική βιβλιογραφία
19
Εικόνα 2-3 Ταξινόμηση τεχνικών ιεράρχησης 24
Εικόνα 2-4 Τυπικές μορφές συναρτήσεων συμμετοχής Ασαφών Συνόλων 32 Εικόνα 2-5 Διακριτό (𝛢1) και συνεχές (𝛢2) ασαφές σύνολο 33
Εικόνα 2-6 Σχηματική Αναπαράσταση IFSs 36
Εικόνα 2-7 Συμβουλευτική Σύσταση προς Ομάδα 42
Σχήμα 2-1 Δραστηριότητες Μηχανικής των Απαιτήσεων 6
Σχήμα 3-1 Διάγραμμα Ροής Προτεινόμενης Μεθόδου 54
Κατάλογος Γραφημάτων / Πινάκων
Γράφημα 2-1 Ευκολία Χρήσης Μεθόδων 27
Γράφημα 2-2 Επεκτασιμότητα Μεθόδων 27
Γράφημα 2-3 Χρόνος Υλοποίησης Μεθόδων 27
Γράφημα 2-4 Ακρίβεια Μεθόδων 27
Γράφημα 4-1 Απεικόνιση Κατανομής Τιμών Τάξεων 3 Απαιτήσεων 79 Γράφημα 4-2 Απεικόνιση Τιμών Συναρτήσεων 𝜇𝑆1(𝑟i) , u𝑆1(𝑟i) και 𝜋𝑆1(𝑟i)
για τον 𝑆1
81 Πίνακας 2-1 Κατάλογος πιθανών Συμμετεχόντων στην Ιεράρχηση
Απαιτήσεων
14 Πίνακας 2-2 Συγκεντρωτικός Πίνακας Μεθόδων Ιεράρχησης και
Χαρακτηριστικών τους
28 Πίνακας 3-1 Υπολογισμός συναρτήσεων συμμετοχής 𝜇𝑗(𝑟𝑖) και
μη συμμετοχής 𝑢𝑗(𝑟𝑖)
60 Πίνακας 4-1 Απόσπασμα Καταλόγου Συμμετεχόντων και των ρόλων τους 70
Πίνακας 4-2 Απόσπασμα Καταλόγου Απαιτήσεων 72
Πίνακας 4-3 Μετατροπή Εκτιμήσεων σε Ιεράρχηση 74
Πίνακας 4-4 Κατάλογος Συμμετεχόντων στην Περίπτωση Μελέτης 76 Πίνακας 4-5 Κατάλογος Απαιτήσεων στην Περίπτωση Μελέτης 77 Πίνακας 4-6 Στοιχεία 18 Συμμετεχόντων και 12 Απαιτήσεων 78 Πίνακας 4-7 Τιμές Συναρτήσεων 𝜇𝑆1(𝑟i) , u𝑆1(𝑟i) για τον Συμμετέχοντα 𝑆1 81 Πίνακας 4-8
Πίνακας 4-9
Τελική Ιεράρχηση των Απαιτήσεων
Συγκεντρωτική Κατάσταση Ιεραρχήσεων και ΓΣΣ Kendall
83 86 Πίνακας 4-10 Στοιχεία με Εφαρμογή Περιορισμών 0.9 × 𝑀𝑂𝑖 87 Πίνακας 4-11 Στοιχεία με Εφαρμογή Περιορισμών 0.8 × 𝑀𝑂𝑖 88
Συντομογραφίες & Ακρωνύμια
RE Requirements Engineering
RP Requirements Prioritization
RS Recommender Systems
FL Fuzzy Logic
IFSs Intuistionistic Fuzzy Sets
KCC Kendall’s Coefficient of Concordance CO
LSDM DMs
Constrained Optimization Large Scale Decision Making Decision Makers
ΙΑ Ιεράρχηση Απαιτήσεων
ΣΣ Συστήματα Συστάσεων
ΑΣ Ασαφή Σύνολα
ΓΣΣΚ Γενικευμένος Συντελεστής Συσχέτισης Kendall ΒΠ Βελτιστοποίηση υπό Περιορισμούς
ΔΕ Διπλωματική Εργασία
1. Εισαγωγή
Περιγραφή Πλαισίου.
Τα Έργα Ανάπτυξης Λογισμικού (Software Development Projects), παρόλο που διαφέρουν από άλλα τεχνικά έργα λόγω της άυλης υπόστασης και της πολύπλοκης φύσης του τελικού προϊόντος, περιλαμβάνουν δραστηριότητες που συναντώνται στη διαχείριση όλων των τεχνικών έργων. Απαιτούν το σχεδιασμό των απαραίτητων ενεργειών, τη διασφάλιση των απαιτούμενων πόρων και το χρονικό προγραμματισμό της απόδοσης του τελικού προϊόντος. Ο όρος «Κρίση Λογισμικού» (Software Crisis) που διατυπώθηκε στα τέλη της δεκαετίας του ’70 [1] χρησιμοποιήθηκε για να χαρακτηρίσει το μεγάλο ποσοστό αποτυχίας στα έργα ανάπτυξης λογισμικού λόγω υπέρβασης χρονοδιαγράμματος, προϋπολογισμού και αδυναμίας ικανοποίησης των προσδοκιών / απαιτήσεων των χρηστών.
Αν και οι περισσότεροι πόροι αναλώνονται στη φάση του ελέγχου και της συντήρησης του λογισμικού, τα περισσότερα λάθη (85%) γίνονται στη φάση της ανάλυσης των απαιτήσεων και της σχεδίασης, ενώ το κόστος διόρθωσης τους αυξάνεται όσο πιο αργά εντοπίζονται. Οι συχνότεροι λόγοι αποτυχίας των έργων λογισμικού οφείλονται σε αιτίες που σχετίζονται με τις απαιτήσεις των συστημάτων:
το (13.1 %) αφορά ελλιπείς απαιτήσεις, το (9.9 %) εξωπραγματικές απαιτήσεις, το (8.7 %) αλλαγές στις απαιτήσεις και το (12.4 %) ελλιπή συμμετοχή στην εκμαίευση των απαιτήσεων [2].
Η αναγνώριση των απαιτήσεων ενός υπό ανάπτυξη συστήματος λογισμικού, των λειτουργιών δηλαδή που το τελικό προϊόν θα περιλαμβάνει, είναι στάδιο πρωταρχικής σημασίας για την επιτυχία του έργου. Οι απαιτήσεις του συστήματος εκμαιεύονται από τους συμμετέχοντες του έργου, τα πρόσωπα ή τις ομάδες που επηρεάζουν και επηρεάζονται από το έργο, όπως πελάτες, χρήστες, προγραμματιστές κλπ. Η λίστα των υποψηφίων απαιτήσεων που τελικά συγκεντρώνεται, περιλαμβάνει απαιτήσεις απαραίτητες για τη λειτουργία του συστήματος, απαιτήσεις σημαντικές αλλά όχι απαραίτητες και απαιτήσεις που θα ήταν επιθυμητό να υπάρχουν [5].
Στα πλαίσια των περιορισμών του συστήματος (περιορισμοί χρονικών προθεσμιών και προϋπολογισμού) που τίθενται από τους διαθέσιμους πόρους, τις περισσότερες φορές δεν είναι δυνατή η υλοποίηση του συνόλου των απαιτήσεων χωρίς την υπέρβαση αυτών. Οι υποψήφιες απαιτήσεις θα πρέπει να αξιολογηθούν από τους συμμετέχοντες, συνήθως σε σχέση με κριτήρια όπως η σημαντικότητα, το κόστος υλοποίησης, ο χρόνος που απαιτείται για την υλοποίηση, η ποινή που θα επιφέρει η απουσία τους κλπ [5].
Η αξιολόγηση των υποψηφίων απαιτήσεων από τους συμμετέχοντες οδηγεί σε μια ιεραρχημένη λίστα όπου οι απαιτήσεις κατατάσσονται σύμφωνα με την τάξη προτεραιότητας που προέκυψε κατά τη διαδικασία. Η ιεράρχηση των απαιτήσεων πρέπει να επιτύχει μια συμβιβαστική λύση μεταξύ των διαφορετικών απόψεων των συμμετεχόντων. Οι συμμετέχοντες, εκτός από διαφορετικούς ρόλους στην ανάπτυξη του έργου, έχουν και διαφορετικές προτεραιότητες, πολλές φορές αλληλοσυγκρουόμενες. Επιπλέον, δεν έχουν όλοι οι συμμετέχοντες τις ίδιες γνώσεις και την ίδια σαφήνεια στις απόψεις τους. Είναι δυνατόν στις αξιολογήσεις των συμμετεχόντων να περιλαμβάνεται ασάφεια, δισταγμός, ακόμα και αδυναμία κατάθεσης γνώμης [3,5].
Για την ιεράρχηση των υποψηφίων απαιτήσεων ενός έργου ανάπτυξης λογισμικού υπάρχουν πολλές διαφορετικές μέθοδοι με διαφορετικά χαρακτηριστικά και δυνατότητες. Όμως, για τη διαχείριση εκτιμήσεων που εμπεριέχουν ασάφεια ή/και δισταγμό, είναι απαραίτητη η εφαρμογή μεθόδων που μπορούν να διαχειριστούν τέτοιες καταστάσεις. Για να ληφθεί υπόψη ο δισταγμός και η έλλειψη γνώσης των συμμετεχόντων και για να γίνει διαχείριση των αξιολογήσεων τους μαθηματικά, πρέπει να γίνει χρήση ιδιαίτερων τεχνικών. Η Ασαφής Λογική και οι επεκτάσεις της έχουν τη δυνατότητα να απεικονίσουν καταστάσεις στην ανθρώπινη κρίση όπως ασάφεια και έλλειψη γνώσης και είναι κατάλληλες για την αντιμετώπιση εκτιμήσεων που εμπεριέχουν αβεβαιότητα.
Συμβολή της Διπλωματικής Εργασίας.
Στόχος της ΔΕ είναι η ιεράρχηση των υποψηφίων απαιτήσεων ενός πραγματικού
Συνόλων (IFSs). Οι εκτιμήσεις των συμμετεχόντων επί της σημαντικότητας των απαιτήσεων περιλαμβάνουν δισταγμό και έλλειψη γνώσης. Στην αξιολόγηση ενός συμμετέχοντα είναι δυνατόν να υπάρχουν απαιτήσεις που καταλαμβάνουν την ίδια τάξη (ties), ή δεν κατατάσσονται σε κάποια τάξη (unranked). Η μαθηματική απεικόνιση της αβεβαιότητας και της έλλειψης γνώσης των συμμετεχόντων θα γίνει με τη χρήση των IFSs ώστε να μην υπάρξει απώλεια πληροφοριών. Τα IFSs μπορούν να εκφράσουν το βαθμό συμμετοχής και μη συμμετοχής σε ένα σύνολο, ενώ παρέχουν και τη δυνατότητα να εκφραστεί μαθηματικά και ο βαθμός διστακτικότητας [65].
Για την υποστήριξη της διαδικασίας ιεράρχησης των απαιτήσεων θα γίνει χρήση των Συστημάτων Συστάσεων (Recommender Systems), που παρέχουν λειτουργίες απεικόνισης και συμβουλευτικής σύστασης των προτιμήσεων μιας ομάδας σε σχέση με ένα σύνολο αντικειμένων. Η συμβουλευτική σύσταση εμπεριέχει την ιδέα της συγκέντρωσης και επεξεργασίας πληροφοριών σχετικά με τις προτιμήσεις της ομάδας και την εξαγωγή μιας συνολικής πρότασης που προκύπτει από τη μέτρηση της συμφωνίας / συσχέτισης των επιμέρους προτιμήσεων [82]. Η μέτρηση του βαθμού συμφωνίας των επιμέρους προτιμήσεων σε απόψεις που εμπεριέχουν ασάφεια και δισταγμό μπορεί να γίνει με τη χρήση του Γενικευμένου Συντελεστή Συσχέτισης Kendall (Generalized Kendall’s Correlation Coefficient) [87].
Η τελική σύσταση για τις προτεραιότητες των απαιτήσεων της μεθόδου της ΔΕ στηρίζεται στην εξαγωγή μιας υψηλού βαθμού συμφωνίας κατάταξη προτίμησης των υποψηφίων απαιτήσεων του έργου, από τις επιμέρους εκτιμήσεις μιας ομάδας συμμετεχόντων σύμφωνα με το κριτήριο της σημαντικότητας, ενώ οι εκτιμήσεις τους είναι δυνατόν να εμπεριέχουν ασάφεια και έλλειψη γνώσης.
Δομή της Διατριβής
Στο Δεύτερο Κεφάλαιο παρουσιάζονται έννοιες απαραίτητες για την κατανόηση του προβλήματος, που βασίζονται στη μελέτη της σχετικής βιβλιογραφίας.
Καταγράφονται οι στόχοι της Μηχανικής των Απαιτήσεων, αναλύονται τα είδη των απαιτήσεων και ο σκοπός της ιεράρχησης αυτών, αναγνωρίζονται οι συμμετέχοντες στη διαδικασία, επισημαίνονται τα κριτήρια βάση των οποίων γίνεται η ιεράρχηση
των απαιτήσεων και παρουσιάζονται οι κυριότερες τεχνικές ιεράρχησης και τα χαρακτηριστικά τους. Ακόμα, ορίζονται συνοπτικά οι έννοιες των Ασαφών Συνόλων και των επεκτάσεων τους και γίνεται αναφορά στις υπάρχουσες τεχνικές ιεράρχησης με τη χρήση των Διαισθητικά Ασαφών Συνόλων (IFSs). Περιγράφονται η έννοια και οι χρήσεις των Συστημάτων Συστάσεων (Recommender Systems) και η συμβολή τους στη Μηχανική των Απαιτήσεων. Αναγνωρίζονται μαθηματικά εργαλεία στη Λήψη Αποφάσεων, όπως οι Συντελεστές Συσχέτισης Kendall και Spearman, οι Συναρτήσεις Συνάθροισης και η Βελτιστοποίηση υπό Περιορισμούς
Στο Τρίτο Κεφάλαιο παρουσιάζεται η προτεινόμενη μέθοδος ιεράρχησης των απαιτήσεων μέσω της ανάλυσης των σταδίων της Αναγνώρισης Συμμετεχόντων και Απαιτήσεων, της Αναπαράστασης των Δεδομένων του ζητήματος με τη χρήση IFSs, του υπολογισμού των Συναρτήσεων Συνάθροισης και του Γενικευμένου Συντελεστή Συσχέτισης Kendall, της Ιεράρχησης των Απαιτήσεων και της Βελτιστοποίησης της πρότασης.
Στο Τέταρτο Κεφάλαιο η προτεινόμενη μέθοδος δοκιμάζεται σε ένα πραγματικό έργο ανάπτυξης λογισμικού. Γίνεται περιγραφή του έργου, αναγνωρίζονται οι συμμετέχοντες και οι απαιτήσεις και αναλύονται οι λόγοι επιλογής των δεδομένων που χρησιμοποιήθηκαν στη μέθοδο ιεράρχησης. Στα επιλεγμένα δεδομένα παρουσιάζεται αναλυτικά η εφαρμογή των σταδίων της προτεινόμενης μεθόδου και καταγράφεται το τελικό αποτέλεσμα αυτής, μια πλήρως ιεραρχημένη λίστα των υποψηφίων απαιτήσεων.
Στο Κεφάλαιο των Συμπερασμάτων αποτυπώνεται συνοπτικά η πορεία της Διπλωματικής Εργασίας, διερευνώνται πιθανές πηγές σφάλματος στη διαδικασία, αξιολογείται η αξιοπιστία της προτεινόμενης μεθόδου και προτείνεται πιθανή επέκταση της μεθόδου σε διαδικασίες Λήψης Αποφάσεων Μεγάλης Κλίμακας (Large Scale Decision Making)..
Στη συνέχεια του κειμένου χρησιμοποιούμε τις έννοιες «Ιεράρχηση» και
«Προτεραιοποίηση», όπως και τις έννοιες «Αξιολόγηση» και «Εκτίμηση», με ισοδύναμο τρόπο, προκειμένου να εκφράσουμε την κατάταξη των θέσεων και την
2. Υπόβαθρο - Επισκόπηση Βιβλιογραφίας 2.1 Ιεράρχηση Απαιτήσεων Λογισμικού
Σε ένα πραγματικό έργο ανάπτυξης λογισμικού, οι απαιτήσεις που θέτουν οι συμμετέχοντες και μπορούν να υλοποιηθούν, περιορίζονται από χρονικές προθεσμίες και διαθέσιμο προϋπολογισμό. Έτσι, οι διαχειριστές έργων έρχονται αντιμέτωποι με το πρόβλημα της επιλογής ενός υποσυνόλου από τις απαιτήσεις των συμμετεχόντων και της ταυτόχρονης δημιουργίας ενός συστήματος που να καλύπτει τις ανάγκες τους.
Η ακριβής καταγραφή των προτεραιοτήτων των απαιτήσεων που μπορεί να προέλθει μέσω της χρήσης μιας (ή περισσοτέρων) κατάλληλης μεθόδου ιεράρχησης, αποτελεί τη βάση για την ανάπτυξη και την επιτυχία των έργων.
2.1.1 Μηχανική των Απαιτήσεων
Η Μηχανική των Απαιτήσεων (Requirements Engineering) ασχολείται με την αναγνώριση των στόχων και των λειτουργιών για ένα προτεινόμενο σύστημα, τη μετατροπή αυτών σε υπηρεσίες και περιορισμούς και την υλοποίηση τους μέσω της διαμοίρασης εργασιών σε πρόσωπα, μηχανήματα και λογισμικό [3,4].
Είναι μια συστηματική και πειθαρχημένη προσέγγιση στην προδιαγραφή και τη διαχείριση των απαιτήσεων που προϋποθέτει [5]: κατανόηση των επιθυμιών και των αναγκών των συμμετεχόντων, επίτευξη συναίνεσης μεταξύ τους, προσδιορισμό και τεκμηρίωση των απαιτήσεων σύμφωνα με συγκεκριμένα πρότυπα και συστηματική διαχείριση τους για ελαχιστοποίηση κινδύνου παράδοσης ενός συστήματος το οποίο δεν ικανοποιεί τους σκοπούς δημιουργίας του.
Περιλαμβάνει πέντε κύριες δραστηριότητες (Σχήμα 2-1) : την Εκμαίευση (Elicitation), την Ανάλυση και Διαπραγμάτευση (Analysis and Negotiation), την Τεκμηρίωση (Documentation), την Επικύρωση (Validation) και τη Διαχείριση (Management) [6,7].
Σχήμα 2-1, Δραστηριότητες Μηχανικής των Απαιτήσεων [6]
Η εκμαίευση καταγράφει τη λίστα των χαρακτηριστικών και των λειτουργιών που το σύστημα πρέπει να εφαρμόσει και θέτει τα όρια του συστήματος [8]. Η παραγωγή υψηλής ποιότητας απαιτήσεων μέσω της αποδοτικής εκμαίευσης είναι θεμελιώδες στάδιο για τη δημιουργία επιτυχών προϊόντων λογισμικού [9,10]. Οι τεχνικές που κυρίως χρησιμοποιούνται για την εκμαίευση των απαιτήσεων περιλαμβάνουν τις ομάδες ενδιαφέροντος, τις συνεντεύξεις, τα ερωτηματολόγια, τα σενάρια και τις περιπτώσεις χρήσης, την κατάθεση ιδεών, τις προτάσεις χρηστών κλπ [11,12,13].
Σημαντικό πρόβλημα στη μηχανική των απαιτήσεων είναι η διαχείριση διαφόρων τύπων ασυνέπειας που προέρχονται από την εκμαίευση των απαιτήσεων [3]. Οι ασυνέπειες γίνονται προφανείς όταν υπάρχουν πολλοί συμμετέχοντες, με διαφορετικές προτεραιότητες, επιδιώξεις και προτάσεις. Η επιτυχία της μηχανικής των απαιτήσεων εξαρτάται από την ακριβή ανάλυση και αντιμετώπιση αυτών των όψεων ασυνέπειας. Οι απαιτήσεις θα πρέπει να αναλυθούν και να διαπραγματευθούν πριν την τεκμηρίωση και την επικύρωση τους. Από ένα σύνολο απαιτήσεων που έχουν συλλεχθεί από διάφορους συμμετέχοντες μπορεί να υπάρχουν διάφορα
αλληλοσυγκρουόμενες απαιτήσεις κλπ. Στη φάση της ανάλυσης και της διαπραγμάτευσης πρέπει να μελετηθούν και να απορριφθούν απαιτήσεις.
Οι απαιτήσεις που επιλέγονται για υλοποίηση καταγράφονται σε λεπτομερή έγγραφα.
Το στάδιο της τεκμηρίωσης αυτών αποτυπώνει όλες τις λεπτομέρειες για την ορθή εφαρμογή της λειτουργικότητας τους και είναι απαραίτητο για την καθοδήγηση της επικύρωσης τους.
Η τελική διαχείριση των απαιτήσεων περιλαμβάνει την υλοποίηση και τον έλεγχο.
Σύμφωνα με μελέτες, περίπου το 60% όλων των σφαλμάτων στην ανάπτυξη συστημάτων λογισμικού λαμβάνουν χώρα κατά τη διάρκεια των δραστηριοτήτων της Μηχανικής των Απαιτήσεων [5]. Αυτά τα σφάλματα ωστόσο, συχνά αποκαλύπτονται μόνο σε μεταγενέστερες φάσεις του έργου ή όταν το σύστημα έχει αναπτυχθεί. Όσο πιο αργά στο αναπτυξιακό έργο διορθώνεται ένα ελάττωμα , τόσο υψηλότερο είναι το κόστος που συνδέεται με την επιδιόρθωση του.
2.1.2 Ιεράρχηση των Απαιτήσεων
Τα έργα λογισμικού έχουν συνήθως περισσότερες υποψήφιες απαιτήσεις από όσες μπορούν να υλοποιηθούν μέσα στα όρια χρόνου και κόστους τους. Η ιεράρχηση των απαιτήσεων βοηθά στην αναγνώριση των λίγων πιο σημαντικών από τις πολλές λιγότερο ουσιώδεις [14,15,16]. Συμβάλλει στη λήψη συμβιβαστικών αποφάσεων σε αλληλοσυγκρουόμενους στόχους , όπως η ποιότητα, το κόστος και ο χρόνος προς την αγορά, και διαμοιράζει πόρους βασιζόμενη στη σημαντικότητα των απαιτήσεων στο έργο ως σύνολο [17,18].
Ο όρος "ιεράρχηση" σημαίνει [19]:
1. Την απόδοση χρονικής προτεραιότητας,
2. Την απόδοση αξίας σε σχέση με ανταγωνιστικές εναλλακτικές λύσεις, 3. Την απόδοση προτίμησης.
Με βάση τα προηγούμενα, η ιεράρχηση πραγματικών απαιτήσεων θα μπορούσε να σημαίνει:
• Ιεράρχηση κατά σειρά υλοποίησης, είναι η δραστηριότητα προσδιορισμού της σειράς υλοποίησης των απαιτήσεων σε έναν αυξητικό και επαναληπτικό κύκλο ανάπτυξης.
• Προτεραιότητα κατά σπουδαιότητα, καθορίζει τη σειρά σπουδαιότητας των απαιτήσεων που προκύπτει από τις εκτιμήσεις των συμμετεχόντων ή θέσεις συμμετεχόντων (π.χ., προσωπική προτίμηση, επιχειρηματική αξία, κόστος υλοποίησης και κίνδυνος).
Η διαδικασία ιεράρχησης απαιτήσεων λογισμικού πρέπει αφενός να είναι απλή και σύντομη και αφετέρου να αποφέρει ακριβή αποτελέσματα. Για να επιτύχει ένα λογισμικό, η ποιότητα πρέπει να μεγιστοποιηθεί, ενώ το κόστος και ο χρόνος παράδοσης να ελαχιστοποιηθούν [8,20,21].
Η ιεράρχηση των απαιτήσεων προϋποθέτει [22,23,24,25]
1. τον ορισμό των συμμετεχόντων που θα ασχοληθούν με τη διαδικασία (πχ χρήστες, πελάτες, διαχειριστές, προγραμματιστές, αναλυτές κλπ).
2. τον καθορισμό των κριτηρίων βάσει των οποίων θα ιεραρχηθούν οι απαιτήσεις (πχ σημαντικότητα, κόστος, χρόνος, όφελος, κίνδυνος κλπ).
3. τον καθορισμό των απαιτήσεων (λειτουργικών και μη) που θα ιεραρχηθούν.
4. την επιλογή της μεθόδου (ή μεθόδων) βάσει της οποίας θα γίνει ιεράρχηση των απαιτήσεων.
Υπάρχουν πολλές προκλήσεις στην εφαρμογή τεχνικών ιεράρχησης απαιτήσεων [6,7,26,27], όπως :
• Η επιλογή των πιο σημαντικών απαιτήσεων για τους χρήστες, από όλο το εύρος των διαθέσιμων απαιτήσεων,
• Η παράδοση των πιο σημαντικών λειτουργιών με τη μεγαλύτερη ικανοποίηση για τους χρήστες, εντός χρόνου,
• Η παράδοση των επιλεχθέντων απαιτήσεων εντός προϋπολογισμού,
• Αλλαγές αναγκών και επιχειρηματικού περιβάλλοντος που είναι δυνατόν να αλλάξουν τις προτεραιότητες,
• Οι συμμετέχοντες μπορεί να παρεξηγήσουν τη διαδικασία ιεράρχησης,
• Η συνεργασία μεταξύ των συμμετεχόντων στην ιεράρχηση των απαιτήσεων είναι υποχρεωτική αλλά μπορεί να είναι προβληματική,
• Η αλλαγή των απαιτήσεων σε προχωρημένα στάδια μπορεί να αλλάξει την ιεράρχηση.
Σύμφωνα με στοιχεία της βιβλιογραφίας [28,29] τα προβλήματα με τις υπάρχουσες μεθόδους ιεράρχησης απαιτήσεων μπορούν να συνοψιστούν : 1. Οι υπάρχουσες τεχνικές δεν αποφέρουν ικανοποιητικές λύσεις όταν οι απαιτήσεις αυξάνονται (επεκτασιμότητα). 2. Είναι χρονοβόρες. 3. Τα αποτελέσματα τους εμπεριέχουν λάθη και είναι επιρρεπείς σε σφάλματα. 4. Τα αποτελέσματα δεν επαληθεύονται. 5. Οι περισσότερες επιλύουν θέματα λίγων απαιτήσεων ή εικονικής χρήσης.
Η Ιεράρχηση ξεκινά με μια λίστα απαιτήσεων. Οι απαιτήσεις είναι μια περιγραφή για το πώς ένα προϊόν λογισμικού πρέπει να λειτουργεί. Η απαίτηση συνήθως αναφέρεται σε μια λειτουργία ενός προϊόντος ή υπηρεσίας.
Ο οργανισμός ΙΕΕΕ ( Institute of Electrical and Electronics Engineers ) ορίζει την απαίτηση [3,5] ως :
1. Μια συνθήκη ή ικανότητα απαιτούμενη από χρήστη για την επίλυση προβλήματος ή την επίτευξη σκοπού.
2. Μια συνθήκη ή ικανότητα που ένα σύστημα ή συστατικό συστήματος πρέπει να διαθέτει για να ικανοποιήσει ένα συμβόλαιο, ένα πρότυπο, μια προδιαγραφή ή κάποιο άλλο επίσημο έγγραφο.
3. Μια έγγραφη αποτύπωση μιας συνθήκης ή ικανότητας όπως στα 1 και 2.
Ταξινόμηση Απαιτήσεων [3,5]: οι απαιτήσεις μπορούν να διακριθούν σε
• Λειτουργικές Απαιτήσεις, τα χαρακτηριστικά που θα περιέχει ή θα εκτελεί το σύστημα.
• Μη Λειτουργικές Απαιτήσεις, επιβαλλόμενοι περιορισμοί όπως ακρίβεια, ασφάλεια, απόδοση, μεταβλητότητα.
• Απαιτήσεις Επιπέδου Στόχων, συνδέονται με τους επιχειρηματικούς στόχους.
• Απαιτήσεις Επιπέδου Πεδίου, συνδέονται με τα προβλήματα πεδίου.
• Απαιτήσεις Επιπέδου Προϊόντος, συνδέονται με το προϊόν.
• Απαιτήσεις Επιπέδου Σχεδίασης, τι τελικά θα υλοποιηθεί.
• Πρωτογενείς Απαιτήσεις, εκμαιεύονται από τους Συμμετέχοντες.
• Προκύπτουσες Απαιτήσεις, προκύπτουν από τις πρωτογενείς απαιτήσεις.
Άλλες Ταξινομήσεις :
o Επιχειρησιακές Απαιτήσεις / Τεχνικές Απαιτήσεις.
o Απαιτήσεις Προϊόντος / Απαιτήσεις Διαδικασίας.
o Απαιτήσεις Ρόλων (Πελάτες, Χρήστες, Συστήματος, Ασφάλειας κλπ).
Πηγές Απαιτήσεων [3,5]
Υπάρχουν τρεις κύριες πηγές απαιτήσεων :
o Οι συμμετέχοντες, είναι άτομα ή ομάδες που (άμεσα ή έμμεσα) επηρεάζουν τις απαιτήσεις ενός συστήματος. Παραδείγματα συμμετεχόντων είναι οι χρήστες του συστήματος, οι φορείς εκμετάλλευσης , οι προγραμματιστές, πελάτες και δοκιμαστές.
o Τα έγγραφα, περιέχουν συχνά σημαντικές πληροφορίες που μπορούν να υποδείξουν απαιτήσεις. Παραδείγματα εγγράφων όπως προτύπων και νομικών εγγράφων, καθώς και συγκεκριμένων τομέων ή οργανισμών.
o Τα συστήματα που ήδη λειτουργούν, μπορεί να είναι προγενέστερα συστήματα καθώς και ανταγωνιστικά συστήματα.
Η χρήση μόνο λειτουργικών απαιτήσεων κατά τη διαδικασία ιεράρχησης μπορεί να οδηγήσει το τελικό προϊόν σε αποτυχία ή σε φτωχή ποιότητα του συστήματος. Η επιτυχία των χαρακτηριστικών ποιότητας των απαιτήσεων, όπως ασφάλεια, διαθεσιμότητα, λειτουργία, μεταβλητότητα κλπ, μαζί με τις λειτουργικές απαιτήσεις, είναι κρίσιμα για την επιτυχία ενός έργου λογισμικού [30,31].
Τα επιτυχημένα συστήματα λογισμικού πάντα εξελίσσονται. Καθώς το περιβάλλον στο οποίο λειτουργούν αλλάζει, και οι απαιτήσεις των συμμετεχόντων αλλάζουν [32,33]. Έτσι, η διαχείριση αλλαγών είναι βασική δραστηριότητα στην ιεράρχηση απαιτήσεων. Οι αλλαγές περιλαμβάνουν την πρόσθεση ή αφαίρεση απαιτήσεων.
Απαιτήσεις προστίθενται σε ανταπόκριση των αναγκών των συμμετεχόντων ή γιατί είχαν παραληφθεί στην αρχική ανάλυση. Απαιτήσεις διαγράφονται κυρίως κατά την
Οι κύριες αιτίες για αλλαγή απαιτήσεων κατά τη διάρκεια ανάπτυξης ενός συστήματος λογισμικού [34], είναι :
1. Αβεβαιότητα, που μπορεί να προκληθεί από αόριστη στρατηγική και άποψη περί του προϊόντος, απουσία βασικών συμμετεχόντων, άγνωστες εξαρτήσεις.
2. Εσφαλμένη ερμηνεία λειτουργικών προδιαγραφών και εγχειριδίων χρήστη.
3. Μεταβολές στις ανάγκες χρηστών ή στις απαιτήσεις της αγοράς, ή αλλαγές στην πολιτική της οργάνωσης.
4. Αλλαγή περιβάλλοντος ή αλλαγές στην υποστήριξη προϊόντος.
5. Αλλαγές στην κατανόηση των χρηστών ή γνώσεων για το σύστημα.
Η διαδικασία ιεράρχησης των απαιτήσεων παρέχει στήριξη για τις ακόλουθες δραστηριότητες [3,19,35] :
- για τους συμμετέχοντες να αποφασίσουν σχετικά με τις βασικές απαιτήσεις για το σύστημα,
- για το σχεδιασμό και την επιλογή ενός βέλτιστου συνόλου απαιτήσεων λογισμικού προς υλοποίηση σε διαδοχικές εκδόσεις,
- για συμβιβασμό του πεδίου εφαρμογής του έργου με ενίοτε αντιφατικούς περιορισμούς όπως το χρονοδιάγραμμα, τον προϋπολογισμό, τους πόρους, το χρόνο προς την αγορά και την ποιότητα,
- για εξισορρόπηση του επιχειρηματικού οφέλους κάθε απαίτησης έναντι του κόστους της,
- για εξισορρόπηση των συνεπειών των απαιτήσεων στην αρχιτεκτονική του λογισμικού και στη μελλοντική εξέλιξη του προϊόντος και του σχετικού κόστους,
- για την επιλογή ενός υποσυνόλου εκ των απαιτήσεων και την απόδοση ενός συστήματος που θα ικανοποιεί τους πελάτες,
- για την εκτίμηση της αναμενόμενης ικανοποίησης των πελατών,
- για την απόκτηση τεχνικού πλεονεκτήματος και βελτιστοποίησης θέσης στην αγορά,
- για την ελαχιστοποίηση της πιθανότητας ανατροπής και ολίσθησης του χρονοδιαγράμματος,
- για τη διαχείριση αντιφατικών απαιτήσεων, την εστίαση στη διαδικασία των διαπραγματεύσεων και την επίλυση διαφωνιών μεταξύ των συμμετεχόντων,
- για τον καθορισμό της σχετικής σημασίας κάθε απαίτησης ώστε να παρέχει τη μεγαλύτερη αξία στο χαμηλότερο κόστος,
- για να υποχρεωθούν οι συμμετέχοντες να ασχοληθούν με όλες τις απαιτήσεις και όχι μόνο τις δικές τους,
- για να εκτιμηθούν τα οφέλη των διαφόρων απαιτήσεων όταν πραγματοποιούνται αναλύσεις κόστους / οφέλους για τον προσδιορισμό των καλύτερων τρόπων δαπάνης των περιορισμένων πόρων του έργου.
2.1.3 Συμμετέχοντες Στην Ιεράρχηση των Απαιτήσεων
Η πρώτη φάση στην ιεράρχηση των απαιτήσεων ενός έργου λογισμικού, ίσως και η σημαντικότερη, είναι ο προσδιορισμός των απαιτήσεων [25,36]. Πιθανά λάθη ή αστοχίες σε αυτή τη φάση είναι δυνατό να οδηγήσουν το έργο σε αποτυχία. Οι απαιτήσεις προσδιορίζονται εκεί που οι συμμετέχοντες (Stakeholders) συγκεντρώνονται και ανταλλάσσουν ιδέες, επικοινωνούν, μοιράζονται γνώσεις και πληροφορίες [37]. Τα προβλήματα ξεκινούν όταν οι ιδέες των συμμετεχόντων είναι αρκετές και διαφέρουν κατά πολύ, οπότε η ιεράρχηση των απαιτήσεων στα πλαίσια των περιορισμών κόστους και χρόνου του έργου γίνεται αναγκαία.
Σε γενικές γραμμές οι συμμετέχοντες είναι (αν και όχι απαραίτητα) ειδικοί στον τομέα της ανάπτυξης λογισμικού [38]. Ένας συμμετέχων σε ένα σύστημα είναι ένα πρόσωπο ή μια ομάδα που έχει (άμεση ή έμμεση) επιρροή στις απαιτήσεις του συστήματος [5]. Είναι πρόσωπα που ενδιαφέρονται για την επιτυχία του συστήματος ή επηρεάζονται κατά κάποιο τρόπο από την ανάπτυξη και την εφαρμογή του συστήματος και ως εκ τούτου πρέπει να συμβουλεύονται κατά τη διάρκεια της εκμαίευσης των απαιτήσεων.
Συνήθως οι συμμετέχοντες περιλαμβάνουν ομάδες και πρόσωπα εσωτερικά και εξωτερικά της οργάνωσης [3]. Ο πελάτης και ειδικότερα ο χορηγός του έργου (project sponsor) είναι συνήθως ο πιο εμφανής συμμετέχοντας του συστήματος. Σε μερικές περιπτώσεις όμως, οι πραγματικοί χρήστες του συστήματος μπορεί να είναι οι πιο σημαντικοί. Άλλα μέρη των οποίων η σφαίρα ενδιαφέροντος μπορεί να
τα πρότυπα της διαδικασίας και οι εταίροι, πρέπει επίσης να θεωρηθούν ως συμμετέχοντες, εάν επηρεάζονται. Ένα από τα πρώτα βήματα στην εκμαίευση απαιτήσεων συνεπώς, είναι η αναγνώριση και η καταγραφή όλων των συμμετεχόντων.
Η διευκρίνιση και η ενημέρωση του τι είδους πληροφορίες αναμένονται από τους συμμετέχοντες σε σχέση με τον προσδιορισμό των απαιτήσεων, ελαττώνει τα προβλήματα εισαγωγής μη σχετικών απαιτήσεων. Οι συμμετέχοντες τείνουν να θεωρούν ως προτεραιότητα ότι έχει σχέση με τις προσδοκίες τους από το σύστημα [17,39]. Μόλις ένας προγραμματιστής επισημάνει το κόστος, τον τεχνικό κίνδυνο ή άλλους συμβιβασμούς που σχετίζονται με μια συγκεκριμένη απαίτηση, οι συμμετέχοντες μπορεί να αποφασίσουν ότι δεν είναι και τόσο απαραίτητη όσο νόμιζαν. Οι προγραμματιστές ενδέχεται επίσης να καθορίσουν ότι ορισμένες λειτουργίες χαμηλότερης προτεραιότητας πρέπει να υλοποιηθούν πρώτες λόγω της επίδρασής τους στην αρχιτεκτονική του προϊόντος.
Πρωταρχικό βήμα στον προσδιορισμό των απαιτήσεων ενός έργου είναι η ακριβής αναγνώριση των συμμετεχόντων. Συμμετέχοντες μπορούν να προστεθούν αργότερα, αλλά συνήθως με πολύ μεγαλύτερο κόστος και με σημαντική αναδιάρθρωση στην ιεράρχηση των απαιτήσεων. Οι συνήθεις συμμετέχοντες σε ένα έργο ανάπτυξης λογισμικού είναι χρήστες, πελάτες, διευθυντές, τεχνικοί [11,22].
Ενδεικτικός κατάλογος για τις κατηγορίες ομάδων που είναι δυνατόν να συμμετέχουν στη διαδικασία ιεράρχησης των απαιτήσεων, παρουσιάζεται στον Πίνακα 2-1.
Ομάδες Συμμετεχόντων στην Ιεράρχηση Απαιτήσεων
- Μηχανικοί Λογισμικού, Εμπειρογνώμονες, Διαχειριστές Έργων, Πελάτες - Αναλυτές, Πελάτες
- Πελάτες, Εμπειρογνώμονες - Διαχειριστές Έργων
- Χρήστες
- Διευθυντές, Προγραμματιστές, Πελάτες
- Μηχανικοί Λογισμικού, Μηχανικοί Απαιτήσεων, Πελάτες, Χρήστες - Ομάδες Πελατών, Διαχειριστές Έργων
- Αναπτυξιακές Ομάδες
- Τμήματα Αγοράς, Προγραμματιστές
- Τεχνικοί και Εμπορικοί Εμπειρογνώμονες - Μηχανικοί Λογισμικού, Αναλυτές
- Εμπειρογνώμονες, Μηχανικοί Απαιτήσεων, Πελάτες - Εμπειρογνώμονες, Προγραμματιστές, Πελάτες - Πελάτες, Ομάδες Σχεδιασμού
- Εμπειρογνώμονες Απαιτήσεων, Ομάδες Πελατών - Χρήστες, Πελάτες, Αναλυτές, Εμπειρογνώμονες - Διαχειριστές Έργων, Μηχανικοί Απαιτήσεων, Πελάτες - Αναλυτές Αγοράς, Εμπειρογνώμονες
- Μηχανικοί Λογισμικού
- Εταιρικοί Διευθυντές, Εταιρικοί Αντιπρόεδροι, Διαχειριστές Έργων - Βασικοί Εκπρόσωποι Πελατών, Εκπρόσωποι Αναλυτών
- Αναλυτές
- Ομάδες Ανάπτυξης, Εμπειρογνώμονες, Πελάτες
- Μηχανικοί Απαιτήσεων, Διαχειριστές Έργων, Χρήστες
Πίνακας 2-1, Κατάλογος κατηγοριών Συμμετεχόντων στην Ιεράρχηση Απαιτήσεων ενός συστήματος Λογισμικού [40]
2.1.4 Κριτήρια για την Ιεράρχηση των Απαιτήσεων
Κατά την ιεράρχηση των απαιτήσεων λαμβάνονται υπόψη διάφορα κριτήρια (Criteria) που σχετίζονται με επιχειρηματικές και τεχνικές πτυχές του υπό ανάπτυξη έργου. Αυτά τα κριτήρια είναι κυρίως οι απόψεις των συμμετεχόντων για τη σημαντικότητα των απαιτήσεων, ο κίνδυνος παράλειψης, το κόστος, η πολυπλοκότητα, χρονικοί περιορισμοί, εξαρτήσεις, επεκτασιμότητα, ευαισθησία έναντι σφαλμάτων, κυρώσεις, μεταβλητότητα, πόροι, ταχύτητα, αξία, προσπάθεια, μέγεθος απαιτήσεων, λεπτομέρεια, στρατηγική σημασία, ευκολία στη χρήση, αντίκτυπος στις πωλήσεις, κλπ [18,41,42,43]. Η ιεράρχηση των απαιτήσεων από τους συμμετέχοντες γίνεται με βάση ένα ή περισσότερα από τα παραπάνω κριτήρια. Τα πιο ευρέως χρησιμοποιούμενα κριτήρια είναι [3,19,40,44] :
Σημαντικότητα (Importance).
Στο κριτήριο της σημαντικότητας οι συμμετέχοντες πρέπει να δώσουν προτεραιότητα στις πιο ουσιαστικές για το σύστημα απαιτήσεις. Ωστόσο, η σημαντικότητα μπορεί να είναι εξαιρετικά πολύπλευρη έννοια δεδομένου ότι εξαρτάται σε μεγάλο βαθμό από
την αρχιτεκτονική του προϊόντος, στρατηγικής σημασίας για την εταιρεία, ιδιαίτερης προσωπικής αξίας για έναν συμμετέχοντα κ.λπ. Κατά συνέπεια, είναι ουσιαστικό να διευκρινιστεί τι είδους σημαντικότητα θα ιεραρχήσουν οι συμμετέχοντες σε κάθε περίπτωση.
Κόστος (Cost).
Η υλοποίηση διαφορετικών απαιτήσεων έχει διαφορετική επίπτωση στο κόστος ανάπτυξης. Με δεδομένους τους περιορισμένους προϋπολογισμούς, το κόστος μπορεί να είναι ο πιο σημαντικός παράγοντας κατά την ιεράρχηση των απαιτήσεων. Το κόστος υλοποίησης εκτιμάται συνήθως από τον υπό ανάπτυξη οργανισμό. Μέτρα που επηρεάζουν το κόστος περιλαμβάνουν: την πολυπλοκότητα της απαίτησης, τη δυνατότητα επαναχρησιμοποίησης υπάρχοντος κώδικα, την ποσότητα ελέγχου και τεκμηρίωσης που απαιτείται, κλπ.
Αξία (Value).
Η αξία κάθε απαίτησης εκφράζει την επιτυχία του έργου και την ικανοποίηση του τελικού χρήστη του συστήματος. Ορισμένες απαιτήσεις είναι κρίσιμες, ενώ άλλες είναι λιγότερο σημαντικές, αν και υποχρεωτικές. Ορισμένες πιθανές απαιτήσεις δεν είναι καν απαιτήσεις παρά επιθυμίες ή χαρακτηριστικά που θα ήταν καλό να υπάρχουν. Επίσης, ορισμένες απαιτήσεις έχουν μια τακτική χρησιμότητα, ενώ άλλες έχουν μια πιο μακροπρόθεσμη στρατηγική αξία για την επιχείρηση.
Εξάρτηση (Dependency).
Ορισμένες απαιτήσεις εξαρτώνται από άλλες. Για παράδειγμα, απαιτήσεις σε χαμηλότερους δεσμούς στη συνολική δομή του συστήματος υλοποιούν απαιτήσεις σε υψηλότερους δεσμούς. Σχέσεις εξαρτήσεων μεταξύ περιπτώσεων χρήσης και σεναρίων, συνεπάγονται εξαρτήσεις μεταξύ των απαιτήσεων τους. Παράγωγες απαιτήσεις έχουν σχεδιαστεί για να υποστηρίζουν πιο θεμελιώδεις απαιτήσεις, οι οποίες εξαρτώνται από την εφαρμογή των πρώτων. Ορισμένες δευτερογενείς απαιτήσεις υποστηρίζουν βασικές απαιτήσεις που είναι απαραίτητες για την επιτυχία του συστήματος. Σε όλες αυτές τις περιπτώσεις, η εφαρμογή ορισμένων απαιτήσεων εξαρτάται από την εφαρμογή άλλων και αυτό συνεπάγεται εξάρτηση μεταξύ τους.
Κίνδυνος (Ris