TRACER Κωδικός Έργου: 09ΣΥΝ Ανάλυση Απαιτήσεων Πλατφόρµας TRACER Παραδοτέο έργου

Transcript

1 Κωδικός Έργου: 09ΣΥΝ Ανάλυση Απαιτήσεων Πλατφόρµας Παραδοτέο έργου Ενότητα Εργασίας: Αριθµός Παραδοτέου: Συντονιστής: Συντελεστές: Ηµεροµηνία υποβολής: Ηµεροµηνία παράδοσης: Αναγνωριστικό εγγράφου: Ε1: State of the Art - Ανάλυση Απαιτήσεων 1.2 SING SING, ΙΤΕ-ΙΠ, ΑΠΘ-ΤΠ, ΟΠΑ-ΔΕΤ 31 Ιανουαρίου Μαρτίου 2012 _Π_1.2

2 Περιεχόµενα 1 Εισαγωγή Μεθοδολογία Εξαγωγής Απαιτήσεων Περιγραφή παρούσας και µελλοντικής κατάστασης Ανάλυση Περιπτώσεων Χρήσης Ανάλυση Απαιτήσεων Πλατφόρµας Περιγραφή διεπαφών συστήµατος Συµπεράσµατα A. Παράρτηµα Α RUP/QFD A.1 The rational unified process (RUP) - Επαναληπτική Ενοποιηµένη Διαδικασία A.1.1 Γιατί να υιοθετήσουµε µια επαναληπτική διαδικασία ανάπτυξης A.1.2 Οι βασικοί στόχοι κάθε επαναληπτικής διαδικασίας A.1.3 Διαχείριση κινδύνου A.1.4 Οι Φάσεις Ανάπτυξης A.2 The Quality Function Deployment (QFD) A.2.1 Ορισµός και ιστορική αναδροµή A.2.2 Περιγραφή του µοντέλου B. Παράρτηµα Β Ερωτήσεις για ηµι-δοµηµένη συνέντευξη C. Παράρτηµα Γ Γλώσσες Προγραµµατισµού D. Παράρτηµα Δ Γλωσσάρι E. Παράρτηµα Ε Βιβλιογραφία... 52

3 Λίστα Σχηµάτων Σχήµα 1: Βήµατα Μεθοδολογίας Εξαγωγής Απαιτήσεων... 7 Σχήµα 2: Διαδικασία Ανάπτυξης και Ελέγχου Λογισµικού σε επίπεδο Έργου Σχήµα 3: Διαδικασία Ανάπτυξης και Ελέγχου Λογισµικού σε επίπεδο Προϊόντος Σχήµα 4: Διαδικασία Ανάπτυξης και Ελέγχου Λογισµικού σε επίπεδο Έργου µε την πλατφόρµα Σχήµα 5: Διαδικασία Ανάπτυξης και Ελέγχου Λογισµικού σε επίπεδο Προϊόντος µε την πλατφόρµα Σχήµα 6: Διαδικασία ελέγχου του κώδικα ενός συστήµατος παλαιών γενεών µε την πλατφόρµα Σχήµα 7: Διάγραµµα Περιπτώσεων Χρήσης Σχήµα 8: Οι Φάσεις και η αντίστοιχη χρονική και ποσοτική αλληλεπίδραση Σχήµα 9: House of Quality Σχήµα 10: Ερωτήσεις που ερωτήθηκαν σε άτοµα εντός και εκτός της SingularLogic Σχήµα 11: Στοιχεία σχετικά µε τις γλώσσες προγραµµατισµού και τις γραµµές κώδικα σε αυτές Λίστα Πινάκων Πίνακας 1: Περιγραφή Δραστών στο Σύστηµα Πίνακας 2: Κωδικοποίηση Περιπτώσεων Χρήσης Πίνακας 3: Λίστα Περιπτώσεων Χρήσης Πίνακας 4: Γλωσσάρι... 50

4 1 Εισαγωγή Στο παραδοτέο αυτό περιγράφονται τα αποτελέσµατα της ανάλυσης απαιτήσεων που πραγµατοποιήθηκε για την πλατφόρµα. Για την δοµή του παραδοτέου και των επιµέρους ενοτήτων χρησιµοποιήσαµε τις προτεινόµενες πρακτικές που παρουσιάζονται στο «IEEE Recommended Practice for Software Requirements Specifications» Σκοπός του παραδοτέου Ο σκοπός αυτού του παραδοτέου είναι να οριστούν οι απαιτήσεις των χρηστών, λειτουργικές και µη, καθώς οι περιπτώσεις χρήσης της πλατφόρµας. Ακόµη, σκοπός του παραδοτέου είναι να εντοπισθούν οι αλλαγές που θα γίνουν στις διαδικασίες που ακολουθούνται σήµερα στην διαδικασία ανάπτυξης ενός συστήµατος λογισµικού µε την εισαγωγή της πλατφόρµας καθώς και να διευκρινιστεί το εύρος των λειτουργιών της πλατφόρµας. 1.2 Σύνοψη Η ασφάλεια ενός συστήµατος λογισµικού είναι κάτι που επηρεάζει τόσο τους χρήστες του, όσο και την οµάδα ανάπτυξής του. Οι συνέπειες µιας τρωτότητας σηµαίνουν κατ ελάχιστο χαµένο χρόνο και σηµαντικό κόστος για τους χρήστες του λογισµικού. Για την οµάδα ανάπτυξης, οι συνέπειες περιλαµβάνουν µεταξύ άλλων επιπλέον χρόνο και κόστος για την συντήρηση του λογισµικού µε σκοπό την θωράκιση από τις τρωτότητες που ανακαλύπτονται, καθώς επίσης και την αποκατάσταση πιθανών βλαβών ή και την αποζηµίωση σε ορισµένες περιπτώσεις των χρηστών του λογισµικού. Επιπλέον προβάλουν µια ασυνεπή εικόνα και δηµιουργούν αρνητική φήµη για την ποιότητα ενός συστήµατος λογισµικού, και κατ επέκταση του οργανισµού που το αναπτύσσει. Παρά το γεγονός ότι τα τελευταία χρόνια τα περιβάλλοντα ανάπτυξης λογισµικού έχουν καταφέρει να αποτρέψουν σε ένα βαθµό την εισαγωγή ευπαθειών κατά τη διάρκεια σχεδιασµού και ανάπτυξης ενός συστήµατος λογισµικού, καθηµερινά ανακαλύπτονται νέες τρωτότητες. Ένας συνηθισµένος λόγος είναι πως το κοµµάτι της ασφάλειας συχνά δεν αποτελεί αντικείµενο µελέτης από τη φάση σχεδιασµού ενός συστήµατος, αλλά προστίθεται εκ των υστέρων (retrofitted). Ειδικά σε συστήµατα παλαιότερων γενεών (legacy systems) αλλά και σε ήδη εγκατεστηµένα συστήµατα τα οποία τυπικά χρησιµοποιούνται ήδη για µεγάλο διάστηµα προτού ανακαλυφθούν οι αδυναµίες τους, η θωράκισή και η διαρκής ενηµέρωση τους είναι µια κοστοβόρα και επίπονη διαδικασία. Η διαδικασία ελέγχου του λογισµικού για αδυναµίες είναι ιδιαίτερα πολύπλοκη και πολλοί προγραµµατιστές δεν είναι εξοικειωµένοι µε βέλτιστες πρακτικές ανάπτυξης ασφαλούς λογισµικού, ενώ και η χρήση συστηµάτων που εντοπίζουν συνηθισµένες ευπάθειες είναι δύσκολη και απαιτεί χρόνο που πολλές φορές δε διαθέτει µια οµάδα ανάπτυξης λόγω πιεστικών χρονοδιαγραµµάτων. Για τους παραπάνω λόγους, η έστω και µερική αυτοµατοποίηση της διαδικασίας ελέγχου και θωράκισης του λογισµικού θα προσέφερε πολλαπλά οφέλη. Βασικοί στόχοι της πλατφόρµας είναι ο έλεγχος συστηµάτων παλαιών γενεών (legacy code) για πιθανές αδυναµίες και η εισήγηση πρακτικών λύσεων που θα θωρακίζουν το σύστηµα αυτό από τις πλέον διαδεδοµένες διαδικτυακές επιθέσεις. Ο έλεγχος θα γίνεται κατά βάση µε την χρήση µεθόδων στατικής ανάλυσης. Συγκεκριµένα, η πλατφόρµα, θα ελέγχει τον κώδικα µιας εφαρµογής (είτε πηγαίο, είτε µεταγλωττισµένο) για αδυναµίες που µπορεί να οδηγήσουν σε ρήγµατα ασφάλειας και θα ενηµερώνει τους προγραµµατιστές της για την ύπαρξή τους. Για να γίνει κάτι τέτοιο, η πλατφόρµα θα µπορεί να χρησιµοποιεί διάφορα υπάρχοντα εργαλεία ανάλογα µε την περίπτωση της εφαρµογής που ελέγχει 2. Επίσης, θα υλοποιηθεί µε τέτοιο τρόπο ώστε να µπορεί να εκτελεσθεί και για παλαιότερες εκδόσεις της εφαρµογής. Με αυτό τον τρόπο θα δίνει µια συνολική εικόνα για το έργο και τις αδυναµίες του παράγοντας πληροφορίες που θα µπορούσαν να φανούν χρήσιµες για τους διαχειριστές µελλοντικών έργων. Έχοντας σαν βάση τις πιο διαδεδοµένες επιθέσεις 1 IEEE Recommended Practice for Software Requirements Specifications, The Institute of Electrical and Electronics Engineers, 1998, USA 2

5 στο διαδίκτυο 3, αλλά και τα αποτελέσµατα της στατικής ανάλυσης, η πλατφόρµα θα προτείνει διάφορες υπάρχουσες λύσεις για την προστασία της εφαρµογής. Εδώ θα πρέπει να σηµειώσουµε πως ως legacy code εφαρµογή, δεν εννοούµε αναγκαία µια παλαιά εφαρµογή που έχει αναπτυχθεί σε µια παρωχηµένη γλώσσα προγραµµατισµού, αλλά σε µια εφαρµογή που τυπικά δεν έχει υποστεί τον έλεγχο που προσφέρει η πλατφόρµα µας. Ιδανικά, την πλατφόρµα θα µπορούν να χρησιµοποιήσουν προγραµµατιστές (programmers) και ελεγκτές (code reviewers) και κατά την διάρκεια της υλοποίησης ενός έργου. 1.3 Δοµή του παραδοτέου Στο παρόν παραδοτέο αναλύεται η µεθοδολογία που ακολουθήθηκε προκειµένου να συλλεχθούν οι απαιτήσεις των χρηστών και οι σύγχρονες µεθοδολογίες ανάπτυξης και ελέγχου λογισµικού. Στη συνέχεια, αναλύεται πως θα αλλάξουν οι διαδικασίες αυτές µε την χρήση της πλατφόρµας και περιγράφονται εκτενώς οι περιπτώσεις χρήσης του συστήµατος µε τους δράστες σε αυτές. Στην επόµενη ενότητα αναλύονται οι λειτουργικές και µη απαιτήσεις των χρηστών και στην τελευταία ενότητα αντιστοιχίζονται οι λειτουργίες του συστήµατος µε της απαιτήσεις αυτές. Το παραδοτέο δοµείται µε αυτό τον τρόπο καθώς κάθε επόµενη ενότητα χρειάζεται τα στοιχεία που αναλύονται στις προηγούµενες ενότητες. Συγκεκριµένα το παραδοτέο έχει την ακόλουθη δοµή: 1. Η Μεθοδολογία Εξαγωγής Απαιτήσεων, που αναλύει τον τρόπο µε τον οποίο οι πληροφορίες που µας παρείχαν οι χρήστες µετατράπηκαν σε συγκεκριµένες απαιτήσεις χρηστών (Ενότητα 2). 2. Η Παρούσα και Μελλοντική Κατάσταση, δηλαδή µε ποιον τρόπο µια εταιρία πληροφορικής αναπτύσσει και ελέγχει λογισµικό σήµερα καθώς και πως θα αλλάξουν οι διαδικασίες αυτές µε την χρήση της πλατφόρµας (Ενότητα 3). 3. Οι Περιπτώσεις Χρήσης και οι Δράστες σε αυτές (Ενότητα 4) 4. Οι Απαιτήσεις των Χρηστών που προέκυψαν από την προαναφερόµενη διαδικασία Εξαγωγής Απαιτήσεων (Ενότητα 5). 5. Η Περιγραφή των διεπαφών του συστήµατος (Ενότητα 6). 6. Τα Συµπεράσµατα του παραδοτέου (Ενότητα 7). 7. Το Παράρτηµα Α που περιλαµβάνει όλες τις απαραίτητες πληροφορίες για την µεθοδολογία Rational unified process (RUP) και την Quality Function Deployment (QFD) προσέγγιση που χρησιµοποιούνται στο παραδοτέο. 8. Το Παράρτηµα Β που περιλαµβάνει τις Ερωτήσεις που απαντήθηκαν προκειµένου να εξάγουµε τις απαιτήσεις των χρηστών. 9. Το Παράρτηµα Γ που αποτελείται από το Γλωσσάρι, δηλαδή τον ορισµό διάφορων εννοιών που χρησιµοποιούνται στο παραδοτέο. 10. Το Παράρτηµα Δ που περιλαµβάνει τη Βιβλιογραφία. 1.4 Σύνδεση µε άλλα παραδοτέα Στο παρόν παραδοτέο συµβουλευτήκαµε το παραδοτέο Π1.1, προκειµένου να εντοπισθούν χρήσιµες πληροφορίες για τον τρόπο µε τον οποίο αναπτύσσεται και ελέγχεται το λογισµικό σε οργανισµούς σήµερα καθώς και µε ποιον τρόπο γίνεται ο έλεγχος και η θωράκιση συστηµάτων παλαιών γενεών. Τα στοιχεία που προκύπτουν από τον παρόν παραδοτέο θα χρησιµοποιηθούν στα επόµενα στάδια της διαδικασίας και συγκεκριµένα στο παραδοτέο «Π2.1: Σχεδιασµός Πλατφόρµας». 2 Μεθοδολογία Εξαγωγής Απαιτήσεων Για την συλλογή και εξαγωγή των απαιτήσεων, εφαρµόστηκε η Rational Unified Process (RUP) ως µεθοδολογία ανάπτυξης λογισµικού σε συνδυασµό µε την Quality Function Deployment 3

6 (QFD) προσέγγιση για τον ορισµό και την ανάπτυξη των περιπτώσεων χρήσης και των απαιτήσεων του συστήµατος (Παράρτηµα Α). Η µεθοδολογία για τον ορισµό των απαιτήσεων ξεκινάει από την εύρεση των σεναρίων των χρηστών. Στη συνέχεια, για την οριστικοποίηση των απαιτήσεων από την πλατφόρµα ακολουθούνται τα βήµατα που παρουσιάζονται στο Σχήµα 1. Π1.1: State of the Art Analysis Κοινοπραξία Ορισµοί / Περιορισµοί Πληροφορίες -Συνεντεύξεις εντός της SingularLogic -Συνεντεύξεις συνεργατών της SingularLogic Περιγραφή Παρούσας & Μελλοντικής Κατάστασης -Παρούσα Κατάσταση -Μελλοντική Κατάσταση Περιπτώσεις Χρήσης -Αναγνώριση Εµπλεκοµένων -Περιπτώσεις Χρήσης Απαιτήσεις Συστήµατος -Λειτουργικές απαιτήσεις -Μη-λειτουργικές απαιτήσεις Σχήµα 1: Βήµατα Μεθοδολογίας Εξαγωγής Απαιτήσεων Σε πρώτη φάση, µελετήθηκε το παραδοτέο Π1.1: State of the Art Analysis και λήφθηκαν υπόψη οι ορισµοί και οι περιορισµοί που έθεσε η κοινοπραξία. Στη συνέχεια οι πιθανοί χρήστες, έδωσαν τις απαραίτητες πληροφορίες προκείµενου να οριστούν τα σενάρια των χρηστών, δηλαδή οι περιγραφές της παρούσας και µελλοντικής κατάστασης (µε την χρήση της πλατφόρµας ). Οι τεχνικοί εταίροι του έργου ερµήνευσαν αυτά τα σενάρια σε περιπτώσεις χρήσης και απαιτήσεις της πλατφόρµας. Τέλος, βασισµένοι στις περιπτώσεις χρήσης και στις απαιτήσεις, ορίστηκαν οι µη-λειτουργικές απαιτήσεις του συστήµατος. 2.1 Ορισµός Ενδιαφερόµενων / Επωφελούµενων και Εµπλεκοµένων (stakeholders) στην πλατφόρµα Η πλατφόρµα έχει ως στόχο την βελτιώση και την ενισχύση της ποιότητας και ασφάλειας των υπηρεσιών και προϊόντων που προσφέρονται από µια ευρεία γκάµα εταιριών. Οι εταιρίες που θα επωφεληθούν από την χρήση της πλατφόρµας θα είναι οι εταιρίες πληροφορικής που αναπτύσσουν εφαρµογές (διαδικτυακές και µη) και υπηρεσίες λογισµικού, καθώς χρειάζονται συνεχείς ελέγχους στον κώδικα που παράγεται και σε αυτό αναµένεται να παίξει σηµαντικό ρόλο η πλατφόρµα. Μέσα από την επιπλέον ασφάλεια που θα έχουν οι προσφερόµενες υπηρεσίες και τα προϊόντα θα επωφεληθούν και οι εταιρίες χρήστες, δηλαδή οι εταιρίες που χρησιµοποιούν αυτές τις υπηρεσίες και εφαρµογές, καθώς θα αποφεύγουν πιθανές κακόβουλες επιθέσεις. Για την πλατφόρµα θα ενδιαφερθούν και εταιρίες που ολοκληρώνουν συστήµατα συνδυάζοντας λογισµικό και υλικό από διαφορετικές πηγές προέλευσης, καθώς θα αποφεύγουν πιθανά ρήγµατα ασφαλείας κατά την ολοκλήρωση των επιµέρους µονάδων. Τέλος, θα επωφεληθούν όλοι οι οργανισµοί που χρησιµοποιούν συστήµατα παλαιών γενεών (legacy systems) καθώς µπορεί τα συστήµατα αυτά να παρουσιάζουν ρήγµατα ασφαλείας.

7 Οι Εµπλεκόµενοι (stakeholders) σε ένα έργο είναι οι οντότητες εντός ή εκτός ενός οργανισµού που χρηµατοδοτούν το έργο, που ενδιαφέρονται ή κερδίζουν από την επιτυχή ολοκλήρωση του έργου ή επηρεάζουν, θετικά ή αρνητικά, την ολοκλήρωση αυτού. Εµπλεκόµενοι στο έργο είναι τόσο οργανισµοί όπως η SingularLogic, το ΟΠΑ-ΔΕΤ, το ΑΠΘ-ΤΠ και το ΙΤΕ-ΙΠ. Η SingularLogic χρηµατοδοτεί προσωπικό που παίρνει µέρος στον σχεδιασµό της πλατφόρµας. Ακόµη, ενδιαφέρεται για την επιτυχή ολοκλήρωση της πλατφόρµας ώστε να την ενσωµατώσει στη διαδικασία ανάπτυξης και συντήρησης των συστηµάτων της και να προσφέρει ενισχυµένες υπηρεσίες στους πελάτες της. Το ΟΠΑ-ΔΕΤ, το ΑΠΘ-ΤΠ και το ΙΤΕ-ΙΠ θα σχεδιάσουν και θα υλοποιήσουν µέρος της πλατφόρµας, ενώ στη συνέχεια θα χρησιµοποιήσουν την πλατφόρµα για ερευνητικούς σκοπούς. 2.2 Συνεντεύξεις Εµπλεκοµένων Μέσω συνεντεύξεων των εµπλεκοµένων, µπορεί να γίνουν κατανοητές οι επιχειρηµατικές διαδικασίες και οι ανάγκες που προκύπτουν από αυτές µέσα από ένα ρεαλιστικό πρίσµα. Οι συνεντεύξεις έγιναν µε την µορφή ηµι-δοµηµένης συνέντευξης τόσο σε εργαζοµένους τις SingularLogic όσο και σε εταιρείες από το δίκτυο συνεργατών της. Αυτό έδωσε την δυνατότητα να ερευνηθούν διάφορα θέµατα που δεν είχαν προβλεφθεί στην αρχική λίστα των ερωτήσεων. Τα άτοµα που ερωτήθηκαν σχετίζονται µε την υλοποίηση και τον έλεγχο λογισµικού και κατέχουν διάφορους ρόλους. Ερωτήθηκαν Προγραµµατιστές, Υπεύθυνοι Ποιότητας Λογισµικού, Υπεύθυνοι Ασφαλείας Λογισµικού και Συστηµάτων και Υπεύθυνοι Πληροφοριακών Συστηµάτων. Τα άτοµα αυτά έχουν µακρόχρονη εµπειρία στην υλοποίηση έργων και προϊόντων πληροφορικής. Σε συνδυασµό µε τις γενικές ερωτήσεις, παρουσιάσαµε στους εµπλεκόµενους την ιδέα της πλατφόρµας και ζητήσαµε την γνώµη τους σχετικά µε τις λειτουργίες που θα επιθυµούσαν να έχει η πλατφόρµα προκειµένου να καλύπτει τις ανάγκες τους. Με την συλλογή των απαντήσεων συγκεντρώσαµε τα εξής αποτελέσµατα: Τα συνηθέστερα περιβάλλοντα ανάπτυξης είναι τα: o.νετ o Oracle Forms o Java SE και J2EE Τα περισσότερα συστήµατα παλαιών γενεών που διαθέτει η SingularLogic είναι υλοποιηµένα στις ακόλουθες γλώσσες προγραµµατισµού: o C# o Delphi o Java o Visual Basic 6.0 Περισσότερες πληροφορίες για τον τρόπο αξιολόγησης καθώς και αναλυτικά αποτελέσµατα µπορείτε να δείτε στο Παράρτηµα Γ. Η πλειοψηφία των ερωτηθέντων ακολουθεί την µεθοδολογία RUP για το σχεδιασµό και την υλοποίηση των συστηµάτων τους. Η µοναδική πιστοποίηση ασφάλειας που επικυρώνει την διαδικασία σχεδιασµού και υλοποίησης συστηµάτων πληροφορικής είναι η ISO Τέτοια πιστοποίηση είχε µόνο µία από τις εταιρείες που συµµετείχαν στην έρευνα (SingularLogic). Οι έλεγχοι για θέµατα ασφάλειας γίνονται στο στάδιο της υλοποίησης των µονάδων του συστήµατος και της ολοκλήρωσης και γίνονται παράλληλα µε τον έλεγχο λειτουργικότητας. Λεπτοµερής παρουσίαση της όλης διαδικασίας βρίσκεται στην ενότητα 3.1. Σε επίπεδο κώδικα συστηµάτων παλαιών γενεών δεν γίνονται έλεγχοι επιθέσεων διαδικτύου. Ο κώδικας δεν ελέγχεται είτε µε στατικές είτε µε δυναµικές µεθόδους τρωτότητες, ιδιαίτερα για cross-site scripting (XSS) επιθέσεις ενώ συγκεκριµένα υποµέρη του προς υλοποίηση συστήµατος (που κρίνονται υψηλής κρισιµότητας) ελέγχονται αποσπασµατικά για αδυναµίες που µπορούν να οδηγήσουν σε ρήγµατα ασφάλειας. Σε επίπεδο υλοποίησης και λειτουργίας ενός προϊόντος για να εξασφαλιστεί η ασφάλεια ενός συστήµατος παρακολουθούνται τα αρχεία καταγραφής του συστήµατος. Δεδοµένου του πλήθος των µονάδων ενός συστήµατος είναι σηµαντική η αυτοµατοποίηση τόσο της

8 διαδικασίας παρακολούθησης όσο και της διαδικασίας ενηµέρωσης σε περίπτωση πιθανού προβλήµατος ασφάλειας. Τέλος, καταγράψαµε και τη χρήση σύγχρονων συστηµάτων τείχους προστασίας που παρέχουν ισχυρούς µηχανισµούς αυθεντικοποίησης καθώς και καταγραφής όλων των πιθανών «διαδροµών» που εξουσιοδοτείται ο κάθε χρήστης να εκτελέσει. Αξίζει να σηµειωθεί ότι το κόστος αγοράς και χρήσης τέτοιων συστηµάτων είναι ιδιαίτερα υψηλό, γεγονός που τα καθιστά απαγορευτικά για µικροµεσαίες επιχειρήσεις. Μέσω της διαδικασίας των συνεντεύξεων και έπειτα από την συγκέντρωση και ανάλυση των αποτελεσµάτων τους, διαµορφώσαµε µία ξεκάθαρη εικόνα του τρόπου υλοποίησης λογισµικού, την παρούσα κατάσταση που περιγράφεται στην Ενότητα 3.1. Επιπλέον, εντοπίσαµε τα στάδια της διαδικασίας αυτής που παρουσιάζουν ελλείψεις και τον τρόπο που θα τα ενισχύσει η πλατφόρµα και µέσω αυτών εξάγαµε τις Περιπτώσεις Χρήσης της πλατφόρµας. 3 Περιγραφή παρούσας και µελλοντικής κατάστασης Ανάπτυξη και έλεγχος λογισµικού σε επίπεδο Έργου χωρίς την χρήση του Αναλυτής Προγραμματιστής Ελεγκτές Υπεύθυνος Έργου Σχεδιασμός Επικύρωση Σχεδιασμού Υλοποίηση μονάδας συστήματος Καταχώρηση του κώδικα Έλεγχος μονάδας συστήματος Λάθος Σωστά αποτελέσματα; Ολοκλήρωση επιμέρους μονάδων Σωστά Έλεγχος Ολοκλήρωσης Λάθος Εγκατάσταση Σωστή Σωστή ολοκλήρωση; Σχήµα 2: Διαδικασία Ανάπτυξης και Ελέγχου Λογισµικού σε επίπεδο Έργου

9 Σε επίπεδο Έργου, όταν πρόκειται για την υλοποίηση ενός πληροφοριακού συστήµατος, τα βήµατα που ακολουθούνται φαίνονται στο Σχήµα 2. Αρχικά αναλύονται οι απαιτήσεις των ενδιαφεροµένων και σχεδιάζεται το πληροφοριακό σύστηµα από τους αναλυτές. Στην συνέχεια ο Υπεύθυνος Έργου επικυρώνει τον σχεδιασµό και οι προγραµµατιστές προχωρούν στην υλοποίηση των µονάδων του συστήµατος και στην καταχώρηση του κώδικα (commit). Οι ελεγκτές πρέπει να ελέγξουν για το αν γίνονται οι απαραίτητες λειτουργίες και αντίστοιχα η διαδικασία προχωράει στο επόµενο βήµα ή οι προγραµµατιστές αναλαµβάνουν να διορθώσουν ότι λάθη υπάρχουν. Εφόσον πραγµατοποιείται επιτυχώς το προηγούµενο στάδιο, ολοκληρώνονται οι επιµέρους µονάδες και ελέγχεται αν η ολοκλήρωση έγινε επιτυχώς. Αν ναι, ολοκληρώνεται η διαδικασία µε την εγκατάσταση του πληροφοριακού συστήµατος. Ανάπτυξη και έλεγχος λογισµικού σήµερα σε επίπεδο Προϊόντος χωρίς την χρήση του Αναλυτής Προγραμματιστής Ελεγκτές Υπεύθυνος Προϊόντος Σχεδιασμός Επικύρωση Σχεδιασμού Υλοποίηση μονάδας συστήματος Καταχώρηση του κώδικα Έλεγχος μονάδας συστήματος Λάθος Ολοκλήρωση επιμέρους μονάδων Σωστά Σωστά αποτελέσματα; Έλεγχος Ολοκλήρωσης Εγκατάσταση Λειτουργία Προϊόντος Λάθος Σωστή Σωστή ολοκλήρωση; Όχι Σωστή λειτουργία; Ναι Σχήµα 3: Διαδικασία Ανάπτυξης και Ελέγχου Λογισµικού σε επίπεδο Προϊόντος Σε επίπεδο Προϊόντος, όταν πρόκειται για την υλοποίηση ενός πληροφοριακού συστήµατος, τα βήµατα που ακολουθούνται φαίνονται στο Σχήµα 3. Ουσιαστικά η διαδικασία περιλαµβάνει τα ίδια βήµατα µε την υλοποίηση ενός πληροφοριακού συστήµατος σε επίπεδο έργου µε τη διαφορά ότι στο τέλος της διαδικασίας δεν αρκεί η εγκατάσταση του πληροφοριακού συστήµατος αλλά ελέγχεται και η εύρυθµη λειτουργία του. Αν το προϊόν δεν λειτουργεί σωστά η διαδικασία ξεκινάει από την αρχή προκειµένου να βρεθεί το πρόβληµα είτε σε επίπεδο σχεδίασης είτε σε επίπεδο υλοποίησης και ενοποίησης του.

10 3.1 Ανάπτυξη Λογισµικού µε την Χρήση της Πλατφόρµας Ανάπτυξη και έλεγχος λογισµικού µε το (TO-BE) σε επίπεδο Ανάπτυξη και έλεγχος λογισµικού µε την πλατφόρµα σε επίπεδο Έργου έργου Αναλυτής Προγραμματιστής Υπεύθυνος Ελεγκτές Έργου Υπεύθυνος Έργου Σχεδιασμός Υλοποίηση μονάδας συστήματος Επικύρωση Σχεδιασμού Έλεγχος κώδικα για αδυναμίες που μπορούν να οδηγήσουν σε ρήγμα ασφάλειας Καταχώρηση του κώδικα Έλεγχος μονάδας συστήματος Ναι Υπάρχουν αδυναμίες στον κώδικα; Όχι Λάθος Σωστά αποτελέσματα; Ολοκλήρωση επιμέρους μονάδων Σωστά Έλεγχος Ολοκλήρωσης Λάθος Εγκατάσταση Σωστή Σωστή ολοκλήρωση; Phase Σχήµα 4: Διαδικασία Ανάπτυξης και Ελέγχου Λογισµικού σε επίπεδο Έργου µε την πλατφόρµα Σε επίπεδο Έργου, µε την χρήση της πλατφόρµας η διαδικασία για την υλοποίηση ενός πληροφοριακού συστήµατος παραµένει σχεδόν ίδια εκτός ενός σηµείου στο οποίο παρεµβαίνει η πλατφόρµα. Μετά την υλοποίηση των µονάδων συστήµατος από τους προγραµµατιστές και πριν την καταχώρηση του κώδικα, η πλατφόρµα ελέγχει τον κώδικα για αδυναµίες που µπορεί να οδηγήσουν σε ρήγµατα ασφάλειας. Αν ο κώδικας βρεθεί ασφαλής πραγµατοποιείται η καταχώρηση του και συνεχίζεται η διαδικασία, όπως και πριν. Αν ωστόσο βρεθούν λάθη ασφαλείας, επισηµαίνεται στον προγραµµατιστή το προβληµατικό κοµµάτι κώδικα και επαναλαµβάνεται η διαδικασία.

11 Ανάπτυξη και έλεγχος λογισµικού µε την πλατφόρµα σε επίπεδο Προϊόντος Αναλυτής Προγραμματιστής Ελεγκτές Υπεύθυνος Προϊόντος Σχεδιασμός Υλοποίηση μονάδας συστήματος Επικύρωση Σχεδιασμού Έλεγχος κώδικα για αδυναμίες που μπορούν να οδηγήσουν σε ρήγμα ασφάλειας Καταχώρηση του κώδικα Έλεγχος μονάδας συστήματος Ναι Υπάρχουν αδυναμίες στον κώδικα; Λάθος Σωστά αποτελέσματα; Όχι Ολοκλήρωση επιμέρους μονάδων Λάθος Σωστά Έλεγχος Ολοκλήρωσης Εγκατάσταση Σωστή ολοκλήρωση; Λειτουργία Προϊόντος Σωστή Όχι Σωστή λειτουργία; Ναι Σχήµα 5: Διαδικασία Ανάπτυξης και Ελέγχου Λογισµικού σε επίπεδο Προϊόντος µε την πλατφόρµα Σε επίπεδο Προϊόντος, µε την χρήση της πλατφόρµας η διαδικασία για την υλοποίηση ενός πληροφοριακού συστήµατος ακολουθεί τα ίδια βήµατα µε την χωρίς διαδικασία εκτός ενός σηµείου στο οποίο παρεµβαίνει η πλατφόρµα. Ο κώδικας πριν καταχωρηθεί ελέγχεται για ρήγµατα ασφαλείας και διορθώνεται εφόσον χρειαστεί. Διαφέρει επίσης από την διαδικασία που ακολουθείται σε επίπεδο έργου, καθώς στο τέλος ελέγχεται και η λειτουργία του προϊόντος και η όλη διαδικασία επαναλαµβάνεται αν χρειαστεί.

12 Έλεγχος κώδικα ενός συστήµατος παλαιών γενεών µε την πλατφόρµα Ελεγκτές Επιλογή και άνοιγµα αρχείου για έλεγχο από το Έλεγχος κώδικα για αδυναμίες που μπορούν να οδηγήσουν σε ρήγμα ασφάλειας Όχι Υπάρχουν αδυναμίες στον κώδικα; Ναι Ενηµέρωση για τις αδυναµίες στον κώδικα που εντοπίστηκαν Σχήµα 6: Διαδικασία ελέγχου του κώδικα ενός συστήµατος παλαιών γενεών µε την πλατφόρµα Με την πλατφόρµα δίνεται η δυνατότητα να ελέγχεται ο κώδικας παλαιών γενεών για αδυναµίες και η διαδικασία ακολουθεί τα βήµατα που φαίνονται παραπάνω. Πριν την χρήση του ο κώδικας παλαιών γενεών δεν ελεγχόταν καθόλου ή ελεγχόταν µόνο από τον εκάστοτε προγραµµατιστή µε περιορισµό τις γνώσεις αυτού. 4 Ανάλυση Περιπτώσεων Χρήσης Για την ανάλυση των περιπτώσεων χρήσης της πλατφόρµας και την ανάλυση των δραστών σε αυτήν χρησιµοποιούµε την γλώσσα UML και της σχηµατικές απεικονίσεις, διαγράµµατα, που αυτή περιλαµβάνει. Για περισσότερες πληροφορίες ανατρέξτε στο Παράρτηµα Β.

13 4.1 Δράστες στο Σύστηµα Δράστης Ρόλος Περιγραφή Αναπτύσσει τις εφαρµογές και είναι υπεύθυνος για τον ορισµό των έργων που θα παρακολουθούνται, την θωράκιση του Προγραµµατιστής κώδικα εφόσον εντοπιστούν ρήγµατα ασφαλείας και την δηµιουργία Προγραµµατιστής λειτουργικών αρθρωµάτων. Υπεύθυνος Λειτουργικών Διαδικασιών Διαχειριστής του Υπεύθυνος Λειτουργικών Διαδικασιών Διαχειριστής της πλατφόρµας Είναι υπεύθυνος για τον ορισµό των έργων που θα παρακολουθούνται. Είναι υπεύθυνος για την δηµιουργία των χρηστών και την διαχείριση των λειτουργικών αρθρωµάτων (plugins). Στοιχείο Συστήµατος Στοιχείο Πλατφόρµας (Component) Πίνακας 1: Περιγραφή Δραστών στο Σύστηµα Το Στοιχείο Συστήµατος θα εκτελεί όλες τις λειτουργίες που γίνονται αυτόµατα χωρίς την συµβολή ανθρώπου, όπως τον έλεγχο του κώδικα για ρήγµατα ασφαλείας, την καταγραφή των προβληµάτων που εντοπίζονται και την θωράκιση µε τη χρήση βιβλιοθηκών ασφαλείας. 4.2 Κατάλογος Περιπτώσεων Χρήσης του Συστήµατος Για την αναγνώριση των περιπτώσεων χρήσης χρησιµοποιήθηκε η εξής κωδικοποίηση: ΠΧ Α/Α Κωδικός Περίπτωσης Χρήσης ΠΧΑ/Α Περίπτωση Χρήσης Αύξων αριθµός Πίνακας 2: Κωδικοποίηση Περιπτώσεων Χρήσης Ένας Κωδικός Περίπτωσης Χρήσης λοιπόν απαρτίζεται από 3 στοιχεία: το πρόθεµα ΠΧ, τον αριθµό της κατηγορίας, και τον αύξοντα αριθµό της περίπτωσης χρήσης εντός της κατηγορίας. Κωδικός Τίτλος ΠΧ Σύντοµη Περιγραφή Βασικοί Δράστες Σηµαντικότητα ΠΧ ΠΧ01 Δηµιουργία Χρηστών Δηµιουργούνται οι χρήστες. Διαχειριστής της Υψηλή πλατφόρµας ΠΧ02 Προσθήκη / Αφαίρεση Έργων στη Λίστα Προσθέτονται / αφαιρούνται τα έργα που θα παρακολουθούνται στην λίστα Υπεύθυνος Λειτουργικών Υψηλή

14 ΠΧ03 ΠΧ04 ΠΧ05 ΠΧ06 ΠΧ07 ΠΧ08 ΠΧ09 Παρακολούθησης παρακολούθησης. Διαδικασιών, Προγραµµατιστής Έλεγχος του Κώδικα Ελέγχεται ο κώδικας για αδυναµίες. Στοιχείο Πλατφόρµας για αδυναµίες που µπορούν να οδηγήσουν σε ρήγµα ασφαλείας Καταγραφή Προβληµάτων Ασφάλειας Θωράκιση µε τη χρήση βιβλιοθηκών ασφάλειας Δηµιουργία Λειτουργικών Αρθρωµάτων Προσθήκη λειτουργικών αρθρωµάτων (Plugins) στην πλατφόρµα Αφαίρεση λειτουργικών αρθρωµάτων (Plugins) από την πλατφόρµα Ενεργοποίηση λειτουργικών αρθρωµάτων (Plugins) στην πλατφόρµα Καταγράφονται τα προβλήµατα ασφαλείας που εντοπίστηκαν κατά τον έλεγχο του κώδικα. Η πλατφόρµα προτείνει τη χρήση βιβλιοθηκών που παρέχουν αντίµετρα για τις συγκεκριµένες αδυναµίες. Δηµιουργείται κάποιο λειτουργικό άρθρωµα (Plugin) βασισµένο σε πρότυπο κώδικα που παρέχεται από την πλατφόρµα, µε σκοπό την πραγµατοποίηση ανίχνευσης νέων ειδών τρωτοτήτων ή την ενσωµάτωση εξωτερικών εργαλείων. Προστίθεται ένα νέο λειτουργικό άρθρωµα στην πλατφόρµα. Αφαιρείται ένα λειτουργικό άρθρωµα από την πλατφόρµα. Καθορίζονται κανόνες µε βάση τους οποίους θα ενεργοποιείται η εκτέλεση ενός λειτουργικού αρθρώµατος. Πίνακας 3: Λίστα Περιπτώσεων Χρήσης Στοιχείο Πλατφόρµας Στοιχείο Πλατφόρµας, Προγραµµατιστής Προγραµµατιστής Διαχειριστής της πλατφόρµας Διαχειριστής της πλατφόρµας Διαχειριστής της πλατφόρµας Υψηλή Υψηλή Μεσαία Υψηλή Υψηλή Χαµηλή Μεσαία

15 4.3 Περιγραφή Περιπτώσεων Χρήσης του Συστήµατος Δηµιουργία Χρηστών Προσθήκη / Αφαίρεση Έργων στη Λίστα Παρακολούθησης Έλεγχος του Κώδικα για αδυναµίες που µπορούν να οδηγήσουν σε ρήγµα ασφαλείας Υπεύθυνος Λειτουργικών Διαδικασιών Καταγραφή Προβληµάτων Ασφάλειας Στοιχείο Συστήµατος Θωράκιση µε τη χρήση βιβλιοθηκών ασφάλειας Προγραµµατιστής Δηµιουργία Λειτουργικών Αρθρωµάτων Προσθήκη λειτουργικών αρθρωµάτων (Plugins) στην πλατφόρµα Αφαίρεση λειτουργικών αρθρωµάτων (Plugins) από την πλατφόρµα Ενεργοποίηση λειτουργικών αρθρωµάτων (Plugins) στην πλατφόρµα Διαχειριστής του Σχήµα 7: Διάγραµµα Περιπτώσεων Χρήσης Ονοµασία Περίπτωσης Δηµιουργία Χρηστών Χρήσης Κωδικός ΠΧ01 Σύντοµη Περιγραφή Δηµιουργούνται οι χρήστες. Βασικοί Δράστες Διαχειριστής της πλατφόρµας Δευτερεύοντες Δράστες -

16 Σηµαντικότητα Υψηλή Προϋποθέσεις - Ο Διαχειριστής της πλατφόρµας επιλέγει την καρτέλα Χρήστες στην Παραµετροποίηση του συστήµατος. Ο Διαχειριστής της πλατφόρµας επιλέγει την Δηµιουργία Χρήστη. Κύρια Ροή Ο Διαχειριστής της πλατφόρµας δίνει τα στοιχεία του καινούριου χρήστη και το του. Ο Διαχειριστής της πλατφόρµας επιλέγει την Αποθήκευση Αλλαγών. Δηµιουργείται ένας νέος Χρήστης αν όλα τα στοιχεία που εισήγαγε ο Μετασυνθήκες Διαχειριστής της πλατφόρµας είναι σωστά. Να εισάγει λάθος στοιχεία, όνοµα ή/ και ο Διαχειριστής της Εναλλακτικές Ροές πλατφόρµας και το σύστηµα να εµφανίσει µήνυµα λάθους. Ονοµασία Περίπτωσης Προσθήκη / Αφαίρεση Έργων στη Λίστα Παρακολούθησης Χρήσης Κωδικός ΠΧ02 Σύντοµη Περιγραφή Προσθέτονται / αφαιρούνται τα έργα που θα παρακολουθούνται στην λίστα παρακολούθησης. Βασικοί Δράστες Υπεύθυνος Λειτουργικών Διαδικασιών, Προγραµµατιστής Δευτερεύοντες Δράστες - Σηµαντικότητα Υψηλή Προϋποθέσεις - Ο Υπεύθυνος Λειτουργικών Διαδικασιών ή ο Προγραµµατιστής επιλέγει την καρτέλα Λίστα Παρακολούθησης στην Παραµετροποίηση του συστήµατος. Ο Υπεύθυνος Λειτουργικών Διαδικασιών ή ο Προγραµµατιστής Κύρια Ροή επιλέγει την Προσθήκη / Αφαίρεση Έργων. Ο Υπεύθυνος Λειτουργικών Διαδικασιών ή ο Προγραµµατιστής επιλέγει το έργο που θα προστεθεί / αφαιρεθεί. Ο Υπεύθυνος Λειτουργικών Διαδικασιών ή ο Προγραµµατιστής επιλέγει την Προσθήκη / Αφαίρεση Αρχείων. Μετασυνθήκες Να προστεθεί / αφαιρεθεί το έργο στην λίστα παρακολούθησης αν όλες οι ενέργειες έγιναν σωστά. Εναλλακτικές Ροές - Ονοµασία Περίπτωσης Έλεγχος του Κώδικα για αδυναµίες που µπορεί να οδηγήσουν σε ρήγµατα Χρήσης ασφαλείας Κωδικός ΠΧ03 Σύντοµη Περιγραφή Ελέγχεται ο κώδικας για αδυναµίες. Βασικοί Δράστες Στοιχείο Πλατφόρµας Δευτερεύοντες Δράστες - Σηµαντικότητα Υψηλή Προϋποθέσεις - Κύρια Ροή Το Στοιχείο Πλατφόρµας ελέγχει τον κώδικα για αδυναµίες. Μετασυνθήκες Ο κώδικας είναι ασφαλής ή δεν είναι ασφαλής και καταγράφεται το πρόβληµα που εντοπίστηκε. Εναλλακτικές Ροές - Ονοµασία Χρήσης Περίπτωσης Καταγραφή Προβληµάτων Ασφάλειας

17 Κωδικός ΠΧ04 Καταγράφονται τα προβλήµατα ασφαλείας που εντοπίστηκαν κατά τον Σύντοµη Περιγραφή έλεγχο του κώδικα. Βασικοί Δράστες Στοιχείο Πλατφόρµας Δευτερεύοντες Δράστες - Σηµαντικότητα Υψηλή Να έχει γίνει έλεγχος ενός αρχείου για αδυναµίες (ΠΧ03). Προϋποθέσεις Να έχει βρεθεί ένα κενό ασφαλείας. 1. Το Στοιχείο Πλατφόρµας καταγράφει το ή τα προβλήµατα που εντοπίστηκαν. Κύρια Ροή 2. Το Στοιχείο Πλατφόρµας εµφανίζει µήνυµα εύρεσης λάθους που περιέχει πληροφορίες σχετικά µε τον τύπου του λάθους, το σηµείο στο οποίο βρέθηκε και την σηµαντικότητα του. Ο Προγραµµατιστής επιλέγει να διορθώσει τα προβλήµατα που Μετασυνθήκες καταγράφηκαν ή τα αγνοεί. Εναλλακτικές Ροές - Ονοµασία Περίπτωσης Θωράκιση µε security libraries Χρήσης Κωδικός ΠΧ05 Σύντοµη Περιγραφή Αν εντοπιστούν αδυναµίες ασφάλειας η πλατφόρµα προτείνει τη χρήση βιβλιοθηκών που παρέχουν αντίµετρα για τις συγκεκριµένες αδυναµίες. Βασικοί Δράστες Προγραµµατιστής, Στοιχείο Πλατφόρµας Δευτερεύοντες Δράστες - Σηµαντικότητα Μεσαία 1. Να έχουν εντοπιστεί στον πηγαίο κώδικα της εφαρµογής αδυναµίες Προϋποθέσεις ασφάλειας. 2. Να έχει γίνει καταγραφή και συσχέτιση βιβλιοθηκών ασφάλειας µε τις αδυναµίες από τις οποίες παρέχουν προστασία. Το Στοιχείο Πλατφόρµας προτείνει τη χρήση συγκεκριµένων Κύρια Ροή βιβλιοθηκών ασφάλειας ανάλογα µε τις αδυναµίες που έχουν εντοπιστεί στον κώδικα της εφαρµογής Ο Προγραµµατιστής ενσωµατώνει στον κώδικα της εφαρµογής αναφορές Μετασυνθήκες και κατάλληλες κλήσεις για την χρήση των βιβλιοθηκών ασφάλειας που προτείνει η πλατφόρµα. Εναλλακτικές Ροές - Ονοµασία Περίπτωσης Δηµιουργία λειτουργικών αρθρωµάτων (Plugins) Χρήσης Κωδικός ΠΧ06 Δηµιουργείται κάποιο λειτουργικό άρθρωµα (Plugin) βασισµένο σε Σύντοµη Περιγραφή πρότυπο κώδικα που παρέχεται από την πλατφόρµα, µε σκοπό την πραγµατοποίηση ανίχνευσης νέων ειδών τρωτοτήτων ή την ενσωµάτωση εξωτερικών εργαλείων. Βασικοί Δράστες Προγραµµατιστής Δευτερεύοντες Δράστες - Σηµαντικότητα Μεσαία Προϋποθέσεις Η πλατφόρµα παρέχει πρότυπο κώδικα για τη δηµιουργία ενός λειτουργικού αρθρώµατος (Plugin) 1. Ο Προγραµµατιστής δηµιουργεί ένα αντίγραφο του προτύπου που παρέχει η πλατφόρµα για την δηµιουργία ενός λειτουργικού Κύρια Ροή αρθρώµατος. 2. Ο Προγραµµατιστής ενσωµατώνει νέο κώδικα στο αντίγραφο του προτύπου, ώστε χρησιµοποιώντας τις κατάλληλες προγραµµατιστικές

18 διεπαφές που παρέχει η πλατφόρµα να δηµιουργήσει ένα λειτουργικό άρθρωµα που προσθέτει νέα λειτουργικότητα στο σύστηµα. 3. Ο Προγραµµατιστής µεταγλωττίζει το νέο λειτουργικό άρθρωµα ώστε αυτό να µπορεί να χρησιµοποιηθεί από την πλατφόρµα. Δηµιουργείται ένα νέο λειτουργικό άρθρωµα το οποίο επεκτείνει τη Μετασυνθήκες λειτουργικότητα της πλατφόρµας Εναλλακτικές Ροές - Ονοµασία Περίπτωσης Προσθήκη λειτουργικών αρθρωµάτων (Plugins) στην πλατφόρµα Χρήσης Κωδικός ΠΧ07 Σύντοµη Περιγραφή Προστίθεται ένα νέο λειτουργικό άρθρωµα στην πλατφόρµα. Βασικοί Δράστες Διαχειριστής της πλατφόρµας Δευτερεύοντες Δράστες - Σηµαντικότητα Μεσαία Προϋποθέσεις - 1. Ο Διαχειριστής της πλατφόρµας επιλέγει την καρτέλα Λειτουργικά Αρθρώµατα στην Παραµετροποίηση του συστήµατος. Κύρια Ροή 2. Ο Διαχειριστής της πλατφόρµας επιλέγει ένα ή περισσότερα αρχεία τα οποία απαρτίζουν το λειτουργικό άρθρωµα. 3. Ο Διαχειριστής της πλατφόρµας επιλέγει την ενέργεια Προσθήκη Μετασυνθήκες Προστίθεται ένα νέο λειτουργικό άρθρωµα στην πλατφόρµα 1. Ο Διαχειριστής της πλατφόρµας να επιλέξει ένα αρχείο που δεν υπάρχει στο σύστηµα ή δεν περιέχει κάποιο λειτουργικό άρθρωµα Εναλλακτικές Ροές και το σύστηµα να εµφανίσει µήνυµα λάθους. 2. Ο Διαχειριστής της πλατφόρµας να µην επιλέξει κανένα αρχείο, να επιλέξει Προσθήκη και το σύστηµα να εµφανίσει µήνυµα λάθους. Ονοµασία Περίπτωσης Αφαίρεση λειτουργικών αρθρωµάτων (Plugins) από την πλατφόρµα Χρήσης Κωδικός ΠΧ08 Σύντοµη Περιγραφή Αφαιρείται ένα υπάρχον λειτουργικό άρθρωµα από την πλατφόρµα Βασικοί Δράστες Διαχειριστής της πλατφόρµας Δευτερεύοντες Δράστες - Σηµαντικότητα Χαµηλή Προϋποθέσεις Να έχει προστεθεί κάποιο λειτουργικό άρθρωµα στην πλατφόρµα (ΠΧ08) 1. Ο Διαχειριστής της πλατφόρµας επιλέγει την καρτέλα Λειτουργικά Αρθρώµατα στην Παραµετροποίηση του συστήµατος. 2. Ο Διαχειριστής της πλατφόρµας επιλέγει ένα ή περισσότερα Κύρια Ροή από τα λειτουργικά αρθρώµατα που έχουν προστεθεί στην πλατφόρµα. 3. Ο Διαχειριστής της πλατφόρµας επιλέγει την ενέργεια Αφαίρεση. Μετασυνθήκες Αφαιρείται ένα ή περισσότερα από τα λειτουργικά αρθρώµατα που έχουν προστεθεί στην πλατφόρµα 2α. Ο Διαχειριστής της πλατφόρµας να µην επιλέξει κανένα Εναλλακτικές Ροές λειτουργικό άρθρωµα, να επιλέξει Αφαίρεση και το σύστηµα να εµφανίσει µήνυµα λάθους.

19 Ονοµασία Περίπτωσης Ενεργοποίηση λειτουργικών αρθρωµάτων (Plugins) Χρήσης Κωδικός ΠΧ09 Σύντοµη Περιγραφή Καθορίζονται κανόνες µε βάση τους οποίους θα ενεργοποιείται η εκτέλεση ενός λειτουργικού αρθρώµατος. Βασικοί Δράστες Διαχειριστής της πλατφόρµας Δευτερεύοντες Δράστες - Σηµαντικότητα Υψηλή 1. Να έχουν προστεθεί λειτουργικά αρθρώµατα (Plugins) στην Προϋποθέσεις πλατφόρµα (ΠΧ07) 2. Ή να έχουν δηµιουργηθεί λειτουργικά αρθρώµατα (Plugins) (ΠΧ06) 1. Ο Προγραµµατιστής ή ο Διαχειριστής της πλατφόρµας επιλέγει την καρτέλα Λειτουργικά Αρθρώµατα στην Παραµετροποίηση του συστήµατος. 2. Ο Προγραµµατιστής ή ο Διαχειριστής της πλατφόρµας επιλέγει την Κύρια Ροή Ενεργοποίηση Λειτουργικών Αρθρωµάτων. 3. Ο Προγραµµατιστής ή ο Διαχειριστής της πλατφόρµας επιλέγει ένα ή περισσότερα από τα λειτουργικά αρθρώµατα που έχουν προστεθεί στην πλατφόρµα για ενεργοποίηση. 4. Ο Προγραµµατιστής ή ο Διαχειριστής της πλατφόρµας επιλέγει την Ενεργοποίηση Επιλεγµένων. Μετασυνθήκες Ενεργοποιούνται τα λειτουργικά αρθρώµατα που επέλεξε ο Προγραµµατιστής ή ο Διαχειριστής της πλατφόρµας. Εναλλακτικές Ροές 3α.Ο Προγραµµατιστής ή ο Διαχειριστής της πλατφόρµας δεν επιλέγει κανένα λειτουργικό άρθρωµα και εµφανίζεται αντίστοιχο µήνυµα λάθους. 5 Ανάλυση Απαιτήσεων Πλατφόρµας 5.1 Περιγραφή των Λειτουργικών Απαιτήσεων Οι λειτουργικές απαιτήσεις της πλατφόρµας που περιγράφονται στις ακόλουθες ενότητες, έχουν οργανωθεί µε βάση τη λειτουργικότητα που θα παρέχει. Στις περιπτώσεις που µια λειτουργία µπορεί να αφορά περισσότερες από µια κατηγορίες χρηστών για τις οποίες υπάρχει διαφοροποίηση στην τρόπο εκτέλεσης, αυτές ορίζονται ανάλογα µε την κατηγορία. Οι περιγραφές και οι απαιτήσεις για τις διεπαφές που θα δηµιουργηθούν ή χρησιµοποιηθούν από την πλατφόρµα αναλύονται στην ενότητα Απαιτήσεις σχετικά µε τους Χρηστών Οι λειτουργικές απαιτήσεις της συγκεκριµένης κατηγορίας σχετίζονται µε τη διαχείριση των δικαιωµάτων των χρηστών του συστήµατος, τη δηµιουργία και τη διαχείριση των ρόλων των χρηστών στο σύστηµα, καθώς και µε τη δηµιουργία και τη διαχείριση των χρηστών του συστήµατος Δηµιουργία Χρηστών (Λειτουργική Απαίτηση 1.1) Η λειτουργία 1.1 αφορά στη δηµιουργία χρηστών, δηλαδή στην ένα προς ένα αντιστοίχηση φυσικών προσώπων µε τους δυνατούς χειριστές του συστήµατος. Κατά την εκτέλεση της συγκεκριµένης λειτουργίας, καταγράφεται στο σύστηµα ένας εν δυνάµει χειριστής του (διατηρώντας στοιχεία όπως το ονοµατεπώνυµο και το του) µε αρχικά κενό σύνολο ρόλων και κατά συνέπεια και δικαιωµάτων σε αυτό Απαιτήσεις σχετικά µε τη Διαχείριση Απειλών

20 Οι λειτουργικές απαιτήσεις της συγκεκριµένης κατηγορίας σχετίζονται µε τη διαχείριση των αρχείων και των προτύπων που θα ελέγχονται. Με τον όρο λίστα παρακολούθησης αναφερόµαστε σε µια λίστα από αρχεία τα οποία ελέγχονται από την πλατφόρµα. Αντίστοιχα, µε τον όρο Προφίλ Ασφαλείας αναφερόµαστε σε µια λίστα από ελέγχους που εκτελούνται σε συγκεκριµένα αρχεία. Σκοπό της διαδικασίας αποτελεί η οµαδοποίηση στόχων ασφαλείας, µε αποτέλεσµα την ευκολότερη διαχείριση της πλατφόρµας Προσθήκη / Αφαίρεση Εργων στη Λίστα Παρακολούθησης (Λειτουργική Απαίτηση 2.1) Η λειτουργία 2.1 αφορά στην προσθήκη αρχείων σε µια ήδη δηµιουργηµένη λίστα παρακολούθησης. Κατά την εκτέλεση της συγκεκριµένης λειτουργίας, το σύνολο των αρχείων που υπάρχουν σε µία λίστα παρακολούθησης αυξάνεται ως προς ένα ή περισσότερα αρχεία Απαιτήσεις σχετικά µε την Ανάλυση Τρωτοτήτων Οι λειτουργικές απαιτήσεις της συγκεκριµένης κατηγορίας αφορούν στη διενέργεια και στο χειρισµό των αποτελεσµάτων των ελέγχων συγκεκριµένων αρχείων. Ο έλεγχος των αρχείων µπορεί να πραγµατοποιηθεί είτε αυτοµατοποιηµένα και συνεχώς, είτε µετά από αίτηση ενός χρήστη Έλεγχος του Κώδικα για αδυναµίες που µπορεί να οδηγήσουν σε ρήγµατα ασφάλειας (Λειτουργική Απαίτηση 3.1) Η λειτουργία 3.3 αφορά στον έλεγχο του κώδικα ενός συγκεκριµένου αρχείου για αδυναµίες σε επίπεδο λογισµικού, που µπορεί να οδηγήσουν σε ρήγµατα ασφαλείας τα οποία µπορεί να εκµεταλλευθεί ένας κακόβουλος χρήστης. Αποτέλεσµα της συγκεκριµένης διαδικασίας αποτελεί η ανίχνευση ή όχι της ύπαρξης των προτύπων που σχετίζονται µε διάφορες ευπάθειες Καταγραφή Προβληµάτων Ασφάλειας (Λειτουργική Απαίτηση 3.2) Η λειτουργία 3.2 αφορά στη καταγραφή των κενών ασφαλείας που έχουν εντοπιστεί µέσω της εκτέλεσης της λειτουργίας 3.3. Κατά την εκτέλεση της λειτουργίας το / τα προβλήµατα καταγράφονται και αποστέλλονται µέσω προειδοποιητικού στον υπεύθυνο ασφαλείας για το συγκεκριµένο αρχείο Απαιτήσεις για την επέκταση της πλατφόρµας µε λειτουργικά αρθρώµατα (Plug-ins) Οι λειτουργικές απαιτήσεις της κατηγορίας αυτής αφορούν το πως η πλατφόρµα θα µπορεί να επεκτείνεται είτε προσθέτοντας εξωτερικά εργαλεία που θα ανιχνεύουν αδυναµίες που µπορούν να οδηγήσουν σε ρήγµατα ασφάλειας, είτε νέα προγράµµατα που θα έχουν γραφτεί από τους προγραµµατιστές και θα έχουν σαν στόχο να ανιχνεύσουν συγκεκριµένες αδυναµίες σε σχέση µε το έργο. Και στις δυο περιπτώσεις, η ενσωµάτωση θα γίνεται µε την µορφή ενός plugin Δηµιουργία υποδοµής για την υποστήριξη λειτουργικών αρθρωµάτων (Plugins) (Λειτουργική Απαίτηση 4.1) Ένα λειτουργικό άρθρωµα είναι ένα στοιχείο λογισµικού (component) το οποίο θα υλοποιεί κάποια διεπαφή την οποία γνωρίζει η πλατφόρµα. Η πλατφόρµα θα µπορεί εποµένως να ενεργοποιήσει το Plugin προκειµένου αυτή να ενεργοποιηθεί και να µπορεί να εκτελεστεί αυτόνοµα ή µέσω άλλων Plugins. Η πλατφόρµα θα πρέπει να ορίζει µια τέτοια προγραµµατιστική διεπαφή (Application Programming Interface, API), που θα επιτρέπει βασικές λειτουργίες όπως η αυτόµατη ενεργοποίηση κατά την πραγµατοποίηση ενός αυτοµατοποιηµένου ή χειροκίνητου ελέγχου για τρωτότητες. Η διεπαφή αυτή θα πρέπει να τεκµηριωθεί µε τη µορφή εξωτερικής τεκµηρίωσης που να επιτρέπει σε τρίτους να δηµιουργούν δικά τους plugins τα οποία θα µπορούν να εκτελεστούν στην πλατφόρµα.

21 Περισσότερες λεπτοµέρειες σχετικά µε τη διεπαφή αυτή µπορούν να βρεθούν στην ενότητα Διεπαφές συστήµατος Ενσωµάτωση εξωτερικών εργαλείων (Λειτουργική Απαίτηση 4.2) Υπάρχει µια πληθώρα εργαλείων που αναλύουν στατικά κώδικα για να εντοπίσουν αδυναµίες [4]. Η ανάλυση µπορεί να γίνεται είτε σε επίπεδο πηγαίου κώδικα (source code) είτε σε επίπεδο µεταγλωττισµένου κώδικα (compiled code). Σκοπός µας είναι να µπορεί ένας προγραµµατιστής να ενσωµατώσει ένα τέτοιο εργαλείο στην πλατφόρµα µας εύκολα και αποδοτικά. Για να γίνει κάτι τέτοιο θα πρέπει να δηµιουργηθεί κάποιο πρότυπο (template) το οποίο θα πρέπει να ακολουθεί ο προγραµµατιστής ώστε να κάνει την ενσωµάτωση. Ακολουθώντας το πρότυπο αυτό, ο προγραµµατιστής θα δηµιουργεί ένα plugin το οποίο αρχικά θα καλεί το εργαλείο ενώ µόλις αυτό το ολοκληρώσει τον έλεγχο του θα αναλύει τα αποτελέσµατά του επιτρέποντας στον προγραµµατιστή να τα απεικονίσει µε όποιον τρόπο επιθυµεί Ενσωµάτωση προσαρµοσµένων προγραµµάτων (Λειτουργική Απαίτηση 4.3) Υπάρχουν περιπτώσεις όπου ένας προγραµµατιστής θα θέλει να διαπιστώσει συγκεκριµένα πράγµατα σε σχέση µε την ασφάλεια της εφαρµογής του. Η πλατφόρµα θα του παρέχει την ευκαιρία να δηµιουργεί προσαρµοσµένα (custom) plugins που θα κάνουν έλεγχους προσαρµοσµένους στην φύση της εφαρµογής που αναπτύχθηκε (π.χ. Την γλώσσα προγραµµατισµού που χρησιµοποιήθηκε, εάν είναι web εφαρµογή κ.α.). Αυτό θα γίνεται πάλι µε πρότυπα όπως αναφέρθηκε και στην προηγούµενη περίπτωση Απαιτήσεις σχετικά µε την ενίσχυση της ασφαλείας της εφαρµογής Εκτός από την ανεύρεση αδυναµιών, ένας άλλος βασικός στόχος της πλατφόρµας είναι να προτείνει αντίµετρα που να µπορούν να χρησιµοποιήσουν οι προγραµµατιστές της εφαρµογής ώστε να την θωρακίσουν. Οι προτάσεις αυτές θα εξαρτώνται άµεσα από τα αποτελέσµατα της στατικής ανάλυση που θα έχει προηγηθεί Θωράκιση µέσω βιβλιοθηκών ασφαλείας (Λειτουργική Απαίτηση 5.1) Ανάλογα µε τα αποτελέσµατα του στατικού ελέγχου η πλατφόρµα θα προτείνει για την προστασία της εφαρµογής την χρησιµοποίηση βιβλιοθηκών ασφάλειας. Συγκεκριµένα, τα αποτελέσµατα του στατικού ελέγχου θα καταγράφονται. Έπειτα, η πλατφόρµα θα τα ελέγχει και θα προτείνει βιβλιοθήκες που θα µπορούν να καταπολεµήσουν τις καταγεγραµµένες αδυναµίες. Ο όρος βιβλιοθήκη ασφάλειας µπορεί να περιλαµβάνει είτε υπάρχουσες βιβλιοθήκες, είτε νέες που µπορούν να αναπτυχθούν για να καλύψουν συγκεκριµένες ανάγκες. 5.2 Περιγραφή Μη-λειτουργικών Απαιτήσεων Φυσικές απαιτήσεις Ο υλικός εξοπλισµός που θα χρησιµοποιηθεί για την εκτέλεση της πλατφόρµας είναι επιθυµητό να βρίσκεται σε φυσική τοποθεσία µε τα ακόλουθα χαρακτηριστικά: Περιορισµένη φυσική πρόσβαση µέσω χρήσης µηχανικής ή ηλεκτρονικής κλειδαριάς. Συστήµατα κλιµατισµού και εξαερισµού µε ανεξάρτητη παροχή ισχύος, προκειµένου ο εξοπλισµός να λειτουργεί εντός των προδιαγραφών θερµοκρασίας και υγρασίας που προτείνεται από τους εκάστοτε κατασκευαστές. Συστήµατα αυτόµατης ανίχνευσης, σήµανσης συναγερµού και κατάσβεσης πυρκαγιάς. Ο συναγερµός είναι επιθυµητό να διαθέτει και δυνατότητα χειροκίνητης σήµανσης, ενώ το σύστηµα πυρόσβεσης θα πρέπει να είναι κατάλληλος για πυρκαγιές που προκαλούνται από ηλεκτρικό εξοπλισµό. Η ανίχνευση είναι επιθυµητό να πραγµατοποιείται µε τη χρήση αισθητήρων θερµότητας, καπνού ή οπτικούς, ή συνδυασµούς αυτών. Ψευδοροφή ή/και υπερυψωµένο πάτωµα, προκειµένου να διευκολύνεται ο κλιµατισµός, η οργάνωση της καλωδίωσης και η προστασία από πληµµύρες.

22 Συστήµατα αδιάλειπτης παροχής ισχύος (Uninterruptible Power Supply, UPS) των οποίων η ικανότητα παροχής ισχύος πρέπει να υπερβαίνει τη µέγιστη κατανάλωση του εξοπλισµού κατά 20% κατ ελάχιστον. Τα συστήµατα αυτά θα πρέπει να διαθέτουν κυκλώµατα προστασίας από υπερτάσεις. Καλωδίωση δικτύου συµβατή µε τα πρότυπα ANSI/TIA/EIA-568-B και ANSI/TIA/EIA-568-B , EN50173 ή ISO/IEC Η υποδοµή καλωδίωσης θα πρέπει να είναι συµβατή µε την Ευρωπαϊκή Οδηγία για την Ηλεκτροµαγνητική Συµβατότητα 2004/108/EEC και να υποστηρίζει µετάδοση δεδοµένων µε ρυθµούς ως 1000Mbps/s στα 100m (1000BaseT). Όλος ο ενεργός ηλεκτρονικός εξοπλισµός (εξυπηρετητές, ενεργός δικτυακός εξοπλισµός, κλπ) θα πρέπει να είναι εγκατεστηµένος σε standard ερµάρια (racks) πλάτους 19 ιντσών, ελάχιστου βάθους 60 εκατοστών και ελάχιστου ύψους τέτοιου που να υπερβαίνει το ύψος του εγκατεστηµένου εξοπλισµού κατά 20%. Τα racks θα πρέπει να επιτρέπουν διευθέτηση της καλωδίωσης, να διαθέτουν αφαιρούµενα πλαϊνά και κλειδαριά στο εµπρόσθιο τµήµα Περιβάλλον λειτουργίας και προσαρµοστικότητα Σε επίπεδο υποδοµών που χρησιµοποιούνται για την λειτουργία της πλατφόρµας, είναι σηµαντικό αυτές να µπορούν να ενισχυθούν / επεκταθούν προκειµένου να είναι διαθέσιµη η απαραίτητη επεξεργαστική ισχύς και η συνδεσιµότητα µέσω δικτύου που απαιτείται για την οµαλή λειτουργία της πλατφόρµας εντός των απαιτήσεων που ορίζονται για την απόδοσή της. Αυτό σηµαίνει πως πρέπει να είναι δυνατή η εγκατάσταση επιπλέον εξοπλισµού επεξεργασίας, συνδεσιµότητας (δικτύων) και παροχής ενέργειας αντίστοιχα προκειµένου να µπορούν να εξυπηρετηθούν µελλοντικές ανάγκες Απαιτήσεις απόδοσης συστήµατος Η αξιολόγηση της απόδοσης ενός συστήµατος εντοπισµού προβληµάτων ασφάλειας σε κώδικα µπορεί να στηριχτεί σε δύο εναλλακτικές προσεγγίσεις: 1. Αξιολόγηση ως προς µία κατασκευασµένη σουίτα δοκιµαστικών προγραµµάτων που σκοπό έχει να καλύψει µεγάλο φάσµα προβληµάτων ασφάλειας σε όλες τις πιθανές εκδοχές [3]. 2. Αξιολόγηση ως προς την απόδοση του συστήµατος σε λογισµικό και benchmarks µε ήδη καταγεγραµµένα προβλήµατα ασφαλείας. Στην περίπτωση αυτή ελέγχεται η επάρκεια αποκλειστικά και µόνο στα προβλήµατα που εµφανίζει το λογισµικό που χρησιµοποιείται για το σκοπό αυτό. Αν δεν καταστεί δυνατή η διάθεση τέτοιου λογισµικού από το χρήστη, τότε θα αναζητηθούν εφαρµογές web ανοικτού λογισµικού. Η πλατφόρµα θα χρησιµοποιείται για την ανάλυση σηµαντικής ποσότητας δεδοµένων (πηγαίου κώδικα εφαρµογών) από διάφορα συστήµατα λογισµικού, όπως περιγράφεται στην ενότητα 4.3. Καθώς πολλοί χρήστες θα χρησιµοποιούν την πλατφόρµα ταυτόχρονα, είναι σηµαντικό να επιτευχθεί ένα σύνολο στόχων απόδοσης που θα επιτρέπει την απροβληµάτιστη εξυπηρέτηση των αναγκών των χρηστών αυτών. Αυτές οι απαιτήσεις περιγράφονται στις παραγράφους που ακολουθούν Απόδοση λειτουργιών δηµιουργίας χρηστών Περιγραφή Σχετικές Π.Χ. Σχόλια Οι λειτουργίες που αφορούν σε δηµιουργία χρηστών πρέπει να ολοκληρώνονται σε χρονικό διάστηµα µικρότερο του ενός λεπτού στο 95% των περιπτώσεων. ΠΧ01 Οι ενέργειες που αφορούν στη δηµιουργία χρηστών µετά την αρχική παραµετροποίηση της πλατφόρµας δεν θα λαµβάνουν χώρα µε ιδιαίτερη συχνότητα, οπότε η απόδοσή τους δεν είναι κρίσιµη. Ωστόσο, η πραγµατοποίησή τους δεν πρέπει να είναι ιδιαίτερα χρονοβόρα προκειµένου να εξασφαλισθεί η καλή εµπειρία του χρήστη (στη συγκεκριµένη περίπτωση του διαχειριστή της πλατφόρµας). Το χρονικό περιθώριο δεν αφορά στο χρόνο που απαιτείται για την εισαγωγή δεδοµένων αλλά για την πραγµατοποίηση της λειτουργίας.

23 Απόδοση λειτουργιών διαχείρισης Έργων Περιγραφή Οι λειτουργίες που αφορούν σε διαχείριση έργων πρέπει να ολοκληρώνονται σε χρονικό διάστηµα µικρότερο του ενός λεπτού στο 95% των περιπτώσεων. Σχετικές Π.Χ. ΠΧ02 Σχόλια Οι ενέργειες που αφορούν στη διαχείριση έργων θα λαµβάνουν χώρα µε ιδιαίτερη συχνότητα κατά τη διάρκεια της λειτουργίας του συστήµατος, οπότε η απόδοσή τους είναι κρίσιµη. Η ολοκλήρωσή τους δεν πρέπει να είναι ιδιαίτερα χρονοβόρα προκειµένου να εξασφαλισθεί η καλή εµπειρία του χρήστη. Το χρονικό περιθώριο δεν αφορά στο χρόνο που απαιτείται για την εισαγωγή δεδοµένων αλλά για την πραγµατοποίηση της λειτουργίας Απόδοση λειτουργιών ελέγχου Έργων Απόδοση Ελέγχου του Κώδικα για αδυναµίες που µπορεί να οδηγήσουν σε ρήγµατα ασφάλειας Περιγραφή Η πλατφόρµα πρέπει να εκτελεί τον έλεγχο ενός αρχείου για κάθε κατηγορία προβληµάτων ασφάλειας σε λιγότερο από 1 λεπτό ανά τύπο στο 95% των περιπτώσεων. Σε περίπτωση που χρειάζεται να εξεταστούν αυτόµατα περισσότερα αρχεία λόγω εξαρτήσεων µεταξύ τους ο συνολικός χρόνος για την ανάλυση δεν πρέπει να ξεπερνά το 1 λεπτό ανά αρχείο αντίστοιχα. Σχετικές Π.Χ. ΠΧ03 Σχόλια Προκειµένου να αποφευχθεί η παρείσφρηση τρωτοτήτων είναι σηµαντικό η ανάλυση ενός αρχείου να πραγµατοποιείται σε σύντοµο χρονικό διάστηµα, έτσι ώστε να επιτευχθεί καλή εµπειρία χρήστη. Δεδοµένου ότι η πλατφόρµα τυπικά θα εξετάζει µεγάλο αριθµό αρχείων, η καλή απόδοση των ελέγχων για τους προαναφερθέντες τύπους τρωτοτήτων θα εξασφαλίσει την καλή απόδοση της πλατφόρµας συνολικά. Το χρονικό περιθώριο που ορίζεται αφορά στον έλεγχο για όλες τις γνωστές πιθανές τρωτότητες που εµπίπτουν στην κάθε κατηγορία αντίστοιχα. Απόδοση Καταγραφής Προβληµάτων Ασφάλειας Περιγραφή Η πλατφόρµα πρέπει να εκτελεί την καταγραφή των προβληµάτων ασφάλειας που έχουν εντοπιστεί σε ένα σύστηµα λογισµικού εντός ενός λεπτού στο 95% των περιπτώσεων. Σχετικές Π.Χ. ΠΧ04 Σχόλια Δεδοµένου ότι η καταγραφή των τρωτοτήτων είναι µια από τις πλέον κρίσιµες λειτουργίες της πλατφόρµας, είναι σηµαντικό να χαρακτηρίζεται από καλή απόδοση. Το χρονικό περιθώριο που ορίζεται κρίνεται επαρκές για να λάβει ο χρήστης της πλατφόρµας έγκαιρη ενηµέρωση σχετικά µε τρωτότητες που έχουν ανιχνευτεί Απόδοση αποθήκευσης και ανάκτησης πληροφοριών Περιγραφή Σχετικές Π.Χ. Σχόλια Ο χρόνος που απαιτείται για την αποθήκευση και ανάκτηση ενός διακριτού στοιχείου πληροφορίας σχετικά µε τη λειτουργία και την παραµετροποίηση της πλατφόρµας (πχ ρόλος, χρήστης, αρχείο προς παρακολούθηση, κλπ.) πρέπει να εκτελείται εντός ενός δευτερολέπτου στο 95% των περιπτώσεων, ανεξάρτητα από την υποκείµενη αναπαράσταση και µορφή αποθήκευσης των δεδοµένων που χρησιµοποιείται. όλες Δεδοµένου ότι η πλατφόρµα θα καταγράφει πληροφορίες για ένα µεγάλο αριθµό οντοτήτων (χρηστών, ρόλων, προφίλ ασφάλειας κλπ) και αρχείων υπό παρακολούθηση, η απόδοση του µηχανισµού αποθήκευσης και ανάκτησης των δεδοµένων αυτών κρίνεται ως ιδιαίτερα σηµαντική για την καλή απόδοση της

24 πλατφόρµας συνολικά. Η απόδοση πρέπει να παραµείνει µέσα στο παραπάνω όριο ανεξαρτήτως του αριθµού των οντοτήτων που διαχειρίζεται η πλατφόρµα Απόδοση διεπαφής χρήστη για τοπικές ενέργειες Περιγραφή Σχετικές Π.Χ. Σχόλια Ο χρόνος που απαιτείται για την πραγµατοποίηση ενεργειών µέσω της διεπαφής χρήστη που περιγράφεται στην ενότητα ΧΧ, οι οποίες δεν απαιτούν ανάκτηση στοιχείων ή µεταφορά δεδοµένων από/προς τον εξυπηρετητή στον οποίο εκτελείται η πλατφόρµα πρέπει να πραγµατοποιούνται εντός ενός δευτερολέπτου στο 99% των περιπτώσεων. όλες Η πλατφόρµα θα προσφέρει κάποιου είδους γραφική διεπαφή (GUI) που θα επιτρέπει στους χρήστες να αλληλεπιδρούν µαζί της για την πραγµατοποίηση των εργασιών διαχείρισης ρόλων, προφίλ ασφάλειας, αρχείων παρακολούθησης κλπ. Η πραγµατοποίηση των ενεργειών αυτών απαιτεί την εκτέλεση µιας σειράς τοπικών ενεργειών, για τις οποίες δεν είναι απαραίτητη η επικοινωνία µέσω δικτύου µε την πλατφόρµα. Προκειµένου να επιτευχθεί υψηλή χρηστικότητα της διεπαφής, είναι κρίσιµο οι ενέργειες αυτές να πραγµατοποιούνται σε σύντοµο χρονικό διάστηµα. Σύµφωνα µε µελέτες σχετικά µε την Αλληλεπίδραση Ανθρώπου-Υπολογιστή, προκειµένου µια διεπαφή χρήστη να προσφέρει αίσθηση καλής ταχύτητας ανταπόκρισης πρέπει να εκτελεί τις ενέργειες ή να προσφέρει απαντήσεις (feedback) εντός ενός δευτερολέπτου Απόδοση διεπαφής χρήστη για αποµακρυσµένες ενέργειες Περιγραφή Σχετικές Π.Χ. Σχόλια Ο χρόνος που απαιτείται για την πραγµατοποίηση ενεργειών µέσω της διεπαφής χρήστη που περιγράφεται στην ενότητα ΧΧ, οι οποίες απαιτούν ανάκτηση στοιχείων ή µεταφορά δεδοµένων από/προς τον εξυπηρετητή στον οποίο εκτελείται η πλατφόρµα πρέπει να πραγµατοποιούνται εντός 30 δευτερολέπτων στο 99% των περιπτώσεων. όλες Η πλατφόρµα θα προσφέρει κάποιου είδους γραφική διεπαφή (GUI) που θα επιτρέπει στους χρήστες να αλληλεπιδρούν µαζί της για την πραγµατοποίηση των εργασιών διαχείρισης ρόλων, προφίλ ασφάλειας, αρχείων παρακολούθησης κλπ. Η πραγµατοποίηση των ενεργειών αυτών απαιτεί την εκτέλεση µιας σειράς τοπικών ενεργειών, για τις οποίες δεν είναι απαραίτητη η επικοινωνία µέσω δικτύου µε την πλατφόρµα, και µια σειρά από ενέργειες οι οποίες προκαλούν την εκτέλεση ενεργειών στον εξυπηρετητή της πλατφόρµας. Τα µέγιστα επιτρεπτά χρονικά διαστήµατα για τα οποία µπορεί να περιµένει ο χρήστης προτού µια ενέργεια θεωρηθεί ότι απέτυχε τυπικά καθορίζονται από το πρωτόκολλο επικοινωνίας που χρησιµοποιείται ανάµεσα στη διεπαφή χρήστη και τον εξυπηρετητή της πλατφόρµας. Τα 30 δευτερόλεπτα είναι µια τυπική τιµή χρονικού περιθωρίου σε αρκετά πρωτόκολλα Ικανότητα Ταυτόχρονης Χρήσης Πλατφόρµας Περιγραφή Σχετικές Π.Χ. Σχόλια Η πλατφόρµα πρέπει να µπορεί να χρησιµοποιηθεί ταυτόχρονα µέσω διαφορετικών στιγµιότυπων των παρεχόµενων διεπαφών χρήστη από τουλάχιστον 5 χρήστες προτού ο χρόνος απόκρισης της πλατφόρµας διπλασιαστεί, υποθέτοντας ότι κάθε χρήστης εκτελεί µια ενέργεια ανά 30 δευτερόλεπτα κατά µέσο όρο. όλες Η πλατφόρµα θα χρησιµοποιείται ταυτόχρονα από χρήστες κάθε κατηγορίας. Δεδοµένου ότι οι χρήστες αυτοί θα εκτελούν διαφορετικές εργασίες ανά πάσα στιγµή, η πλατφόρµα πρέπει να µπορεί να εξυπηρετήσει τις ενέργειες που απαιτούνται από όλους τους χρήστες σε εύλογο χρονικό διάστηµα.