Οντολογία για τη διαχείριση έργων λογισμικού Πτυχιακή εργασία Βασιλειάδου Ιωάννα

Μέγεθος: px
Εμφάνιση ξεκινά από τη σελίδα:

Download "Οντολογία για τη διαχείριση έργων λογισμικού Πτυχιακή εργασία Βασιλειάδου Ιωάννα"

Transcript

1 Αριστοτέλειο Πανεπιστήμιο Θεσσαλονίκης Πρόγραμμα Μεταπτυχιακών Σπουδών «Πληροφορική και Διοίκηση» Οντολογία για τη διαχείριση έργων λογισμικού Πτυχιακή εργασία Βασιλειάδου Ιωάννα 07 Επιβλέποντες: Φιτσιλής Π. Μπουτσούκη Χ.

2 Περίληψη Η παρούσα πτυχιακή εργασία μελετάει τα πεδία της διαχείρισης έργων, της διαχείρισης έργων λογισμικού και το πεδίο των οντολογιών με τελικό στόχο τη δημιουργία μιας οντολογίας για το πεδίο της διαχείρισης έργων λογισμικού. Ο στόχος λοιπόν είναι διπλός. Αρχικά παρατίθεται μια βιβλιογραφική ανασκόπηση των ανωτέρω πεδίων και ακολουθεί η πρακτική εφαρμογή, που είναι η δημιουργία της οντολογίας. Η πτυχιακή εργασία τελειώνει με τα συμπεράσματα της παραπάνω μελέτης. Όσον αφορά τη βιβλιογραφική ανασκόπηση, η μελέτη των πεδίων γίνεται με στόχο την αναφορά στοιχείων που θα βοηθήσουν στην ανάπτυξη της οντολογίας. Δεν πρόκειται λοιπόν για μια γενική μελέτη του κάθε πεδίου. Για παράδειγμα, επειδή στην οντολογία, για το πεδίο της διαχείρισης έργων θα χρησιμοποιηθεί και η βάση γνώσης PMBOK, στην βιβλιογραφική ανασκόπηση γίνεται μια προσπάθεια να δοθούν, με όσον το δυνατόν πιο συνοπτικό τρόπο, όλοι οι βασικοί όροι που εμφανίζονται στη συγκεκριμένη βάση γνώσης. Όσον αφορά τη δημιουργία της οντολογίας της διαχείρισης έργων λογισμικού, έγινε μια προσπάθεια να ενωθούν τα πεδία της διαχείρισης έργων και της τεχνολογίας λογισμικού. Η οντολογία στηρίχθηκε σε διεθνώς αναγνωρισμένες βάσεις γνώσης όπως είναι η PMBOK και άλλες, ενώ τεκμηριώθηκε με βάση παλαιότερες προσπάθειες για τη δημιουργία οντολογιών, οι οποίες αναφέρονται στην ενότητα «Οντολογίες, Διαχείριση Έργων Λογισμικού & Τεχνολογία Λογισμικού». Επιπρόσθετα, στόχος της οντολογίας δεν είναι η πλήρης και αναλυτική περιγραφή όλων των όρων που υπάρχουν στο συγκεκριμένο πεδίο, το οποίο θα απαιτούσε εκατοντάδες ή και χιλιάδες όρους. Αντίθετα, στόχος είναι η καταγραφή των πλέον βασικών όρων και οι σχέσεις μεταξύ τους. Η ανάπτυξη οντολογιών για την αναπαράσταση και τη μελέτη πεδίων παρουσιάζει ιδιαίτερο ενδιαφέρον και αποτελεί θέμα έρευνας για πολλούς ερευνητές. Οι οντολογίες μπορούν να παίξουν ένα σημαντικό ρόλο στον τομέα της διαχείρισης έργων λογισμικού, όπως και σε άλλες επιστήμες, καθώς παρέχουν μια πηγή καθορισμένων όρων, προσφέρουν μια κοινή κατανόηση του πεδίου και αποδίδουν σαφώς όλα τα κρυμμένα νοήματα όσον αφορά όλα τα αντικείμενα που περιλαμβάνονται στο συγκεκριμένο πεδίο γνώσης. 1

3 Περιεχόμενα Περίληψη... 1 Περιεχόμενα... 1 Λίστα Γραφημάτων... 1 Λίστα Πινάκων... 1 Βιβλιογραφική Ανασκόπηση... 1 Εισαγωγή...1 Διαχείριση Έργων...1 Εισαγωγή...1 Ορισμός του Έργου...1 Ορισμός της Διαχείρισης Έργου...1 Συμμέτοχοι στο έργο...1 Το περιβάλλον διαχείρισης έργου και οι οργανωσιακές επιδράσεις...1 Δομές Οργάνωσης σε ένα έργο...1 Ο κύκλος ζωής του έργου...1 Διαδικασίες Διαχείρισης Έργων σε συνδυασμό με τις Γνωστικές Περιοχές (PMI)...1 Βασικά Παραδοτέα και Τεχνικές...1 Διαδικασίες εκτίμησης του έργου (estimating)...1 Έλεγχος του Έργου...1 Διαχείριση Έργων Πληροφορικής (Software Project Management)...1 Εισαγωγή...1 Τα τέσσερα P (Product-People-Project-Process)...1 Το προϊόν Λογισμικό (Product)...1 Κατηγορίες Λογισμικού...1 Ιδιότητες Ποιοτικού Λογισμικού...1 Οι Άνθρωποι (People)...1 Οι συμμέτοχοι Stakeholders...1 Ρόλοι των μελών μιας ομάδας λογισμικού...1 Δομές Οργάνωσης και Οργάνωση Ομάδων Προγραμματισμού....1 Το έργο (Project)...1 Στόχοι της Αποτελεσματικής Διοίκησης...1 Η διεργασία (process)...1 Η σημασία της έννοιας διεργασία...1 Μοντέλα Κύκλου Ζωής...1 Το Γραμμικό Μοντέλο...1 Η Code-and-Fix Προσέγγιση...1 Το μοντέλο V...1 Το μοντέλο πρωτυποποίησης...1 Αυξητική και επαναληπτική ανάπτυξη...1 Το σπειροειδές μοντέλο...1 Ενοποιημένη Προσέγγιση (Unified Process)...1 Ευέλικτες Προσεγγίσεις (Agile Approaches)...1 Xp programming...1 Scrum...1 2

4 Βοηθητικές Διαδικασίες (Umbrella Processes)...1 Διοίκηση Ποιότητας (Quality Management)...1 Διαχείριση Κινδύνων (Risk Management)...1 Μέτρα για τις Διαδικασίες και τα Έργα...1 Σχεδιασμός του Έργου Λογισμικού...1 Επιχειρηματικός Σχεδιασμός (Business Planning)...1 Τεχνικός Σχεδιασμός...1 Οντολογία (Ontology)...1 Ορισμοί...1 Γιατί κάποιος να αναπτύξει μια οντολογία;...1 Τα βασικά συστατικά μιας Οντολογίας...1 Κατηγορίες Οντολογιών...1 Μερικές Εφαρμογές των Οντολογιών...1 Οντολογίες, Διαχείριση Έργων Λογισμικού & Τεχνολογία Λογισμικού...1 Οντολογία για τη διαχείριση έργων λογισμικού... 1 Εισαγωγή...1 Στόχος...1 PMBOK...1 Δημιουργία της οντολογίας...1 Περιγραφή της οντολογίας...1 Συμπεράσματα... 1 Βιβλιογραφία

5 Λίστα Γραφημάτων Εικόνα 1: Κύκλος ζωής του έργου...1 Εικόνα 2: Διαδικασίες Διαχείρισης Έργων...1 Εικόνα 3: Περιγραφή της γνωστικής περιοχής διαχείριση ενοποίησης έργου...1 Εικόνα 4: Παράδειγμα διαγράμματος δικτύου...1 Εικόνα 5: Γραμμικό χρονοδιάγραμμα (ή διάγραμμα Gantt)...1 Εικόνα 6: Αναπαράσταση των ειδών διοίκησης...1 Εικόνα 7: Το μοντέλο καταρράκτη για τη διαδικασία παραγωγής λογισμικού...1 Εικόνα 8: Το μοντέλο V...1 Εικόνα 9: Το σπειροειδές μοντέλο...1 Εικόνα 10: Ο κύκλος ζωής της ενοποιήμενης προσέγγισης και τα ορόσημα κάθε φάσης....1 Εικόνα 11: Ο συνδυασμός των φάσεων και των ροών εργασιών στην UP...1 Εικόνα 12: Το μοντέλο "XP Programming"...1 Εικόνα 13: Παράγοντες ποιότητας λογισμικού του McCall...1 Εικόνα 14: Παράγοντες που επηρεάζουν την ποιότητα λογισμικού....1 Εικόνα 15: Οντολογία για την τεχνολογία λογισμικού...1 Εικόνα 16: Η περιοχή γνώση ποιότητα λογισμικού...1 Εικόνα 17: Οντολογία για τη διαδικασία λογισμικού...1 Εικόνα 18: Οντολογία για το μοντέλο CMMI...1 Εικόνα 19: Παράδειγμα Επαγγελματικής Οντολογίας (business ontology)...1 Εικόνα 20: Παράδειγμα για την οντολογία της τεχνολογίας λογισμικού...1 Εικόνα 21: Παράδειγμα για την οντολογία της διαχείρισης έργων...1 Εικόνα 22: Οντολογίες θεμάτων (issues) και λύσης σε έργα της τεχνολογίας της πληροφορίας...1 Εικόνα 23: Αρχιτεκτονική του συστήματος...1 Εικόνα 24: Τμήμα της οντολογίας Τεχνολογία Λογισμικού...1 Εικόνα 25: Το περιβάλλον της οντολογίας...1 Εικόνα 26: Η έννοια του έργου...1 Εικόνα 27: Οι γνωστικές περιοχές...1 Εικόνα 28: Οι γνωστικές περιοχές συνδέονται με τις δραστηριότητες μέσω της σχέσης "hasactivities"...1 Εικόνα 29: Οι γνωστικές περιοχές, οι δραστηριότητες, οι είσοδοι, έξοδοι και τα εργαλεία...1 Εικόνα 30: Οι συμμέτοχοι του έργου...1 Εικόνα 31: Ο φορέας υλοποίησης...1 Εικόνα 32: Οι έννοιες ομάδα, ομάδα λογισμικού, ομάδα διοίκησης, μέλη της ομάδας λογισμικού...1 Εικόνα 33: Οι έννοιες προϊόν και λογισμικό...1 Εικόνα 34: Οι έννοιες κύκλος ζωής, φάση, διαδικασία, μοντέλα κύκλου ζωής, προϊόν, πόροι, παραδοτέα, δραστηριότητες και συμμέτοχοι...1 Εικόνα 37: Το μοντέλο της ενοποιημένης προσέγγισης...1 Εικόνα 38: Xp Programming...1 Εικόνα 39: H έννοια της ποιότητας...1 Εικόνα 40: Η έννοια του κινδύνου...1 Εικόνα 41: Η έννοια των πόρων...1 Εικόνα 42: Η έννοια των περιορισμών...1 4

6 Εικόνα 43: Οι παράγοντες που επηρεάζουν το έργο...1 Εικόνα 46: Η έννοια του κόστους...1 Εικόνα 47: Οι μετρικές που χρησιμοποιούνται στην παραγωγή λογισμικού...1 Λίστα Πινάκων Πίνακας 1: Κύκλος ζωής του έργου...1 Πίνακας 2: Οι διαδικασίες στην PMBOK...1 Πίνακας

7 Βιβλιογραφική Ανασκόπηση Εισαγωγή Η βιβλιογραφική ανασκόπηση αποτελείται από τέσσερις ενότητες. Στην πρώτη ενότητα παρουσιάζεται η διαχείριση έργων, με έμφαση, όπως έχει ήδη αναφερθεί, στη βάση γνώσης PMBOK. Αναφέρονται έννοιες, όπως έργο, διαχείριση έργων, συμμέτοχοι στο έργο, το περιβάλλον του έργου, οι βασικές διαδικασίες και οι δραστηριότητες της διαχείρισης έργων. Στη δεύτερη ενότητα παρουσιάζεται η διαχείριση έργων λογισμικού. Σε αυτήν την ενότητα, συμπληρώνεται η διαχείριση έργων και δίνονται στοιχεία από την πλευρά του λογισμικού. Στην τρίτη ενότητα αναφέρονται οι οντολογίες, με βασικά θέματα τον ορισμό της οντολογίας, τη χρησιμότητά της και τα βασικά συστατικά της. Τέλος, στην τέταρτη και τελευταία ενότητα της βιβλιογραφικής επισκόπησης, παρουσιάζεται ένα σύνολο από έρευνες που έγιναν με στόχο την μελέτη της αναπαράστασης της γνώσης με τη χρήση οντολογιών σε διάφορα πεδία και κυρίως στην τεχνολογία λογισμικού. Αυτή η ενότητα δείχνει τον τρόπο που χρησιμοποιούνται οι οντολογίες για την αναπαράσταση πεδίων. Οι ερευνητές χρησιμοποιούν γνώση που είναι ευρέως αποδεκτή, όπως για παράδειγμα τη γνώση που βρίσκεται σε βάσεις γνώσης (body of knowledge) που εκδίδονται από αναγνωρισμένους οργανισμούς. Τέλος, παρουσιάζεται ο τρόπος που χρησιμοποιούν τις έννοιες και τις σχέσεις μεταξύ τους. Όλα αυτά λαμβάνονται υπόψη για την ανάπτυξη της τελικής οντολογίας. 6

8 Διαχείριση Έργων Εισαγωγή Η διαχείριση έργων αποτελεί οργανωμένη προσέγγιση με βάση την οποία μπορεί κανείς να χειριστεί τη διαδικασία εκτέλεσης και ολοκλήρωσης διαφόρων τύπων έργων. Καθώς το μέγεθος και η πολυπλοκότητα των έργων αυξάνεται σταδιακά, η ικανότητα σχεδιασμού και ελέγχου αποκτά ολοένα και κρισιμότερη σημασία για τη διαχείρισή τους. Ορισμός του Έργου Το εγχειρίδιο που εξέδωσε το ινστιτούτο διαχείρισης έργων (project management institute, PMI) (PMBOK, 2004) ορίζει ως έργο (project) ένα προσωρινό εγχείρημα που στοχεύει στη δημιουργία ενός μοναδικού προϊόντος ή υπηρεσίας. «Προσωρινό σημαίνει ότι κάθε έργο έχει καθορισμένη αρχή και τέλος. Μοναδικό σημαίνει ότι το παραγόμενο αποτέλεσμα, προϊόν ή υπηρεσία διαφέρει κατά διακριτό τρόπο από όλα τα υπόλοιπα παρόμοια προϊόντα ή υπηρεσίες.» Τα έργα ποικίλουν ως προς το μέγεθος, το αντικείμενο εργασιών, το κόστος και τον απαιτούμενο χρόνο ολοκλήρωσης, και μπορεί να είναι από υπερμεγέθη διεθνή έργα που κοστίζουν εκατομμύρια ευρώ και διαρκούν πολλά χρόνια, έως μικρά, τοπικά έργα με μικρό προϋπολογισμό που απαιτούν μόνο μερικές ημέρες εργασίας. Παραδείγματα έργων είναι τα εξής: η υλοποίηση ενός νέου πληροφοριακού συστήματος ο σχεδιασμός και η κατασκευή ενός κτηρίου Τα κυριότερα προβλήματα που εμφανίζονται κατά την πορεία ενός έργου μπορούν να συνοψιστούν στα εξής: (Δημητριάδης, 1999) υπέρβαση κόστους υπέρβαση χρόνου εργασιακά προβλήματα η ασάφεια στόχων και αντικειμενικών σκοπών οι ανεπαρκείς οικονομικές προβλέψεις η ανεπαρκής πληροφόρηση η ελλιπής οργανωτική υποδομή η άκριτη συμπίεση του χρόνου στα έργα η έλλειψη τυποποίησης 7

9 Ορισμός της Διαχείρισης Έργου Η Διαχείριση έργων ορίζεται από την (PMBOK, 2004) ως: τη διαδικασία κατά την οποία εφαρμόζουμε γνώσεις, δεξιότητες, εργαλεία και τεχνικές κατά την εκτέλεση των δραστηριοτήτων του έργου έτσι ώστε να ικανοποιηθούν οι απαιτήσεις και οι προσδοκίες των συμμετεχόντων. Μέσω αυτού του ορισμού είναι σαφές ότι ο σκοπός ενός έργου είναι να ικανοποιήσει τις απαιτήσεις και τις προσδοκίες των συμμετεχόντων. Γι αυτό λοιπόν είναι θεμελιώδες προαπαιτούμενο για τον διευθυντή του έργου να καθορίσει ποιοι είναι οι συμμέτοχοι (εκτός από τον πελάτη), να αναλύσει τις ανάγκες τους και τις προσδοκίες τους και εν τέλει το σκοπό του έργου. Ο τομέας της διοίκησης έργων μπορεί να περιγραφεί σε εννέα γνωστικές περιοχές: (PMBOK, 2004) Ενοποίηση του έργου (project integration management): Ενοποιεί τις τρεις βασικές διαδικασίες της διαχείρισης έργου: τον προγραμματισμό, την εκτέλεση και τον έλεγχο, συγκεντρώνοντας γνώσεις από πολλές γνωστικές περιοχές. Διαχείριση του αντικειμένου εργασιών (project scope management): Είναι η διαδικασία που διασφαλίζει ότι στο έργο θα συμπεριληφθούν όλες οι αναγκαίες εργασίες και μόνον αυτές- που απαιτούνται για να ολοκληρωθεί το έργο με επιτυχία. Η διαχείριση του αντικειμένου εργασιών περιλαμβάνει τα εξής ζητήματα: ανάθεση αρμοδιοτήτων, σχεδιασμό του αντικειμένου εργασιών, διαχείριση αλλαγών του αντικειμένου εργασιών και επαλήθευση του αντικειμένου εργασιών. Διαχείριση χρόνου (project time management): Είναι η διαδικασία που διασφαλίζει ότι το έργο θα εκτελεστεί έγκαιρα. Αναφέρεται στα εξής ζητήματα: ορισμό δραστηριοτήτων, καθορισμό της αλληλουχίας των δραστηριοτήτων, εκτίμηση της διάρκειας, οριστικοποίηση των εργάσιμων ημερών, ανάπτυξη χρονοδιαγράμματος και ελέγχου του χρόνου. Διαχείριση κόστους (project cost management): Είναι η διαδικασία που διασφαλίζει ότι το έργο θα ολοκληρωθεί στα πλαίσια του προϋπολογισμού. Αναφέρεται στον προγραμματισμό πόρων, την εκτίμηση κόστους, τον προϋπολογισμό κόστους και τον έλεγχο χρηματικών ροών και κόστους. Διαχείριση ποιότητας (project quality management): Είναι η διαδικασία που διασφαλίζει ότι τα παραδοτέα του έργου ικανοποιούν τις ποιοτικές ανάγκες. Αναφέρεται στα εξής ζητήματα: προσδιορισμό των απαιτούμενων συνθηκών, σχεδιασμό ποιότητας, διασφάλιση ποιότητας και έλεγχο ποιότητας. 8

10 Διοίκηση Ανθρωπίνων Πόρων (project human resource management): Είναι η διαδικασία που διασφαλίζει τη βέλτιστη λειτουργία των ατόμων που εμπλέκονται στο έργο. Περιλαμβάνει ζητήματα όπως: σχεδιασμό της οργανωτικής δομής, πρόσληψη προσωπικού και στελέχωση ομάδων. Διαχείριση επικοινωνίας (project communication management): Είναι η διαδικασία που οργανώνει τη συλλογή και διάχυση των αναγκαίων πληροφοριών σχετικά με το έργο. Αναφέρεται στα εξής ζητήματα: σχεδιασμό επικοινωνίας, κατανομή πληροφοριών, συναντήσεις, σύνταξη εκθέσεων προόδου και έκθεση ολοκλήρωσης. Διαχείριση κινδύνου (project risk management): Είναι η διαδικασία κατά την οποία προσδιορίζεται και αναλύεται ο κίνδυνος που ενέχει το έργο καθώς και ο τρόπος απόκρισης σε αυτόν. Αναφέρεται στα εξής ζητήματα: προσδιορισμό του κινδύνου (risk identification), ποσοτικοποίηση του κινδύνου και των επιπτώσεών του, ανάπτυξη τρόπων ανταπόκρισης και ελέγχου του κινδύνου. Διαχείριση προμηθειών αγορών (project procurement management): Είναι η διαδικασία με την οποία εξασφαλίζεται η προμήθεια αγαθών και υπηρεσιών από πηγές που βρίσκονται εκτός της ομάδας εκτέλεσης του έργου ή και εκτός της ίδιας της εταιρίας. Αναφέρεται στα εξής ζητήματα: προγραμματισμό προμηθειών-αγορών, σχεδιασμό της διαδικασίας συλλογής, παραλαβής προσφορών, επιλογή προμηθευτών, διαχείριση συμβάσεων και ολοκλήρωση λύση συμβάσεων. Ο κορμός γνώσεων υποδιαιρείται δηλαδή σε: 4 βασικές γνωστικές περιοχές αντιστοιχούν σε συγκεκριμένους στόχους του έργου (αντικείμενο, χρόνος, κόστος και ποιότητα) 4 υποστηρικτικές γνωστικές περιοχές αποτελούν το μέσο με το οποίο επιτυγχάνονται οι στόχοι (διαχείριση ανθρώπινων πόρων, επικοινωνίας, κινδύνων, υπεργολαβιών) 1 γνωστική περιοχή (διαχείριση ολοκλήρωσης έργου) επηρεάζει και επηρεάζεται από όλες τις άλλες γνωστικές περιοχές Το APMBOK (Association for Project Management, 2000) ορίζει τη διαχείριση έργων σαν τον πιο αποτελεσματικό τρόπο για την εισαγωγή της αλλαγής που επιτυγχάνεται μέσω: του καθορισμού των στόχων που αφορούν τον χρόνο, το κόστος και παραμέτρους απόδοσης διαφόρων τεχνικών και ποιοτικών χαρακτηριστικών. 9

11 της ανάπτυξης ενός πλάνου για την επίτευξη των στόχων του έργου καθώς και την παρακολούθηση του έργου ώστε να διασφαλίσουμε ότι η πρόοδος του έργου είναι με τους αρχικούς στόχους. της χρησιμοποίησης των κατάλληλων τεχνικών και εργαλείων για το σχεδιασμό, τον έλεγχο και τη διατήρηση του ρυθμού προόδου. της εργασίας προσωπικού κατάλληλα καταρτισμένου στη διαχείριση έργων. Συμμέτοχοι στο έργο Οι συμμέτοχοι στο έργο θεωρούνται εταιρείες ή άτομα τα οποία έχουν λόγο να αναμιχθούν στο έργο. Οι συμμέτοχοι μπορεί να είναι οργανώσεις ή άτομα τα οποία είτε εμπλέκονται ενεργά στο έργο είτε έχουν συμφέροντα που επηρεάζονται από το έργο και τον τρόπο που αυτό υλοποιείται. Είναι στην ευθύνη του υπευθύνου έργου να συγκεράσει όλες τις απαιτήσεις και ανάγκες των εμπλεκομένων, με προτεραιότητα φυσικά τις απαιτήσεις του πελάτη αλλά και τις επιταγές της κεντρικής διοίκησης της εταιρείας του ώστε να πετύχει τα καλύτερα δυνατά αποτελέσματα. Οι κύριοι συμμέτοχοι σε κάθε έργο συμπεριλαμβάνουν: (PMBOK, 2004) Τον διευθυντή του έργου: Το άτομο που είναι υπεύθυνο για τη διοίκηση του έργου. Τον πελάτη/χρήστη: Το άτομο ή ο οργανισμό που θα χρησιμοποιήσει το προϊόν του έργου. Το φορέα υλοποίησης: Η επιχείρηση της οποίας οι εργαζόμενοι εμπλέκονται αμεσότερα με την εκτέλεση της εργασίας του έργου. Τα μέλη της ομάδας έργου: Το σύνολο των ατόμων που εκτελεί τις εργασίες του έργου. Η ομάδα διοίκησης του έργου: Τα μέλη της ομάδας έργου που εμπλέκονται άμεσα στις δραστηριότητες διοίκησης του έργου. Το χορηγό: Το άτομο ή η ομάδα που παρέχει τους οικονομικούς πόρους, σε μετρητά ή σε είδος, για το έργο. Οι επηρεαστές (influencers): Τα άτομα ή οι ομάδες που δεν σχετίζονται άμεσα με την απόκτηση ή τη χρήση του προϊόντος του έργου, αλλά λόγω της θέσης κάποιου ατόμου στον οργανισμό το πελάτη ή του φορέα υλοποίησης, μπορούν να επηρεάσουν, θετικά ή αρνητικά την πορεία του έργου. Το γραφείο διοίκησης έργου (PMO): 10

12 Πέραν των ανωτέρω κύριων συμμετόχων, υπάρχουν πολλά διαφορετικά ονόματα και κατηγορίες των συμμετόχων του έργου, μεταξύ των οποίων εσωτερικοί και εξωτερικοί, ιδιοκτήτες και επενδυτές, προμηθευτές και εργολάβοι, μέλη της ομάδας και οι οικογένειές τους, κυβερνητικοί οργανισμοί και μέσα ενημέρωσης και η ευρύτερη κοινωνία. Το περιβάλλον διαχείρισης έργου και οι οργανωσιακές επιδράσεις Τα έργα δεν εκτελούνται στο κενό, αλλά επηρεάζονται από πολλούς εξωγενείς παράγοντες αλλά και παράγοντες που προέρχονται από τον ίδιο τον οργανισμό που εκτελεί το έργο. Παραδείγματος χάριν, το περιβάλλον του έργου μπορεί να επηρεαστεί από τα παρακάτω: (Burke, 2002) τις ομάδες συμμέτοχους (όλα τα ενδιαφερόμενα μέρη) τις απαιτήσεις πελατών/χορηγών την οργανωτική του οργανισμού οργανωτικές αντιλήψεις του οργανισμού και το ύφος: Οι περισσότεροι οργανισμοί έχουν αναπτύξει μοναδικές και περιγράψιμες αντιλήψεις. συστήματα οργάνωσης του οργανισμού τις απαιτήσεις της αγοράς τους ανταγωνιστές τις νέες τεχνολογίες νόμους και κανονισμούς το πολιτισμικό και κοινωνικό περιβάλλον το διεθνές και πολιτικό περιβάλλον το φυσικό περιβάλλον Δομές Οργάνωσης σε ένα έργο Η ανάπτυξη ενός έργου θέτει σε κίνηση έναν αριθμό ατόμων τα οποία θα πρέπει να ενεργούν συντονισμένα στη βάση ενός συγκεκριμένου σχεδίου δράσης. Το πρόβλημα της οργάνωσης του έργου απαιτεί τη δημιουργία ενός μηχανισμού του οποίου το μέγεθος και η πολυπλοκότητα ποικίλουν ανάλογα με το μέγεθος και τη φύση του έργου αλλά και την οργανωτική αντίληψη της διοίκησης. (Δημητριάδης, 1999) Η κλασική λειτουργική οργάνωση (functional organization) είναι μια ιεραρχία. Το προσωπικό κατηγοριοποιείται κατά ειδικότητες, όπως παραγωγή, 11

13 μάρκετινγκ, μηχανικοί και λογιστήριο στο ανώτερο επίπεδο. Ο συντονισμός του έργου πραγματοποιείται μεταξύ των προϊσταμένων αυτών των ειδικοτήτων. Το αποτέλεσμα αυτής της οργάνωσης είναι η σημαντική ειδίκευση που αποκτάται στον κάθε τομέα, πλην όμως αναφύονται πολλά προβλήματα και κυρίως στη φάση της συνεργασίας των ομάδων διαφόρων ειδικοτήτων. Στο άλλο άκρο του φάσματος βρίσκεται η οργάνωση κατά έργα (projected organizations), η οποία παρουσιάζει το χαρακτηριστικό, το προσωπικό της εταιρείας να είναι κατανεμημένο σε τμήματα ανά έργο. Κάθε τμήμα παρουσιάζεται σαν μια μικρογραφία της εταιρείας, με αντίστοιχους οργανωτικούς μηχανισμούς. Κατ αυτήν έχουμε ομάδες αποτελούμενες από εργαζόμενους διαφόρων ειδικοτήτων κατευθυνόμενες από τον διευθυντή του έργου. Κάθε τμήμα έχει την ευθύνη για την υλοποίηση ενός έργου και όταν το παραδίδει αναλαμβάνει κάποιο άλλο. Οι οργανισμοί τύπου μήτρας (matrix organizations) συνδυάζουν τα χαρακτηριστικά της οργάνωσης κατά έργα και της οργάνωσης κατά λειτουργίες. Οι ασθενείς μήτρες (weak matrices) διατηρούν πολλά χαρακτηριστικά ενός λειτουργικού οργανισμού. Ομοίως οι ισχυρές μήτρες (strong matrices) διατηρούν πολλά από τα χαρακτηριστικά ενός εγωκεντρικού οργανισμού. Η οργάνωση ισορροπημένης μήτρας, αν και αναγνωρίζει την ανάγκη του διευθυντή έργων, δεν του παρέχει πλήρη εξουσία πάνω στο έργου και τη χρηματοδότησή του. Ο κύκλος ζωής του έργου Το εγχειρίδιο (PMBOK, 2004) αναφέρει: «καθώς το έργο είναι μοναδικό και ενέχει κάποιο βαθμό κινδύνου, οι εταιρίες που αναλαμβάνουν την εκτέλεση έργων συνήθως τα υποδιαιρούν σε φάσεις για να υπάρχει καλύτερος διοικητικός έλεγχος. Συλλογικά όλες μαζί οι φάσεις αυτές συνιστούν τον κύκλο ζωής του έργου.» Έτσι λοιπόν ο κύκλος ζωής σπάει το έργο σε ένα σύνολο φάσεων. Το τέλος κάθε φάσης αποτελεί σημείο ελέγχου των μέχρι τώρα πεπραχθέντων. Η διοίκηση παίρνει σημαντικές αποφάσεις και προγραμματίζει με περισσότερα λεπτομέρεια τις φάσεις που ακολουθούν. Η πλειοψηφία των έργων αποτελείται από τρεις με πέντε φάσεις. (Tinnirello, 2001) Κατά γενική ομολογία, για τα περισσότερα έργα, ο κύκλος ζωής αποτελείται από 4 φάσεις, οι οποίες αναπαρίστανται στην Εικόνα 1 και αναλυτικότερα στον Πίνακα1. 12

14 Εικόνα 1: Κύκλος ζωής του έργου Αρχική Φάση: Αναγνώριση αναγκών/ερεθισμάτων του περιβάλλοντος ή πιθανών προβλημάτων της παρούσας κατάστασης Σύλληψη της ιδέας και των στόχων του έργου Εξέταση της ιδέας και των στόχων του έργου στα πλαίσια της στρατηγικής του οργανισμού Ανάλυση της πιθανής συσχέτισης του έργου με τα εκτελεσθέντα ή τρέχοντα έργα Αρχικός προσεγγιστικός καθορισμός τεχνικής και οικονομικής σκοπιμότητας του έργου Απόφαση για υλοποίηση έργου Επιλογή διαχειριστή & ομάδας έργου Σχεδιασμός: Καθορισμός των απαιτήσεων απόδοσης του έργου Αναλυτική περιγραφή και προσδιορισμός των παραδοτέων του έργου Ανάλυση σε υποέργα, καθορισμός των διεπαφών (interfaces) μεταξύ των υποέργων, καθώς και των επιδράσεων του εξωτερικού περιβάλλοντος Χρονικός προγραμματισμός του έργου Προσδιορισμός των πόρων που απαιτούνται για υποστηρικτικές λειτουργίες Καθορισμός απαιτήσεων κόστους Αρχικός προσδιορισμός των περιοχών κινδύνου για τις επόμενες φάσεις Προετοιμασία τελικών σχεδίων προγραμματισμού της υλοποίηση του έργου 13

15 Καθορισμός πολιτικών, διαδικασιών, κλπ. για τις επόμενες φάσεις Εκτέλεση: Επαλήθευση της ικανοποίησης των προκαθορισμένων προδιαγραφών (specifications) από το έργο Διαχείριση/ συντονισμός των πόρων για την υλοποίηση του έργου Παραγωγή παραδοτέων έργου Πραγματοποίηση δοκιμών και ελέγχων ικανοποίησης των προδιαγραφών επίδοσης του έργου Ανάπτυξη τεχνικών εγχειριδίων τεκμηρίωσης του έργου Ολοκλήρωση του έργου σε υπάρχουσες ή καινούργιες οργανωτικές δομές Χρήση/Λειτουργία του έργου Κλείσιμο: Αξιολόγηση της τεχνικής, οικονομικής και κοινωνικής απόδοσης του έργου σε συνθήκες πραγματικής λειτουργίας Εξαγωγή συμπερασμάτων στην ομάδα του έργου σχετικά με λάθη, προβλήματα, παραλείψεις, επεκτάσεις του συστήματος Ανάλυση προβλημάτων και των τρόπων με τους οποίους αντιμετωπίστηκαν Συστάσεις για ανάπτυξη και τη διαχείριση μελλοντικών έργων Σύλληψη Σχεδιασμός Υλοποίηση Κλείσιμο Δεδομένα εισόδου Δεδομένα εισόδου Δεδομένα εισόδου Δεδομένα εισόδου Πρόβλημα ή ευκαιρία, εντολή έργου, καταστατικό έργου Έγκριση για συνέχιση και σχεδιασμό το προϊόντος Έγκριση για υλοποίηση του έργου Σχέδιο θέσης σε λειτουργία, κοινοποίηση της ολοκλήρωσης του έργου. Ακολουθούμενη Ακολουθούμενη Ακολουθούμενη Ακολουθούμενη διαδικασία Πρόταση έργου, μελέτη σκοπιμότητας, προσδιορισμός συμμετόχων, ανάλυση κόστους ωφέλειας Παραγόμενο παραδοτέο Μελέτη σκοπιμότητας διαδικασία Σχεδιασμός προϊόντος, ανάπτυξη λεπτομερών προγραμμάτων, WBS, CPM, και κατάρτιση προϋπολογισμού Παραγόμενο παραδοτέο Βασικό πλάνο διαδικασία Ανάθεση συμβάσεων και έκδοση οδηγιών, αγορά εξοπλισμού και υπηρεσιών, κατασκευή προϊόντος ή επίλυση προβλήματος, έναρξη λειτουργίας και έλεγχος του προϊόντος Παραγόμενο παραδοτέο Πιστοποίηση ολοκλήρωσης διαδικασία Δημιουργία τελικών σχεδίων που απεικονίζουν το πως κατασκευάστηκε» και σύνταξη εγχειριδίων λειτουργίας. Παραγόμενο παραδοτέο Έκθεση ολοκλήρωσης του έργου 14

16 Έγκριση Έγκριση Έγκριση Έγκριση Απόφαση ναι ή όχι σχετικά με το αν θα προχωρήσει το έργο στη φάση σχεδιασμού Το έργο να εφαρμοστεί Να γίνει η προετοιμασία για να τεθεί σε λειτουργία Το έργο γίνεται αποδεκτό από τον πελάτη Πίνακας 1: Κύκλος ζωής του έργου Τα παραδοτέα (deliverables) είναι απτά και κατάλληλα επικυρωμένα παράγωγα εργασίας όπως μια μελέτη, ένα ολοκληρωμένο σχέδιο ή ένα πρωτότυπο. Όταν σχεδιάζεται ένα έργο, θα πρέπει να εγκαθίστανται μια σειρά από ορόσημα (milestones), όπου ορόσημο είναι ένα τελικό σημείο μιας φάσης της διαδικασίας ανάπτυξης. Το τέλος κάθε φάσης σηματοδοτείτε από την αξιολόγηση τόσο των παραδοτέων όσο και της απόδοσης του έργου με στόχο να καθοριστεί εάν το έργο είναι σε θέση να προχωρήσει στην επόμενη φάση να εντοπιστούν και να διορθωθούν λάθη αναφορικά με το κόστος αποτελεσματικά. Αν κατά την μετάβαση του έργου από τη μία φάση στην άλλη, αλλάξουν οι στόχοι, τότε πρέπει να υποστεί αλλαγές και το πλάνο διαχείρισης του έργου. Ο κύκλος ζωής του έργου μπορεί να υποδιαιρεθεί σε περισσότερες από τέσσερις φάσεις, μάλιστα μπορούμε να υποδιαιρέσουμε κάθε φάση σε τέσσερις υπόφάσεις. Αν είναι αναγκαίο, μπορούμε να υποδιαιρέσουμε περαιτέρω ακόμη και τις υπό-φάσεις μέχρι να φτάσουμε σε ένα επιθυμητό επίπεδο κατάτμησης. Διαδικασίες Διαχείρισης Έργων σε συνδυασμό με τις Γνωστικές Περιοχές (PMI) Το PMBOK προκειμένου να αναλύσει τον κύκλο ζωής του έργου χρησιμοποιεί τις Διαδικασίες Διαχείρισης Έργων, οι οποίες αναλύονται στη συνέχεια, σε σχέση με τις γνωστικές περιοχές που έχουν αναφερθεί παραπάνω. Με βάση λοιπόν αυτές τις διαδικασίες και τις γνωστικές περιοχές αναλύει περισσότερο τη διεργασία ανάπτυξης ενός έργου σε μικρότερες διεργασίες, οι οποίες έχουν εισόδους, υλοποιούνται με κάποιες τεχνικές και με κάποια εργαλεία και παράγουν τις αντίστοιχες εξόδους. Μια διαδικασία είναι μια σειρά από ενέργειες με σκοπό να μας οδηγήσουν σε συγκεκριμένο αποτέλεσμα. Οι διαδικασίες του έργου μπορούν να χωριστούν σε δύο κατηγορίες : Διαδικασίες προσανατολισμένες προς το αποτέλεσμα του έργου, σχετιζόμενες με τον προσδιορισμό και τη δημιουργία αποτελέσματος του έργου. 15

17 Διαδικασίες Διαχείρισης, σχετιζόμενες με την περιγραφή και οργάνωση της δουλειάς σε ένα έργο. Σκοπός των Διαδικασιών Διαχείρισης είναι η αναγνώριση, εγκαθίδρυση και συντονισμός δραστηριοτήτων και ενεργειών παρακολούθησης με την χρήση κατάλληλων πόρων προκειμένου να επιτευχθεί το προδιαγεγραμμένο αποτέλεσμα του έργου. Διαδικασίες Έναρξης (Initiating Processes): Αναγνωρίζεται ότι το έργο πρέπει να αρχίσει. Διαδικασίες Σχεδιασμού (Planning Processes): Καταρτίζεται και διαμορφώνεται το σχέδιο εργασίας για την υλοποίηση του έργου. Διαδικασίες Εκτέλεσης (Executing Processes): Συγχρονίζεται το ανθρώπινο δυναμικό ή άλλοι πόροι για να φέρουν εις πέρας το προς εκτέλεση έργο. Διαδικασίες Ελέγχου (Controlling Processes): Μετράται και παρουσιάζεται η πρόοδος της εκτέλεσης και λαμβάνονται διορθωτικά μέτρα όταν υπάρχουν αποκλίσεις. Διαδικασίες Πέρατος (Closing Processes): Συντονίζεται η αποδοχή του. Στην Εικόνα 2 αναπαρίστανται αυτές οι διαδικασίες και οι ροές πληροφοριών μεταξύ τους. Εικόνα 2: Διαδικασίες Διαχείρισης Έργων Στην τομή των Διαδικασιών και των γνωστικών περιοχών υπάρχουν περισσότερες διαδικασίες. Κάθε διαδικασία έχει την ίδια οργάνωση: 1. Είσοδοι (Inputs): Όλα αυτά που χρειάζεται να χρησιμοποιηθούν προκειμένου να ολοκληρωθεί η διαδικασία. 16

18 2. Εργαλεία και Τεχνικές (Tools and Techniques): Βοηθούν την ομάδα στην εκτέλεση του έργου. Κάποια από αυτά είναι: το διάγραμμα Gantt, το διάγραμμα δικτύου, ανάλυση του κρίσιμου μονοπατιού και γενικότερα χρονοπρογραμματισμό. Εκτίμηση του κόστους και ανάλυση πιστοοποιημένης αξίας (earned value analysis) 3. Έξοδοι (Outputs): Όλα αυτά που παράγονται από τη διαδικασία. Στον πίνακα που ακολουθεί παριστάνονται οι διαδικασίες που βρίσκονται στην τομή της αντίστοιχης Διαδικασίας και Γνωστικές Περιοχής. Ενοποίηση του έργου Διαχείριση του αντικειμένο υ εργασιών Διαχείριση χρόνου Διαδικασίες Διαδικασίες Έναρξης Σχεδιασμού Ανάπτυξη του Ανάπτυξη του Καταστατικού Σχεδίου Διοίκησης του Έργου του Έργου (Project (Project Management Plan) Charter) Ανάπτυξη μια προκαταρκτική ς Έκθεσης Αντικειμένου του Έργου (Project Scope Statement) Σχεδιασμός Αντικειμένου (Scope Planning) Ορισμός Αντικειμένου (Scope Definition) Δημιουργία ΔΑΕ - Δομής Ανάλυσης Εργασιών (Create WBS) Ορισμός Δραστηριοτήτων (Activity Definition) Ακολουθία Δραστηριοτήτων (Activity Sequencing) Εκτίμηση Πόρων Δραστηριοτήτων (Activity Resource Estimating) Εκτίμηση Διάρκειας Δραστηριοτήτων (Activity Duration Estimating) Ανάπτυξη Χρονοδιαγράμματος (Schedule Development) 17 Διαδικασίες Εκτέλεσης Διοίκηση και Διαχείρισης της Εκτέλεσης Έργου (Direct and Manage Project Execution) Διαδικασίες Ελέγχου Παρακολούθηση και Έλεγχος Εργασιών Έργου (Monitor and Control Project Work) Ολοκληρωμένος Έλεγχος Αλλαγών (Integrated Change Control) Επαλήθευση Αντικειμένου (Scope Verification) Έλεγχος Αντικειμένου (Scope control) Έλεγχος Χρονοδιαγράμματ ος (Schedule Control) Διαδικασίε ς Πέρατος Κλείσιμο έργου (Close Project)

19 Διαχείριση κόστους Διαχείριση ποιότητας Διοίκηση Ανθρωπίνω ν Πόρων Διαχείριση επικοινωνία ς Διαχείριση κινδύνου Διαχείριση προμηθειών αγορών Εκτίμηση Κόστους (Cost Estimating) Προϋπολογισμός Κόστους (Cost Budgeting) Σχεδιασμός Ποιότητας (Quality Planning) Σχεδιασμός Ανθρώπινων Πόρων (Human Resource Planning) Σχεδιασμός Επικοινωνιών (Communications Planning) Σχεδιασμός Διοίκησης Κινδύνων (Risk Management Planning) Προσδιορισμός Κινδύνων (Risk Identification) Ποιοτική Ανάλυση Κινδύων (Qualitative Risk Analysis) Ποσοτική Ανάλυση Κινδύνων (Quantitative Risk Analysis) Σχεδιασμός Απόκρισης σε Κινδύνους (Risk Response Planning) Σχεδιασμός Αγορών και Αποκτήσεων (Plan Purchases and Acquisitions) Σχεδιασμός Συμβάσεων (Plan Contracting) Έλεγχος Κόστους (Cost Control) Εκτέλεση Εκτέλεσης Διασφάλισης Ελέγχου Ποιότητας Ποιότητας (Perform Quality (Perform Quality Assurance) Control) Απόκτηση της Ομάδας Έργου Ανάπτυξη της Ομάδας Έργου (Develop Project Team ) Διανομή Πληροφοριών (Information Distribution) Αίτηση Απαντήσεων Προμηθευτών (Request Seller Responses) Επιλογή Προμηθευτών (Select Sellers) Διοίκηση Ομάδας Έργου (Manage Project Team) Αναφορά Απόδοσης (Performance Reporting) Διοίκηση Συμμετόχων (Manage Stakeholders) Παρακολούθηση και Έλεγχος Κινδύνων (Risk Monitoring and Control) Διαχείριση Συμβάσεων (Contract Administration) Περάτωση Συμβάσεων (Contract Closure) Πίνακας 2: Οι διαδικασίες στην PMBOK 18

20 Για παράδειγμα, στην Εικόνα 3 που ακολουθεί παριστάνεται η γνωστική περιοχή που ονομάζεται Ενοποίηση του Έργου. Βλέπουμε λοιπόν όλες τις διαδικασίες που περιέχει αυτή η γνωστική περιοχή και παρατηρούμε ότι κάθε διαδικασία εμπεριέχει εισόδους, εργαλεία & τεχνικές και εξόδους. Εικόνα 3: Περιγραφή της γνωστικής περιοχής διαχείριση ενοποίησης έργου 19

21 Βασικά Παραδοτέα και Τεχνικές Ο σχεδιασμός προγραμματισμός (Planning Scheduling) ενός έργου γίνεται κάτω από συνθήκες αβεβαιότητας. Αυτό σημαίνει ότι ο διοικητικός φορέας το έργου δεν έχει καθόλου (ή έχει ελάχιστες) πληροφορίες για ενδεχόμενα γεγονότα κατά την υλοποίηση του έργου. Παρακάτω δίνονται κάποια από τα πιο αντιπροσωπευτικά έγγραφα και εργαλεία που χρησιμοποιούνται κατά τον προγραμματισμό του έργου. Καταστατικό του έργου (project charter): Έγγραφο που μορφοποιεί και επισημοποιεί το έργο και στο οποίο θα πρέπει να αναφέρεται ο σκοπός του έργου. Το καταστατικό του έργου θα πρέπει να μπορεί να περιγράφει το έργο μέσα σε λίγες και απλές προτάσεις. Πλάνο διαχείρισης έργου. (Project management plan) : Ένα επίσημο, εγκεκριμένο έγγραφο (document) που ορίζει το πώς εκτελείται, παρακολουθείται και ελέγχεται το έργο. Μπορεί να είναι περιληπτικό ή λεπτομερές και να αποτελείται από ένα ή περισσότερα επικουρικά σχέδια διοίκησης και άλλα έγγραφα σχεδιασμού. Μελέτη σκοπιμότητας (feasibility study): Έγγραφο που αναπτύσσει το καταστατικό και τη συνοπτική περιγραφή του έργου σε πλήρη πρόταση έργου και στη συνέχεια σε μέθοδο υλοποίησης. Στη μελέτη σκοπιμότητας οριστικοποιούνται οι απαιτήσεις, οι περιορισμοί και τα αναμενόμενα αποτελέσματα, επίσης πραγματοποιείται μελέτη για τον προϋπολογισμό, τους κινδύνους και την τεχνική υποστήριξη. Αρχικά θα πρέπει να εντοπιστούν οι εμπλεκόμενοι στο έργο και στη συνέχεια ο διευθυντής του έργου θα πρέπει να προσδιορίσει ποιες είναι οι ανάγκες και οι προσδοκίες τους. Επόμενο βήμα του διευθυντή έργου είναι να διαχειριστεί, να επηρεάσει και να εξισορροπήσει αυτές τις ανάγκες. Σημαντικός επίσης είναι και ο καθορισμός των αναγκών του πελάτη. Η πρόκληση στην οποία καλείται να ανταποκριθεί ο διευθυντής έργου είναι να μεταβάλει την ανάγκη του πελάτη από κάτι αρκετά αόριστο σε κάτι συγκεκριμένο. Πολλές φορές κάποιες από τις συνθήκες που θέτει ο πελάτης είναι αμοιβαία αποκλειόμενες που σημαίνει ότι θα πρέπει να εξεταστούν συμβιβασμοί. Ένα σημαντικό κομμάτι της μελέτης σκοπιμότητας είναι και ο έλεγχος βιωσιμότητας του έργου. Το ερώτημα που τίθεται εδώ είναι: θα μπορεί το προϊόν τεχνικά και εμπορικά να ικανοποιήσει τις απαιτήσεις της αγοράς: Ένα άλλο κρίσιμο σημείο είναι η αξιολόγηση των περιορισμών. Οι περιορισμοί μπορούν να ενταχθούν σε τρεις κατηγορίες: περιορισμοί εσωτερικοί προς το έργο, περιορισμοί εσωτερικοί ως προς την εταιρία, εξωτερικοί περιορισμοί. 20

22 Έκθεση Αντικειμένου του έργου (Project Scope Statement): Προσδιορίζει τι περιλαμβάνει και ακόμη σημαντικότερο, τι δεν περιλαμβάνεται στο έργο ώστε να καλυφθούν οι αντικειμενικοί στόχοι που έχουν τεθεί ρητώς. Το εγχειρίδιο PMBOK ορίζει τον προγραμματισμό του αντικειμένου εργασιών ως: «τη διαδικασία ενός γραπτού κειμένου που να περιγράφει το αντικείμενο των εργασιών ως βάση λήψης μελλοντικών αποφάσεων. Ειδικότερο το έγγραφο αυτό θα πρέπει να περιλαμβάνει τα κριτήρια με βάση τα οποία θα αποφασίζεται αν έχει ολοκληρωθεί με επιτυχία η κάθε φάση ξεχωριστά καθώς και ολόκληρο το έργο.» Το εγχειρίδιο PMBOK ως ορισμό του αντικειμένου εργασιών δίνει «τη διαδικασία υποδιαίρεσης των βασικών προϊόντων του έργου σε μικρότερες συνιστώσες, τις οποίες μπορούμε να χειριστούμε ευκολότερα.» Όσον αφορά την επαλήθευση του αντικειμένου εργασιών, ορίζεται από το PMBOK ως «. Τη διαδικασία κατά την οποία επισημοποιείται η αποδοχή του αντικειμένου εργασιών από τους συμμετόχους.». Ενώ ο έλεγχος αλλαγών του αντικειμένου εργασιών ορίζεται «ως η διαδικασία εκείνη κατά την οποία επιχειρούμε α) να επηρεάσουμε τους παράγοντες εκείνους που προκαλούν αλλαγές στο αντικείμενο εργασιών, ώστε να εξασφαλίσουμε ότι οι ενδεχόμενες αλλαγές είναι επωφελείς για το έργο. β) να εντοπίσουμε πότε συμβαίνουν αλλαγές στο αντικείμενο εργασιών. γ) να διαχειριστούμε τις οποιεσδήποτε αλλαγές όταν και αν προκύψουν. Δομική ανάλυση του έργου (WBS, Work Breakdown Structure): Ο ρόλος της είναι να υποδιαιρεί το αντικείμενο εργασιών σε πακέτα εργασιών τα οποία μπορούμε να χειριστούμε, να εκτιμήσουμε και να προγραμματίσουμε και για την ολοκλήρωση των οποίων μπορούμε να αναθέσουμε την ευθύνη σε συγκεκριμένα άτομα ή τμήματα. Μέθοδος κρίσιμης διαδρομής (CPM, Critical Path Method): Ο χρονοπρογραμματισμός του έργου εμπεριέχει το διαχωρισμό της συνολικής εργασίας που περιλαμβάνεται σε ένα έργο, σε ξεχωριστές δραστηριότητες και εκτιμήσεις του πότε αυτές οι δραστηριότητες θα ολοκληρωθούν. Δραστηριότητα ονομάζουμε οποιοδήποτε καθήκον, εργασία ή λειτουργία πρέπει να εκτελεστεί για να ολοκληρωθεί το πακέτο εργασιών ή το έργο στο οποίο ανήκει. Πολλές φορές, κάποιες από τις δραστηριότητες πραγματοποιούνται παράλληλα. Οι υπεύθυνοι για το χρονοπρογραμματισμό του έργου πρέπει να συγχρονίσουν αυτές τις παράλληλες δραστηριότητες και να οργανώσουν την εργασία έτσι ώστε οι πόροι(ανθρώπινοι ή όχι) να χρησιμοποιηθούν με βέλτιστο τρόπο. Στόχος είναι να αποφύγουμε την 21

23 κατάσταση κατά την οποία όλο το έργο καθυστερεί επειδή ένα κρίσιμο τμήμα είναι ατελές. Χρησιμοποιείται ένα διάγραμμα δικτύου (network diagram) για να αναπαραστήσει τη λογική αλληλουχία που συνδέει τις δραστηριότητες και η οποία απορρέει από τη μέθοδο υλοποίησης και άλλους περιορισμούς. Στην Εικόνα 4 δίνεται ένα παράδειγμα ενός τέτοιου διαγράμματος. 14/7/88 15 μέρες 15 μέρες 8 μέρες Τ1 Μ1 25/7/88 Τ3 5 μέρες Τ6 4/8/88 Μ4 Τ9 25/8/88 Μ6 4/7/88 Μ3 7 μέρες Εκκίνηση 15 μέρες 20 μέρες Τ7 Τ11 Τ2 11/8/88 5/9/88 25/7/88 Μ7 Μ8 Μ2 10 μέρες 15 μέρες 10 μέρες Τ5 Τ10 Τ12 10 μέρες 18/7/88 25 μέρες 19/9/88 Τ4 Μ5 Τ8 Λήξη Εικόνα 4: Παράδειγμα διαγράμματος δικτύου Χρονοδιάγραμμα (Project Schedule) : Οι σχεδιασμένες ημερομηνίες για την εκτέλεση των δραστηριοτήτων προγράμματος και οι σχεδιασμένες ημερομηνίες για την επίτευξη των ορόσημων χρονοδιαγράμματος. Γραμμικό Χρονοδιάγραμμα (Gantt Chart): Χρησιμοποιείται ευρύτατα για την κοινοποίηση πληροφοριών σχετικά με το πρόγραμμα του έργου. Ο χρονικός προγραμματισμός της κάθε δραστηριότητας αναπαρίσταται από μια οριζόντια γραμμή που ξεκινά από την ημέρα έναρξης της δραστηριότητας και καταλήγει στην ημερομηνία λήξης της. Το μήκος της γραμμής είναι ανάλογο προς την εκτιμώμενη διάρκεια της δραστηριότητας. Στην Εικόνα 5 δίνεται ένα παράδειγμα. 22

24 4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 Εκκίνηση T4 T1 T2 M1 T7 T3 T8 M3 M2 T6 T5 M4 T9 M7 T10 M6 T11 M8 T12 Τέλος Εικόνα 5: Γραμμικό χρονοδιάγραμμα (ή διάγραμμα Gantt) Εκτίμηση Κόστους (Cost Estimating): Η διαδικασία ανάπτυξης μίας προσέγγισης για το κόστος των πόρων που απαιτούνται ώστε να ολοκληρωθούν οι δραστηριότητες του έργου. Σχέδιο Διοίκησης Κόστους (Cost Management Plan) : Το έγγραφο που θέτει τη μορφή και θεσπίζει τις δραστηριότητες και τα κριτήρια για το σχεδιασμό, τη δόμηση και τον έλεγχο του κόστους του έργου. Σχέδιο Διοίκησης Προμηθειών (Procurement Management Plan) :Το έγγραφο που περιγράφει το πώς θα γίνει η διοίκηση των διαδικασιών προμηθειών από την ανάπτυξη της προμηθευτικής τεκμηρίωσης μέχρι την περάτωση των συμβάσεων. Οργανόγραμμα (Organization Chart): Μία μέθοδος απεικόνισης των αλληλοσυσχετίσεων μεταξύ ενός συνόλου ατόμων που εργάζονται μαζί προς ένα κοινό αντικειμενικό στόχο (objective). Ιστόγραμμα Πόρων (Resource Histogram): Πόρος, για κάθε δραστηριότητα μπορεί να είναι οποιοδήποτε άτομο ή μηχάνημα το οποίο θα εκτελέσει τη συγκεκριμένη δραστηριότητα. Ως εκ τούτου, προγραμματισμός πόρων είναι η διαδικασία πρόβλεψης των πόρων του απαιτούνται για να εκτελεστεί το αντικείμενου του έργου εντός του καθορισμένου χρονικού πλαισίου. 23

25 Πλάνο διαχείρισης επικοινωνίας έργου (communications management plan): Αναφέρεται στις διαδικασίες συλλογής και διάχυσης των πληροφοριών που αφορούν το έργο. Περιλαμβάνει τον προγραμματισμό της επικοινωνίας, τη διανομή πληροφοριών, το πρόγραμμα των συναντήσεων που αφορούν το έργο κτλ. Πλάνο διαχείρισης της ποιότητας (project quality plan): Σχηματοποιεί ένα σύστημα διαχείρισης ποιότητας (εξασφάλιση ποιότητας και ποιοτικό έλεγχο) μελετημένο να καθοδηγεί και να κάνει εφικτή την κάλυψη των απαιτούμενων απαιτήσεων. Πλάνο διαχείρισης κινδύνου (risk management plan): Περιλαμβάνει τις διαδικασίες για τον προσδιορισμό και ανάλυση των κινδύνων του έργου καθώς και τις διαδικασίες απόκρισης σε αυτόν. Αποτελείται από τα ακόλουθα μέρη: προσδιορισμό κινδύνων, ποσοτική εκτίμηση και επιπτώσεις των κινδύνων, ανάπτυξη διαδικασιών απόκρισης. Διαδικασίες εκτίμησης του έργου (estimating) Η διαδικασία της εκτίμησης αποτελεί αναπόσπαστο κομμάτι της διαχείρισης έργου. Για να μπορέσει ο διευθυντής του έργου να προγραμματίσει και να ελέγξει το έργο αποτελεσματικά θα πρέπει να έχει στη διάθεσή του ακριβείς εκτιμήσεις. Η ποιότητα και οι ακρίβεια βελτιώνεται σταδιακά καθώς το έργο αρχίζει να εκτελείται, διότι στη φάση αυτή συγκεντρώνονται λεπτομερέστερες και ακριβέστερες πληροφορίες. Δυστυχώς όμως ο διευθυντής του έργου είναι τις περισσότερες φορές υποχρεωμένος να δεσμεύει την εταιρία, οικονομικά και νομικά, ήδη κατά τη φάση υποβολή προσφορών, δηλαδή όταν ακόμα οι διαθέσιμες πληροφορίες είναι περιορισμένες. Για αυτό το λόγο είναι σημαντικό να μπορεί κανείς να καταλήγει σε όσο το δυνατό ακριβέστερες εκτιμήσεις με βάση ελλιπείς πληροφορίες. Για παράδειγμα, όσον αφορά την ανάλυση των οικονομικών στοιχείων του έργου, η εκτίμηση μπορεί να υποδιαιρεθεί ανάλογα με τα διαφορετικά στοιχεία κόστους του έργου: Άμεσο κόστος, Έμμεσο κόστος, Κόστος που εξαρτάται από το χρόνο, Κόστος εργασίας, Κόστος πρώτων υλών και εξοπλισμού κ.τ.λ. (Burke, 2002) Έλεγχος του Έργου Ο έλεγχος του έργου αποτελείται από μια σειρά βημάτων μέσω των οποίων το έργο καταλήγει να ολοκληρωθεί με επιτυχία. Το πλάνο διαχείρισης έργου αποτελεί 24

26 σημείο εκκίνησης της διαδικασίας ελέγχου του έργου, διότι καθορίζει ένα σχεδιασμό διαχείρισης του έργου. Η διαδικασία του ελέγχου καταγράφει την απόδοση του έργου και τη συγκρίνει με το πλάνο διαχείρισης έργου- περιλαμβάνει επίσης έναν μηχανισμό για την ενσωμάτωση των αλλαγών. (Burke, 2002) Στην ουσία ο έλεγχος λειτουργεί ως πλοηγός που οδηγεί το πρόγραμμα στην επιτυχημένη ολοκλήρωσή του, παρακολουθώντας την απόδοση και εφαρμόζοντας διορθωτικές ενέργειες όποτε αυτό είναι απαραίτητο. Οι έμπειροι επαγγελματίες του κλάδου συνιστούν την υιοθέτηση μιας οργανωμένης προσέγγιση όσον αφορά τον έλεγχο του έργου και αυτό γιατί όταν υπάρχει ένα καλά οργανωμένο σύστημα ελέγχου, όλα τα εμπλεκόμενα μέρη γνωρίζουν τι πρέπει να κάνουν, ποια είναι η αναμενόμενη απόδοσή τους και τι αναφορές πρέπει να συντάξουν. Αντικείμενο του ελέγχου Ο έλεγχος αφορά όλες τις όψεις της διαχείρισης έργου. Διαχείριση του αντικειμένου εργασιών Τεχνική υποστήριξη Διαχείριση Χρόνου Διαχείριση προμηθειών Διαχείριση πόρων Διαχείριση κόστους Έλεγχος αλλαγών Διαχείριση ποιότητας Διαχείριση επικοινωνίας Διαχείριση ανθρώπινων πόρων Διαχείριση περιβάλλοντος. Έλεγχος όσων συμμετέχουν στο έργο 25

27 Διαχείριση Έργων Πληροφορικής (Software Project Management) Εισαγωγή Εικόνα 6: Αναπαράσταση των ειδών διοίκησης Η Διαχείριση Έργων Λογισμικού (Software Project Management) περιλαμβάνει τη γνώση, τις τεχνικές και τα εργαλεία που είναι απαραίτητα για τη διοίκηση της ανάπτυξης προϊόντων λογισμικού. Ο όρος λογισμικό δεν αναφέρεται μόνο στον κώδικα αλλά περιλαμβάνει και την απαραίτητη τεκμηρίωση που απαιτείται για την εγκατάσταση, χρήση, ανάπτυξη και συντήρηση αυτού. (Sommerville, 1992) Ένα έργο ανάπτυξης λογισμικού (software development project) είναι ένα πολύπλοκο εγχείρημα που αναλαμβάνουν να το φέρουν εις πέρας δύο ή περισσότεροι άνθρωποι και ενώ υπάρχουν περιορισμοί του χρόνου, του κόστους και των πόρων με στόχο να παραχθεί νέος ή βελτιωμένος κώδικας λογισμικού που προσθέτει σημαντική αξία σε μια νέα ή υπάρχουσα επιχειρηματική διαδικασία. (Wysocki, 2006) Η αποτυχία πολλών μεγάλων έργων λογισμικού τη δεκαετία του 60 και τα πρώτα χρόνια της δεκαετίας του 70 κατέδειξε τα προβλήματα της διοίκησης έργων λογισμικού. Η αποτυχία αυτών των έργων δεν οφειλόταν στο γεγονός ότι οι υπεύθυνοι έργου ή οι προγραμματιστές που εργάζονταν σε αυτά ήταν ανεπαρκείς. Το πρόβλημα βρισκόταν στις τεχνικές διοίκησης που χρησιμοποιούνταν. Οι τεχνικές που 26

28 προέκυψαν από τα έργα μικρής κλίμακας ήταν ακατάλληλες για την ανάπτυξη μεγάλων συστημάτων. Το παραδιδόμενο λογισμικό παραδιδόταν εκπρόθεσμα, ήταν αναξιόπιστο, το κόστος του ήταν πολλαπλάσιο της αρχικής εκτίμησης και συχνά επιδείκνυε κακή απόδοση. (Brooks, 1975) Η διοίκηση έργων λογισμικού διαφέρει από άλλους τύπους διοίκησης μηχανικών έργων, σε έναν αριθμό σημείων: (Dan, 2006) Το προϊόν δεν είναι χειροπιαστό. Ο υπεύθυνος ενός ναυπηγικού έργου ή ένας πολιτικός μηχανικός μπορούν να βλέπουν το έργο που αναπτύσσεται. Το λογισμικό δεν είναι χειροπιαστό. Δεν μπορεί να ιδωθεί ή να αγγιχθεί. Ο υπεύθυνος του έργου στηρίζεται στην τεκμηρίωση (documentation) για να επιθεωρήσει την πρόοδο του έργου. Δεν έχουμε κατανοήσει πλήρως την διαδικασία ανάπτυξης λογισμικού. Σε μηχανικούς επιστημονικούς κλάδους, τα στάδια της ανάπτυξης είναι κατανοητά και προβλεπόμενα. Στην τεχνολογία λογισμικού τα πράγματα δεν είναι έτσι. Μοντέλα, όπως αυτό του καταρράκτη και του κύκλου ζωής λογισμικού, είναι απλοποιημένες παραστάσεις διαδικασιών. H ανάπτυξη λογισμικού σαν ξεχωριστός κλάδος είναι τόσο νέος ώστε μετρήσιμες, αποδοτικές τεχνικές δεν είναι ακόμη διαθέσιμες και αυτές που είναι διαθέσιμες δεν είναι καλά καθορισμένες Τα μεγάλα συστήματα λογισμικού είναι συνήθως έργα μοναδικά στο είδος τους. Διαφέρουν από προηγούμενα έργα. Είναι δύσκολος ο εντοπισμός και η αποφυγή λαθών στο λογισμικό. Επιπλέον, το λογισμικό έχει έναν υψηλό βαθμό πολυπλοκότητας. Το μεγάλο κόστος σε ανθρώπινο δυναμικό, με μεγάλο βαθμό ειδίκευσης Οι εκτιμήσεις κόστους και χρόνου είναι ιδιαίτερα πολύπλοκες. Εμφανίζονται νέοι αλγόριθμοι, μέθοδοι, νέες γλώσσες, πλατφόρμες, αρχιτεκτονικές, υποστηρικτικά εργαλεία, λειτουργικά συστήματα και τεχνολογία γενικότερα. Συνήθως τέτοιου είδους έργα παρουσιάζουν μεγάλο αριθμό αλλαγών στις αρχικές απαιτήσεις. Οι διαδικασίες ανάπτυξης λογισμικού και οι μοντέρνες διαδικασίες διαχείρισης έργου είναι και οι δύο περίπου πενήντα χρόνων. Πρόκειται λοιπόν για δύο νέες επιστήμες που ενώ μπορούν να συνεισφέρουν στην επιτυχία ενός έργου, δυστυχώς, και οι δύο έχουν τη φήμη ότι πολλές φορές αποτυγχάνουν. (Wysocki, 2006) 27

29 Τα τέσσερα P (Product-People- Project-Process) Όπως αναφέρθηκε και παραπάνω, ένα έργο ανάπτυξης λογισμικού είναι ένα πολύπλοκο εγχείρημα στο οποίο πρωταγωνιστικό ρόλο παίζει η διοίκηση του έργου, η διαδικασία που ακολουθείται, το προϊόν που πρόκειται να παραχθεί και οι άνθρωποι που δουλεύουν για αυτό. Έτσι λοιπόν, η αποτελεσματική διοίκηση έργων λογισμικού εστιάζει σε τέσσερα P : Προϊόν (product) : Πριν ένα έργο σχεδιασθεί, θα πρέπει να καθοριστούν οι στόχοι και το πλαίσιο του έργου, θα πρέπει να έχουν σχεδιασθεί εναλλακτικές λύσεις και τέλος θα πρέπει να έχουν αναγνωρισθεί τεχνικοί και διοικητικοί περιορισμοί. Χωρίς αυτές τις πληροφορίες είναι αδύνατο να πραγματοποιηθούν ρεαλιστικές εκτιμήσεις κόστους, μια αποτελεσματική εκτίμηση του κινδύνου, μια ρεαλιστική κατάτμηση των εργασιών του έργου ή ένα ουσιώδες χρονοδιάγραμμα του αντικατοπτρίζει τους πραγματικούς δείκτες προόδου. 28 έργου που να Άνθρωποι (people): Ένα προσωπικό κατάλληλα εκπαιδευμένο αλλά και με κίνητρα ήταν βασικό θέμα συζήτησης από τη δεκαετία του Μάλιστα, ο ανθρώπινος παράγοντας είναι τόσο σημαντικός που το Ινστιτούτο Τεχνολογίας Λογισμικού (software engineering institute) έχει αναπτύξει ένα μοντέλο ωριμότητας (capability maturity model) για την διοίκηση του ανθρώπινου παράγοντα (PM-CMM), το οποίο καθορίζει τις ακόλουθες βασικές περιοχές: στρατολόγηση, επιλογή, διοίκηση της απόδοσης, εκπαίδευση, αποζημίωση, ανάπτυξη της καριέρας, οργάνωση και σχεδιασμός της εργασίας και τέλος ανάπτυξη της ομαδικότητας και της κουλτούρας της ομάδας. Διαδικασία (process): Παρέχει το πλαίσιο από το οποίο προκύπτει ένα αναλυτικό σχέδιο ανάπτυξης του έργου. Ένας μικρός αριθμός δραστηριοτήτων είναι εφαρμόσιμος σε όλα τα έργα λογισμικού, ανεξάρτητα από το μέγεθος ή την πολυπλοκότητά τους. Ένας αριθμός διαφορετικών συνόλων εργασιών, οροσημών (milestones), προϊόντων εργασίας (work products) - δίνουν τη δυνατότητα το πλαίσιο δραστηριοτήτων να είναι προσαρμόσιμο στα χαρακτηριστικά διαφορετικών έργων λογισμικού. Εν τέλει, υπάρχει ένα σύνολο από δραστηριότητες ομπρέλα (umbrella activities), όπως η διασφάλιση της ποιότητας του λογισμικού, η διοίκηση κινδύνων και οι μετρικές που επικαλύπτουν όλο το έργο. Αυτές οι δραστηριότητες από το υπόλοιπο πλαίσιο δραστηριοτήτων και πραγματοποιούνται σε όλη τη διάρκεια του έργου.

30 Έργο (project): Αν και οι δείκτες επιτυχίας των έργων λογισμικού έχουν βελτιωθεί, ωστόσο η αποτυχία παραμένει σε υψηλά επίπεδα σε σχέση με την επιθυμητή. Για να αποφευχθεί η αποτυχία του έργου, ο διευθύνων του έργου και όλη η ομάδα του έργου θα πρέπει να είναι προσεκτικοί με διάφορα σημάδια προειδοποίησης, να κατανοήσουν τους σημαντικούς παράγοντες επιτυχίας του έργου που οδηγούν στην επιτυχημένη διοίκηση του έργου και να αναπτύξουν μια αναλυτική προσέγγιση για το σχεδιασμό, την παρακολούθηση και τον έλεγχο του έργου. (Pressman, 2005) 29

31 Το προϊόν Λογισμικό (Product) Κατηγορίες Λογισμικού Στις μέρες μας υπάρχουν εφτά ευρείς κατηγορίες λογισμικού: (Pressman, 2005) 1. Λογισμικό Συστήματος (system software) είναι μια συλλογή προγραμμάτων που εξυπηρετούν άλλα προγράμματα, για παράδειγμα μεταφραστές, οδηγούς, τμήματα του λειτουργικού συστήματος, λογισμικό διαδικτύωσης και άλλα. Το λογισμικό συστήματος χαρακτηρίζεται από την υψηλή αλληλεπίδραση με το υλικό, από την χρησιμοποίησή του από πολλούς χρήστες και από ταυτόχρονη λειτουργία που απαιτεί χρονοπρογραμματισμό, διαμοίραση πόρων και πολύπλοκες δομές δεδομένων. 2. Λογισμικό Εφαρμογών (application software) αποτελείται από προγράμματα που επιλύουν μια συγκεκριμένη επαγγελματική ανάγκη. Οι εφαρμογές επεξεργάζονται επαγγελματικά ή τεχνικά δεδομένα με τέτοιο τρόπο που διευκολύνουν τις επιχειρηματικές διεργασίες και τη διαδικασία λήψης απόφασης. 3. Λογισμικό Μηχανικό/Επιστημονικό (engineering/scientific software) χαρακτηρίζεται από αριθμητικούς αλγόριθμους και περιλαμβάνει μια ποικιλία προγραμμάτων. Ωστόσο οι καινούργιες εφαρμογές σε αυτήν την περιοχή έχουν αρχίσει να ξεφεύγουν από τους απλούς μαθηματικούς αλγορίθμους και η προσομοίωση μαζί με άλλες εφαρμογές αλληλεπίδρασης έχουν κερδίσει έδαφος. 4. Ενσωματωμένο Λογισμικό (embedded software): τοποθετείται μέσα σε ένα προϊόν ή σύστημα και χρησιμοποιείται για να υλοποιήσει και για να ελέγξει χαρακτηριστικά και λειτουργίες για τον τελικό χρήστη και για το σύστημα το ίδιο. 5. Γραμμές Προϊόντων Λογισμικού (product line software): είναι σχεδιασμένο για να παρέχει μια συγκεκριμένη δυνατότητα για χρήση από πολλούς διαφορετικούς πελάτες. Αυτού του είδους το λογισμικό μπορεί να εστιάσει σε μια κάθετη αγορά ( για παράδειγμα προϊόντα ελέγχου αποθήκης) ή να απευθυνθεί σε μια μεγάλη και μαζική αγορά (για παράδειγμα επεξεργασία κειμένου, λογιστικά φύλλα, εφαρμογές γραφικών κ.α.) 6. Εφαρμογές Διαδικτύου (web applications) εμπεριέχουν ένα ευρύ φάσμα εφαρμογών. Στην απλούστερή τους μορφή μπορεί να είναι ένα σύνολο 30

32 σελίδων με υπερσύνδεσμους που παρουσιάζουν πληροφορίες χρησιμοποιώντας κείμενο και περιορισμένα γραφικά. Ωστόσο, καθώς το ηλεκτρονικό εμπόριο και οι εφαρμογές B2B κερδίζουν όλο και περισσότερο έδαφος, οι εφαρμογές αυτές εξελίσσονται σε περιβάλλοντα που όχι μόνο παρέχουν διάφορα χαρακτηριστικά, υπολογιστικές λειτουργίες και περιεχόμενο στον τελικό χρήστη αλλά επίσης συνεργάζονται με βάσεις δεδομένων αλλά και άλλες εφαρμογές. 7. Λογισμικό Τεχνητής Νοημοσύνης (artificial intelligence software) κάνει χρήση μη-αριθμητικών αλγορίθμων για να επιλύσουν πολύπλοκα προβλήματα. Τέτοιου είδους εφαρμογές είναι τα έμπειρα συστήματα, τα νευρωνικά δίκτυα κ.α. Ιδιότητες Ποιοτικού Λογισμικού Γενικά θα λέγαμε ότι ένα καλά κατασκευασμένο πακέτο λογισμικού πρέπει να κατέχει τις παρακάτω ιδιότητες : (Sommerville, 1992) Το λογισμικό θα πρέπει να είναι συντηρήσιμο. (maintainable) Επειδή ένα λογισμικό γίνεται αντικείμενο συνεχών αλλαγών θα πρέπει αυτές οι αλλαγές που γίνονται να καταγράφονται και να τεκμηριώνονται. Το λογισμικό θα πρέπει να είναι αξιόπιστο (reliable). Θα πρέπει επομένως να δουλεύει όπως οι χρήστες απαιτούν και να μη καταρρέει πιο συχνά από ότι αναφέρουν οι προδιαγραφές του. Το λογισμικό θα πρέπει να είναι αποδοτικό. (efficient), Με το όρο αποδοτικό εννοούμε ότι το σύστημα δεν θα πρέπει να σπαταλάει τους πόρους του συστήματος όπως π.χ μνήμη, κύκλοι μηχανής. Αντιθέτως θα πρέπει να επιδιώκουμε την αξιοποίηση των πόρων στο μεγαλύτερο δυνατό βαθμό. Το λογισμικό θα πρέπει να προσφέρει την κατάλληλη διεπαφή για τον χρήστη. Με την κατάλληλη διεπαφή επιτυγχάνεται μεγαλύτερη αξιοποίηση του λογισμικού. 31

33 Οι Άνθρωποι (People) Σύμφωνα με μελέτες που πραγματοποιήθηκαν ένας ιδιαίτερα σημαντικός παράγοντας για την επιτυχία του έργου, και για πολλούς ο σημαντικότερος, είναι ο ανθρώπινος παράγοντας. Οι συμμέτοχοι Stakeholders Στην διαδικασία παραγωγής του λογισμικού εμπλέκονται πολλοί μέτοχοι, οι οποίοι έχουν συμπίπτουν με τους συμμέτοχους ενός γενικού έργου και έχουν αναφερθεί στην ενότητα της διαχείρισης έργων. Ρόλοι των μελών μιας ομάδας λογισμικού Ρόλοι των μελών της ομάδας λογισμικού: (Voas, 2007) Αναλυτής συστήματος (systems analyst): αναλύει τις απαιτήσεις για μια εφαρμογή. Αρχιτέκτονας λογισμικού (software architect): σχεδιάζει τη συνολική δομή της εφαρμογής. Ειδικός λογισμικού δικτύου (software network specialist): σχεδιασμός, εγκατάσταση και συντήρηση LAN/WAN δικτύου. Προγραμματιστής λογισμικού (software programmer): υλοποιεί το σχεδιασμό χρησιμοποιώντας εργαλεία ανάπτυξης λογισμικού και γλώσσες προγραμματισμού. Διοικητής του συστήματος λογισμικού (software systems administrator): εποπτεύει τους λογαριασμούς των χρηστών, τις ανανεώσεις της τεχνολογίας, τη μετάβαση του λογισμικού από την παραγωγή στους χρηστές και την επίλυση προβλημάτων. Διοικητής της βάσης δεδομένων (software database administrator): εποπτεύει τη βάση δεδομένων (εγκατάσταση, συντήρηση). Τεχνολόγος Υποστήριξης πελατών (customer support engineer): επιλύει προβλήματα των πελατών και των τελικών χρηστών με τη βοήθεια εφαρμογών λογισμικού. Webmaster :σχεδιάζει, υλοποιεί και συντηρεί μια ιστοσελίδα. Τεχνολόγος ασφάλειας λογισμικού (software security engineer): αναγνώριση, προστασία δεδομένων, ακεραιότητα δεδομένων. 32

34 Ελεγκτής λογισμικού (software tester): ανεξάρτητος οργανισμός επαλήθευσης και επικύρωσης λογισμικού. Διευθύνων του έργου λογισμικού (software project manager): σχεδιάζει, οργανώνει, κατευθύνει, συντονίζει και ελέγχει το έργο λογισμικού. Διοικητής της διαμόρφωσης λογισμικού (software configuration manager): είναι υπεύθυνος για τον έλεγχο της αλλαγής, πραγματοποιεί ελέγχους και αξιολογήσης. Διευθύνων/τεχνολόγος ποιότητας λογισμικού (software quality manager/engineer): είναι υπεύθυνος για την ποιότητα του λογισμικού και πραγματοποιεί έλεγχο ποιότητας και ανάλυση κινδύνων. Δομές Οργάνωσης και Οργάνωση Ομάδων Προγραμματισμού. Η διοικητική δομή έργων λογισμικού είναι συνήθως λειτουργική αλλά οι υπεύθυνοι λογισμικού θα πρέπει να χειρίζονται λιγότερους υπαλλήλους σε σχέση με άλλου τύπου έργα λόγω της πολυπλοκότητας των έργων λογισμικού. Τα έργα λογισμικού δεν θα πρέπει να αντιμετωπίζονται από μια μόνο μεγάλη ομάδα από μηχανικούς λογισμικού. Μεγάλες ομάδες σημαίνει ότι ο χρόνος που καταναλώνεται στην επικοινωνία μεταξύ των μελών της ομάδας είναι μεγαλύτερος από το χρόνο που αφιερώνεται στον προγραμματισμό. Αν χρησιμοποιηθεί μια μεγάλη ομάδα προγραμματισμού, τα τμήματα του προγράμματος είναι συνήθως αυθαίρετα και έχουν πολύπλοκες διεπαφές. Κατά συνέπεια, η πιθανότητα λάθους σε κάποια διασύνδεση είναι μεγάλη και επιπλέον προκαλείται κόστος επαλήθευσης (verification) και πιστοποίησης (validation).έτσι, εκτός και αν οι συνθήκες είναι ιδιάζουσες, μια ομάδα δεν θα πρέπει να έχει πάνω από οκτώ (8) άτομα. Εκτός από το να ελαχιστοποιούν τα προβλήματα επικοινωνίας, οι μικρές ομάδες προγραμματισμού έχουν έναν αριθμό άλλων πλεονεκτημάτων: (Sommerville, 1992) Μπορεί να αναπτυχθεί ένα πρότυπο ποιότητας της ομάδας. Επειδή αυτό το πρότυπο επιλέγεται από την ίδια την ομάδα, είναι πιο πιθανό να εφαρμοσθεί από το να επιβληθούν εξωτερικά πρότυπα στην ομάδα. Τα μέλη της ομάδας δουλεύουν στενά μαζί. Τα μέλη της ομάδας μπορούν να διδαχτούν το ένα από το άλλο. 33

35 Μπορεί να εφαρμοστεί μη εγωιστικός προγραμματισμός. Τα προγράμματα θεωρούνται ιδιοκτησία της ομάδας παρά προσωπική ιδιοκτησία. Τα μέλη της ομάδας τείνουν να γνωρίζουν την δουλειά του καθενός. Η συνέχιση και η συντήρηση του συστήματος είναι εφικτή ακόμα και αν ένα μέλος της ομάδας φύγει. Όσον αφορά την οργάνωση των μελών της ομάδας λογισμικού, ο Constantine (1993) προτείνει τέσσερα οργανωσιακά πρότυπα: 1. Στο κλειστό πρότυπο (closed paradigm) η ομάδα δομείται σύμφωνα με την παραδοσιακή ιεραρχία εξουσίας. Τέτοιες ομάδες μπορούν να δουλέψουν καλά όταν παράγουν λογισμικό που είναι παρόμοιο με λογισμικά που παρέχθησαν στο παρελθόν, αλλά είναι λιγότερο πιθανό να είναι καινοτόμο. 2. Στο τυχαίο πρότυπο (random paradigm) η ομάδα δομείται χαλαρά και εξαρτάται από την προσωπική πρωτοβουλία των μελών της ομάδας. Όταν απαιτείται καινοτομία ή τεχνολογία επιτεύγματα, αυτός ο τύπος ομάδας μπορεί να έχει άριστη απόδοση αλλά αντίθετα δεν έχει καλά αποτελέσματα όταν απαιτείται παλαιότερη εμπειρία. 3. Το ανοιχτό πρότυπο (open paradigm) προσπαθεί να δομήσει μια ομάδα με τρόπο που επιτυγχάνει κάποιον από τον έλεγχο του κλειστού προτύπου αλλά επίσης και την καινοτομία του τυχαίου προτύπου. Στηρίζεται στη συνεργασία, στην επικοινωνία και στην ομοφωνία των μελών της ομάδας. Αυτές οι ομάδες είναι περισσότερο κατάλληλες για πολύπλοκα προβλήματα αλλά ίσως να μην είναι τόσο αποδοτικές όσο άλλες ομάδες. 4. Το συγχρονισμένο πρότυπο (synchronous paradigm) βασίζεται στη φυσική τμηματοποίηση ενός προβλήματος και οργανώνει τα μέλη της ομάδας να δουλέψουν στα τμήματα του προβλήματος με λίγη επικοινωνία μεταξύ τους. 34

36 Το έργο (Project) Στόχοι της Αποτελεσματικής Διοίκησης Ένας διευθυντής έργου ανάπτυξης λογισμικού πρέπει να λαμβάνει υπόψη του σε όλη τη διάρκεια της σχεδίασης και της εκτέλεσης του έργου, την ποιότητα, την παραγωγικότητα, τη μείωση των κινδύνων, το κόστος και το χρόνο παραγωγής. Ποιότητα: Η ποιότητα επιτυγχάνεται μέσω της προσεκτικής προσκόλλησης στα πρότυπα, στις αποτελεσματικές τεχνικές ανάπτυξης και στον περιοδικό έλεγχο σε όλη τη διάρκεια του έργου. Η διοίκηση θα πρέπει να συνεργάζεται και να συγχρονίζεται με του οργανισμούς εξασφάλισης ποιότητας, αν υπάρχουν. Παραγωγικότητα: Η αυξημένη παραγωγικότητα μειώνει το κόστος. Στην τρέχουσα κατάσταση οι σημαντικότεροι παράγοντες που επηρεάζουν την παραγωγικότητα είναι: η ικανότητα των τεχνολόγων λογισμικού, η ποιότητα των εργαλείων με τα οποία εργάζονται καθώς και το περιβάλλον εργασίας. Μείωση Κινδύνων: Οι διευθυντές θα πρέπει να αναγνωρίσουν τα δυσκολότερα μέρη του συγκεκριμένου έργου και τα αντιμετωπίσουν συστηματικά με αποτελεσματικές λύσεις. Κόστος: Το κόστος παραγωγής είναι ένας από τους βασικότερους παράγοντες επιτυχίας ενός έργου. Ένα προϊόν όσο ποιοτικό και αν είναι, σε περίπτωση που το έργο υπερβεί κατά πολύ το προβλεπόμενο κόστος, δεν παύει το έργο να θεωρείται αποτυχημένο. Χρόνος: Ο διευθυντής του έργου οφείλει, παρά το προβλήματα που ενδεχομένως να εμφανίζονται, να ακολουθεί το προβλεπόμενο χρονοδιάγραμμα. 35

37 Η διεργασία (process) Η σημασία της έννοιας διεργασία Όταν παρέχουμε μια υπηρεσία ή δημιουργούμε ένα προϊόν, ανεξάρτητα από το εάν πρόκειται για την ανάπτυξη λογισμικού, τη σύνταξη μιας έκθεσης ή μια επαγγελματική περιοδεία σχεδόν πάντα ακολουθούμε μια σειρά βημάτων για την ολοκλήρωση ενός συνόλου εργασιών. Έτσι ως διεργασία (process) ένα σύνολο διατεταγμένων εργασιών: μια σειρά βημάτων που σχετίζονται με δραστηριότητες, περιορισμούς και πόρους και παράγουν κάποιου είδους αποτέλεσμα στο οποίο στοχεύουμε από την αρχή. (Pfleeger, 2003) Όταν η διεργασία αφορά τη δημιουργία κάποιου προϊόντος, αναφερόμαστε ορισμένες φορές σε αυτή με τον όρο κύκλος ζωής. Γι αυτόν το λόγο, η διεργασία ανάπτυξης λογισμικού αποκαλείται και κύκλος ζωής λογισμικού, επειδή περιγράφει τη ζωή ενός προϊόντος λογισμικού από τη σύλληψη της ιδέας μέχρι την υλοποίηση, την παράδοση, τη χρήση και τη συντήρησή του. (Pfleeger, 2003) Ο κύκλος ζωής λογισμικού (software lifecycle) ορίζεται ως το σύνολο των δραστηριοτήτων και των σχέσεων μεταξύ τους για την υποστήριξη της ανάπτυξης ενός συστήματος λογισμικού. Οι διεργασίες είναι σημαντικές επειδή επιβάλλουν συνέπεια και δομή σε ένα σύνολο δραστηριοτήτων. Κάθε εφαρμογή λογισμικού από τη σύλληψη μέχρι την απόσυρσή της, διέρχεται από διάφορες φάσεις σε καθεμιά εκ των οποίων πρέπει να γίνονται ορισμένες εργασίες ώστε να επιτυγχάνεται το επιθυμητό αποτέλεσμα. Σε μακροσκοπικό επίπεδο οι πολύ γενικές φάσεις είναι: σύλληψη, κατασκευή, χρήση/ συντήρηση και απόσυρση και, όπως είναι εύκολα αντιληπτό, λαμβάνουν χώρα με τη σειρά αυτή. (Βεσκούκης, 2000) Μια δραστηριότητα ή διαδικασία ανάπτυξης λογισμικού (software process) καθορίζει ποιες ενέργειες πρέπει να γίνουν για να επιτευχθεί ένα επιθυμητό αποτέλεσμα σε κάποια από τις φάσεις του κύκλου ζωής. Μια δραστηριότητα μπορεί να αναλύεται σε περισσότερες από μία επιμέρους φάσεις. (Βεσκούκης, 2000) ακολούθως: Οι διαδικασίες ανάπτυξης λογισμικού μπορούν να ταξινομηθούν ως 36

38 Προδιαγραφή, δηλαδή καθορισμός των εργασιών που θα επιτελεί το λογισμικό, καθώς και των περιορισμών και των παραδοχών που ισχύουν. Ανάπτυξη, δηλαδή κατασκευή του λογισμικού. Εδώ, σε όλα τα μοντέλα κύκλου ζωής μπορούμε να διακρίνουμε τρεις επιμέρους φάσεις: την ανάλυση, σχεδίαση και τη συγγραφή του πηγαίου κώδικα (κωδικοποίηση). Επαλήθευση, δηλαδή επιβεβαίωση της ικανοποίησης των προδιαγραφών και της μη ύπαρξης σφαλμάτων. Εξέλιξη, δηλαδή επαύξηση των λειτουργικών χαρακτηριστικών του λογισμικού ή τροποποίηση των υπαρχουσών, προκειμένου να ικανοποιούνται οι μεταβαλλόμενες ανάγκες. Με βάση τα προηγούμενα, ο ορισμός του Μοντέλου Κύκλου Ζωής του λογισμικού είναι ο εξής: «Ένα Μοντέλο Κύκλου Ζωής Λογισμικού είναι μια περιγραφή των δραστηριοτήτων και των επιμέρους φάσεων από τις οποίες διέρχεται μια εφαρμογή λογισμικού από τη σύλληψη μέχρι την απόσυρσή της, καθώς και των εργασιών που λαμβάνουν χώρα σε καθεμιά από τις φάσεις αυτές. (Βεσκούκης, 2000) Τα μοντέλα κύκλου ζωής λογισμικού προσδιορίζουν τις διαδικασίες ανάπτυξης οι οποίες λαμβάνουν χώρα κατά τις γενικές φάσεις «κατασκευή» και «χρήση συντήρηση», προσδιορίζοντας τις επιμέρους φάσεις στις οποίες αυτές αναλύονται, τα προϊόντα που παράγονται σε καθεμιά από αυτές καθώς και τη σειρά εκτέλεσής τους. Σε κάθε διαδικασία ανάπτυξης μπορούμε να διακρίνουμε περισσότερες από μία επιμέρους φάσεις, ενώ σε κάθε επιμέρους φάση μπορούμε να διακρίνουμε περισσότερες από μία εργασίες. Η βάση της τεχνολογίας λογισμικού είναι το επίπεδο της διεργασίας (process layer). Αυτή η διεργασία είναι η κόλλα που συγκρατεί ενωμένα τα επίπεδα της τεχνολογίας και κάνει δυνατή την έγκαιρη και οργανωμένη ανάπτυξη λογισμικού. Η διεργασία λογισμικού αποτελεί τη βάση για έλεγχο της διοίκησης των έργων λογισμικού και ορίζει το πλαίσιο στο οποίο εφαρμόζονται οι τεχνικοί μέθοδοι, τα παραδοτέα εργασίας (work products) παράγονται (μοντέλα, έγγραφα, δεδομένα, αναφορές, φόρμες κτλ), ορίζονται τα ορόσημα (milestones) για μετάβαση στις επόμενες φάσεις, διασφαλίζεται η ποιότητα και διοικείται κατάλληλα η αλλαγή. Κάθε διεργασία είναι δυνατό να περιγραφεί με πολλούς και διάφορους τρόπους με τη χρήση κειμένων, εικόνων ή συνδυασμών τους. Οι άνθρωποι που έχουν ασχοληθεί μέχρι σήμερα με την έρευνα γύρω από την τεχνολογία λογισμικού έχουν 37

39 προτείνει κατά καιρούς πολλές και διάφορες μορφές γι αυτήν την περιγραφή, οργανωμένες ως μοντέλο το οποίο περιλαμβάνει τα βασικά χαρακτηριστικά μιας διεργασίας. Στη βιβλιογραφία της τεχνολογίας λογισμικού περιγράφονται πολλά μοντέλα διεργασιών. Μοντέλα Κύκλου Ζωής Το Γραμμικό Μοντέλο Ο προσδιορισμός της «κρίσης του λογισμικού» (software crisis) στο 1960 και η άποψη ότι η παραγωγή του λογισμικού είναι μια τεχνολογική διαδικασία οδήγησε στην άποψη ότι η διαδικασία παραγωγής λογισμικού μοιάζει με άλλες τεχνολογικές διαδικασίες. Έτσι, το πρώτο μοντέλο που δημιουργήθηκε για παραγωγή λογισμικού προέκυψε από άλλες αντίστοιχες τεχνολογικές διαδικασίες. (Sommerville, 1992) Πρόκειται για το γραμμικό μοντέλο ή μοντέλο καταρράκτη (waterfall model), το οποίο έγινε δεκτό με ενθουσιασμό από τους ανθρώπους που ασχολούνταν με τη διοίκηση της διαδικασίας παραγωγής λογισμικού. Τα στάδια αυτού του μοντέλου παρίστανται με τη μορφή μιας γραμμικής ακολουθίας, σαν καταρράκτης που οδηγεί από το ένα στο άλλο. Όπως φαίνεται και στην εικόνα 7 για να ξεκινήσει κάθε στάδιο της ανάπτυξης θα πρέπει να έχει ολοκληρωθεί το προηγούμενο. Πρόκειται λοιπόν για μια ακολουθία βημάτων, όπου το κάθε βήμα είναι σαφώς καθορισμένο και καταλήγει στη δημιουργία προϊόντος (έγγραφο ή κώδικας). Κάθε βήμα αποτελεί τη βάση για το επόμενο. Σύμφωνα με αυτό το μοντέλο, με κάθε δραστηριότητα της διεργασίας σχετίζονται ορόσημα (milestones) και πρότυπα παραδοτέων προϊόντων, έτσι ώστε οι υπεύθυνοι των έργων να μπορούν να χρησιμοποιούν το μοντέλο για να κάνουν εκτιμήσεις για το χρόνο ολοκλήρωσης του έργου τους. Παρακάτω αναλύονται τα στάδια του μοντέλου: Ανάλυση και προσδιορισμός των απαιτήσεων. Οι υπηρεσίες, στόχοι και περιορισμοί του συστήματος καθορίζονται μετά από συζήτηση με τους ανθρώπους που θα χρησιμοποιήσουν το σύστημα. Μετά ορίζονται με τρόπο κατανοητό και από τις δύο πλευρές. Σχεδιασμός συστήματος και λογισμικού. Καθορίζεται μια γενική αρχιτεκτονική του συστήματος. 38

40 Υλοποίηση και έλεγχος ενοτήτων (units). Κατά τη διάρκεια αυτού του σταδίου, το λογισμικό υλοποιείται ως ένα σύνολο από προγράμματα και ενότητες προγραμμάτων. Ολοκλήρωση και έλεγχος του συστήματος. Σε αυτό το στάδιο το σύστημα χτίζεται από τις επιμέρους ενότητες και ελέγχεται ως ολοκληρωμένο πλέον σύστημα. Το προτελευταίο στάδιο περιλαμβάνει τον έλεγχο του ολοκληρωμένου συστήματος, που σημαίνει και επικύρωση και επαλήθευση του συστήματος. Η μεν επαλήθευση (verification) εξετάζει αν το υπό κατασκευή σύστημα πληρεί τις προδιαγραφές του, η δε επικύρωση (validation) εξετάζει αν το προϊόν που παράγεται είναι το σωστό. Λειτουργία και συντήρηση. Το σύστημα εγκαθίσταται και χρησιμοποιείται. Συντήρηση σημαίνει διόρθωση των λαθών που δεν είχαν ανακαλυφθεί σε προηγούμενα στάδια του σχεδιασμού, βελτίωση των προγραμμάτων και βελτίωση των υπηρεσιών του συστήματος όσο παρουσιάζονται νέες απαιτήσεις. (Sommerville, 1992) Εικόνα 7: Το μοντέλο καταρράκτη για τη διαδικασία παραγωγής λογισμικού 39

41 Η Code-and-Fix Προσέγγιση Η προσέγγιση Code-and-fix είναι η πιο συνηθισμένη σε σχέση με τις υπόλοιπες μεθόδους ανάπτυξης στον τομέα της τεχνολογίας της πληροφορίας. Είναι παραδοσιακά η μεθοδολογία που χρησιμοποιείται για την ανάπτυξη εφαρμογών λογισμικού. Επιπρόσθετα, είναι ο γρηγορότερος και λιγότερο αποδοτικός τρόπος για την ανάπτυξη λογισμικού διότι συχνά αυτή η προσέγγιση καταλήγει να ξεφεύγει εκτός ελέγχου με αποτέλεσμα το έργο να μην μπορεί να ολοκληρωθεί. Κυριολεκτικά, δεν υπάρχουν κανόνες στην μέθοδο code-and-fix. Σε μικρές εταιρείες, όπου η ομάδα είναι μικρή συχνά αυτή η μέθοδος είναι η μόνη που χρησιμοποιείται. Συνήθως αυτό που προτείνεται σε μια τέτοια είδους μεθοδολογία είναι η σταδιακή χρήση προτύπων, ελέγχων σε όλη τη διαδικασία ανάπτυξης. (Charvat, 2003) Το μοντέλο V Το μοντέλο V είναι μια παραλλαγή του γραμμικού μοντέλου. Όπως φαίνεται και στην Εικόνα 8, η κωδικοποίηση παριστάνεται στην κορυφή ενός σχήματος V, με την ανάλυση και τη σχεδίαση στο αριστερό σκέλος του V και τις δοκιμές και τη συντήρηση στο δεξιό. Το μοντέλο V προτείνει τη χρήση δοκιμών μονάδων και ενοποίησης και για την επαλήθευση του σχεδίου των προγραμμάτων. Με άλλα λόγια, κατά τη διάρκεια αυτών των δοκιμών τα μέλη των ομάδων κωδικοποίησης και ελέγχου θα πρέπει να εξασφαλίζουν ότι έχουν υλοποιηθεί σωστά στον κώδικα όλες οι πτυχές της σχεδίασης των προγραμμάτων. Παρόμοια, οι δοκιμές του συστήματος θα πρέπει να επαληθεύουν το σχέδιο του συστήματος, εξασφαλίζοντας ότι όλες οι πτυχές αυτού του σχεδίου έχουν υλοποιηθεί σωστά. Οι έλεγχοι αποδοχής, οι οποίοι γίνονται από τον πελάτη και όχι από τους δημιουργούς επικυρώνουν τις προδιαγραφές συσχετίζοντας κάθε βήμα των δοκιμών με το αντίστοιχο στοιχείο των προδιαγραφών. Η σύνδεση που επιχειρείται σε αυτό το μοντέλο μεταξύ του αριστερού και του δεξιού σκέλους του V υπονοεί ότι αν εντοπιστούν προβλήματα κατά τη διάρκεια της επαλήθευσης και της επικύρωσης, το αριστερό σκέλος του V θα μπορεί να εκτελεστεί ξανά προκειμένου να διορθωθούν και να βελτιωθούν οι προδιαγραφές, το σχέδιο και ο κώδικας πριν ξεκινήσουν και πάλι τα βήματα των δοκιμών του δεξιού σκέλους του V. 40

42 Εικόνα 8: Το μοντέλο V Το μοντέλο V δίνει έμφαση στο γεγονός ότι ο έλεγχος (επικύρωση και επαλήθευση) σχετίζεται με την ανάλυση και σχεδίαση και προκαλεί επαναλήψεις. (Pfleeger, 2003) Το μοντέλο πρωτυποποίησης Συχνά ο πελάτης ορίζει ένα σύνολο γενικών στόχων για το λογισμικό, χωρίς να μπορεί να δώσει για λεπτομερή περιγραφή για το λογισμικό που πρόκειται να παραχθεί. Σε άλλες περιπτώσεις, αυτός που αναπτύσσει το λογισμικό ίσως να μην είναι βέβαιος για την αποτελεσματικότητα ενός αλγορίθμου, την προσαρμοστικότητα ενός λειτουργικού συστήματος ή την μορφή που μπορεί να έχει η αλληλεπίδραση ανθρώπου μηχανής. Σε αυτές και πολλές άλλες περιπτώσεις χρησιμοποιείται αυτό το μοντέλο. Η κεντρική ιδέα του μοντέλου προτυποποίησης είναι η ανάπτυξη του λογισμικού όχι εξολοκλήρου, αλλά σε τμήματα, που ονομάζονται «πρωτότυπα». Οι διαδικασίες ανάπτυξης επαναλαμβάνονται για ένα τμήμα του συστήματος κάθε φορά και για το λόγο αυτό, το μοντέλο χαρακτηρίζεται ως επαναληπτικό. Κάθε πρωτότυπο περιλαμβάνει τις βασικές από τις λειτουργίες που προορίζεται να εκτελεί το λογισμικό και τίθεται σε δοκιμασία από τον πελάτη. Από εκεί συλλέγονται παρατηρήσεις και η διαδικασία κατασκευής νέου πρωτοτύπου επαναλαμβάνεται μέχρις ότου ένα πρωτότυπο να ικανοποιεί τις απαιτήσεις, δηλαδή να εκτελεί τις επιθυμητές λειτουργίες του λογισμικού με τρόπο ικανοποιητικό και να γίνεται αποδεκτό από τον πελάτη. Ένα σημαντικό πλεονέκτημα του μοντέλου αυτού είναι η δυνατότητα απόκτησης άποψης για την εφαρμογή λογισμικού νωρίτερα απ ότι στο μοντέλο καταρράκτη. Ωστόσο το μέγεθος των εφαρμογών αυτών δεν μπορεί να είναι ιδιαίτερα 41

43 μεγάλο, διότι ο χρόνος ανάπτυξης κάθε πρωτοτύπου μεγαλώνει και η απαιτούμενη ευελιξία μειώνεται. (Βεσκούκης, 2000) Αυξητική και επαναληπτική ανάπτυξη Το σύστημα σχεδιάζεται με τέτοιο τρόπο ώστε να μπορεί να παραδοθεί σε τμήματα, γεγονός που δίνει στους χρήστες τη δυνατότητα να χρησιμοποιούν ορισμένες λειτουργίες του όσο αναπτύσσεται το υπόλοιπο. Έτσι συνήθως υπάρχουν δύο συστήματα που λειτουργούν παράλληλα: το σύστημα παραγωγής και το σύστημα ανάπτυξης. Το σύστημα λειτουργίας (operational system) ή σύστημα παραγωγής (production system) είναι αυτό που χρησιμοποιείται από τον πελάτη και το χρήστη ενώ το σύστημα ανάπτυξης (development system) είναι η επόμενη έκδοσή του, η οποία ετοιμάζεται προκειμένου να αντικαταστήσει το τρέχον σύστημα παραγωγής. (Pfleeger, 2003) Οι δύο δημοφιλέστερες προσεγγίσεις είναι η αυξητική επανάληψη και η επαναληπτική ανάπτυξη. Στην αυξητική ανάπτυξη (incremental development), το σύστημα που περιγράφηκε στα έγγραφα καθορισμού των προδιαγραφών διαμοιράζεται σε υποσυστήματα με βάση τις λειτουργίες του. Σε αυτήν την περίπτωση οι εκδόσεις ορίζονται με την αρχική ανάπτυξη ενός μικρού υποσυστήματος λειτουργίας και την προσθήκη επιπλέον λειτουργιών σε κάθε νέα έκδοση. Αντίθετα στην επαναληπτική ανάπτυξη (iterative development) παραδίδεται από την αρχή ένα πλήρες σύστημα και σε κάθε νέα του έκδοση οι λειτουργίες κάθε υποσυστήματος τροποποιούνται. Στην πράξη, πολλοί οργανισμοί χρησιμοποιούν ένα συνδυασμό αυξητικής και επαναληπτικής ανάπτυξης. Κάθε νέα έκδοση μπορεί να περιλαμβάνει λειτουργίες αλλά και βελτιώσεις των λειτουργιών της υπάρχουσας έκδοσης συστήματος. Το σπειροειδές μοντέλο Ο Boehm (1988) προέβαλε τη διεργασία ανάπτυξης λογισμικού στο φως των κινδύνων που ενυπάρχουν σε αυτή, προτείνοντας της χρήση ενός σπειροειδούς μοντέλου (Εικόνα 9) στο οποίο είναι δυνατός ο συνδυασμός των δραστηριοτήτων ανάπτυξης με τη διαχείριση των κινδύνων προκειμένου να ελαχιστοποιηθούν και να ελεγχθούν οι πιθανοί κίνδυνοι. Στο σπειροειδές μοντέλο διακρίνονται τέσσερις κατηγορίες εργασιών : προσδιορισμός στόχων, εντοπισμός και επίλυση 42

44 κινδύνων, εκτέλεση διαδικασιών ανάπτυξης καθώς και εργασίες προγραμματισμού. (Pfleeger, 2003) Κατά τον προσδιορισμό των στόχων καθορίζονται τα αντικείμενα εργασιών κάθε επανάληψης, καταγράφονται οι περιορισμοί επί του προϊόντος, αλλά και επί της διαδικασίας για την οποία κατασκευάζεται ένα αναλυτικό πλάνο διοίκησης. Επίσης καταγράφονται οι κίνδυνοι που εμπεριέχει η διαδικασία και οι εναλλακτικές λύσεις, όπου υπάρχουν. Κατά τις εργασίες επίλυσης κινδύνων αναλύονται οι κίνδυνοι που έχουν καταγραφεί και αποτιμάται κάθε εναλλακτική λύση. Στο σημείο αυτό λαμβάνονται αποφάσεις για τη συνέχιση ή όχι της ανάπτυξης, για το μοντέλο που θα ακολουθηθεί στη συγκεκριμένη επανάληψη, για την κατασκευή ή όχι πρωτοτύπου και άλλα. Εικόνα 9: Το σπειροειδές μοντέλο Ακολουθεί η εκτέλεση των βημάτων της διαδικασίας ανάπτυξης λογισμικού που έχει επιλεγεί για το τμήμα εκείνο του συστήματος που αφορά η τρέχουσα επανάληψη. Τέλος, μετά την επαλήθευση των αποτελεσμάτων-ενδιάμεσων προϊόντων λογισμικού γίνεται προγραμματισμός της συνέχισης της ανάπτυξης. Πρόκειται για μια γενίκευση των μοντέλων της λειτουργικής επαύξησης και της πρωτυποποίησης με σημαντικά νέα στοιχεία: 43

45 Οι φάσεις και οι διαδικασίες ανάπτυξης λογισμικού δεν είναι προκαθορισμένες από το μοντέλο, αλλά εξειδικεύονται στο χώρο της εφαρμογής του. Η ανάπτυξη ολόκληρου του συστήματος χωρίζεται σε πολλούς κύκλους, σε καθέναν από τους οποίους προστίθενται νέα λειτουργικά χαρακτηριστικά στο σύστημα. Πριν από την έναρξη κάθε κύκλου γίνεται μια μελέτη σκοπιμότητας και ανάλυση κινδύνων, από την οποία προκύπτουν, αφενός, οι συγκεκριμένες εργασίες που θα εκτελεστούν μέσα στον κύκλο, αφετέρου, η ίδια η εφικτότητα εκτέλεσης του κύκλου αυτού. (Βεσκούκης, 2000) Ενοποιημένη Προσέγγιση (Unified Process) Η ενοποιημένη προσέγγιση είναι ένα δημοφιλές επαναληπτικό (iterative) και αυξητικό(incremental) πλαίσιο για τη διαδικασία ανάπτυξης λογισμικού. Ο στόχος της είναι να διασφαλίσει την παραγωγή λογισμικού υψηλής ποιότητας που ικανοποιεί τις ανάγκες των τελικών χρηστών μέσα σε ένα συγκεκριμένο χρονοδιάγραμμα και κόστος. Εμφανίστηκε για πρώτη φορά το1998 ως RUP 5.0 ως μετεξέλιξη παλαιότερων εκδόσεων. Φτιάχτηκε στην εταιρεία Rational, η οποία δεν υπάρχει πια καθώς εξαγοράστηκε το 2002 από την IBM. H ενοποιημένη προσέγγιση βασίζεται: (Jacobson) στο καλό χειρισμό των απαιτήσεων με το μοντέλο των περιπτώσεων χρήσης (Use case driven) στην ανάπτυξη της αρχιτεκτονικής του συστήματος ως βασικό συστατικό επιτυχίας (Architecture-centric) στη γραφική ανάπτυξη με χρήση UML (Η UP είναι ένας οδηγός για το πώς θα χρησιμοποιηθεί αποτελεσματικά η UML) σε επαναληπτική διαδικασία ανάπτυξης (iterative development) και αυξητική (incremental development) Ο κύκλος ζωής του λογισμικού στη UP υποδιαιρείται σε τέσσερις συνεχόμενες φάσεις (Εικόνα 10), καθεμία από τις οποίες ολοκληρώνεται με την παράδοση κάποιων ορόσημων (milestones). 44

46 Εικόνα 10: Ο κύκλος ζωής της ενοποιήμενης προσέγγισης και τα ορόσημα κάθε φάσης. Οι φάσεις του κύκλου ζωής είναι όπως φαίνεται και από το παραπάνω σχήμα: (Pressman, 2005) Σύλληψη (inception): Ορίζεται το όραμα του συστήματος, η στρατηγική που θα ακολουθηθεί, οι υψηλού επιπέδου απαιτήσεις και περιπτώσεις χρήσεις, οι κίνδυνοι, τα κέρδη και κάποιες αρχικές εκτιμήσεις για το κόστος και τη διάρκεια των εργασιών ανάπτυξης. Επεξεργασία (elaboration): Αναπτύσσονται οι στρατηγικοί στόχοι του συστήματος, γίνεται καταγραφή και ανάλυση των απαιτήσεων, αναπτύσσεται η βασική αρχιτεκτονική του συστήματος, αντιμετωπίζονται οι κίνδυνοι και μελετώνται περαιτέρω οι προβλέψεις για κόστος, χρόνο και πόρους του έργου. Κατασκευή (construction): Υλοποίηση του προϊόντος. Μετάβαση (transition): Είναι η φάση κατά την οποία το τελικό προϊόν δίνεται στον πελάτη. Στο κάτω μέρος των βέλων δίνονται οι ονομασίες των οροσήμων κάθε φάσης. Στο τέλος κάθε φάσης πραγματοποιείται μια αποτίμηση η οποία κρίνει εάν οι στόχοι της φάσης έχουν ικανοποιηθεί προκειμένου να αρχίσει η επόμενη φάση. Η UP για να περιγράφει το σύνολο των εργασιών της χρησιμοποιεί την έννοια της ροής εργασίας. (workflow). Μια ροή εργασίας είναι μια λογική ομαδοποίηση δραστηριοτήτων η οποία περιγράφεται με: (Jacobson) Ρόλους Ποιος κάνει τι; 45

47 Δραστηριότητες (activities) ένα κομμάτι δουλειάς που έχει ένα διακριτό αποτέλεσμα Αποτελέσματα (artifacts) Τα αποτελέσματα των δραστηριοτήτων μπορεί να είναι παραδοτέα (deliverables), έγγραφα, κώδικας, πρότυπα Οι ροές εργασίας είναι οι εξής: Βασικές ροές εργασιών Σχεδιασμός επιχειρηματικών διαδικασιών Απαιτήσεις Ανάλυση και Σχεδιασμός Υλοποίηση Έλεγχος Διάταξη Υποστηρικτικές ροές εργασιών Διαχείριση Σχηματισμών Διαχείριση έργου Περιβάλλον Η Εικόνα 11 είναι ιδιαίτερα σημαντική καθώς συσχετίζει τις φάσεις με τις ροές εργασιών. Παρατηρούμε ότι σε κάθε φάση εκτελούνται όλες οι ροές εργασίας, άλλες σε μεγαλύτερο και άλλες σε μικρότερο βαθμό. Δηλαδή είναι λογικότερο στη φάση της σύλληψης να εκτελείται σε μεγαλύτερο βαθμό ο σχεδιασμός των επιχειρηματικών διαδικασιών και σε μικρότερο βαθμό η υλοποίηση. 46

48 Εικόνα 11: Ο συνδυασμός των φάσεων και των ροών εργασιών στην UP. Ευέλικτες Προσεγγίσεις (Agile Approaches) Το μεγαλύτερο μέρος της ανάπτυξης λογισμικού είναι μια χαοτική ενέργεια, που συχνά χαρακτηρίζεται από την προσέγγιση code and fix. Το λογισμικό παράγεται πολλές φορές χωρίς ιδιαίτερο σχεδιασμό και από πολλές βραχυπρόθεσμες αποφάσεις. Αυτός ο τρόπος ανάπτυξης έχει κάποια αποτελέσματα εφόσον το σύστημα είναι μικρό, αλλά καθώς το σύστημα μεγαλώνει γίνεται ιδιαίτερα δύσκολο να προστεθούν νέα χαρακτηριστικά στο προϊόν ή να διορθωθούν λάθη. Η αρχική προσπάθεια που έγινε εισήγαγε την έννοια της μεθοδολογίας. Αυτές οι μεθοδολογίες επιβάλουν μια «πειθαρχημένη» διεργασία πάνω στην ανάπτυξη του λογισμικού με σκοπό να κάνουν την ανάπτυξη λογισμικού πιο προβλέψιμη και αποδοτική. Αυτό το επιτυγχάνουν αναπτύσσοντας μια λεπτομερής διεργασία με μια ιδιαίτερη έμφαση στο σχεδιασμό, κάτι που το δανείζονται από άλλες τεχνολογικές προσεγγίσεις (engineering methodologies) γι αυτό και συχνά αποκαλούνται με τον όρο engineering methodologies, άλλες ονομασίες τους είναι βαριές μεθοδολογίες (heavy methodologies) ή μεθοδολογίες οδηγημένες από το σχεδιασμό. (plan driven methodologies) Οι μεθοδολογίες αυτές επικρατούσαν στο χώρο για πολύ μεγάλο χρονικό διάστημα και επικρατούν ακόμα. Ωστόσο, η αλήθεια είναι ότι πολλά έργα λογισμικού 47

49 αποτυγχάνουν και ο πιο συχνή κριτική που γίνεται σε αυτές τις προσεγγίσεις είναι η γραφειοκρατία τους. Οι ευέλικτες προσεγγίσεις αναπτύχθηκαν σαν αντίδραση σε αυτές τις μεθοδολογίες και αυτό που προσπαθούν να πετύχουν είναι να συμβιβάσουν την έννοια της διεργασίας με την «υπερβολική διεργασία», παρέχοντας απλώς τα απαραίτητα έτσι ώστε να επιτευχθεί το επιθυμητό αποτέλεσμα. Η μεγαλύτερη διαφορά τους είναι ότι απαιτούν λιγότερα έγγραφα (document oriented) και λιγότερη τεκμηρίωση για μια δεδομένη δραστηριότητα. Στηρίζονται περισσότερο στον κώδικα, ακολουθώντας μια πορεία που λέει ότι το βασικό κλειδί της τεκμηρίωσης είναι ο κώδικας. (Fowler, 2005) Xp programming Αυτή η προσέγγιση αναπτύχθηκε από τα προβλήματα που δημιουργήθηκαν από τους μεγάλους κύκλους ανάπτυξης των παραδοσιακών μοντέλων ανάπτυξης. Αρχικά ξεκίνησε σαν μια ευκαιρία να γίνει «η δουλειά γρήγορα» βασισμένη σε πρακτικές που αποδείχθηκαν αποτελεσματικές στις διεργασίες ανάπτυξης λογισμικού παλαιότερα. Μετά από έναν αριθμό επιτυχημένων δοκιμών στην πράξη, η XP μεθοδολογία βασίστηκε πάνω στις πρακτικές και στις αρχές που ήταν κλειδιά στην ανάπτυξη λογισμικού. Ο όρος «extreme προέρχεται από το ότι χρησιμοποιούντα όλες αυτές οι πρακτικές σε υπερβολικό extreme βαθμό. Εικόνα 12: Το μοντέλο "XP Programming" 48

50 Η κύκλος ζωής (Εικόνα 12) αποτελείται από έξι φάσεις: Εξερεύνηση (Exploration), Σχεδιασμός (Planning), Επαναλήψεις μέχρι την έκδοση (Iterations to release), Παραγωγή (Productionizing), Συντήρηση (Maintenance) και Θάνατος (Death). (Abrahamsson, Salo, & Ronkainen, 2002) Στη φάση της Εξερεύνησης, ο πελάτης συμπληρώνει τις λεγόμενες «story cards» με τα χαρακτηριστικά που θέλει να ενσωματωθούν στην πρώτη έκδοση. Από την άλλη πλευρά, η ομάδα λογισμικού οικειοποιείται με τα εργαλεία, την τεχνολογία και τις πρακτικές που πρόκειται να χρησιμοποιηθούν στο έργο. Η τεχνολογία που πρόκειται να χρησιμοποιηθεί θα ελεγχθεί, όπως και οι δυνατές αρχιτεκτονικές με τη δημιουργία ενός πρωτοτύπου. Η φάση αυτή λαμβάνει χώρα από λίγες εβδομάδες μέχρι και λίγους μήνες. Η φάση Σχεδιασμού θέτει τη σειρά των προτεραιοτήτων των χαρακτηριστικών του έργου και τη συμφωνία για τα περιεχόμενα της πρώτης μικρής έκδοσης. Οι προγραμματιστές εκτιμούν τις ανθρωποώρες της πρώτης έκδοσης διότι το χρονοδιάγραμμα της πρώτης έκδοσης δεν θα πρέπει να ξεπερνά τους δύο μήνες. Αυτή η φάση διαρκεί λίγες μέρες. Η φάση που ονομάζεται Επαναλήψεις μέχρι την Έκδοση (Iterations to release) περιλαμβάνει μερικές επαναλήψεις του συστήματος μέχρι την πρώτη έκδοση. Το χρονοδιάγραμμα που είχε καθοριστεί στη φάση σχεδιασμού χωρίζεται σε έναν αριθμό επαναλήψεων, κάθε μια από τις οποίες θα διαρκέσεις από μία έως τέσσερις εβδομάδες για να υλοποιηθεί. Η πρώτη επανάληψη δημιουργεί ένα σύστημα με την αρχιτεκτονική ολόκληρου του συστήματος. Στη συνέχεια ο πελάτης αποφασίζει ποια θα είναι τα χαρακτηριστικά που θα προστεθούν σε κάθε μία επανάληψη που ακολουθεί. Οι λειτουργικοί έλεγχοι που δημιουργήθηκαν από τον πελάτη πραγματοποιούνται στο τέλος κάθε επανάληψης. Στο τέλος της τελευταίας επανάληψης το σύστημα είναι έτοιμο για παραγωγή. Η φάση παραγωγής (Productioninzing Phase) απαιτεί επιπλέον έλεγχο της απόδοσης του συστήματος πριν το σύστημα παραδοθεί στον πελάτη. Σε αυτήν τη φάση, μπορεί να εμφανιστούν νέες αλλαγές και η απόφαση που θα πρέπει να παρθεί είναι αν το αν αυτές θα συμπεριληφθούν στην παρούσα έκδοση. Κατά τη διάρκεια αυτής της φάση, οι επαναλήψεις μπορεί να χρειασθεί να συντομευθούν από τις τρεις στην μία εβδομάδα. Οι προτεινόμενες ιδέες και προτάσεις λαμβάνονται υπόψη για υλοποίηση στο μέλλον, για παράδειγμα κατά τη φάση της συντήρησης. Μετά την παραγωγή της πρώτης έκδοσης, το έργο θα πρέπει από την μία πλευρά να κρατήσει το σύστημα στην παραγωγή «τρέχοντάς» το συνεχώς, και από 49

51 την άλλη πλευρά να συνεχίσει σε νέες επαναλήψεις. Προκειμένου να το πετύχει αυτό, η φάση της Συντήρησης (Maintenance Phase) απαιτεί προσπάθεια και από την πλευρά του πελάτη. Έτσι, η ταχύτητα της ανάπτυξης του συστήματος ίσως μειωθεί σε αυτήν την φάση. Στη φάση αυτή, επίσης, ίσως απαιτηθεί η ενσωμάτωση νέων μελών στην ομάδα, με αποτέλεσμα να αλλάξει η δομή της. Η φάση Θανάτου (Death Phase) είναι κοντά όταν ο πελάτης δεν έχει να προσθέσει αλλά χαρακτηριστικά στο σύστημα, κάτι που σημαίνει ότι το σύστημα καλύπτει πλήρως τις ανάγκες του πελάτη. Αυτή είναι η στιγμή, που στη διεργασία XP συντάσσονται τα έγγραφα της τεκμηρίωσης του συστήματος καθώς δεν θα πραγματοποιηθούν άλλες αλλαγές στην αρχιτεκτονική, στο σχεδιασμό ή στον κώδικα. Ο θάνατος μπορεί να συμβεί επίσης εάν το σύστημα δεν αποδίδει τα αναμενόμενα αποτελέσματα ή εάν η συνέχισή του κριθεί ασύμφορη. Scrum Scrum (το όνομα προέρχεται από ένα όρο του ράγκμπι) είναι ένα μοντέλο που ανήκει στην οικογένεια των ευέλικτων (agile) προσεγγίσεων, το οποίο αναπτύχθηκε από το Jeff Sutherland και την ομάδα του στις αρχές τις δεκαετίας Τα χαρακτηριστικά του είναι: (Origins of Scrum, 1996) Δημιουργούνται μικρές ομάδες εργασίας με στόχο να μεγιστοποιηθεί η επικοινωνία και η διακίνηση άρρητης και ανεπίσημης γνώσης. Η διαδικασία οφείλει να είναι προσαρμόσιμη και σε τεχνικές και σε επαγγελματικές αλλαγές. Η διαδικασία οφείλει να μπορεί να ανταποκρίνεται σε συχνές προσθετικές ενέργειες, οι οποίες θα πρέπει να εντοπίζονται, να τροποποιούνται, να ελέγχονται και τέλος να υλοποιούνται. Θα πρέπει να υπάρχει σωστή κατάτμηση της εργασίας και των ομάδων εργασίας. Ο έλεγχος και η τεκμηρίωση πραγματοποιούνται σε όλη τη διάρκεια του έργου. Τα δύο σημαντικότερα στοιχεία που υποστηρίζει το Scrum είναι η ενδυνάμωση της ομάδας (team empowerment) και η προσαρμοστικότητα (adaptability): (Charvat, 2003) Ενδυνάμωση της ομάδας. Όταν ανατίθεται εργασία στις ομάδες, τότε αυτές είναι πλέον υπεύθυνες να βρουν τον τρόπο να φέρουν σε πέρας την εργασία 50

52 που τους παραδόθηκε. Όταν η ομάδα εργάζεται, η μόνη αλληλεπίδραση που έχει με την διοίκηση είναι να τον πληροφορήσει για το οποιοδήποτε πρόβλημα αντιμετωπίζει, τότε η διοίκηση αποφασίζει αν θα πρέπει να αλλάξει κάτι με απώτερο στόχο πάντα να αυξηθεί η παραγωγικότητα. Προσαρμοστικότητα: Το Scrum χρησιμοποιεί μια διακοπτόμενη ισορροπία. (punctuated equilibrium). Το έργο διατηρεί την ισορροπία του συνεχίζοντας την προσπάθεια για την επίτευξη των στόχων του ενώ απομονώνεται από εξωτερικούς παράγοντες. Κάθε 30 μέρες, η ομάδα του έργου και η διοίκηση προγραμματίζουν τι θα γίνει τις επόμενες 30 μέρες. Αυτή η απόφαση παίρνεται λαμβάνοντας υπόψη τι η ομάδα έχει επιτύχει μέχρι τώρα και τις νέες αλλαγές που εμφανίζονται. 51

53 Βοηθητικές Διαδικασίες (Umbrella Processes) Διοίκηση Ποιότητας (Quality Management) Έχουν δοθεί πολλοί ορισμοί για τον όρο ποιότητα. Για τον Phil Crosby (1979) πρόκειται για «τη συμμόρφωση προς τις απαιτήσεις του χρήστη». Πρόσφατα, η ποιότητα ορίστηκε(iso 9001:2000, 1994) ως «ο βαθμός στον οποίο ένα σύνολο από χαρακτηριστικά τηρούν τις απαιτήσεις.» Σε αυτό το σημείο θα πρέπει να διαφοροποιήσουμε την ποιότητα της διαδικασίας από την ποιότητα του προϊόντος. Φυσικά, δεν είναι δυνατόν να τις ξεχωρίσουμε τελείως μεταξύ τους καθώς η ποιότητα της διαδικασίας επηρεάζει την ποιότητα των χαρακτηριστικών του προϊόντος λογισμικού, η οποία με τη σειρά της επηρεάζει την ποιότητα της χρήσης του προϊόντος, όπως την αντιλαμβάνεται ο πελάτης. Παράγοντες ποιότητας λογισμικού Οι παράγοντες αυτοί μπορούν να χωρισθούν σε δύο κύριες κατηγορίες: (1) σε παράγοντες που μπορούν να μετρηθούν άμεσα (π.χ. λάθη\kloc\unit-time) και (2) σε παράγοντες που μπορούν να μετρηθούν έμμεσα (π.χ. ευχρηστία ή συντηρησιμότητα). Σε κάθε περίπτωση πρέπει να συμβούν μετρήσεις. Πρέπει να συγκρίνουμε το λογισμικό (έγγραφα, προγράμματα, κ.λ.π.) με κάποια δεδομένα και να καταλήξουμε σε κάποια ένδειξη ποιότητας. Ο McCall και οι συνεργάτες του (1997) προτείνανε μια χρήσιμη κατηγοριοποίηση των παραγόντων που επηρεάζουν την ποιότητα του λογισμικού. Αυτοί οι παράγοντες ποιότητας λογισμικού, όπως φαίνεται και στην Εικόνα 13 εστιάζονται σε τρεις σημαντικές πλευρές ενός λογισμικού προϊόντος: στα λειτουργικά χαρακτηριστικά του, στην ικανότητά του να υποστεί αλλαγές, και στην προσαρμοστικότητά του σε νέα περιβάλλοντα. Αναφορικά με το σχήμα έχουμε τις ακόλουθες περιγραφές: Ορθότητα (Correctness). Ο βαθμός κατά τον οποίο ένα πρόγραμμα ικανοποιεί τις προδιαγραφές του και ικανοποιεί τους αντικειμενικούς στόχους του πελάτη (κάνει αυτό που θέλω;). Αξιοπιστία (Reliability). Ο βαθμός κατά τον οποίο ένα πρόγραμμα μπορεί να αναμένεται να εκτελέσει τις λειτουργίες του με την απαιτούμενη ακρίβεια (λειτουργεί σωστά πάντα;). 52

54 Αποδοτικότητα (Efficiency). Ο όγκος υπολογιστικών πόρων και κώδικα που απαιτούνται από ένα πρόγραμμα για να εκτελέσει τη λειτουργία του (θα τρέξει το υλικό που έχω, όσο πιο αποδοτικά γίνεται;). Ακεραιότητα (Integrity). Ο βαθμός κατά τον οποίο ελέγχεται η πρόσβαση σε λογισμικό ή σε δεδομένα από μη εξουσιοδοτημένα άτομα (είναι ασφαλές;). Ευκολία Χρήσης (Usability). Η απαιτούμενη προσπάθεια για τη μάθηση, τη λειτουργία, την προετοιμασία της εισόδου και τη μεταγλώττιση της εξόδου ενός προγράμματος (μπορώ να το τρέξω;). Συντηρησιμότητα (Maintainability). Η απαιτούμενη προσπάθεια για την εύρεση και επιδιόρθωση ενός λάθους σε ένα πρόγραμμα (μπορώ να το διορθώσω;). Ευελιξία (Flexibility). Η απαιτούμενη προσπάθεια για τη μεταβολή ενός λειτουργούντος προγράμματος (μπορώ να το αλλάξω;). Ελεγξιμότητα (Testability). Η απαιτούμενη προσπάθεια για τον έλεγχο ενός προγράμματος έτσι ώστε να διασφαλιστεί ότι επιτελεί την προγραμματισμένη λειτουργία (μπορώ να το ελέγξω;). Μεταφερσιμότητα (Portability). Η απαιτούμενη προσπάθεια για την μεταφορά ενός προγράμματος από ένα περιβάλλον υλικού και\ή λογισμικού σε άλλο (μπορώ να το μεταφέρω σε άλλο μηχάνημα;). Επαναχρησιμοποίηση (Reusability). Ο βαθμός κατά τον οποίο ένα πρόγραμμα (ή τμήματα αυτού) μπορεί να επαναχρησιμοποιηθεί σε άλλες εφαρμογές (μπορώ να επαναχρησιμοποιήσω μέρος του λογισμικού;). Διαλειτουργικότητα (Interoperability). Η προσπάθεια που απαιτείται για να κάνουμε το πρόγραμμα να δουλέψει μαζί με κάποιο άλλο (θα μπορέσω να το βάλω να λειτουργήσει μαζί με κάποιο άλλο σύστημα;). 53

55 Συντηρησιμότητα Ευελιξία Ελεγξιμότητα Μεταφερσιμότητα Επαναχρησιμοποίηση Διαλειτουργικότητα Ικανότητα Αλλαγής Προσαρμοστικότητα Λειτουργικά Χαρακτηριστικά Ορθότητα Αξιοπιστία Αποδοτικότητα Ακεραιότητα Ευκολία Χρήσης Εικόνα 13: Παράγοντες ποιότητας λογισμικού του McCall. Διοικητικές Διαδικασίες για την ποιότητα του λογισμικού. ( Software Quality Management Processes) Η διοίκηση της ποιότητας λογισμικού (Software quality management (SQM)) εφαρμόζεται σε όλες τις όψεις των διαδικασιών λογισμικού, προϊόντων και πόρων λογισμικού. Καθορίζει τις διαδικασίες, τους υπεύθυνους των διαδικασιών, τις απαιτήσεις για αυτές τις διαδικασίες, καθώς και τα μέτρα και τα αποτελέσματά τους. Οι διαδικασίες της διοίκησης για την ποιότητα λογισμικού αποτελούνται από πολλές δραστηριότητες (activities). Η διοίκηση για την ποιότητα λογισμικού μπορεί να χρησιμοποιηθεί για να εκτιμήσει και τα ενδιάμεσα και τα τελικά προϊόντα. Κάποιες από διαδικασίες της διοίκησης της ποιότητας λογισμικού είναι: (IEEE ) Η διαδικασία για την εξασφάλιση της ποιότητας (Quality assurance process): Η εξασφάλιση ποιότητας είναι μια δραστηριότητα που απασχολεί γενικότερα κάθε επιχείρηση. Η SQA ομάδα λειτουργεί ως ο εκπρόσωπος του πελάτη. Αυτό σημαίνει ότι αντιμετωπίζουν το λογισμικό από την πλευρά του πελάτη. Η εξασφάλιση της ποιότητας εμπεριέχει ένα αριθμό από εργασίες που σχετίζονται με επτά βασικές δραστηριότητες: (1) εφαρμογή τεχνικών μεθόδων, (2) πραγματοποίηση τυπικών τεχνικών επιθεωρήσεων, (3) έλεγχο του λογισμικού, (4) επιβολή προτύπων, (5) έλεγχος των αλλαγών, (6) 54

56 μετρήσεις και (7) δημιουργία πρακτικών και αναφορών σχετικών με την πορεία του έργου Η διαδικασία της επαλήθευσης (verification process) & η διαδικασία της επικύρωσης (validation process): Η διαδικασία αυτή εκτιμά τα προϊόντα λογισμικού σε όλη τη διάρκεια του κύκλου ζωής του προϊόντος και είναι αυτή που προσπαθεί να διασφαλίσει ότι το λογισμικό ικανοποιεί τις απαιτήσεις του χρήστη. Χρησιμοποιεί τεχνικές ελέγχου οι οποίες μπορούν να εντοπίσουν ελαττώματα. Επίσης, εκτιμά τα ενδιάμεσα προϊόντα και φυσικά τα ενδιάμεσα βήματα για την παραγωγή του λογισμικού. Η διαδικασία της επιθεώρησης (Review process) και η διαδικασία του ελέγχου (Audit process). Στο πρότυπο IEEE περιέχονται πέντε τύποι επιθεωρήσεων και ελέγχων. Είναι τεχνικές που στοχεύουν στη μείωση του αριθμού των λαθών που περνούν από τη μια στην επόμενη φάση της διαδικασίας ανάπτυξης. Διοικητικές Επιθεωρήσεις (Management reviews) Τεχνικές επιθεωρήσεις (Technical reviews) Επιθεωρήσεις (Inspections) Περάσματα (Walk-throughs) Έλεγχοι (Audits) Αυτές οι διαδικασίες βοηθούν στην επίτευξη της ποιότητας και επίσης βρίσκουν πιθανά προβλήματα. Αλλά διαφέρουν μεταξύ τους στην έμφαση που δίνουν σε διάφορα σημεία. Αυτές οι διαδικασίες είναι στενά συνδεδεμένες μεταξύ τους, πολλές φορές αλληλεπικαλύπτονται και άλλες φορές συνδυάζονται. Διαχείριση Κινδύνων (Risk Management) Τα πιο πολλά έργα ανάπτυξης λογισμικού χαρακτηρίζονται από υψηλό επίπεδο καινοτομίας και ρίσκων, τα οποία με τη σειρά τους δημιουργούν δυσκολία στους διοικητές του έργου να προβλέψουν τις δυσκολίες που μπορεί να συναντήσουν στην πορεία του έργου. Η έννοια του κινδύνου είναι θεμελιώδης στη διοίκηση έργου. Κίνδυνος είναι η πιθανότητα να συμβεί ένα καθορισμένο μη επιθυμητό γεγονός μέσα σε συγκεκριμένο χρονικό διάστημα ή κάτω από συγκεκριμένες συνθήκες. Η Διαχείριση Κινδύνων εστιάζει στις δραστηριότητες που απαιτούνται για να 55

57 αναγνωριστούν με επιτυχία, να αναλυθούν, και να ελεγχθούν τα ρίσκα του έργου ανάπτυξης λογισμικού. Οι κίνδυνοι συμπεριλαμβάνουν πάντα δύο χαρακτηριστικά: (Higuera & Haimes, 1996) Την αβεβαιότητα: ο κίνδυνος ενδέχεται να συμβεί ή ενδέχεται να μην συμβεί. Απώλεια: εάν ο κίνδυνος γίνει πραγματικότητα, αρνητικές συνέπειες ή απώλειες θα λάβουν χώρα. Κατηγορίες Κινδύνων (Pressman, 2005) Κίνδυνοι Έργων (Project Risks): Απειλούν το πλάνο του έργου (project plan). Εάν ο κίνδυνος γίνει πραγματικός, είναι πιθανό το χρονοδιάγραμμα του έργου να μην μπορεί πλέον να ακολουθηθεί και τα αντίστοιχα κόστη να αυξηθούν. Αφορούν συνήθως, το χρονοδιάγραμμα, το προσωπικό, τους πόρους, τους μετόχους, τα προβλήματα των απαιτήσεων και την επίδρασή τους στο έργο. Τεχνικοί Κίνδυνοι (Technical Risks): Απειλούν την ποιότητα και το χρόνο ολοκλήρωσης του υπό ανάπτυξη λογισμικού. Εάν ένας τεχνικός κίνδυνος γίνει πραγματικότητα η υλοποίηση μπορεί να γίνει δύσκολη έως και αδύνατη. Οι τεχνικοί κίνδυνοι αφορούν συνήθως προβλήματα της σχεδίασης, της υλοποίησης, της συντήρησης κ.α. Επιχειρησιακοί Κίνδυνοι (Business Risks): Απειλούν τη βιωσιμότητα του λογισμικού. Οι πέντε συχνότεροι επιχειρησιακοί κίνδυνοι είναι: Η δημιουργία ενός προϊόντος που κανείς δεν θέλει να το αγοράσει Η δημιουργία ενός προϊόντος που δεν ταιριάζει πλέον στη συνολική επιχειρησιακή στρατηγική της εταιρείας Η δημιουργία ενός προϊόντος που το τμήμα πωλήσεων δεν ξέρει πώς να το προωθήσει Να χάνεις την υποστήριξη της κεντρικής διοίκησης Να χάνεις την αφοσίωση του προσωπικού ή της χρηματοδότησης. Οι κίνδυνοι μπορούν επίσης να ομαδοποιηθούν άμεσα ή έμμεσα. Οι έμμεσοι κίνδυνοι είναι αυτοί στους οποίους η ομάδα του έργου έχει λίγο ή καθόλου έλεγχο. Αντίθετα, οι άμεσοι κίνδυνοι είναι αυτοί στους οποίους η ομάδα εργασίας έχει έλεγχο σε μεγάλο βαθμό, για παράδειγμα, μη ακριβές πρόγραμμα, έλλειψη προϋπολογισμού, μη επαρκές είσοδο για προσπάθεια. 56

58 Αναγνώριση των κινδύνων Η αναγνώριση των κινδύνων είναι μια συστηματική προσπάθεια να καθοριστούν οι απειλές για το πλάνο του έργου. Αναγνωρίζοντας γνωστούς και προβλέψιμους κινδύνους ο διευθυντής του έργου κάνει ένα πρώτο βήμα στη διαδικασία που ονομάζεται έλεγχος του ρίσκου και αποφυγή του. Μία μέθοδος για την αναγνώριση των κινδύνων είναι η δημιουργία μια λίστας κινδύνων (risk item checklist). Ένας μεγάλος αριθμός λιστών για κινδύνους σε έργα λογισμικού παρέχονται στη βιβλιογραφία. Ανάλυση των κινδύνων Η ανάλυση των κινδύνων ή αλλιώς εκτίμηση των κινδύνων (risk estimation) είναι η διαδικασία κατά την οποία κάθε ρίσκο αναλύεται ως εξής: Στην πιθανότητα ότι ο κίνδυνος θα συμβεί στην πραγματικότητα Στις συνέπειες που θα επέλθουν. Ο σκοπός αυτών των βημάτων είναι να βαθμολογηθούν οι κίνδυνοι με βάση την προτεραιότητά τους. Καμία ομάδα λογισμικού δεν έχει τους πόρους να διαχειριστεί κάθε πιθανό κίνδυνο. Έτσι λοιπόν προσπαθεί να εντοπίσει αυτούς που έχουν τη μεγαλύτερη πιθανότητα εμφάνισης και αυτούς που θα έχουν τη μεγαλύτερη επίδραση στο έργο. Κίνδυνος Κατηγορία Πιθανότητα Επίδραση Πίνακας 3: Πίνακας για ανάλυση κινδύνων Έτσι λοιπόν δημιουργείται ένας πίνακας (Πίνακας 3) όπου αναγράφονται όλοι οι κίνδυνοι, η κατηγορία στην οποία ανήκουν (επιχειρηματικός κίνδυνος, τεχνικός κίνδυνος κ.τ.λ.), η πιθανότητα εμφάνισης του κινδύνου και τέλος η επίδραση του ( καθορίζεται μια βαθμίδα βαθμολόγησης για παράδειγμα από το 1-10). Ο διευθυντής του έργου μελετά τον παραπάνω πίνακα και ορίζει μεταξύ τους μια γραμμή. Όσοι κίνδυνοι βρίσκονται επάνω από την γραμμή θα μελετηθούν περισσότερο και θα δοθούν στρατηγικές για την αντιμετώπισή τους. Ενώ όσοι βρίσκονται κάτω από την γραμμή δεν θα μελετηθούν περεταίρω. 57

59 Ένα άλλο εργαλείο που χρησιμοποιείται είναι η έκθεση στον κίνδυνο (risk exposure), η οποία καθορίζεται από τον εξής τύπο RE=P*C P είναι η πιθανότητα εμφάνισης του κινδύνου C είναι το κόστος που θα προκληθεί στο έργο από την εμφάνισή του Η έκθεση στον κίνδυνο μπορεί να υπολογιστεί για κάθε κίνδυνο στον παραπάνω πίνακα (για όσους βρίσκονται πάνω από την γραμμή) και έτσι να παρέχει ένα μέσο που θα βοηθήσει στον υπολογισμό του συνολικού κόστους του έργου. (Pressman, 2005) Έλεγχος των Κινδύνων Όλες αυτές οι τεχνικές που αναφέρθηκαν παραπάνω θα πρέπει να εφαρμόζονται κατ επανάληψη σε όλη τη διάρκεια του έργου. Η ομάδα του έργου θα πρέπει να επανεξετάζει τον πίνακα κινδύνων σε σύντομα χρονικά διαστήματα, αξιολογώντας ξανά κάθε κίνδυνο και υπολογίζεται κάτω από τις νέες κάθε φορά συνθήκες η πιθανότητα και η επίδρασή του. Σαν συνέπεια, νέοι κίνδυνοι ενδέχεται να προστεθούν στον παραπάνω πίνακα, άλλοι μπορεί να αφαιρεθούν, ενώ άλλοι μπορεί να αλλάξουν θέση στον πίνακα. Όλες οι παραπάνω δραστηριότητες που αναφέρθηκαν παραπάνω έχουν ένα σκοπό, να βοηθήσουν την ομάδα του έργου να αναπτύξει μια στρατηγική για κάθε πιθανό κίνδυνο. Μια αποτελεσματική στρατηγική λαμβάνει υπ όψη της τρία θέματα: Αποφυγή το κινδύνου Παρακολούθηση του κινδύνου Διοίκηση του κινδύνου Μία στρατηγική είναι η αποδοχή του κινδύνου και η συνέχιση με αυτό. Άλλες στρατηγικές είναι πιο υπεύθυνες και κατάλληλες για τη χρήση τους στη διοίκηση έργων ανάπτυξης λογισμικού. Σε περίπτωση που η διοίκηση θέλει να ακολουθήσει μια προληπτική στρατηγική, η αποφυγή είναι πάντα η καλύτερη λύση. Αυτό επιτυγχάνεται, αναπτύσσοντας ένα σχέδιο για άμβλυνση του κινδύνου. Θα πρέπει πάντα να λαμβάνεται υπ όψη ότι όλες αυτές οι δραστηριότητες είναι ένα επιπλέον κόστος για το έργο. Μέρος της διαχείρισης κινδύνου είναι η αξιολόγηση του αν τα πλεονεκτήματα που απορρέουν από τις παραπάνω δραστηριότητες ξεπερνούν τα κόστη της διενέργειάς τους. Η λίστα κινδύνων (Risk List) μίας εργασίας περιέχει όλες τις πληροφορίες και τα αποτελέσματα που παράγονται από τις δραστηριότητες διαχείρισης κινδύνου 58

60 καθ όλο το έργο. Για κάθε κίνδυνο που έχει αναγνωριστεί, η πιθανότητά του να συμβεί όπως και η επίδρασή του στο έργο πρέπει να επαληθευθεί, δείκτες πρέπει να περιγράφουν, και, τέλος οι στρατηγικές μετρίασης και ενδεχομένων πρέπει να σχεδιαστούν. Η λίστα με τους κινδύνους πρέπει να κρατηθεί ενήμερη καθ όλη τη διάρκεια του έργου. Μέτρα για τις Διαδικασίες και τα Έργα Η μέτρηση (measurement) μπορεί να εφαρμοστεί στη διαδικασία ανάπτυξης λογισμικού με σκοπό να τη βελτιώσει σε μια συνεχή βάση. Η μέτρηση μπορεί να χρησιμοποιηθεί σε όλη τη διάρκεια ενός έργου λογισμικού και να βοηθήσει στην εκτίμηση (estimation), στον έλεγχο της ποιότητας, στην εκτίμηση της παραγωγικότητας και τον έλεγχο του έργου. Υπάρχει μια διάκριση των μέτρων. Τα μέτρα της διαδικασίας (process metrics) συλλέγονται από όλα τα έργα και σε μια μακρά περίοδο χρόνου. Ο στόχος του είναι να παρέχουν ένα σύνολο από δείκτες της διαδικασίας που οδηγούν στην μακροπρόθεσμη βελτίωση της διαδικασίας. Τα μέτρα του έργου (project metrics) δίνουν τη δυνατότητα στον υπεύθυνο του έργου να (1) εκτιμήσει την παρούσα κατάσταση ενός έργου, (2) να εντοπίσει πιθανούς κινδύνους, (3) να εντοπίσει προβληματικά σημεία, πριν φθάσουν σε κάποιο σημείο που μετά δεν μπορούν να ξεπεραστούν, (4) να ρυθμίσει τη ροή των εργασιών, (5) να εκτιμήσει την ικανότητα της ομάδας να ελέγχει την ποιότητα των προϊόντων λογισμικού. (Pressman, 2005) Τα μέτρα της διαδικασίας. Σύμφωνα με τους Paulish και Carleton (1994) η διαδικασία είναι μόνο ένας από τους παράγοντες που καθορίζουν την ποιότητα του λογισμικού. 59

61 Προϊόν Χαρακτηριστικά Πελατών Επαγγελματικές Συνθήκες Διαδικασία Άνθρωποι Περιβάλλον Ανάπτυξης Τεχνολογία Εικόνα 14: Παράγοντες που επηρεάζουν την ποιότητα λογισμικού. Η διαδικασία βρίσκεται στο κέντρο ενός τρίγωνου (Εικόνα 14) που συνδέει τρεις παράγοντες που έχουν βασική επιρροή στην ποιότητα του λογισμικού. Η δεξιότητα του ανθρώπινου δυναμικού αποτελεί τον πιο σημαντικό παράγοντα όσον αφορά την ποιότητα και την απόδοση. Η πολυπλοκότητα του προϊόντος και η τεχνολογία (εργαλεία και μέθοδοι της τεχνολογίας λογισμικού) έχουν μια σημαντική επιρροή στην ποιότητα και στην απόδοση της ομάδας. Επιπλέον, το τρίγωνο περικλείεται από ένα κύκλο περιβαλλοντικών συνθηκών, στις οποίες ανήκουν το περιβάλλον ανάπτυξης (για παράδειγμα εργαλεία CASE), οι επαγγελματικές συνθήκες (προθεσμίες, επαγγελματικοί κανόνες) και τα χαρακτηριστικά πελατών (για παράδειγμα συνεργασία). Η αποτελεσματικότητα της διαδικασίας λογισμικού μετριέται έμμεσα. Αυτό σημαίνει, ότι χρησιμοποιείται ένα σύνολο από μέτρα που βασίζονται στα αποτελέσματα που αποκομίζονται από τη διαδικασία. Τα αποτελέσματα αυτά συμπεριλαμβάνουν το σύνολο των λαθών που βρίσκονται πριν την έκδοση του λογισμικού, ελαττώματα που αναφέρονται από τους τελικούς χρήστες, την ανθρώπινη προσπάθεια που καταβλήθηκε, τη συμμόρφωση με το χρονοδιάγραμμα και άλλα μέτρα. Τα μέτρα του Έργου (Project Metrics) Τα μέτρα του έργου χρησιμοποιούνται από τον υπεύθυνο του έργου και την ομάδα για να βοηθήσουν στην προσαρμογή της ροής του έργου και στις τεχνικές δραστηριότητες. Η πρώτη εφαρμογή των μέτρων του έργου στα περισσότερα έργα λογισμικού είναι κατά της διάρκεια της εκτίμησης-estimation. Τα μέτρα που 60

62 συλλέγονται από παλαιότερα έργα χρησιμοποιούνται ως βάση από την οποία γίνονται εκτιμήσεις για την προσπάθεια και το χρόνο των παρόντων έργων. Καθώς το έργο προχωρά, τα μέτρα προσπάθειας και χρόνου συγκρίνονται με τις αρχικές εκτιμήσεις. Ο υπεύθυνος του έργου χρησιμοποιεί αυτά τα δεδομένα για να παρακολουθήσει και να ελέγξει την ομάδα του έργου. Στη συνέχεια, καθώς αρχίζει η τεχνική εργασία άλλα μέτρα του έργου έχουν ιδιαίτερη σημασία. Οι ρυθμοί παραγωγικότητας μετρούνται σε μοντέλα που έχουν δημιουργηθεί, σε παραγόμενες γραμμές κώδικα κ.α. Επιπρόσθετα, αποκαλύπτονται λάθη κατά τη διάρκεια κάθε εργασίας λογισμικού. Καθώς το λογισμικό προχωρά από τις απαιτήσεις στο σχεδιασμό τα μέτρα εκτιμούν την ποιότητα του σχεδιασμού και παρέχουν δείκτες που επηρεάζουν την προσέγγιση που θα χρησιμοποιηθεί για τη δημιουργία του κώδικα και τον έλεγχο. Μέτρα λογισμικού (software measurement) Size-oriented metrics: με βάση το μέγεθος του λογισμικού που έχει παραχθεί π.χ γραμμές κώδικα KLOC (thousand lines of code) Function-oriented metrics: με βάση τη λειτουργικότητα της εφαρμογής Object-oriented metrics: μέτρα για αντικειμενοστραφής εφαρμογές π.χ. number of key classes Use-case oriented metrics: με βάση τις περιπτώσεις χρήσης Web engineering Project Metrics, για παράδειγμα «Αριθμός των στατικών ιστοσελίδων» (Number of static web pages) Μέτρα για την ποιότητα λογισμικού Ο πρωταρχικός στόχος της τεχνολογίας λογισμικού είναι να παράγει ποιοτικά προϊόντα μέσα σε καθορισμένα όρια κόστους και χρόνου. Τα μέτρα της ποιότητας είναι χρήσιμοι δείκτες για την ομάδα λογισμικού και σύμφωνα με το άρθρο του Gilb(1988), Principles of Software Project Management είναι: Ορθότητα (correctness) Συντηρησιμότητα (maintainability) Ενότητα (integrity) Χρησιμότητα (usability) 61

63 Σχεδιασμός του Έργου Λογισμικού Η αποτελεσματική διοίκηση ενός έργου λογισμικού στηρίζεται στο λεπτομερή σχεδιασμό της προόδου του έργου, προβλέποντας προβλήματα που ίσως προκύψουν και προετοιμάζοντας προκαταβολικά πιθανές λύσεις για τα προβλήματα αυτά. Ένα σχέδιο, καταρτισμένο στην αρχή του έργου, θα πρέπει να χρησιμοποιείται σαν οδηγός του έργου. Αυτό το αρχικό σχέδιο δεν είναι στατικό αλλά πρέπει να μεταβάλλεται καθώς το έργο προοδεύει και γίνονται διαθέσιμες περισσότερες πληροφορίες. Η διαδικασία σχεδιασμού ξεκινά με μια εκτίμηση των περιορισμών (απαιτούμενη ημερομηνία παράδοσης, διαθέσιμο προσωπικό, ολικός προϋπολογισμός, κλπ.) που επηρεάζουν το έργο. Η εκτίμηση αυτή πραγματοποιείται σε συνδυασμό με παραμέτρους του έργου όπως η δομή, το μέγεθος και οι διαδικασίες διανομής. Στη συνέχεια ορίζονται τα ορόσημα του έργου και το τι ακριβώς θα παραδοθεί. Ο Σχεδιασμός του προϊόντος μπορεί να χωριστεί σε επιχειρηματικά σχέδια, τα οποία σχετίζονται με τον πελάτη και σε τεχνικά σχέδια, τα οποία χρησιμοποιούνται εσωτερικά από την ομάδα του έργου. Επιχειρηματικός Σχεδιασμός (Business Planning) 1. Καθορισμός Στόχων Οι στόχοι για τη λειτουργία, το κόστος και την τιμή ενός προϊόντος λογισμικού πρέπει να καθοριστούν. Επίσης, θα πρέπει να καθοριστούν οι στόχοι του έργου. 2. Πρόβλεψη ζήτησης για το προϊόν. Ένα προϊόν λογισμικού δημιουργείται με βάση το ότι υπάρχει μια αγορά για αυτό το προϊόν. Δημιουργούνται οι κατάλληλες έρευνες αγοράς προκειμένου να εκτιμηθεί ο προβλεπόμενος αριθμός αγοραστών. αναφερθεί και ως έλεγχος βιωσιμότητας του προϊόντος. 3. Συγγραφή Πρότασης (Proposal writing) Διαφορετικά, μπορεί να Σε πολλά περιβάλλοντα, υπογράφεται ένα συμβόλαιο. Όλη αυτή η διαδικασία ξεκινάει όταν γίνεται μια αίτηση από τον πελάτη για την πρόταση και την τιμή του προϊόντος. 4. Ανάλυση Απαιτήσεων Η ανάλυση των απαιτήσεων είναι ένας πολυσυζητημένος τομέας για τον οποίο πολλά έχουν ειπωθεί. Είναι ιδιαίτερα κρίσιμο σημείο για την επιτυχία του έργου. 62

64 Οι απαιτήσεις του προϊόντος θα πρέπει να αναλυθούν σε τέτοιο βαθμό έτσι ώστε να γίνει κατανοητό ποια είναι τα χαρακτηριστικά το προϊόντος. 5. Νομικά ζητήματα (πατέντα, copyright, νομική ευθύνη, εγγύηση) Οι διευθυντές έργου οφείλουν να έχουν υπόψη τους και νομικά θέματα περί πνευματικής ιδιοκτησίας. Επιπλέον, θα πρέπει να εγγυώνται ότι το λογισμικό καλύπτει κάθε νομική ευθύνη και απαιτήσεις εγγυήσεων. (Tomayko & Hallman, 1989) Τεχνικός Σχεδιασμός 1. Μοντέλα Κύκλου Ζωής Έχουν αναφερθεί παραπάνω. 2. Τύποι Πλάνων Τεκμηρίωση (documentation) Υπάρχει ένας μεγάλος αριθμός πλάνων που αναπτύσσονται κατά τη διάρκεια ενός έργου. Βασικό πλάνο του έργου (program master plan) Πλάνο διοίκησης (management plan) Πλάνο ανάπτυξης (development plan) Πλάνο διοίκησης σχηματιστών (Configuration management plan) Πλάνο ποιότητας (quality assurance plan) Πλάνο Συντήρησης (maintenance plan) Πλάνο Ελέγχου (test plan) Πλάνο Ενοποίησης (integration plan) Πλάνο Εγγράφων (documentation plan) (Tomayko & Hallman, 1989) 63

65 Οντολογία (Ontology) Ορισμοί Οι οντολογίες προτάθηκαν για τη λύση του προβλήματος που δημιουργείται όταν χρησιμοποιούνται διαφορετικοί όροι για την ίδια έννοια ή όταν χρησιμοποιείται ο ίδιος όρος για διαφορετικές έννοιες. Ο όρος «οντολογία» προέρχεται από τη Φιλοσοφία. Για την Τεχνητή Νοημοσύνη το νόημα της λέξης είναι διαφορετικό από αυτό της Φιλοσοφίας. Σύμφωνα με τον Gruber (1993a) και (1993b), «Μια οντολογία είναι μια τυπική (formal), κατηγορηματική (explicit) προδιαγραφή μιας διαμοιρασμένης (shared) εννοιολογικής αναπαράστασης (conceptualization)» 1. Ο όρος «εννοιολογική αναπαράσταση» αναφέρεται σε ένα αφηρημένο μοντέλο φαινόμενων του κόσμου στο οποίο έχουν προσδιοριστεί οι έννοιες που σχετίζονται με τα φαινόμενα αυτά. 2. Ο όρος «κατηγορηματική» σημαίνει ότι το είδος των εννοιών που χρησιμοποιούνται, και οι περιορισμοί που αφορούν την χρήση αυτών των εννοιών είναι προσδιορισμένα με σαφήνεια. 3. όρος «αυστηρή» αναφέρεται στο ότι η οντολογία πρέπει να είναι μηχανικά αναγνώσιμη. 4. Ο όρος «διαμοιρασμένη» αναφέρεται στο ότι η οντολογία πρέπει να αποτυπώνει γνώση κοινής αποδοχής στα πλαίσια μιας κοινότητας Μια οντολογία ορίζει ένα κοινό λεξιλόγια για ερευνητές που μοιράζονται μια ενιαία γνώση σε ένα πεδίο. Περιέχει ορισμούς των βασικών εννοιών του πεδίου και των σχέσεων μεταξύ τους. που γίνονται κατανοητοί από μηχανές. Για την Φιλοσοφία, ο όρος οντολογία σημαίνει μια «συστηματική περιγραφή ύπαρξης». Οι Guarino και Giaretta (1995) πρότειναν η λέξη Οντολογία (με κεφαλαίο Ο) να αναφέρεται στην Φιλοσοφία και η λέξη οντολογία (με μικρό ο) να αναφέρεται στην Τεχνητή Νοημοσύνη. Μία οντολογία είναι η κοινή κατανόηση ενός πεδίου ενδιαφέροντος. Είναι μία σαφής περιγραφή ενός πεδίου και περιέχει: Έννοιες (Concepts) Ιδιότητες των εννοιών (Properties and attributes of concepts) Περιορισμούς στις ιδιότητες (Constraints on properties and attributes) 64

66 Μία οντολογία καθορίζει: Ένα κοινό λεξιλόγιο (A common vocabulary) Μία κοινή κατανόηση (A shared understanding) Μια οντολογία καθορίζει ένα κοινό λεξιλόγιο μεταξύ διαφορετικών συστημάτων. Προσπαθεί να αναγνωρίσει και να ξεπεράσει τα εμπόδια της κοινής κατανόησης της γνώσης και της επαναχρησιμοποίησής της. Επίσης, θα πρέπει να γίνει κατανοητό ότι σε μια οντολογία αναπαρίστανται μόνο έννοιες, όχι λέξεις. Αν και οι οντολογίες αναπαριστούν στατική γνώση πεδίου, είναι γνωστό ότι μια οντολογία εξαρτάται από την εφαρμογή που προκάλεσε την κατασκευή της. Εάν δύο εφαρμογές έχουν σχέση με το ίδιο το πεδίο αλλά οι εργασίες που έχουν να εφαρμόσουν είναι διαφορετικές, τότε είναι φυσικό αυτές οι οντολογίες να διαφέρουν λίγο. Αν και το μεγάλο μέρος των εννοιών είναι συνήθως κοινό, ίσως να είναι καθορισμένο με διαφορετικό τρόπο, σε διαφορετικό επίπεδο λεπτομέρειας ή να αναπαριστά διαφορετικές όψεις ή χαρακτηριστικά της ίδιας έννοιας. Θα πρέπει να τονιστεί ότι δεν υπάρχει ένας και μοναδικός τρόπος οργάνωσης των εννοιών. Υπάρχουν εναλλακτικοί τρόποι. Γιατί κάποιος να αναπτύξει μια οντολογία; Η ψηφιακή πληροφορία μεγαλώνει. Η πρόσβαση, η εύρεση και η σύνοψη της πληροφορίας γίνεται ολοένα και πιο δύσκολη. Το βασικό πρόβλημα: το κενό μεταξύ της σημασίας της πληροφορίας και της καταχωρημένης πληροφορίας. Έτσι λοιπόν μερικοί από τους λόγους είναι οι εξής: (Noy & McGuiness) 1. «Η Κοινή κατανόηση της δομής της πληροφορίας μεταξύ των ανθρώπων ή πρακτόρων λογισμικού» είναι ένας από τους πιο συνηθισμένους λόγους για την ανάπτυξη οντολογιών. (Musen, 1992) Για παράδειγμα, έστω ότι υπάρχει ένας αριθμός από ιστοσελίδες που περιέχουν ιατρικές πληροφορίες ή παρέχουν ιατρικές υπηρεσίες ηλεκτρονικού εμπορίου. Εάν αυτές οι ιστοσελίδες διαθέτουν την ίδια οντολογία για τους όρους που όλες χρησιμοποιούν, τότε οι πράκτορες μπορούν να εξάγουν και να συγκεντρώσουν την πληροφορία από αυτές τις διαφορετικές ιστοσελίδες. Οι πράκτορες μπορούν να χρησιμοποιήσουν αυτή τη συμπυκνωμένη πληροφορία για να απαντήσουν στα ερωτήματα των χρηστών ή για να τη χρησιμοποιήσουν ως είσοδο σε άλλες εφαρμογές. 65

67 2. Η δυνατότητα «επαναχρησιμοποίησης της γνώσης πεδίου» ήταν ένας από τους σημαντικότερους λόγους που ώθησαν την έρευνα για τις οντολογίες. Για παράδειγμα, μοντέλα από πολλά διαφορετικά πεδία χρειάζονται να αναπαραστήσουν την έννοια του χρόνου. Αυτή η αναπαράσταση συμπεριλαμβάνει τις έννοιες των διαστημάτων χρόνου, των σημείων χρόνου, σχετικών μέτρων χρόνου κ.α. Εάν μια ομάδα ερευνητών αναπτύξει μια οντολογία, τότε και άλλοι μπορούν να την χρησιμοποιήσουν στα δικά τους πεδία γνώσης. 3. Σαφή ορισμό των αξιωμάτων μιας γνωστικής περιοχής, έτσι ώστε να είναι δυνατόν εύκολα να γίνουν αλλαγές εξαιτίας αλλαγών που προκύπτουν στο πεδίο της γνώσης. 4. Ο διαχωρισμός της γνώσης πεδίου (domain knowledge) από τη λειτουργική γνώση είναι μια άλλη χρήση των οντολογιών. Μια εργασία διαχωρισμού ενός προϊόντος από τα συστατικά του, σύμφωνα με τις απαιτούμενες προδιαγραφές, και στη συνέχεια η υλοποίηση ενός προγράμματος που κάνει αυτή τη διαμόρφωση ανεξάρτητη από τα προϊόντα και τα επιμέρους συστατικά. (McGuiness & Wright, 1998) Έτσι λοιπόν μπορεί να αναπτυχθεί μια οντολογία που στηρίζεται στα συστατικά ενός υπολογιστή και στα χαρακτηριστικά τους και εφαρμόζει τον αλγόριθμο για να διαμορφώσει τους ζητούμενους υπολογιστές. 5. Η ανάλυση της γνώσης πεδίου γίνεται δυνατή, αφού είναι διαθέσιμη μια λεπτομερής περιγραφή των όρων. Τα βασικά συστατικά μιας Οντολογίας Μια οντολογία συνήθως παίρνει τη μορφή μιας ιεραρχίας συμβόλων. Τα σύμβολα αναπαριστούν τις έννοιες ενός συγκεκριμένου πεδίου. Μερικές φορές αυτή η ιεραρχία αναφέρεται ως ταξινομία και τα σύμβολα αναφέρονται σαν έννοιες, λεξιλόγιο ή όροι. Για να περιορίσει τις πιθανές παρερμηνείες των συμβόλων της, μια οντολογία περιέχει ένα σύνολο από αξιώματα. Αυτά τα αξιώματα εκφράζουν τους περιορισμούς στους οποίους υπόκεινται τα σύμβολα. Έτσι λοιπόν, το πιο σημαντικό μέρος μιας οντολογίας είναι η σημασιολογία που σχετίζεται με τα σύμβολά της. Μια οντολογία αποτελείται από πέντε κατηγορίες συστατικών: 66

68 Κλάσεις (classes): Έννοιες που σχετίζονται με ένα πεδίο ή κάποιες εργασίες, οι οποίες είναι συνήθως οργανωμένες σε κάποιο ταξινομικό σύστημα. Σε μια οντολογία που αφορά το πανεπιστήμιο: ο φοιτητής και ο καθηγητής αποτελούν δύο κλάσεις. Σχέσεις (relations): Ένας τύπος αλληλεπίδρασης μεταξύ εννοιών ενός πεδίου όπως: subclass-of, is-a Συναρτήσεις (functions) μια ειδική περίπτωση σχέσης στην οποία το ν-οστό στοιχείο της σχέσης προσδιορίζεται μοναδικά από τα ν-1 προηγούμενα στοιχεία. Για παράδειγμα, η τιμή-μεταχειρισμένου-αυτοκινήτου μπορεί να προσδιορίζεται σαν συνάρτηση της αρχικής τιμής του καινούριου αυτοκινήτου, του μοντέλου του αυτοκινήτου, των χαρακτηριστικών του αυτοκινήτου και των χιλιομέτρων που έχει διανύσει. Αξιώματα (axioms): αναπαριστούν προτάσεις που είναι πάντα αληθείς παράδειγμα: αν ο Φ είναι δευτεροετής φοιτητής τότε μπορεί να εγγραφεί στο επιλεγόμενο μάθημα Μ. Στιγμιότυπα (instances): αναπαριστούν συγκεκριμένα στοιχεία παράδειγμα: ο φοιτητής με το όνομα Νίκος είναι ένα στιγμιότυπο της κλάσης φοιτητής. Τα παρακάτω συνοψίζουν τα χαρακτηριστικά των οντολογιών : Εξαγωγή συμπερασμάτων (Inferencing) : Είναι η διαδικασία κατά την οποία χρησιμοποιούνται τα αξιώματα/κανόνες (rules/axioms) για τη δημιουργία συμπερασμάτων/κανόνων. Με άλλα λόγια είναι η δημιουργία νέας γνώσης από υπάρχουσα γνώση. Παράδειγμα τέτοιας διαδικασίας αποτελεί η μεταβατικότητα, που επιτρέπει την εξαγωγή συμπερασμάτων του τύπου : IF (Α IS_HIGHER_THAN B) AND (B IS_HIGHER_THAN C) THEN (A IS_HIGHER_THAN C). Επεκτασιμότητα (Extensibility) : Οι ακριβείς ανάγκες στη χρήση είναι δύσκολο να καθοριστούν από την αρχή, για το λόγο αυτό απαιτείται η οντολογία να είναι επεκτάσιμη τόσο ως προς στιγμιότυπα όσο και ως προς έννοιες και σχέσεις. Σαφήνεια (Clarity) : Το στοχευόμενο μήνυμα χρειάζεται να μπορεί να μεταφερθεί αποδοτικά, ελαττώνοντας την ασάφεια. Συνοχή (Coherence) : Η οντολογία πρέπει να διακρίνεται από εσωτερική συνέπεια. Τα αξιώματα ορισμού και οι έννοιες πρέπει να είναι λογικά συνεπή. Ελαχιστοποίηση της οντολογικής δέσμευσης (minimal ontological commitment) : Αναφέρεται στην γενίκευση των αξιωμάτων με τρόπο που να 67

69 αποφεύγεται σαφής αναφορά στον κόσμο που μοντελοποιείται, έτσι ώστε να υπάρχει ελευθερία για εξειδίκευση και εφαρμογή σε συγκεκριμένες περιοχές. Ελαχιστοποίηση της μεροληψίας στην κωδικοποίηση (minimal coding bias) : Η οντολογία πρέπει να στοχεύει στο γνωστικό επίπεδο και όχι στην συμβολική αναπαράσταση της. Ο στόχος είναι να μπορεί να χρησιμοποιηθεί από διαφορετικά συστήματα με διαφορετικές προσεγγίσεις αναπαράστασης. Κληρονομικότητα (Inheritance) : Οι κλάσεις ταξινομούνται στην ιεραρχία με τη σχέση subclass_of κάνοντας την ερώτηση : «αν ένα αντικείμενο είναι instance μιας κλάσης τότε αυτό θα είναι απαραίτητα αντικείμενο και μιας άλλης κλάσης» ή «if a class B is subclass_of A, then every instance of B is also an instance of A». Αντίστροφες σχέσεις (Inverse Relations): Αντίστροφες σχέσεις είναι αυτές του τύπου : «Α produces B», «Β is produced_by Α». Παρόλο που η αποθήκευση και των δύο σχέσεων μπορεί να φαίνεται υπερβολή, αφού είναι θέμα απλής συνεπαγωγής, είναι χρήσιμο στα συστήματα διαχείρισης γνώσης να ορίζονται οι αντίστροφες σχέσεις έτσι ώστε το σύστημα να μπορεί να κάνει από μόνο του τη συνεπαγωγή. Κατηγορίες Οντολογιών Μερικές χαρακτηριστικές κατηγορίες οντολογιών είναι οι ακόλουθες: (van Heist, 1997)(Guarino N., 1998) Οντολογίες πεδίου ορισμού (domain ontologies): αναπαριστούν γνώση γύρω από ένα συγκεκριμένο πεδίο (π.χ. ιατρική, ηλεκτρονικά κ.λ.π.). Οντολογίες μεταδεδομένων (metadata ontologies): παρέχουν ένα λεξιλόγιο για την περιγραφή του περιεχομένου ηλεκτρονικά διαθέσιμης πληροφορίας. Γενικές ή κοινές οντολογίες (generic or common sense ontologies): στοχεύουν στο να αποτυπώσουν γενική γνώση γύρω από τον κόσμο, παρέχοντας βασικές έννοιες όπως ο χρόνος, ο χώρος, τα συμβάντα, κ.λ.π. Οντολογίες αναπαράστασης (representational ontologies): παρέχουν οντότητες αναπαράστασης χωρίς να προσδιορίζουν τη συγκεκριμένο αναπαριστούν π.χ. Frame Ontology (Gruber T., 1993a) ορίζει έννοιες όπως frames, slots, slot constraints κ.λ.π. Οντολογίες μεθοδολογίας ή εργασιών (method or task ontologies): παρέχουν όρους που αναφέρονται σε συγκεκριμένες εργασίες (π.χ. διάγνωση κ.λ.π.) 68

70 Σχετικά με τον βαθμό της τυπικότητας της αναπαράστασης μιας οντολογίας αυτή μπορεί να είναι: 1. Άτυπη (informal), εκφρασμένη σε μια φυσική γλώσσα. 2. Ημι-άτυπη (semi-informal): για παράδειγμα διατυπωμένη σε ένα περιορισμένο και δομημένο υποσύνολο κάποιας φυσικής γλώσσας. 3. Ημι-τυπική (semi-formal): διατυπωμένη σε μια τεχνητή και αυστηρά ορισμένη γλώσσα. 4. Αυστηρά τυπική (rigorously formal): ορισμοί όρων με αυστηρή σημασιολογία, θεωρήματα και αποδείξεις ιδιοτήτων όπως η ορθότητα (soundness) και η πληρότητα (completeness) Με βάση την εκφραστικότητα(mcguinness, 2003) : Ελεγχόμενο Λεξιλόγιο (Controlled vocabulary): μία λίστα από όρους Θησαυρός γνώσης (Thesaurus): παρέχονται σχέσεις μεταξύ όρων όπως είναι αυτή των συνώνυμων Άτυπη ταξινομία (Informal taxonomy): υπάρχει μία σαφής ιεραρχία αλλά δεν υπάρχει κληρονομικότητα δηλ. ένα στιγμιότυπο μιας έννοιας δεν είναι απαραίτητα στιγμιότυπο του υπερώνυμού της. Τυπική Ταξινομία (Formal taxonomy): υπάρχει κληρονομικότητα Πλαίσια (Frames): ένα πλαίσιο (η αλλιώς, κλάση) περιέχει ένα αριθμό ιδιοτήτων και αυτές οι ιδιότητες κληρονομούνται από τα υπο-πλαίσια και τα στιγμιότυπα. Παραδείγματα προτύπων Πλαισίων είναι το XML, RDF(S) Περιορισμοί Τιμών (Value restrictions): οι τιμές των ιδιοτήτων περιορίζονται (π.χ. από ένα τύπο δεδομένων) Περιορισμοί Γενικής Λογικής (General logic constraints): οι τιμές των ιδιοτήτων μπορεί να περιοριστούν από λογικές ή μαθηματικές εξισώσεις χρησιμοποιώντας τιμές από άλλες ιδιότητες Περιορισμοί Λογικής Πρώτης Τάξης (First-order logic constraints): πολύ εκφραστικές γλώσσες οντολογιών όπως στο Ontolingua (Farquar et al, 1996) επιτρέπουν περιορισμούς λογικής πρώτης τάξεως μεταξύ των όρων και πιο λεπτομερείς σχέσεις όπως είναι η σχέση disjoint, inverse, part-whole, κλπ. Δεν μπορούν να εξαχθούν ολοκληρωμένα συμπεράσματα (semi-decidable) και δεν έχει μεγάλη υπολογιστική δυνατότητα για μεγάλες οντολογίες. 69

71 Περιγραφική Λογική (Description Logics): Χρησιμοποιεί ένα περιορισμένο σύνολο της Λογικής Πρώτης Τάξης για την ιεραρχία της ορολογίας. Έχει καλύτερη υπολογιστική δυνατότητα σε σχέση με την Λογική πρώτης Τάξης, και η ικανότητα εξαγωγής συμπερασμάτων είναι περιορισμένη στον έλεγχο της συνέπειας μιας οντολογίας. Παραδείγματα: CLASSIC/ NeoCLASSIC Μερικές Εφαρμογές των Οντολογιών 1. Επικοινωνία μεταξύ ανθρώπων και μηχανών. 2. Παρέχουν ολοκληρωμένο πλαίσιο εννοιών και ορολογίας μεταξύ ανθρώπων με διαφορετικές ανάγκες και οπτικές γωνίες στα πλαίσια ενός οργανισμού. Διευκολύνουν την επικοινωνία των ανθρώπων στα πλαίσια του οργανισμού. 3. Δια-λειτουργικότητα (inter-operability) μεταξύ συστημάτων 4. Διάφοροι χρήστες χρειάζεται να ανταλλάσσουν δεδομένα ή χρησιμοποιούν διαφορετικά πακέτα λογισμικού. 5. Χρήση οντολογιών για την υποστήριξη μετάφρασης μεταξύ διαφορετικών γλωσσών και αναπαραστάσεων. 6. Μηχανική Συστημάτων (systems engineering) 7. Προδιαγραφές 8. Επαναχρησιμοποίηση τμημάτων 9. Αξιοπιστία Οι οντολογίες έχουν γίνει δημοφιλής σε πολλές ερευνητικές ομάδες και επιχειρησιακές κοινότητες Μηχανική Γνώσης (Knowledge engineering) Επεξεργασία της φυσικής γλώσσας (Natural language processing) Ενοποίηση πληροφορίας (Information integration) Ανάκτηση πληροφορίας (Information retrieval) Ψηφιακές Βιβλιοθήκες (Digital libraries) Εφαρμογές στον Παγκόσμιο Ιστό (Semantic Web) Ηλεκτρονικό Εμπόριο (E-commerce) 70

72 Οντολογίες, Διαχείριση Έργων Λογισμικού & Τεχνολογία Λογισμικού Οι ρόλοι των οντολογιών στην τεχνολογία λογισμικού είναι δύο. Οντολογίες στη διαδικασία της τεχνολογίας λογισμικού: Κάποια από τα πρώτα ζητήματα στο πεδίο της τεχνολογίας λογισμικού είναι η τμηματοποίηση, επαναχρησιμοποίηση και ενοποίηση των τμημάτων και συστημάτων λογισμικού. Όσο αυτές οι εργασίες επεκτείνονται και αυτοματοποιούνται, τόσο πιο σημαντικός γίνεται ο ορισμός και η χρήση των οντολογιών. Πρόσφατες μεθοδολογίες για την ανάπτυξη λογισμικού όπως η ανάπτυξη μέσω μοντέλων (modeldriven development (MDD)) δείχνουν προτίμηση στα μοντέλα σαν τη κεντρική βάση γνώσης. Οντολογίες για το πεδίο της τεχνολογίας λογισμικού: Η τεχνολογία λογισμικού είναι επιστημονικό και επαγγελματικό πεδίο με τη δική της δομή και ορολογία. Δεδομένου ότι πρόκειται για ένα καινούργιο πεδίο, η δημιουργία μιας (ή περισσοτέρων) οντολογίας είναι απαραίτητη. (Hesse) Στη συνέχεια αυτής της ενότητας θα ασχοληθούμε με τον δεύτερο ρόλο των οντολογιών. Στην επιστήμη της Τεχνολογία Λογισμικού υπήρξαν κάποιες αρχικές προσπάθειες να παραχθούν κάποιες ειδικές οντολογίες (μέρη του πεδίου Τεχνολογία Λογισμικού). Όπως θα δούμε και στη συνέχεια κοινός παρονομαστής στα περισσότερα άρθρα είναι ο βασικός κορμός γνώσεων της Τεχνολογίας Λογισμικού με την ονομασία SWEBOK GUIDE. (SWEBOK guide, 2004) Ο οδηγός SWEBOK (Software Engineering Body of Knowledge), είναι το αποτέλεσμα της συνεργασίας ανάμεσα στον οργανισμό IEEE Computer Society και το Πανεπιστήμιο Université du Québec (École de Technologie Supérieure and UQAM). Στο πέρασμα των χρόνων, περίπου 500 συμμετέχοντες από πολλά διαφορετικά πεδία, μεταξύ των οποίων ακαδημαϊκή και βιομηχανικοί κύκλοι, κυβερνητικοί οργανισμοί και διεθνής οργανισμοί προτυποποίησης έχουν συμμετάσχει σε αυτήν την προσπάθεια. Ο οδηγός SWEBOK περιέχει δομημένη γνώση η οποία 71

73 βρισκόταν σε διάφορα έγγραφα (επιστημονικά άρθρα, βιβλία, τεχνικές αναφορές, τεχνικά πρότυπα) καθώς και γνώση από ειδικούς πεδίου κα επιστήμονές. Στη συνέχεια ακολουθεί μια περιγραφή κάποιων άρθρων που μελέτησαν το συγκεκριμένο θέμα. Στο άρθρο τους οι Olavo Mendes & Alain Abran (Software Engineering Ontology: A Development Methodology) κάνουν μια προσπάθεια να δημιουργήσουν μια οντολογία για την τεχνολογία λογισμικού, χρησιμοποιώντας τη γνώση που έχει δομηθεί, επικυρωθεί και είναι διαθέσιμη, μέσω του οδηγού SWEBOK Guide (SWEBOK guide, 2004)όπως επίσης και από άλλες επιστημονικές πηγές όπως τεχνικά πρότυπα. (ISO και IEEE). Εικόνα 15: Οντολογία για την τεχνολογία λογισμικού Σύμφωνα με την εικόνα 15, στην κλάση ρίζα της οντολογίας υπάρχει η έννοια που αντιστοιχεί στην ονομασία SWEBOK GUIDE. Κάτω από αυτήν την κλάση υπάρχουν οι κύριες κλάσεις που αντιστοιχούν στις 10 περιοχές γνώσεις (knowledge areas) που περιέχονται στον οδηγό SWEBOK, μέσω της σχέσης «έχει Μέρος» (has 72

74 Part). Κάθε περιοχή γνώσης στη συνέχεια μπορεί να αναλυθεί περισσότερο σε νέες κλάσεις σε μεγαλύτερο επίπεδο λεπτομέρειας Οι κλάσεις είναι οργανωμένες σε μια δομημένη ιεραρχία χρησιμοποιώντας συνδέσμους γενίκευσης και ειδίκευσης (generalization/specification) για να παράγουν μια ταξινομία. Επίσης υπάρχουν και άλλης μορφής σύνδεσμοί (όπως για παράδειγμα περιέχει-contains, έχει Θέμα (hastopic), ορίζει (defines), και οι αντίστροφες σχέσεις ανήκει σε (pertainsto), είναι Θέμα του (istopicof), είναι ορισμός του-isdefinitionof, etc.) που αναπαριστούν την υπάρχουσα σημασιολογία μέσα από πολλαπλούς συνδέσμους εννοιών. Για παράδειγμα, όσον αφορά την περιοχή γνώση «Software Quality», που είναι το κεφάλαιο 11 του οδηγού SWEBOK, αντιστοιχούν οι παρακάτω έννοιες που αναπαριστούν τη γνώση που έχει σχέση με αυτό το θέμα. Η παρακάτω εικόνα 16 παρουσιάζει τις 4 υποκατηγορίες αυτού του θέματος. Ο σύνδεσμός C* αναπαριστά τη σχέση έχειμέρη (hasparts). Εικόνα 16: Η περιοχή γνώση ποιότητα λογισμικού Οι Li Liao, Yuzhong Qu, Hareton K. N. Leung (A Software Process Ontology and Its Application) στο άρθρο τους κάνουν μια προσπάθεια να δημιουργήσουν μια οντολογία για τη διαδικασία παραγωγής λογισμικού. Σε αυτό το άρθρο περιγράφεται μια προσέγγιση, για να περιγραφεί η διαδικασία λογισμικού (software process) σε εννοιολογικό επίπεδο. Αυτή η οντολογία ονομάζεται SPO (Software Process Ontology), και η οποία μπορεί στη συνέχεια να επεκταθεί περαιτέρω έτσι ώστε να εκφράζει συγκεκριμένα μοντέλα όπως το CMMI και το ISO/IEC

75 Μια διαδικασία λογισμικού ορίζεται σαν ένα σύνολο δραστηριοτήτων, μεθόδων και πρακτικών που οι άνθρωποι χρησιμοποιούν για να αναπτύξουν και να συντηρήσουν το λογισμικό. Είναι σαν ένα μέσο μέσω του οποίου επιτυγχάνεται βελτίωση της ποιότητας λογισμικού όπως επίσης και η παραγωγικότητα. Έχει δημιουργηθεί ένα σύνολο μοντέλων όπως το Capability Maturity Model (CMM) και το ISO/IEC Οι συγγραφείς στην προσπάθειά τους να δημιουργήσουν μια γενική οντολογία που να περιγράφει τη διαδικασία παραγωγής λογισμικού συγκρίνουν αυτά τα δύο μοντέλα και παρατηρούν ότι έχουν διαφορετικές διαδικασίες (processes) αλλά τα περιεχόμενα αυτών των διαδικασιών μπορούν να αντιστοιχηθούν. Στην προσπάθεια αυτή να αντιστοιχηθούν όλα τα διαφορετικά σημεία στα δύο μοντέλα, συγκεντρώθηκαν όλες οι δραστηριότητες των μοντέλων και ονομάστηκαν ατομικές πρακτικές (atomic practices). Μια ατομική πρακτική είναι η ελάχιστη δραστηριότητα που μπορεί να παράγει ένα παραδοτέο (artifact). Μια διαδικασία λογισμικού αποτελείται από έναν αριθμό πρακτικών (practices) ενώ μια πρακτική αποτελείται από έναν αριθμό ατομικών πρακτικών. Μία ατομική πρακτική μπορεί να περιέχει τις ακόλουθες ιδιότητες. Όνομα της Δραστηριότητας και Σκοπός (Activity Name and Purpose) Παραδοτέα που χρησιμοποιούνται / απαιτούνται (Artifacts used/ required) Περιγραφή της Εργασίας (Task description) Ευθύνη της Εργασίας (Task responsibility) Προϊόντα / Έγγραφα που παράγονται (Product(s)/Document(s) developed) Μέτρα (Measures) Στη συνέχεια ακολουθεί ένα πλαίσιο του μοντέλου της διαδικασίας ανάπτυξης λογισμικού, Software Process Ontology. 74

76 Εικόνα 17: Οντολογία για τη διαδικασία λογισμικού Στην εικόνα 17, Process είναι μία κλάση που αναπαριστά την υπερκλάση όλων των ειδών των διαδικασιών (processes), που υπάρχουν στο μοντέλο. Η κλάση Practice είναι η υπεκλάση όλων των πρακτικών (practices) στα μοντέλα. Στη συνέχεια, βασισμένη στην παραπάνω οντολογία, ανέπτυσσαν την οντολογία για το μοντέλο CMMI. (Εικόνα 18) Εικόνα 18: Οντολογία για το μοντέλο CMMI 75

77 Οι Wongthongtham, Chang και Dillon στο άρθρο τους ONTOLOGIES FOR MULTI-SITE SOFTWARE ENGINEERING (2004) προτείνουν τις οντολογίες ως λύση για την ανάπτυξη λογισμικού από πολλά κανάλια (multi site software development). Η ανάπτυξη λογισμικού από πολλά κανάλια πραγματοποιείται όταν οι ομάδες λογισμικού είναι απομακρυσμένες η μία από την άλλη, σε διαφορετικές πόλεις, χώρες ή ακόμα και ηπείρους. Αποτέλεσμα είναι να δημιουργούνται νέα προβλήματα που δεν είχαν εμφανιστεί παλαιότερα. Διαφορετικές ομάδες ίσως να μην γνωρίζουν ποιες εργασίες έχουν ήδη πραγματοποιηθεί από άλλες ομάδες, ώστε η δουλειά των ομάδων να επικαλύπτει η μία την άλλη ή κάποια άλλη εργασία να μην εκτελεστεί καθόλου, λόγω της λανθασμένης ανάθεσης εργασιών. Μπορεί να εκτελεστούν εργασίες λανθασμένα λόγω άγνοιας ή ελλιπούς επικοινωνίας μεταξύ των ομάδων. Οι συγγραφείς πρότειναν τη χρήση ευφυών πρακτόρων λογισμικού σε συνδυασμό με τις οντολογίες για να υποστηρίξουν την ανάπτυξη λογισμικού από πολλά κανάλια. Ο ευφυής πράκτορας θα πρέπει να έχει τρία χαρακτηριστικά: Να ταξινομεί ιδιότητες, ρόλους και έννοιες μέσα σε μια οντολογία. Να διαχειρίζεται θέματα που προκύπτουν κατά τη διάρκεια εκτέλεσης ενός έργου Να επικοινωνεί με τους δημιουργούς και να βρίσκει λύση σε τυχόν προβλήματα που αντιμετωπίζουν. Προτείνουν λοιπόν τη δημιουργία πέντε οντολογιών για την ανάπτυξη ενός τέτοιου είδους συστήματος: 1. Οντολογία του επαγγελματικού πεδίου (business domain ontology), 2. Οντολογία της τεχνολογίας λογισμικού (software engineering ontology), 3. Οντολογία της διαχείρισης έργου (project management ontology), 4. Οντολογία θεμάτων (issues ontology) 5. Οντολογία λύσης (solution ontology) Οντολογία του επαγγελματικού πεδίου Όλα τα έργα λογισμικού, μικρά ή μεγάλα, είναι συνδεδεμένα με μια συγκεκριμένη επαγγελματική ανάγκη, (λογιστική, εξυπηρέτηση πελατών, ανθρώπινοι πόροι κ.τ.λ.). Έτσι λοιπόν, μια βασική γνώση (όχι απαραίτητα βαθιά) του πεδίου είναι σημαντική για την επιτυχία του έργου. 76

78 Εικόνα 19: Παράδειγμα Επαγγελματικής Οντολογίας (business ontology) Οντολογία Τεχνολογίας Λογισμικού Στην παρακάτω εικόνα είναι ένα παράδειγμα για την οντολογία της Τεχνολογίας Λογισμικού(SE Ontology). Βασίζεται στον οδηγό SWEBOK(SWEBOK guide, 2004) στο βιβλίο του Καθηγητή Ι. Sommerville Software Engineering (Sommerville, 1992). Εικόνα 20: Παράδειγμα για την οντολογία της τεχνολογίας λογισμικού Οντολογία για τη διαχείριση έργων Υπάρχει μία μεγάλη βιβλιογραφία για τη διαχείριση έργων για όλες τις όψεις μιας επιχείρησης και οργανισμού. Αυτό το άρθρο επικεντρώνεται κυρίως στη διαχείριση έργου που σχετίζεται με την Τεχνολογία της Πληροφορίας. Σε αντίθεση με την τεχνολογία λογισμικού, για την οποία κάθε μέλος της ομάδας θα πρέπει να γνωρίζει το σύνολο της πληροφορίας, η γνώση της διαχείρισης έργου χρησιμοποιείται από τα στελέχη κάθε επιπέδου και υπευθύνους του έργου. Η παρακάτω εικόνα δείχνει ένα παράδειγμα μιας οντολογίας διαχείρισης έργων. 77

79 Εικόνα 21: Παράδειγμα για την οντολογία της διαχείρισης έργων Οντολογία Θεμάτων και Λύσης Κατά τη διάρκεια της ανάπτυξης του λογισμικού, υπάρχουν πάντα θέματα, τα οποία πολλαπλασιάζονται και επιλύονται δυσκολότερα καθώς το έργο προχώρα. Αν δεν υπάρξει άμεση λύση, τα θέματα αυτά σε κάποιες περιπτώσεις προκαλούν την αποτυχία του έργου. Με βάση τα ιστορικά στοιχεία, τρεις είναι οι κύριοι λόγοι που προκαλούν την αποτυχία του έργου: Πρώτη περιοχή αποτυχίας: Απαιτήσεις: Η ομάδα δεν κατανοεί πλήρως τα επαγγελματικά μοντέλα και τις επαγγελματικές διαδικασίες. Η επιτυχία του έργου απαιτεί πλήρη γνώση του πεδίου. Δεύτερη περιοχή αποτυχίας: Διαδικασία της Ανάπτυξης Λογισμικού: Αν υποθέσουμε ότι η ομάδα κατανοεί πλήρως τις απαιτήσεις του έργου, ο δεύτερος μεγαλύτερος κίνδυνος είναι η διαδικασία της τεχνολογίας λογισμικού που θα ακολουθηθεί και η διαχείριση του έργου. Ένα από τα συνηθισμένα προβλήματα είναι η επικοινωνία μεταξύ όλων των συμμέτοχων, συμπεριλαμβανομένων των ομάδων ανάπτυξης λογισμικού. Ένα άλλο πρόβλημα είναι ότι πολλές φορές η ομάδα δίνει υποσχέσεις που δεν μπορεί να κρατήσει. Ένας από τους μεγάλους κινδύνους είναι ότι μόνο λίγα άτομα έχουν εκπαιδευτεί στην τεχνολογία λογισμικού και στη διαχείριση έργου. Τρίτη περιοχή αποτυχίας: Προϊόν: Το έργο μπορεί να αποτύχει και εξαιτίας της ποιότητας του προϊόντος και της μη ικανότητάς του να ενοποιηθεί με τα υπάρχοντά επαγγελματικά και πληροφοριακά συστήματα ή και λόγω της μη ικανότητάς του να είναι ευέλικτο και να δέχεται περεταίρω αλλαγές. 78

80 Έτσι λοιπόν, παρατηρούμε ότι οι περιοχές ένα και δύο, έχουν σχέση με την οντολογική πλευρά του επαγγελματικού πεδίου γνώσης, του πεδίου της τεχνολογίας λογισμικού και της διαχείρισης έργων. Ενώ η τρίτη περιοχή έχει σχέση με τη γνώση των θεμάτων και της λύσης που οδηγεί στην επιτυχία του προϊόντος και του έργου. Τα στελέχη του έργου οφείλουν να πάρουν μια πληθώρα αποφάσεων και συνήθως είναι πολύ απασχολημένα. Γι αυτό λοιπόν είναι σημαντικό τα θέματα να είναι ταξινομημένα και ξεκάθαρα διατυπωμένα. Περίπου 30% των ερωτήσεων έχουν σχέση με οντολογικά θέματα (ontological issues), όπως το να μην είναι η ομάδα απόλυτα σίγουρη για τον ορισμό των επαγγελματικών μοντέλων (business models) ή των τεχνικών όρων της τεχνολογίας λογισμικού ή της διαχείρισης έργων. Τα μέλη της ομάδας σπαταλούν πολύτιμο χρόνο στην προσπάθεια τους να διδάξουν το ένα στο άλλα τι γνωρίζουν ενώ υπάρχει και ο κίνδυνος λάθους. Άλλα θέματα όπως τεχνικά προβλήματα (technical issues) επηρεάζουν στρατηγικές αποφάσεις του έργου. Και τέλος υπάρχουν και διοικητικά θέματα (managerial issues) όπως για παράδειγμα αποφάσεις που έχουν σχέση με την παραίτηση του ανθρώπινου δυναμικού. Γι αυτό έχουν δημιουργηθεί τρία θέματα στην οντολογία, τα οποία ταξινομούν όλα τα προβλήματα που ενδέχεται να εμφανιστούν κατά τη διαδικασία της ανάπτυξης σε τρεις κατηγορίες. : 1. Οντολογικά Θέματα (Ontological issues) 2. Τεχνικά Θέματα (Technical issues) 3. Διοικητικά Θέματα (Managerial issues) Όταν προκύπτει ένα θέμα, ο πράκτορας λογισμικού είναι αυτός που έρχεται σε πρώτη επαφή με την ομάδα λογισμικού. Ταξινομεί τα ερωτήματα ή τα θέματα, και αν πρόκειται για ένα οντολογικό θέμα, χρησιμοποιεί την οντολογία για να παρουσιάσει τη λύση. Για να το κάνει αυτό ο πράκτορας λογισμικού κάνει αναζήτηση στα 69 πιο συνηθισμένα ή σε όλα τα οντολογικά θέματα και δεν περιμένει τον διευθυντή του έργου. 79

81 Εικόνα 22: Οντολογίες θεμάτων (issues) και λύσης σε έργα της τεχνολογίας της πληροφορίας Τέλος, έχουν αναπτύξει μια οντολογία λύσης (solution ontology), η οποία βασίζεται σε τέσσερα στρατηγικά μέτρα του οργανισμού, τα οποία χρησιμοποιούν πολλοί οργανισμοί: 1. οργανωσιακοί στόχοι (organizational goals) 2. προτεραιότητες εργασιών (task priorities), 3. προϋπολογισμός 4. χρονικά όρια (timelines) Ο πράκτορας λογισμικού αφού ταξινομήσει τα θέματα παίρνει αποφάσεις βασιζόμενος στα τέσσερα αυτά μέτρα. Για παράδειγμα, εάν ένας υπάλληλος ζητήσει 29 μέρες άδεια, ο πράκτορας αφού ελέγξει τα τέσσερα αυτά μέτρα, για παράδειγμα, απαντά «Δεν ταιριάζει το χρονοδιάγραμμα». Για τα θέματα για το οποία ο πράκτορας δεν έχει λύση, προωθούνται στον διευθυντή έργου. Στο άρθρο τους οι P. Wongthongtham a, E. Chang a,*, T.S. Dillon b Information Engineering of a Software Engineering Ontology (Information Engineering of a Software Engineering Ontology, 2005), συνεχίζουν την έρευνά τους και χρησιμοποιούν τις οντολογίες σε συνδυασμό με ένα σύστημα ευφυή πράκτορα για να λύσουν τα προβλήματα που εμφανίζονται όταν η ανάπτυξη λογισμικού πραγματοποιείται από πολλά κανάλια. Αυτή τη φορά εστιάζονται στην οντολογία για την τεχνολογία λογισμικού. 80

82 Οι οντολογίες σε συνδυασμό με πολυπρακτορικά συστήματα επιτρέπουν την επικοινωνία συγκεντρώνοντας τη γνώση για το έργο, τη γνώση πεδίου (domain knowledge), και τις έννοιες της τεχνολογίας λογισμικού σε μια ενιαία πλατφόρμα (shared information resource platform). Η αναπαράσταση των εννοιών της τεχνολογίας λογισμικού, των εργασιών ανάπτυξης λογισμικού (software development tasks), των μοντέλων ανάπτυξης λογισμικού (software development models), των διαδικασιών ανάπτυξης λογισμικού (software development processes) και της τεκμηρίωσης (documentation) ανάπτυξης λογισμικού χρησιμοποιώντας μια οντολογία θα προσδώσει σαφήνεια, σαφείς έννοιες και ταξινομημένη γνώση. Οι οντολογίες δίνουν νέες διαστάσεις στα συστήματα ερώτησης-απάντησης και την επίλυση προβλημάτων μέσω υπολογιστή. Στόχος τους είναι 1. να χτίσουν μια οντολογία της τεχνολογίας λογισμικού βασιζόμενοι στη βάση γνώσης της τεχνολογίας λογισμικού (SWEBOK) και στο βιβλίο του Καθηγητή Ian Sommerville (Sommerville, 1992) 2. να υλοποιήσουν ένα σύστημα βασισμένο στη Java για συγκέντρωση της πληροφορίας, εξαγωγή της γνώσης και συντήρηση της οντολογίας. Η αρχιτεκτονική του συστήματος φαίνεται στο παρακάτω σχήμα. Το σύστημα είναι χωρισμένο σε δύο μέρη: εξυπηρετητής ερωτημάτων της οντολογίας (ontology query server) εξυπηρετητής της διεπαφής χρήστη. (user interface server) Εικόνα 23: Αρχιτεκτονική του συστήματος 81

83 Ο εξυπηρετητής ερωτημάτων της οντολογίας είναι υπεύθυνος για τις λειτουργίες που αφορούν την οντολογία, για παράδειγμα την αναζήτηση μέσα στην οντολογία και την μετατροπή της. Αυτό είναι το μοναδικό κομμάτι του συστήματος που αλληλεπιδρά με την Οντολογία. Τα αποτελέσματα των ερωτημάτων εμφανίζονται σε XML μορφοποίηση. Ο εξυπηρετητής της διεπαφής χρήστη αλληλεπιδρά με τους χρήστες. Στη συνέχεια ακολουθεί μια περιγραφή της Οντολογίας της Τεχνολογίας Λογισμικού. Οι έννοιες (concepts) σε μια οντολογία είναι καθορισμένες σε ταξινομίες που αναπαριστούν κληρονομικότητα (inheritance) και συγκέντρωση (aggregation). Για παράδειγμα, στο πεδίο της τεχνολογίας λογισμικού κάποιες από τις έννοιες είναι :η διαδικασία λογισμικού, οι απαιτήσεις, ο σχεδιασμός, η ανάπτυξη, η επαλήθευση και η επικύρωση του λογισμικού. Για παράδειγμα οι υποκλάσεις της έννοιας σχεδιασμός (design) μπορεί να είναι οι εξής: αντικειμενοστραφής σχεδιασμός (object oriented design), σχεδιασμός λογισμικού πραγματικού χρόνου (real-time software design) σχεδιασμός διεπαφής χρήστη (user interface design) Ενώ το διάγραμμα κλάσεων (Class diagram) και το διάγραμμα περιπτώσεων χρήσης (use case diagram) είναι υποκλάσεις του μοντέλου του αντικειμενοστραφούς σχεδιασμού. Οι σχέσεις (Relationships) αναπαριστούν ένα είδος σχέσης ανάμεσα στις έννοιες του πεδίου. Για παράδειγμα ο σύνδεσμος έχει μοντέλο (hasμodel) συνδέει τη τεχνολογία λογισμικού με ένα μοντέλο. Κάθε σχέση μπορεί να έχει μια αντίστροφη σχέση που συνδέει τις έννοιες προς την αντίθετη κατεύθυνση και /ή μια συμμετρική σχέση που συνδέει τις έννοιες προς την ίδια κατεύθυνση και / ή μεταβατική σχέση που συνδέει τις δύο έννοιες σε μια μεταβατική κατεύθυνση. Για παράδειγμα η σχέση «is tool of» είναι η αντίστροφη της «has tool». Τα στιγμιότυπα - Instances περιγράφουν αντικείμενα ή άτομα σε μια Οντολογία. Για παράδειγμα ένα στιγμιότυπο της έννοιας κλάση στη UML είναι πελάτης (customer). Οι ιδιότητες (Attributes) αναπαριστούν ιδιότητες των στιγμιότυπων κα των εννοιών. Υπάρχουν δύο τύποι ιδιοτήτων, που είναι οι ιδιότητες στιγμιότυπου (instance attributes) και οι ιδιότητες τάξης (class attributes). 82

84 Τα αξιώματα (Formal axioms) χρησιμοποιούνται για να ορίσουν περιορισμούς σε μια οντολογία. Είναι λογικές εκφράσεις που είναι πάντα αλήθεια. Για παράδειγμα μια σχέση σε ένα διάγραμμα κλάσης στη UML δεν μπορεί να είναι εξάρτηση (dependency) και συσχέτιση (association) στο ίδιο διάγραμμα. Εικόνα 24: Τμήμα της οντολογίας Τεχνολογία Λογισμικού Μια από τις υπηρεσίες που προσφέρει το σύστημα είναι η γενική αναζήτηση (Generic Search) και κυρίως χρησιμοποιείται για την εμφάνιση μόνο αποτελεσμάτων αναζήτησης. Η κύρια λειτουργία είναι να επιτρέπει στους χρήστες να έχουν πρόσβαση, να ανακτούν και να βλέπουν τη βάση γνώσης και να αποκτούν την πληροφορία που αναζητούν. Πρώτα το πρόγραμμα λαμβάνει την είσοδο του χρήστη μέσω της διεπαφής και μετά βρίσκει την κλάση στην οντολογία. Σε περίπτωση που δεν βρει κάποια κλάση εμφανίζεσαι μήνυμα λάθους. Αν όμως τη βρει, το σύστημα εμφανίζει όλες τις ιδιότητες της συγκεκριμένης κλάσης. Ένα άλλο χαρακτηριστικό του προγράμματος είναι ότι εμφανίζει και την υπερκλάση και όλες τις υποκλάσεις της κλάσης σε μια μορφή δένδρου. 83

85 Οντολογία για τη διαχείριση έργων λογισμικού Εισαγωγή Οι οντολογίες μπορούν να παίξουν ένα σημαντικό ρόλο στον τομέα της διαχείρισης έργων λογισμικού, όπως και σε άλλες επιστήμες, καθώς: παρέχουν μια πηγή καθορισμένων όρων που μπορεί να χρησιμοποιηθεί από τα μέλη της ομάδας και τις εφαρμογές (πληροφοριακά συστήματα ή ευφυής πράκτορες), προσφέρουν μια κοινή κατανόηση του πεδίου και αποδίδουν σαφώς όλα τα κρυμμένα νοήματα όσον αφορά όλα τα αντικείμενα επιτρέψει: που περιλαμβάνονται στο συγκεκριμένο πεδίο γνώσης. Η ανάπτυξη μιας οντολογίας για το πεδίο της διαχείρισης έργων λογισμικού θα Το μοίρασμα και την επαναχρησιμοποίηση όλης της γνώσης που έχει συσσωρευτεί μέχρι τώρα στο πεδίο της διαχείρισης έργων λογισμικού. Θα ανοίξει νέους δρόμους στην αυτόματη ερμηνεία αυτής της γνώσης, χρησιμοποιώντας πληροφοριακά συστήματα ή ευφυείς πράκτορες λογισμικού. Στόχος Στόχος της παρούσας πτυχιακής εργασίας είναι η δημιουργία μιας οντολογίας για το πεδίο της διαχείρισης έργων λογισμικού, χρησιμοποιώντας τη γνώση που έχει αποκτηθεί, δομηθεί, επικυρωθεί και είναι διαθέσιμη στον οδηγό PMBOK(PMBOK, 2004), καθώς επίσης τη γνώση από άλλες επιστημονικές πηγές που αναφέρονται στο βιβλιογραφικό κομμάτι της εργασίας. Επιπρόσθετα, στόχος της οντολογίας δεν είναι η πλήρης και αναλυτική περιγραφή όλων των όρων που υπάρχουν στο συγκεκριμένο πεδίο, το οποίο θα απαιτούσε εκατοντάδες ή και χιλιάδες όρους. Αντίθετα, στόχος είναι η καταγραφή των πλέον βασικών όρων και οι σχέσεις μεταξύ τους. PMBOK Ο οδηγός PMBOK (3 η έκδοση), όπως έχει ήδη αναφερθεί δημιουργήθηκε από το ινστιτούτο διαχείρισης έργων (PMI) και παρέχει ένα κοινό λεξιλόγιο για συζήτηση, 84

86 συγγραφή και εφαρμογή της διοίκησης έργων. Πρωταρχικός σκοπός του Οδηγού PMBOK είναι ο προσδιορισμός του υποσυνόλου των βασικών γνώσεων στη διαχείριση έργων, το οποίο είναι γενικά αποδεκτό ως σωστή πρακτική. Δημιουργία της οντολογίας Το εργαλείο που επιλέχθηκε για την ανάπτυξη της οντολογίας είναι το Protégé (έκδοση 3.2.1, Standford University). Το Protégé αποτελεί ένα εργαλείο αναγνωρισμένο από την επιστημονική κοινότητα και διαθέτει ιδιαίτερα καλές δυνατότητες αναπαράστασης της γνώσης. Στο protégé, κάθε έννοια είναι μία κλάση (class). Όταν μία κλάση είναι υποκλάση μιας άλλης κλάσης, κληρονομεί τα χαρακτηριστικά της και συνδέεται μαζί της με τη σχέση isa. Εκτός από τη σχέση isa, στην οντολογία υπάρχει ένα μεγάλο σύνολο από σχέσης, όπως για παράδειγμα η σχέση has Activities. Στο Protégé, όταν μία έννοια έχει σχέση με μία άλλη έννοια, τότε η σχέση αναπαρίσταται σαν ιδιότητα (slot) μιας εκ των δύο εννοιών. Στην Εικόνα παρουσιάζεται το περιβάλλον του εργαλείου Protégé, οι κλάσεις τις οντολογίας και οι ιδιότητες της έννοιας έργο. Εικόνα 25: Το περιβάλλον της οντολογίας 85

87 Περιγραφή της οντολογίας Στη συνέχεια, με τη βοήθεια του εργαλείου Ontoviz, το οποίο αποτελεί επιπλέον κομμάτι του Protégé αναπαρίσταται η οντολογία σε διαγράμματα. Η έννοια του έργου και οι σχέσεις που έχει με άλλες έννοιες. Εικόνα 26: Η έννοια του έργου Στην οντολογία υπάρχουν οι έννοιες της PMBOK: Η έννοια γνωστική περιοχή (ProjectKnowledgeArea), η οποία συνδέεται με σχέση isa με όλες τις γνωστικές περιοχές όπως φαίνεται στην Εικόνα 27. Εικόνα 27: Οι γνωστικές περιοχές 86

88 Στη συνέχεια, οι γνωστικές περιοχές συνδέονται με την κλάση δραστηριότητες (Activities) μέσω της σχέσης «has Activities». Εικόνα 28: Οι γνωστικές περιοχές συνδέονται με τις δραστηριότητες μέσω της σχέσης "hasactivities". Η έννοια της διαδικασίας διαχείρισης έργων (ProjectProcesses) και φυσικά οι αντίστοιχες υποκλάσεις. Εικόνα 29: Οι γνωστικές περιοχές, οι δραστηριότητες, οι είσοδοι, έξοδοι και τα εργαλεία Η κλάση Δραστηριότητες (Activities) έχει τις εξής ιδιότητες: Έξοδοι(Output): Δεν προσδιορίζεται ο τύπος καθώς μπορεί να είναι οτιδήποτε. Είσοδοι (Input): Δεν προσδιορίζεται ο τύπος καθώς μπορεί να είναι οτιδήποτε. Τεχνικές κα εργαλεία (Tools&Techniques): συνδέεται με την κλάση Τεχνικές και εργαλεία μέσω της σχέσης tools&techniques, όπως φαίνεται στην εικόνα

89 Στην εικόνα 30, αναπαρίστανται οι συμμέτοχοι του έργου. Εικόνα 30: Οι συμμέτοχοι του έργου 88

ΕΙΣΑΓΩΓΗ ΣΤΗ ΔΙΑΧΕΙΡΙΣΗ ΚΑΙ ΣΤΟΝ ΠΡΟΓΡΑΜΜΑΤΙΣΜΟ ΕΡΓΩΝ

ΕΙΣΑΓΩΓΗ ΣΤΗ ΔΙΑΧΕΙΡΙΣΗ ΚΑΙ ΣΤΟΝ ΠΡΟΓΡΑΜΜΑΤΙΣΜΟ ΕΡΓΩΝ ΕΙΣΑΓΩΓΗ ΣΤΗ ΔΙΑΧΕΙΡΙΣΗ ΚΑΙ ΣΤΟΝ ΠΡΟΓΡΑΜΜΑΤΙΣΜΟ ΕΡΓΩΝ 1. Διαχείριση έργων Τις τελευταίες δεκαετίες παρατηρείται σημαντική αξιοποίηση της διαχείρισης έργων σαν ένα εργαλείο με το οποίο οι διάφορες επιχειρήσεις

Διαβάστε περισσότερα

ΔΙΟΙΚΗΣΗ ΕΡΓΩΝ Ο Ρ Ι Σ Μ Ο Ι Γ Ε Ν Ι Κ Ε Σ Ε Ν Ν Ο Ι Ε Σ. ΡΟΜΠΟΓΙΑΝΝΑΚΗΣ ΙΩΑΝΝΗΣ, PhD.

ΔΙΟΙΚΗΣΗ ΕΡΓΩΝ Ο Ρ Ι Σ Μ Ο Ι Γ Ε Ν Ι Κ Ε Σ Ε Ν Ν Ο Ι Ε Σ. ΡΟΜΠΟΓΙΑΝΝΑΚΗΣ ΙΩΑΝΝΗΣ, PhD. ΔΙΟΙΚΗΣΗ ΕΡΓΩΝ Ο Ρ Ι Σ Μ Ο Ι Γ Ε Ν Ι Κ Ε Σ Ε Ν Ν Ο Ι Ε Σ ΈΝΝΟΙΕΣ ΟΡΙΣΜΟΙ (1) ΠΑΡΑΓΩΓΙΚΗ ΔΙΑΔΙΚΑΣΙΑ - ΕΡΓΟ Κοινά στοιχεία & διαφορές Διενεργούνται από ανθρώπους (και) μηχανές Διαθέτουν περιορισμένους πόρους

Διαβάστε περισσότερα

ΕΝΟΤΗΤΑ 1. ΕΙΣΑΓΩΓΗ ΣΤΗΝ ΔΙΑΧΕΙΡΙΣΗ ΕΡΓΟΥ - ΙΣΤΟΡΙΑ. Κατερίνα Αδάμ, Μ. Sc., PhD Eπίκουρος Καθηγήτρια

ΕΝΟΤΗΤΑ 1. ΕΙΣΑΓΩΓΗ ΣΤΗΝ ΔΙΑΧΕΙΡΙΣΗ ΕΡΓΟΥ - ΙΣΤΟΡΙΑ. Κατερίνα Αδάμ, Μ. Sc., PhD Eπίκουρος Καθηγήτρια ΔΙΑΧΕΙΡΙΣΗ ΕΡΓΟΥ Τομέας Μεταλλευτικής Τμήμα Μηχανικών Μεταλλείων Μεταλλουργών ΕΝΟΤΗΤΑ 1. ΕΙΣΑΓΩΓΗ ΣΤΗΝ ΔΙΑΧΕΙΡΙΣΗ ΕΡΓΟΥ - ΙΣΤΟΡΙΑ Κατερίνα Αδάμ, Μ. Sc., PhD Eπίκουρος Καθηγήτρια ΑΔΕΙΑ ΧΡΗΣΗΣ 2 Το παρόν

Διαβάστε περισσότερα

Διαχείριση έργων. Βασικές αρχές Τεχνολογίας Λογισμικού, 8η αγγ. έκδοση

Διαχείριση έργων. Βασικές αρχές Τεχνολογίας Λογισμικού, 8η αγγ. έκδοση Διαχείριση έργων Στόχοι Ερμηνεία των κύριων εργασιών ενός διευθυντή έργου λογισμικού Παρουσίαση της διαχείρισης έργων λογισμικού και περιγραφή των χαρακτηριστικών που τη διακρίνουν Εξέταση του σχεδιασμού

Διαβάστε περισσότερα

ΑΝΤΙΚΕΙΜΕΝΟΣΤΡΕΦΗΣ ΑΝΑΛΥΣΗ Rational Unified Process. Ιωάννης Σταμέλος Βάιος Κολοφωτιάς Πληροφορική

ΑΝΤΙΚΕΙΜΕΝΟΣΤΡΕΦΗΣ ΑΝΑΛΥΣΗ Rational Unified Process. Ιωάννης Σταμέλος Βάιος Κολοφωτιάς Πληροφορική ΑΝΤΙΚΕΙΜΕΝΟΣΤΡΕΦΗΣ ΑΝΑΛΥΣΗ Rational Unified Process Ιωάννης Σταμέλος Βάιος Κολοφωτιάς Πληροφορική Θεσσαλονίκη, Σεπτέμβριος 2013 ΑΝΤΙΚΕΙΜΕΝΟΣΤΡΕΦΗΣ ΑΝΑΛΥΣΗ Άδειες Χρήσης Το παρόν εκπαιδευτικό υλικό υπόκειται

Διαβάστε περισσότερα

3. Διαχείριση Εύρους Στόχοι Εύρος Δομή Εργασιών Πακέτα Εργασίας. Σύνοψη

3. Διαχείριση Εύρους Στόχοι Εύρος Δομή Εργασιών Πακέτα Εργασίας. Σύνοψη 3. Διαχείριση Εύρους Στόχοι Εύρος Δομή Εργασιών Πακέτα Εργασίας Σύνοψη 1. Διατύπωση στόχων του Οι στόχοι του έργου εκφράζουν τα αναμενόμενα αποτελέσματα που προκύπτουν από τα παραδοτέα του. Βασικοί Στόχοι:

Διαβάστε περισσότερα

Εκπόνηση σχεδίων. 1a. Διαδικασία Εκκίνησης (Project Initiation) Επιχειρηματικό σχέδιο έργου (Project Business Case)

Εκπόνηση σχεδίων. 1a. Διαδικασία Εκκίνησης (Project Initiation) Επιχειρηματικό σχέδιο έργου (Project Business Case) 1a. Διαδικασία Εκκίνησης (Project Initiation) Εκπόνηση σχεδίων Επιχειρηματικό σχέδιο έργου (Project Business Case) Καταστατικό Έργου (Project Charter) Επιχειρηματικό σχέδιο του Έργου (Project Business

Διαβάστε περισσότερα

Θεωρία του Έργου. Διαχείριση Έργου Κύκλος Ζωής. Μαρίνα Α.Τσιρώνη Πολιτικός Μηχανικός, MSc ΕΔΑ Περιφέρειας Κεντρικής Μακεδονίας.

Θεωρία του Έργου. Διαχείριση Έργου Κύκλος Ζωής. Μαρίνα Α.Τσιρώνη Πολιτικός Μηχανικός, MSc ΕΔΑ Περιφέρειας Κεντρικής Μακεδονίας. Θεωρία του Έργου Διαχείριση Έργου Κύκλος Ζωής Μαρίνα Α.Τσιρώνη Πολιτικός Μηχανικός, MSc ΕΔΑ Περιφέρειας Κεντρικής Μακεδονίας Οκτώβριος 2009 Διαχείριση του Έργου (Project Management) Ορισμοί Κάθε μιά όχι

Διαβάστε περισσότερα

ΔΙΑΧΕΙΡΙΣΗ ΕΡΓΟΥ PROJECT MANAGEMENT

ΔΙΑΧΕΙΡΙΣΗ ΕΡΓΟΥ PROJECT MANAGEMENT 1. ΕΙΣΑΓΩΓΗ ΑΙΤΙΑ ΑΠΟΤΥΧΙΑΣ ΤΩΝ ΕΡΓΩΝ ΚΑΙ ΤΡΟΠΟΙ ΑΝΤΙΜΕΤΩΠΙΣΗΣ - Τρόποι πρόληψης της αποτυχίας Η ΣΑΝ ΔΙΕΡΓΑΣΙΑ Η ΣΗΜΑΣΙΑ ΤΗΣ ΥΠΟΣΤΗΡΙΞΗΣ ΑΠΟ ΤΗ ΔΙΟΙΚΗΣΗ ΓΙΑ ΤΗΝ ΕΠΙΤΥΧΗ ΥΛΟΠΟΙΗΣΗ ΕΡΓΟΥ Η ΕΙΣΑΓΩΓΗ ΤΗΣ ΑΝΤΙΛΗΨΗΣ

Διαβάστε περισσότερα

Αποτελεσματική Διαχείριση Έργων

Αποτελεσματική Διαχείριση Έργων Έναρξη σεμιναρίου: Σάββατο, 19 Μαΐου, 09:30 15:30 Αποτελεσματική Διαχείριση Έργων Αποτελεσματική Διαχείριση Έργων στις Υπηρεσίες και τον Τραπεζικό και Χρηματοοικονομικό κλάδο Μάθετε τις τεχνικές, τα εργαλεία

Διαβάστε περισσότερα

Τα Εργαλεία του Project Management: Δομή Ανάλυσης Εργασιών (Work Breakdown Structure, WBS)

Τα Εργαλεία του Project Management: Δομή Ανάλυσης Εργασιών (Work Breakdown Structure, WBS) Τα Εργαλεία του Project Management: Δομή Ανάλυσης Εργασιών (Work Breakdown Structure, WBS) Γιάννης Βιθυνός PMP (yvithynos@criticalpath.gr) Μάιος 2009 Ο Γιάννης Βιθυνός είναι Γενικός Διευθυντής της εταιρείας

Διαβάστε περισσότερα

Βασικά Στοιχεία Διαχείρισης Έργων

Βασικά Στοιχεία Διαχείρισης Έργων Βασικά Στοιχεία Διαχείρισης Έργων Ενότητα 1-Το γενικό πλαίσιο της διαχείρισης έργων Δρ. Δημήτριος Τσέλιος Καθηγητής Εφαρμογών Τμήμα Μηχανικών Πληροφορικής Τ.Ε.- ΤΕΙ Θεσσαλίας Μεταπτυχιακό Πρόγραμμα Μηχανική

Διαβάστε περισσότερα

Διοίκηση Έργων Κτηματογράφησης

Διοίκηση Έργων Κτηματογράφησης Διοίκηση Έργων Κτηματογράφησης Άρια Ιωαννίδη Αγρ. Τοπογράφος Μηχανικός, ΕΜΠ MSc Περιβαλλοντικός Σχεδιασμός Έργων Υποδομής Διευθύντρια Διεύθυνσης Έργων ΕΚΧΑ Α.Ε. e-mail: aioannid@ktimatologio.gr Περιεχόμενα

Διαβάστε περισσότερα

ΜΙΝΙ ΓΛΩΣΣΑΡΙ 23ων ΒΑΣΙΚΩΝ ΟΡΩΝ ΤΟΥ PROJECT MANAGEMENT.

ΜΙΝΙ ΓΛΩΣΣΑΡΙ 23ων ΒΑΣΙΚΩΝ ΟΡΩΝ ΤΟΥ PROJECT MANAGEMENT. ΜΙΝΙ ΓΛΩΣΣΑΡΙ 23ων ΒΑΣΙΚΩΝ ΟΡΩΝ ΤΟΥ PROJECT MANAGEMENT www.dimitrazervaki.com Άδεια Χρήσης: Αναφορά Δημιουργού - Μη Εμπορική Χρήση - Παρόμοια Διανομή CC BY-NC-SA Αυτή η άδεια επιτρέπει στους άλλους να

Διαβάστε περισσότερα

Ðåñéå üìåíá. Κεφάλαιο 1 Το πλαίσιο της διοίκησης έργων 13

Ðåñéå üìåíá. Κεφάλαιο 1 Το πλαίσιο της διοίκησης έργων 13 Πλήρης οδηγός µελέτης και εφαρµογής Ðåñéå üìåíá Κεφάλαιο 1 Το πλαίσιο της διοίκησης έργων 13 1.1. Εισαγωγή και βασικοί ορισµοί 13 1.1.1. Βασικοί ορισµοί 14 1.2. Διοίκηση έργων 16 1.2.1. Η κατανόηση της

Διαβάστε περισσότερα

ΔΙΑΧΕΙΡΙΣΗ ΠΡΟΓΡΑΜΜΑΤΩΝ ΚΑΙ ΧΑΡΤΟΦΥΛΑΚΙΩΝ ΕΡΓΩΝ. Διάλεξη 1 η Εισαγωγικές έννοιες και ορισμοί Δημήτρης Τσέλιος

ΔΙΑΧΕΙΡΙΣΗ ΠΡΟΓΡΑΜΜΑΤΩΝ ΚΑΙ ΧΑΡΤΟΦΥΛΑΚΙΩΝ ΕΡΓΩΝ. Διάλεξη 1 η Εισαγωγικές έννοιες και ορισμοί Δημήτρης Τσέλιος ΔΙΑΧΕΙΡΙΣΗ ΠΡΟΓΡΑΜΜΑΤΩΝ ΚΑΙ ΧΑΡΤΟΦΥΛΑΚΙΩΝ ΕΡΓΩΝ Διάλεξη 1 η Εισαγωγικές έννοιες και ορισμοί Δημήτρης Τσέλιος Συχνές ερωτήσεις ενός διαχειριστή έργων Γιατί υλοποιούμε αυτό το έργο; Τι υποτίθεται ότι θα

Διαβάστε περισσότερα

ΕΙΔΙΚΗ ΕΠΙΣΤΗΜΟΝΙΚΗ ΕΠΙΤΡΟΠΗ ΘΕΜΑΤΩΝ ΤΥΠΟΠΟΙΗΣΗΣ, ΠΙΣΤΟΠΟΙΗΣΗΣ ΚΑΙ ΔΙΑΧΕΙΡΙΣΗΣ ΠΟΙΟΤΗΤΑΣ. Εισηγήτρια: Γκαβέλα Σταματία Δρ. Χημικός Μηχανικός ΕΜΠ

ΕΙΔΙΚΗ ΕΠΙΣΤΗΜΟΝΙΚΗ ΕΠΙΤΡΟΠΗ ΘΕΜΑΤΩΝ ΤΥΠΟΠΟΙΗΣΗΣ, ΠΙΣΤΟΠΟΙΗΣΗΣ ΚΑΙ ΔΙΑΧΕΙΡΙΣΗΣ ΠΟΙΟΤΗΤΑΣ. Εισηγήτρια: Γκαβέλα Σταματία Δρ. Χημικός Μηχανικός ΕΜΠ ΕΝΗΜΕΡΩΤΙΚΗ ΕΚΔΗΛΩΣΗ ΤΕΕ ΓΙΑ ΤΗ ΔΙΑΧΕΙΡΙΣΗ ΤΗΣ ΠΟΙΟΤΗΤΑΣ ΤΕΧΝΙΚΟ ΕΠΙΜΕΛΗΤΗΡΙΟ ΕΛΛΑΔΑΣ ΕΕΕ ΤΠΔΠ ΕΙΔΙΚΗ ΕΠΙΣΤΗΜΟΝΙΚΗ ΕΠΙΤΡΟΠΗ ΘΕΜΑΤΩΝ ΤΥΠΟΠΟΙΗΣΗΣ, ΠΙΣΤΟΠΟΙΗΣΗΣ ΚΑΙ ΔΙΑΧΕΙΡΙΣΗΣ ΠΟΙΟΤΗΤΑΣ Θέμα εισήγησης: «ΕΛΟΤ

Διαβάστε περισσότερα

ΠΛΗΡΟΦΟΡΙΑΚΑ ΣΥΣΤΗΜΑΤΑ

ΠΛΗΡΟΦΟΡΙΑΚΑ ΣΥΣΤΗΜΑΤΑ ΠΛΗΡΟΦΟΡΙΑΚΑ ΣΥΣΤΗΜΑΤΑ Μάθημα 10: Ανάπτυξη ΠΣ Μαρίνος Θεμιστοκλέους Email: mthemist@unipi.gr Ανδρούτσου 150 Γραφείο 206 Τηλ. 210 414 2723 Ώρες Γραφείου: Δευτέρα 11-12 πμ Ενδεικτικά Περιεχόμενα Εργασίας

Διαβάστε περισσότερα

Εκπαιδευτική Μονάδα 10.2: Εργαλεία χρονοπρογραμματισμού των δραστηριοτήτων.

Εκπαιδευτική Μονάδα 10.2: Εργαλεία χρονοπρογραμματισμού των δραστηριοτήτων. Εκπαιδευτική Μονάδα 10.2: Εργαλεία χρονοπρογραμματισμού των δραστηριοτήτων. Στην προηγούμενη Εκπαιδευτική Μονάδα παρουσιάστηκαν ορισμένα χρήσιμα παραδείγματα διαδεδομένων εργαλείων για τον χρονοπρογραμματισμό

Διαβάστε περισσότερα

Διαχείριση Έργων. Ενότητα 7: Εκτέλεση, παρακολούθηση και έλεγχος έργου

Διαχείριση Έργων. Ενότητα 7: Εκτέλεση, παρακολούθηση και έλεγχος έργου Διαχείριση Έργων Ενότητα 7: Εκτέλεση, παρακολούθηση και έλεγχος έργου Μπεληγιάννης Γρηγόριος Σχολή Οργάνωσης και Διοίκησης Επιχειρήσεων Τμήμα Διοίκησης Επιχειρήσεων Αγροτικών Προϊόντων & Τροφίμων (Δ.Ε.Α.Π.Τ.)

Διαβάστε περισσότερα

Πληροφοριακά Συστήματα Διοίκησης (ΜΒΑ) Ενότητα 4: Διαχείριση Έργων

Πληροφοριακά Συστήματα Διοίκησης (ΜΒΑ) Ενότητα 4: Διαχείριση Έργων Πληροφοριακά Συστήματα Διοίκησης (ΜΒΑ) Ενότητα 4: Διαχείριση Έργων Μπεληγιάννης Γρηγόριος Σχολή Οργάνωσης και Διοίκησης Επιχειρήσεων Τμήμα Διοίκησης Επιχειρήσεων Αγροτικών Προϊόντων & Τροφίμων (Δ.Ε.Α.Π.Τ.)

Διαβάστε περισσότερα

Πίνακας Περιεχομένων

Πίνακας Περιεχομένων Πίνακας Περιεχομένων Πρόλογος...13 Πρόλογος του Συγγραφέα...15 Κεφάλαιο 1: Βασικές Έννοιες της Διοίκησης - Διαχείρισης Έργου...19 1.1 Λειτουργία, Έργο, Πρόγραμμα...19 1.2 Οι Εμπλεκόμενοι στο Έργο...21

Διαβάστε περισσότερα

Τεχνολογία Λογισμικού

Τεχνολογία Λογισμικού Τμήμα Πληροφορικής & Τηλεπικοινωνιών, ΕΚΠΑ Τεχνολογία Λογισμικού 8ο Εξάμηνο 2018 19 Εισαγωγή στη διαχείριση έργων λογισμικού Δρ. Κώστας Σαΐδης saiko@di.uoa.gr A. Διαχείριση έργου γενικά Ορισμοί Βασικές

Διαβάστε περισσότερα

Οργανωτικές δομές. Κωνσταντίνος Κηρυττόπουλος Βρασίδας Λεώπουλος

Οργανωτικές δομές. Κωνσταντίνος Κηρυττόπουλος Βρασίδας Λεώπουλος Οργανωτικές δομές Κωνσταντίνος Κηρυττόπουλος Βρασίδας Λεώπουλος 1 Άδεια Χρήσης Το παρόν εκπαιδευτικό υλικό υπόκειται σε άδειες χρήσης Creative Commons. Για εκπαιδευτικό υλικό, όπως εικόνες, που υπόκειται

Διαβάστε περισσότερα

Πληροφοριακά Συστήματα Διοίκησης Ενότητα 9: Διαχείριση Έργων (1ο Μέρος)

Πληροφοριακά Συστήματα Διοίκησης Ενότητα 9: Διαχείριση Έργων (1ο Μέρος) Πληροφοριακά Συστήματα Διοίκησης Ενότητα 9: Διαχείριση Έργων (1ο Μέρος) Γρηγόριος Μπεληγιάννης Σχολή Οργάνωσης και Διοίκησης Επιχειρήσεων Τμήμα Διοίκησης Επιχειρήσεων Αγροτικών Προϊόντων και Τροφίμων Σκοποί

Διαβάστε περισσότερα

Διαχείριση Έργων. Ενότητα 1: Εισαγωγή στη διαχείριση έργου (ιστορία, πρότυπα, ενοποίηση)

Διαχείριση Έργων. Ενότητα 1: Εισαγωγή στη διαχείριση έργου (ιστορία, πρότυπα, ενοποίηση) Διαχείριση Έργων Ενότητα 1: Εισαγωγή στη διαχείριση έργου (ιστορία, πρότυπα, ενοποίηση) Μπεληγιάννης Γρηγόριος Σχολή Οργάνωσης και Διοίκησης Επιχειρήσεων Τμήμα Διοίκησης Επιχειρήσεων Αγροτικών Προϊόντων

Διαβάστε περισσότερα

ΔΙΟΙΚΗΣΗ ΕΡΓΩΝ. Τ Α Ε Ρ Γ Α Λ Ε Ι Α Τ Η ς Δ Ι Α Χ Ε Ι Ρ Ι Σ Η Σ Ε Ρ Γ Ω Ν - WBS. ΡΟΜΠΟΓΙΑΝΝΑΚΗΣ ΙΩΑΝΝΗΣ, PhD.

ΔΙΟΙΚΗΣΗ ΕΡΓΩΝ. Τ Α Ε Ρ Γ Α Λ Ε Ι Α Τ Η ς Δ Ι Α Χ Ε Ι Ρ Ι Σ Η Σ Ε Ρ Γ Ω Ν - WBS. ΡΟΜΠΟΓΙΑΝΝΑΚΗΣ ΙΩΑΝΝΗΣ, PhD. ΔΙΟΙΚΗΣΗ ΕΡΓΩΝ Τ Α Ε Ρ Γ Α Λ Ε Ι Α Τ Η ς Δ Ι Α Χ Ε Ι Ρ Ι Σ Η Σ Ε Ρ Γ Ω Ν - WBS ΤΑ ΕΡΓΑΛΕΙΑ ΤΟΥ PROJECT MANAGEMENT Η αποτελεσματική Διαχείριση Έργων υλοποιείται με την βοήθεια μιας σειράς εργαλείων και

Διαβάστε περισσότερα

Διαχείριση έργων. Βασικές αρχές Τεχνολογίας Λογισμικού, 8η αγγ. έκδοση

Διαχείριση έργων. Βασικές αρχές Τεχνολογίας Λογισμικού, 8η αγγ. έκδοση Διαχείριση έργων Στόχοι Ερμηνεία των κύριων εργασιών ενός διευθυντή έργου λογισμικού Παρουσίαση της διαχείρισης έργων λογισμικού και περιγραφή των χαρακτηριστικών που τη διακρίνουν Εξέταση του σχεδιασμού

Διαβάστε περισσότερα

Διοίκηση Έργων - Project Management

Διοίκηση Έργων - Project Management Πανεπιστήμιο Αιγαίου Πολυτεχνική Σχολή Τμήμα Μηχανικών Οικονομίας και Διοίκησης Διοίκηση Έργων - Project Management ΔΙΑΛΕΞΗ 1 η : Εισαγωγή στις βασικές έννοιες της Διοίκησης Έργων Δρ. Β. Ζεϊμπέκης Επίκουρος

Διαβάστε περισσότερα

Διαχείριση Έργων Πληροφορικής

Διαχείριση Έργων Πληροφορικής Διαχείριση Έργων Πληροφορικής Εισαγωγικό εργαστήριο Ευαγγελία Μανιαδή Άννα Μαριδάκη 07 & 08 Μαρτίου 2017 Μάθημα στο eclass Ονομασία: ΔΙΑΧΕΙΡΙΣΗ ΕΡΓΩΝ ΠΛΗΡΟΦΟΡΙΚΗΣ - ΕΑΡΙΝΟ 2017 Κωδικός Μαθήματος στο eclass:

Διαβάστε περισσότερα

Agile Προσέγγιση στη Διαχείριση Έργων Λογισμικού

Agile Προσέγγιση στη Διαχείριση Έργων Λογισμικού Agile Προσέγγιση στη Διαχείριση Έργων Λογισμικού Ενότητα 2- Οι αρχές της agile προσέγγισης Δρ. Δημήτριος Τσέλιος Καθηγητής Εφαρμογών Τμήμα Μηχανικών Πληροφορικής Τ.Ε.- ΤΕΙ Θεσσαλίας Μεταπτυχιακό Πρόγραμμα

Διαβάστε περισσότερα

Πληροφορική 2. Τεχνολογία Λογισμικού

Πληροφορική 2. Τεχνολογία Λογισμικού Πληροφορική 2 Τεχνολογία Λογισμικού 1 2 Κρίση Λογισμικού (1968) Στην δεκαετία του 1970 παρατηρήθηκαν μαζικά: Μεγάλες καθυστερήσεις στην ολοκλήρωση κατασκευής λογισμικών Μεγαλύτερα κόστη ανάπτυξης λογισμικού

Διαβάστε περισσότερα

ΕΙΣΑΓΩΓΗ ΣΤΗ ΔΙΑΧΕΙΡΙΣΗ ΕΡΓΩΝ. Πάνος Φιτσιλής

ΕΙΣΑΓΩΓΗ ΣΤΗ ΔΙΑΧΕΙΡΙΣΗ ΕΡΓΩΝ. Πάνος Φιτσιλής ΕΙΣΑΓΩΓΗ ΣΤΗ ΔΙΑΧΕΙΡΙΣΗ ΕΡΓΩΝ Πάνος Φιτσιλής pfitsilis@gmail.com Περιεχόμενα Σημερινής διάλεξης Πρότυπα διαχείρισης έργων Τα ΠΡΟΤΥΠΑ ΔΙΑΧΕΙΡΙΣΗΣ ΕΡΓΩΝ o o PMI PMBOK Project Management Body of Knowledge

Διαβάστε περισσότερα

Περιεχόμενα. Πρόλογος... 15 Σημείωμα του συγγραφέα... 18 Υποστηρικτικό υλικό... 22

Περιεχόμενα. Πρόλογος... 15 Σημείωμα του συγγραφέα... 18 Υποστηρικτικό υλικό... 22 Περιεχόμενα Πρόλογος........................................................ 15 Σημείωμα του συγγραφέα............................................ 18 Υποστηρικτικό υλικό................................................

Διαβάστε περισσότερα

ΑΝΤΙΚΕΙΜΕΝΟΣΤΡΕΦΗΣ ΑΝΑΛΥΣΗ Επιχειρηματική Μοντελοποίηση. Ιωάννης Σταμέλος Βάιος Κολοφωτιάς Πληροφορική

ΑΝΤΙΚΕΙΜΕΝΟΣΤΡΕΦΗΣ ΑΝΑΛΥΣΗ Επιχειρηματική Μοντελοποίηση. Ιωάννης Σταμέλος Βάιος Κολοφωτιάς Πληροφορική ΑΝΤΙΚΕΙΜΕΝΟΣΤΡΕΦΗΣ ΑΝΑΛΥΣΗ Επιχειρηματική Μοντελοποίηση Ιωάννης Σταμέλος Βάιος Κολοφωτιάς Πληροφορική Θεσσαλονίκη, Σεπτέμβριος 2013 Άδειες Χρήσης Το παρόν εκπαιδευτικό υλικό υπόκειται σε άδειες χρήσης

Διαβάστε περισσότερα

ΜΕΘΟΔΟΛΟΓΙΕΣ ΑΝΑΠΤΥΞΗΣ ΣΥΣΤΗΜΑΤΩΝ ΠΛΗΡΟΦΟΡΙΚΗΣ

ΜΕΘΟΔΟΛΟΓΙΕΣ ΑΝΑΠΤΥΞΗΣ ΣΥΣΤΗΜΑΤΩΝ ΠΛΗΡΟΦΟΡΙΚΗΣ ΜΕΘΟΔΟΛΟΓΙΕΣ ΑΝΑΠΤΥΞΗΣ ΣΥΣΤΗΜΑΤΩΝ ΠΛΗΡΟΦΟΡΙΚΗΣ Μεθοδολογίες Ανάπτυξης Συστημάτων Πληροφορικής Απαντούν στα εξής ερωτήματα Ποιά βήματα θα ακολουθηθούν? Με ποιά σειρά? Ποιά τα παραδοτέα και πότε? Επομένως,

Διαβάστε περισσότερα

Διαχείριση Έργων Πληροφορικής

Διαχείριση Έργων Πληροφορικής Διαχείριση Έργων Πληροφορικής Εισαγωγικό εργαστήριο Ευαγγελία Μανιαδή 27 & 28 Φεβρουαρίου 2018 Μάθημα στο eclass Ονομασία: ΔΙΑΧΕΙΡΙΣΗ ΕΡΓΩΝ ΠΛΗΡΟΦΟΡΙΚΗΣ - ΕΑΡΙΝΟ 2018 Κωδικός Μαθήματος στο eclass: TP364

Διαβάστε περισσότερα

Διαδικασίες παραγωγής λογισμικού. Βασικές αρχές Τεχνολογίας Λογισμικού, 8η αγγ. έκδοση

Διαδικασίες παραγωγής λογισμικού. Βασικές αρχές Τεχνολογίας Λογισμικού, 8η αγγ. έκδοση Διαδικασίες παραγωγής λογισμικού Περιεχόμενα Παρουσίαση μοντέλων διεργασίας ανάπτυξης λογισμικού Περιγραφή τριών γενικών μοντέλων διεργασίας ανάπτυξης λογισμικού Γενική περιγραφή των διαδικασιών που περιλαμβάνονται

Διαβάστε περισσότερα

Η συμβολή στην επιτυχία ενός οργανισμού, παρουσιάζοντας σχετικά δεδομένα με τη χρήση τεχνικών 2Δ ή 3Δ τεχνολογίας. Αρμοδιότητα

Η συμβολή στην επιτυχία ενός οργανισμού, παρουσιάζοντας σχετικά δεδομένα με τη χρήση τεχνικών 2Δ ή 3Δ τεχνολογίας. Αρμοδιότητα Σχεδιαστής Ψηφιακών Κινούμενων Σχεδίων ή Digital Animator 1. Περιγραφή Ρόλου Τίτλος Προφίλ Σχε Σχεδιαστής Ψηφιακών Κινούμενων Σχεδίων ή Digital Animator Γνωστό και ως Ειδικός Σχεδιασμού 2Δ- 3Δ γραφικών,

Διαβάστε περισσότερα

ΤΕΙ ΚΡΗΤΗΣ ΤΜΗΜΑ ΛΟΓΙΣΤΙΚΗΣ ΔΙΟΙΚΗΣΗ ΕΠΙΧΕΙΡΗΣΕΩΝ ΣΥΣΤΗΜΑΤΑ ΠΟΙΟΤΗΤΑΣ

ΤΕΙ ΚΡΗΤΗΣ ΤΜΗΜΑ ΛΟΓΙΣΤΙΚΗΣ ΔΙΟΙΚΗΣΗ ΕΠΙΧΕΙΡΗΣΕΩΝ ΣΥΣΤΗΜΑΤΑ ΠΟΙΟΤΗΤΑΣ ΤΕΙ ΚΡΗΤΗΣ ΤΜΗΜΑ ΛΟΓΙΣΤΙΚΗΣ ΔΙΟΙΚΗΣΗ ΕΠΙΧΕΙΡΗΣΕΩΝ ΣΥΣΤΗΜΑΤΑ ΠΟΙΟΤΗΤΑΣ Στόχος Βασικές έννοιες για την ποιότητα και τα συστήματα ποιότητας Έννοια της ποιότητας και των συστημάτων ποιότητας Τεκμηρίωση ενός

Διαβάστε περισσότερα

Περιεχόμενα. Κεφάλαιο 3 Πρότυπα διαχείρισης έργου 46

Περιεχόμενα. Κεφάλαιο 3 Πρότυπα διαχείρισης έργου 46 Περιεχόμενα Πρόλογος Σημείωμα του συγγραφέα Κεφάλαιο 1 Εισαγωγή στη διαχείριση έργου 18 1. Τι είναι έργο; 21 2. Έργο εναντίον γραμμής παραγωγής 23 3. Τύποι έργων 26 4. Τι είναι διαχείριση έργου; 29 5.

Διαβάστε περισσότερα

Εκπαιδευτική Μονάδα 1.1: Τεχνικές δεξιότητες και προσόντα

Εκπαιδευτική Μονάδα 1.1: Τεχνικές δεξιότητες και προσόντα Εκπαιδευτική Μονάδα 1.1: Τεχνικές δεξιότητες και προσόντα Πέρα από την τυπολογία της χρηματοδότησης, των εμπλεκόμενων ομάδων-στόχων και την διάρκεια, κάθε project διακρατικής κινητικότητας αποτελεί μια

Διαβάστε περισσότερα

6. Διαχείριση Έργου. Έκδοση των φοιτητών

6. Διαχείριση Έργου. Έκδοση των φοιτητών 6. Διαχείριση Έργου Έκδοση των φοιτητών Εισαγωγή 1. Η διαδικασία της Διαχείρισης Έργου 2. Διαχείριση κινδύνων Επανεξέταση Ερωτήσεις Αυτοαξιολόγησης Διαχείριση του έργου είναι να βάζεις σαφείς στόχους,

Διαβάστε περισσότερα

Ποιότητα και Πρότυπα στη Διοίκηση Επιχειρήσεων Συστήµατα Διασφάλισης Ποιότητας ISO Διεργασιακή Προσέγγιση Διάλεξη 3

Ποιότητα και Πρότυπα στη Διοίκηση Επιχειρήσεων Συστήµατα Διασφάλισης Ποιότητας ISO Διεργασιακή Προσέγγιση Διάλεξη 3 Ποιότητα και Πρότυπα στη Διοίκηση Επιχειρήσεων Συστήµατα Διασφάλισης Ποιότητας ISO 9001- Διεργασιακή Προσέγγιση Διάλεξη 3 Τµήµα Διοίκησης Επιχειρήσεων Τει Δυτικής Ελλάδας Μεσολόγγι Δρ. Α. Στεφανή ISO 9001:

Διαβάστε περισσότερα

Μεθοδολογίες Παραγωγής Λογισµικού

Μεθοδολογίες Παραγωγής Λογισµικού Μεθοδολογίες Παραγωγής Λογισµικού Βασικά Γενικά Μοντέλα Μοντέλο καταρράκτη (waterfall model) Ξεχωριστές φάσεις καθορισµού απαιτήσεων και ανάπτυξης, επικύρωσης, εξέλιξης Εξελικτική ανάπτυξη (evolutionary

Διαβάστε περισσότερα

Διαχείριση Έργων. Ενότητα 2: Διεργασία και σχέδιο διαχείρισης, κύκλος ζωής και μελέτη σκοπιμότητας έργου

Διαχείριση Έργων. Ενότητα 2: Διεργασία και σχέδιο διαχείρισης, κύκλος ζωής και μελέτη σκοπιμότητας έργου Διαχείριση Έργων Ενότητα 2: Διεργασία και σχέδιο διαχείρισης, κύκλος ζωής και μελέτη σκοπιμότητας έργου Μπεληγιάννης Γρηγόριος Σχολή Οργάνωσης και Διοίκησης Επιχειρήσεων Τμήμα Διοίκησης Επιχειρήσεων Αγροτικών

Διαβάστε περισσότερα

Εισαγωγή στη Σχεδίαση Λογισμικού

Εισαγωγή στη Σχεδίαση Λογισμικού Εισαγωγή στη Σχεδίαση Λογισμικού περιεχόμενα παρουσίασης Τι είναι η σχεδίαση λογισμικού Έννοιες σχεδίασης Δραστηριότητες σχεδίασης Σχεδίαση και υποδείγματα ανάπτυξης λογισμικού σχεδίαση Η σχεδίαση του

Διαβάστε περισσότερα

Τ.Ε.Ι. ΚΡΗΤΗΣ, Σ.Δ.Ο., Τμήμα Λογιστικής. Business Processes

Τ.Ε.Ι. ΚΡΗΤΗΣ, Σ.Δ.Ο., Τμήμα Λογιστικής. Business Processes Τ.Ε.Ι. ΚΡΗΤΗΣ, Σ.Δ.Ο., Τμήμα Λογιστικής Business Processes Οι οργανισμοί-επιχειρήσεις υπάρχουν για να εξυπηρετούν κάποιο εμπορικό σκοπό ή να προσφέρουν κάποιες κοινωνικές υπηρεσίες. Διαφέρουν είτε στον

Διαβάστε περισσότερα

ΚΕΦΑΛΑΙΟ 5. Κύκλος Ζωής Εφαρμογών ΕΝΟΤΗΤΑ 2. Εφαρμογές Πληροφορικής. Διδακτικές ενότητες 5.1 Πρόβλημα και υπολογιστής 5.2 Ανάπτυξη εφαρμογών

ΚΕΦΑΛΑΙΟ 5. Κύκλος Ζωής Εφαρμογών ΕΝΟΤΗΤΑ 2. Εφαρμογές Πληροφορικής. Διδακτικές ενότητες 5.1 Πρόβλημα και υπολογιστής 5.2 Ανάπτυξη εφαρμογών 44 Διδακτικές ενότητες 5.1 Πρόβλημα και υπολογιστής 5.2 Ανάπτυξη εφαρμογών Διδακτικοί στόχοι Σκοπός του κεφαλαίου είναι οι μαθητές να κατανοήσουν τα βήματα που ακολουθούνται κατά την ανάπτυξη μιας εφαρμογής.

Διαβάστε περισσότερα

ΑΡΧΕΙΟ ΠΡΙΝ ΤΙΣ ΔΙΟΡΘΩΣΕΙΣ

ΑΡΧΕΙΟ ΠΡΙΝ ΤΙΣ ΔΙΟΡΘΩΣΕΙΣ Περιεχόμενα Πρόλογος Σημείωμα του συγγραφέα Κεφάλαιο 1 Εισαγωγή στη διαχείριση έργου 18 1. Τι είναι έργο; 21 2. Έργο εναντίον γραμμής παραγωγής 23 3. Τύποι έργων 26 4. Τι είναι διαχείριση έργου; 29 5.

Διαβάστε περισσότερα

Αρχιτεκτονική Λογισμικού

Αρχιτεκτονική Λογισμικού Αρχιτεκτονική Λογισμικού περιεχόμενα παρουσίασης Τι είναι η αρχιτεκτονική λογισμικού Αρχιτεκτονική και απαιτήσεις Σενάρια ποιότητας Βήματα αρχιτεκτονικής σχεδίασης Αρχιτεκτονικά πρότυπα Διαστρωματωμένη

Διαβάστε περισσότερα

Διαχείριση Έργων Πληροφορικής

Διαχείριση Έργων Πληροφορικής Διαχείριση Έργων Πληροφορικής Project Lifecycle Κύκλος ζωής ενός έργου Μ. Τσικνάκης Ε. Μανιαδή, Α. Μαριδάκη Διαχείριση Έργων - Project Management What is a project? One definition of a project (from the

Διαβάστε περισσότερα

Κεφάλαιο 2: Έννοιες και Ορισμοί

Κεφάλαιο 2: Έννοιες και Ορισμοί ΔΙΟΙΚΗΣΗ ΟΛΙΚΗΣ ΠΟΙΟΤΗΤΑΣ Ε.ΜΙΧΑΗΛΙΔΟΥ - 1 Κεφάλαιο 2: Έννοιες και Ορισμοί Η επιτυχία των επιχειρήσεων βασίζεται στην ικανοποίηση των απαιτήσεων των πελατών για: - Ποιοτικά και αξιόπιστα προϊόντα - Ποιοτικές

Διαβάστε περισσότερα

Προγράμματα Η /Υ / Εφαρμογές σε συστ ήματα Π ό οι τητας Αριστομένης Μακρής

Προγράμματα Η /Υ / Εφαρμογές σε συστ ήματα Π ό οι τητας Αριστομένης Μακρής Προγράμματα Η/Υ Εφαρμογές σε συστήματα Ποιότητας Οι οκτώ αρχές της ποιότητας Εστίαση στον πελάτη: οι επιχειρήσεις, δδ δεδομένου ότι στηρίζονται και εξαρτώνται απ τους πελάτες, οφείλουν να αναγνωρίζουν

Διαβάστε περισσότερα

Πληροφοριακά Συστήματα Διοίκησης. Διοικητική Επιστήμη και Λήψη Αποφάσεων

Πληροφοριακά Συστήματα Διοίκησης. Διοικητική Επιστήμη και Λήψη Αποφάσεων Πληροφοριακά Συστήματα Διοίκησης Διοικητική Επιστήμη και Λήψη Αποφάσεων Η πολυπλοκότητα των αποφάσεων Αυξανόμενη πολυπλοκότητα λόγω: Ταχύτητας αλλαγών στο εξωτερικό περιβάλλον της επιχείρησης. Έντασης

Διαβάστε περισσότερα

Διοίκηση Παραγωγής και Υπηρεσιών

Διοίκηση Παραγωγής και Υπηρεσιών Διοίκηση Παραγωγής και Υπηρεσιών Εισαγωγή -3 Γιώργος Ιωάννου, Ph.D. Αναπληρωτής Καθηγητής Σύνοψη διάλεξης Σχεδιασμός διαδικασιών ορισμός Συστημική προσέγγιση Μεθοδολογίες σχεδιασμού διαδικασιών Διαγράμματα

Διαβάστε περισσότερα

ΤΕΙ ΛΑΡΙΣΑΣ - ΛΑΜΙΑΣ. Ενθάρρυνση Επιχειρηματικών Δράσεων, Καινοτομικών Εφαρμογών και Μαθημάτων Επιλογής Φοιτητών ΤΕΙ Λάρισας - Λαμίας PLEASE ENTER

ΤΕΙ ΛΑΡΙΣΑΣ - ΛΑΜΙΑΣ. Ενθάρρυνση Επιχειρηματικών Δράσεων, Καινοτομικών Εφαρμογών και Μαθημάτων Επιλογής Φοιτητών ΤΕΙ Λάρισας - Λαμίας PLEASE ENTER ΤΕΙ ΛΑΡΙΣΑΣ - ΛΑΜΙΑΣ Ενθάρρυνση Επιχειρηματικών Δράσεων, Καινοτομικών Εφαρμογών και Μαθημάτων Επιλογής Φοιτητών ΤΕΙ Λάρισας - Λαμίας PLEASE ENTER ΕΚΠΑΙΔΕΥΤΙΚΟ ΥΛΙΚΟ ΚΕΦΑΛΑΙΟ 12 «ΔΙΟΙΚΗΣΗ ΟΛΙΚΗΣ ΠΟΙΟΤΗΤΑΣ

Διαβάστε περισσότερα

Μοντέλο συστήματος διαχείρισης της ποιότητας

Μοντέλο συστήματος διαχείρισης της ποιότητας Μοντέλο συστήματος διαχείρισης της ποιότητας Διαρκής βελτίωση του Συστήματος Διαχείρισης της Ποιότητας Ευθύνη της Διοίκησης Πελάτες Πελάτες Διαχείριση Πόρων Μέτρηση, ανάλυση και βελτίωση Ικανοποίηση Απαιτήσεις

Διαβάστε περισσότερα

Εισαγωγή, Βασικές Έννοιες, Οφέλη και Κίνδυνοι

Εισαγωγή, Βασικές Έννοιες, Οφέλη και Κίνδυνοι Εισαγωγή, Βασικές Έννοιες, Οφέλη και Κίνδυνοι Ευθύμιος Ταμπούρης tambouris@uom.gr Επιστημονική Επιχειρηματική Χρήση των Η/Υ Η επιστημονική κοινότητα ασχολείται με τη λύση πολύπλοκων μαθηματικών προβλημάτων

Διαβάστε περισσότερα

2. Ανάλυση Ενδιαφερομένων Μερών

2. Ανάλυση Ενδιαφερομένων Μερών 2. Ανάλυση Ενδιαφερομένων Μερών To Περιβάλλον του Έργου Ενδιαφερόμενα Μέρη (Interested Parties or Stakeholders) Άτομα ή Ομάδες Που έχουν άμεσο ενδιαφέρον για την εκτέλεση ή/και για την επιτυχία του έργου

Διαβάστε περισσότερα

Προδιαγραφές Απαιτήσεων Επικύρωση Απαιτήσεων

Προδιαγραφές Απαιτήσεων Επικύρωση Απαιτήσεων Προδιαγραφές Απαιτήσεων Επικύρωση Απαιτήσεων περιεχόμενα παρουσίασης Προδιαγραφές Απαιτήσεων Έγγραφο Προδιαγραφών Απαιτήσεων λογισμικού (ΕΠΑΛ) Επικύρωση απαιτήσεων Ιχνηλάτηση απαιτήσεων προδιαγραφές απαιτήσεων

Διαβάστε περισσότερα

Προγραμματισμός και Επιλογή Συστημάτων

Προγραμματισμός και Επιλογή Συστημάτων Ενότητα 4 Προγραμματισμός και Επιλογή Συστημάτων Πληροφοριακά Συστήματα Διοίκησης ΙI Νίκος Καρακαπιλίδης 4-1 Μαθησιακοί στόχοι Κατανόηση των διαδικασιών προσδιορισμού και επιλογής έργων ανάπτυξης ΠΣ Κατανόηση

Διαβάστε περισσότερα

Διαχείριση Έργων. Ενότητα 3: Διαχείριση εύρους έργου, δομή ανάλυσης εργασιών, μέθοδος CPM

Διαχείριση Έργων. Ενότητα 3: Διαχείριση εύρους έργου, δομή ανάλυσης εργασιών, μέθοδος CPM Διαχείριση Έργων Ενότητα 3: Διαχείριση εύρους έργου, δομή ανάλυσης εργασιών, μέθοδος CPM Μπεληγιάννης Γρηγόριος Σχολή Οργάνωσης και Διοίκησης Επιχειρήσεων Τμήμα Διοίκησης Επιχειρήσεων Αγροτικών Προϊόντων

Διαβάστε περισσότερα

Εισαγωγή στην Τεχνολογία Λογισμικού

Εισαγωγή στην Τεχνολογία Λογισμικού Εισαγωγή στην Τεχνολογία Λογισμικού περιεχόμενα παρουσίασης Αντικείμενο της Τεχνολογίας Λογισμικού Η ανάπτυξη λογισμικού Μοντέλα διαδικασίας λογισμικού τεχνολογία λογισμικού Κλάδος της πληροφορικής που

Διαβάστε περισσότερα

Διαδικασίες παραγωγής λογισμικού. I. Sommerville 2006 Βασικές αρχές Τεχνολογίας Λογισμικού, 8η αγγ. έκδοση Κεφ. 4

Διαδικασίες παραγωγής λογισμικού. I. Sommerville 2006 Βασικές αρχές Τεχνολογίας Λογισμικού, 8η αγγ. έκδοση Κεφ. 4 Διαδικασίες παραγωγής λογισμικού Στόχοι Παρουσίαση μοντέλων παραγωγής λογισμικού Περιγραφή τριών γενικών μοντέλων παραγωγής λογισμικού και πότε μπορούν να χρησιμοποιούνται Γενική περιγραφή των μοντέλων

Διαβάστε περισσότερα

Ποιότητα Λογισμικού και Πιστοποίηση

Ποιότητα Λογισμικού και Πιστοποίηση Ποιότητα Λογισμικού και Πιστοποίηση Πιστοποιήση: - Διεργασιών Λογισμικού - Προϊόντων Λογισμικού Ι. Σταμέλος Καθηγητής Τεχνολογίας Λογισμικού Τμ. Πληροφορικής Α.Π.Θ. Ποιότητα Λογισμικού Ένας ορισμός (από

Διαβάστε περισσότερα

Ανάπτυξη πληροφοριακών συστημάτων

Ανάπτυξη πληροφοριακών συστημάτων Κεφάλαιο 12 Ανάπτυξη πληροφοριακών συστημάτων 12.1 Επίλυση προβλημάτων και ανάπτυξη συστημάτων Τα νέα πληροφοριακά συστήματα δημιουργούνται για να δώσουν λύσεις σε συγκεκριμένα προβλήματα Η ανάπτυξη ενός

Διαβάστε περισσότερα

20/10/2017. Χειμερινό Εξάμηνο,

20/10/2017. Χειμερινό Εξάμηνο, Οργάνωση & Διαχείριση Υπόγειων Έργων-1 η ενότητα ΔΠΜΣ Σχεδιασμός & Κατασκευή Υπόγειων Εργων Κατερίνα Αδάμ, Μ. Sc., Ph.D Aναπληρώτρια Καθηγήτρια, Σχολή ΜΜΜ 20/10/2017 Χειμερινό Εξάμηνο, 2017-2018 1 Οργάνωση

Διαβάστε περισσότερα

Κεφάλαιο 2 ο. Συστήματα Πληροφοριών στην επιχείρηση

Κεφάλαιο 2 ο. Συστήματα Πληροφοριών στην επιχείρηση Κεφάλαιο 2 ο Συστήματα Πληροφοριών στην επιχείρηση Διδακτικοί στόχοι Να αναλυθούν οι ρόλοι των 6 τύπων των συστημάτων πληροφοριών Να περιγραφούν οι τύποι των πληροφοριακών συστημάτων Να αναλυθούν οι σχέσεις

Διαβάστε περισσότερα

Διαδικασίες παραγωγής λογισμικού. Βασικές αρχές Τεχνολογίας Λογισμικού, 8η αγγ. έκδοση

Διαδικασίες παραγωγής λογισμικού. Βασικές αρχές Τεχνολογίας Λογισμικού, 8η αγγ. έκδοση Διαδικασίες παραγωγής λογισμικού Περιεχόμενα Παρουσίαση μοντέλων διεργασίας ανάπτυξης λογισμικού Περιγραφή τριών γενικών μοντέλων διεργασίας ανάπτυξης λογισμικού Γενική περιγραφή των διαδικασιών που περιλαμβάνονται

Διαβάστε περισσότερα

Συστήματα Διαχείρισης Ποιότητας Το πρότυπο ISO9001:2015 και οι εφαρμογές του

Συστήματα Διαχείρισης Ποιότητας Το πρότυπο ISO9001:2015 και οι εφαρμογές του Συστήματα Διαχείρισης Ποιότητας Το πρότυπο ISO9001:2015 και οι εφαρμογές του 4 η ενότητα Τομέας Βιομηχανικής Διοίκησης & Επιχειρησιακής Έρευνας ΕΜΠ Απαιτήσεις του ISO9001:2015 1. Αντικείμενο 2. Τυποποιητική

Διαβάστε περισσότερα

Διοίκηση Έργων Πληροφορικής - Τηλεπικοινωνιών

Διοίκηση Έργων Πληροφορικής - Τηλεπικοινωνιών Διοίκηση Έργων Πληροφορικής - Τηλεπικοινωνιών ΔΗΜΗΤΡΑ ΤΖΙΓΚΟΥ Λ Ε Υ Κ Α Δ Α 2 0 1 2 (1/2) Ένα έργο (project) Πληροφορικής είναι ένα σύνολο από δραστηριότητες, δηλαδή εργασίες που η υλοποίηση τους απαιτεί

Διαβάστε περισσότερα

22/2/2014 ΑΡΧΕΣ ΟΡΓΑΝΩΣΗΣ ΚΑΙ ΔΙΟΙΚΗΣΗΣ ΕΠΙΧΕΙΡΗΣΕΩΝ ΚΑΙ ΥΠΗΡΕΣΙΩΝ. Επιστήμη Διοίκησης Επιχειρήσεων. Πότε εμφανίστηκε η ανάγκη της διοίκησης;

22/2/2014 ΑΡΧΕΣ ΟΡΓΑΝΩΣΗΣ ΚΑΙ ΔΙΟΙΚΗΣΗΣ ΕΠΙΧΕΙΡΗΣΕΩΝ ΚΑΙ ΥΠΗΡΕΣΙΩΝ. Επιστήμη Διοίκησης Επιχειρήσεων. Πότε εμφανίστηκε η ανάγκη της διοίκησης; ΑΡΧΕΣ ΟΡΓΑΝΩΣΗΣ ΚΑΙ ΔΙΟΙΚΗΣΗΣ ΕΠΙΧΕΙΡΗΣΕΩΝ ΚΑΙ ΥΠΗΡΕΣΙΩΝ Πότε εμφανίστηκε η ανάγκη της διοίκησης; Κεφάλαιο 2 ο Η επιστήμη της Διοίκησης των Επιχειρήσεων Όταν το άτομο δημιούργησε ομάδες. Για ποιο λόγο

Διαβάστε περισσότερα

02α Διαχείριση Έργων Λογισμικού

02α Διαχείριση Έργων Λογισμικού 02α Διαχείριση Έργων Λογισμικού Τεχνολογία Λογισμικού Σχολή Hλεκτρολόγων Mηχανικών & Mηχανικών Yπολογιστών Εθνικό Μετσόβιο Πολυτεχνείο Χειμερινό εξάμηνο 2017 18 Δρ. Κώστας Σαΐδης saiko@di.uoa.gr Διαχείριση

Διαβάστε περισσότερα

Ελληνική Εταιρεία Πιστοποιημένων Απεντομωτών (Ε.Ε.Π.Α.)

Ελληνική Εταιρεία Πιστοποιημένων Απεντομωτών (Ε.Ε.Π.Α.) Ελληνική Εταιρεία Πιστοποιημένων Απεντομωτών (Ε.Ε.Π.Α.) ΕΓΧΕΙΡΙΔΙΟ ΠΟΙΟΤΗΤΑΣ 2_Egxeiridio_Poiothtas_v03 Σελίδα 1 από 16 ΠΕΡΙΕΧΟΜΕΝΑ ΕΓΧΕΙΡΙΔΙΟΥ σελίδα ΠΑΡΟΥΣΙΑΣΗ ΕΕΠΑ 3 ΠΟΛΙΤΙΚΗ ΠΟΙΟΤΗΤΑΣ ΚΑΙ ΔΕΣΜΕΥΣΗ

Διαβάστε περισσότερα

Το σύστημα ISO9000. Παρουσιάστηκε το 1987, αναθεωρήθηκε το 1994 και το 2000.

Το σύστημα ISO9000. Παρουσιάστηκε το 1987, αναθεωρήθηκε το 1994 και το 2000. Το σύστημα ISO9000 Παρουσιάστηκε το 1987, αναθεωρήθηκε το 1994 και το 2000. Με τις αλλαγές δόθηκε έμφαση στην εφαρμογή της πολιτικής της ποιότητας και σε πιο πλήρεις διορθωτικές ενέργειες. Σε όλο τον κόσμο,

Διαβάστε περισσότερα

ΘΕΜΑ: MASTERPLAN OF THE OLYMPIC GAMES.

ΘΕΜΑ: MASTERPLAN OF THE OLYMPIC GAMES. ΠΑΝΕΠΙΣΤΗΜΙΟ ΠΕΛΟΠΟΝΝΗΣΟΥ ΣΧΟΛΗ ΑΝΘΡΩΠΙΝΗΣ ΚΙΝΗΣΗΣ & ΠΟΙΟΤΗΤΑΣ ΖΩΗΣ ΤΜΗΜΑ ΟΡΓΑΝΩΣΗΣ ΚΑΙ ΔΙΑΧΕΙΡΙΣΗΣ ΑΘΛΗΤΙΣΜΟΥ ΘΕΜΑ: MASTERPLAN OF THE OLYMPIC GAMES. ΕΠΙΜΕΛΕΙΑ: ΔΑΣΚΑΛΟΠΟΥΛΟΥ ΑΙΚΑΤΕΡΙΝΗ ΚΑΤΣΟΥΛΙΔΟΥ ΣΤΕΛΛΑ

Διαβάστε περισσότερα

Προκαταρκτική Φάση Ανάλυσης

Προκαταρκτική Φάση Ανάλυσης Ενότητα 2 Προκαταρκτική Φάση Ανάλυσης Πληροφοριακά Συστήματα Διοίκησης ΙI Ι Διδάσκων: Νίκος Καρακαπιλίδης 2-1 Στόχοι & αντικείμενο ενότητας Εισαγωγικές Έννοιες, εργασίες, τεχνικές, μέθοδοι, εργαλεία Σχέδιο

Διαβάστε περισσότερα

Προγραμματισμός και στρατηγική διοίκηση. 4 ο Κεφάλαιο

Προγραμματισμός και στρατηγική διοίκηση. 4 ο Κεφάλαιο Προγραμματισμός και στρατηγική διοίκηση 4 ο Κεφάλαιο Μαθησιακοί στόχοι (1) Μετά τη μελέτη του κεφαλαίου, θα είστε σε θέση να: 1. Συνοψίσετε τα βασικά βήματα σε οποιαδήποτε διαδικασία προγραμματισμού. 2.

Διαβάστε περισσότερα

ΠΛΗΡΟΦΟΡΙΑΚΑ ΣΥΣΤΗΜΑΤΑ ΔΙΟΙΚΗΣΗΣ MANAGEMENT INFORMATION SYSTEMS (M.I.S.)

ΠΛΗΡΟΦΟΡΙΑΚΑ ΣΥΣΤΗΜΑΤΑ ΔΙΟΙΚΗΣΗΣ MANAGEMENT INFORMATION SYSTEMS (M.I.S.) ΠΛΗΡΟΦΟΡΙΑΚΑ ΣΥΣΤΗΜΑΤΑ ΔΙΟΙΚΗΣΗΣ MANAGEMENT INFORMATION SYSTEMS (M.I.S.) 1.1 Κωνσταντίνος Ταραμπάνης Καθηγητής Τμήμα Οργάνωσης και Διοίκησης Επιχειρήσεων Πανεπιστήμιο Μακεδονίας Γρ. 307 2310-891-578 kat@uom.gr

Διαβάστε περισσότερα

Επιχειρησιακή Στρατηγική και Πολιτική Ο σκελετός της ιοίκησης

Επιχειρησιακή Στρατηγική και Πολιτική Ο σκελετός της ιοίκησης και Πολιτική Ο σκελετός της ιοίκησης Η Αλίκη στη χώρα των θαυµάτων Αυτό εξαρτάται από το πού θέλεις να φτάσεις Μπορείς να µου πεις προς τα πού πρέπει να πάω; Επιτυχηµένοι Αποτυχηµένοι Οργανισµοί Επιτυχηµένοι

Διαβάστε περισσότερα

ΕΝΟΤΗΤΑ 2 η ΙΑΧΕΙΡΙΣΗ ΡΟΗΣ ΕΡΓΑΣΙΑΣ (WORKFLOW MANAGEMENT) 2.1 Εισαγωγή

ΕΝΟΤΗΤΑ 2 η ΙΑΧΕΙΡΙΣΗ ΡΟΗΣ ΕΡΓΑΣΙΑΣ (WORKFLOW MANAGEMENT) 2.1 Εισαγωγή ΕΝΟΤΗΤΑ 2 η ΙΑΧΕΙΡΙΣΗ ΡΟΗΣ ΕΡΓΑΣΙΑΣ (WORKFLOW MANAGEMENT) 2.1 Εισαγωγή Οι σηµερινές δραστηριότητες των επιχειρήσεων δηµιουργούν την ανάγκη για όσο το δυνατό µεγαλύτερη υποστήριξη από τα πληροφοριακά τους

Διαβάστε περισσότερα

ΕΚΠΑΙΔΕΥΤΙΚΗ ΔΡΑΣΤΗΡΙΟΤΗΤΑ βάφοντας το σαλόνι Ent-teach Kεφάλαιο 6 Διαχείριση Έργου

ΕΚΠΑΙΔΕΥΤΙΚΗ ΔΡΑΣΤΗΡΙΟΤΗΤΑ βάφοντας το σαλόνι Ent-teach Kεφάλαιο 6 Διαχείριση Έργου ΕΚΠΑΙΔΕΥΤΙΚΗ ΔΡΑΣΤΗΡΙΟΤΗΤΑ βάφοντας το σαλόνι Ent-teach Kεφάλαιο 6 Διαχείριση Έργου Περιγραφή της εκπαιδευτικής δραστηριότητας Εσύ μαζί με 3 φίλους σου αποφασίζετε να βάψετε το καθιστικό. Για να μπορέσετε

Διαβάστε περισσότερα

ΠΑΝΕΠΙΣΤΗΜΙΟ ΣΤΕΡΕΑΣ ΕΛΛΑΔΑΣ- ΤΜΗΜΑ ΠΕΡΙΦΕΡΕΙΑΚΗΣ ΟΙΚΟΝΟΜΙΚΗΣ ΑΝΑΠΤΥΞΗΣ, ΜΑΘΗΜΑ: ΔΙΑΧΕΙΡΙΣΗ ΑΝΘΡΩΠΙΝΩΝ ΚΑΙ ΦΥΣΙΚΩΝ ΠΟΡΩΝ- ΧΡΙΣΤΟΣ ΑΠ.

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

Διαβάστε περισσότερα

2. Ανάλυση Ενδιαφερομένων Μερών

2. Ανάλυση Ενδιαφερομένων Μερών 2. Ανάλυση Ενδιαφερομένων Μερών To Περιβάλλον του Έργου Ενδιαφερόμενα Μέρη (Interested Parties or Stakeholders) Άτομα ή Ομάδες Που έχουν άμεσο ενδιαφέρον για την εκτέλεση ή/και για την επιτυχία του έργου

Διαβάστε περισσότερα

ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΙΓΑΙΟΥ

ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΙΓΑΙΟΥ ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΙΓΑΙΟΥ ΤΜΗΜΑ ΜΗΧΑΝΙΚΩΝ ΠΛΗΡΟΦΟΡΙΑΚΩΝ ΚΑΙ ΕΠΙΚΟΙΝΩΝΙΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ ΠΡΟΠΤΥΧΙΑΚΟ ΠΡΟΓΡΑΜΜΑ ΣΠΟΥΔΩΝ ΜΑΘΗΜΑ: ΤΕΧΝΟΛΟΓΙΑ ΛΟΓΙΣΜΙΚΟΥ ΔΙΑΔΙΚΑΣΙΕΣ ΠΑΡΑΓΩΓΗΣ ΛΟΓΙΣΜΙΚΟΥ Διδάσκων: Γ. Χαραλαμπίδης,

Διαβάστε περισσότερα

Γενική Επισκόπηση. Διοίκηση Έργων Πληροφορικής ΤΕΙ Δυτικής Ελλάδας Τµήµα Διοίκησης Επιχειρήσεων (Μεσολόγγι)

Γενική Επισκόπηση. Διοίκηση Έργων Πληροφορικής ΤΕΙ Δυτικής Ελλάδας Τµήµα Διοίκησης Επιχειρήσεων (Μεσολόγγι) Γενική Επισκόπηση Διοίκηση Έργων Πληροφορικής ΤΕΙ Δυτικής Ελλάδας Τµήµα Διοίκησης Επιχειρήσεων (Μεσολόγγι) Έργο Ø «Ένα προσωρινό εγχείρημα που στοχεύει στη δημιουργία ενός μοναδικού προϊόντος, υπηρεσίας

Διαβάστε περισσότερα

H Έννοια και η Φύση του Προγραμματισμού. Αθανασία Καρακίτσιου, PhD

H Έννοια και η Φύση του Προγραμματισμού. Αθανασία Καρακίτσιου, PhD H Έννοια και η Φύση του Προγραμματισμού Αθανασία Καρακίτσιου, PhD 1 Η Διαδικασία του προγραμματισμού Προγραμματισμός είναι η διαδικασία καθορισμού στόχων και η επιλογή μιας μελλοντικής πορείας για την

Διαβάστε περισσότερα

Είναι πλήρως εξοικειωμένος με τους κανόνες λειτουργίας του Ταμείου.

Είναι πλήρως εξοικειωμένος με τους κανόνες λειτουργίας του Ταμείου. Πρόσληψη Προσόντα Η Διαχειριστική Επιτροπή (ΔΕ) επιλέγει ή/και προσλαμβάνει το Γενικό Διευθυντή του Ταμείου. Ο Γενικός Διευθυντής πρέπει να είναι πτυχιούχος και να κατέχει τα κατάλληλα ακαδημαϊκά και επαγγελματικά

Διαβάστε περισσότερα

Διαχείριση Έργων Πληροφορικής

Διαχείριση Έργων Πληροφορικής Διαχείριση Έργων Πληροφορικής Μελέτη Σκοπιμότητας Feasibility Study Μ. Τσικνάκης Ε. Μανιαδή, Α. Μαριδάκη Μάθημα στο eclass Ονομασία: ΔΙΑΧΕΙΡΙΣΗ ΕΡΓΩΝ ΠΛΗΡΟΦΟΡΙΚΗΣ ΕΑΡΙΝΟ 2017 Κωδικός Μαθήματος στο eclass:

Διαβάστε περισσότερα

Διαδικασίες παραγωγής λογισμικού. I. Sommerville 2006 Βασικές αρχές Τεχνολογίας Λογισμικού, 8η αγγ. έκδοση Κεφ. 4

Διαδικασίες παραγωγής λογισμικού. I. Sommerville 2006 Βασικές αρχές Τεχνολογίας Λογισμικού, 8η αγγ. έκδοση Κεφ. 4 Διαδικασίες παραγωγής λογισμικού Περιεχόμενα Παρουσίαση μοντέλων διεργασίας ανάπτυξης λογισμικού Περιγραφή τριών γενικών μοντέλων διεργασίας ανάπτυξης λογισμικού Γενική περιγραφή των διαδικασιών που περιλαμβάνονται

Διαβάστε περισσότερα

Σχεδιασµός πεδίου εφαρµογής του έργου

Σχεδιασµός πεδίου εφαρµογής του έργου ÊåöÜëáéï 3 Σχεδιασµός πεδίου εφαρµογής 3.1. Εισαγωγή Μετά την έναρξη, πρέπει να εκπονηθεί ένα σχέδιο διαχείρισης (project management plan), το οποίο αποτελεί την κύρια πηγή πληροφοριών για το πώς το επικείµενο

Διαβάστε περισσότερα

ΕΛΟΤ ΕΝ ISO 9000 και 9001

ΕΛΟΤ ΕΝ ISO 9000 και 9001 Εκδήλωση για την Παγκόσμια Ημέρα Προτύπων «Νέες εκδόσεις προτύπων διαχείρισης ποιότητας και περιβάλλοντος» Νέες εκδόσεις προτύπων για διαχείριση της ποιότητας ΕΛΟΤ ΕΝ ISO 9000 και 9001 Τετάρτη 14 Οκτωβρίου

Διαβάστε περισσότερα

«Συντονισμός του Σχεδιασμού και της Εφαρμογής Δημόσιων Πολιτικών»

«Συντονισμός του Σχεδιασμού και της Εφαρμογής Δημόσιων Πολιτικών» Πέμπτη 4 Δεκεμβρίου 2014 «Συντονισμός του Σχεδιασμού και της Εφαρμογής Δημόσιων Πολιτικών» Αποτελεσματική Παρακολούθηση και Αξιολόγηση της Εφαρμογής Δημόσιων Πολιτικών Νίκος Παπαδάτος, Μέλος & τ. Πρόεδρος

Διαβάστε περισσότερα

2. Ανάλυση Ενδιαφερομένων Μερών

2. Ανάλυση Ενδιαφερομένων Μερών 2. Ανάλυση Ενδιαφερομένων Μερών To Περιβάλλον του Έργου Ενδιαφερόμενα Μέρη (Interested Parties or Stakeholders) Άτομα ή Ομάδες Που έχουν άμεσο ενδιαφέρον για την εκτέλεση ή/και για την επιτυχία του έργου

Διαβάστε περισσότερα

«Διαδικασία Συµµετοχής Η σωστή επιλογή προγράµµατος, εταιρικού σχήµατος και στρατηγικής. Η υποβολή της πρότασης»

«Διαδικασία Συµµετοχής Η σωστή επιλογή προγράµµατος, εταιρικού σχήµατος και στρατηγικής. Η υποβολή της πρότασης» Training Session Ευκαιρίες χρηµατοδότησης για έργα σχετικά µε την προστασία του περιβάλλοντος στην Περιφερειακή Ενότητα Πρέβεζας και στην Περιφέρεια Ηπείρου γενικότερα Πρέβεζα, 8 9 Οκτωβρίου 2012 «Διαδικασία

Διαβάστε περισσότερα

Στρατηγικό Σχεδιασµό Πληροφοριακών Συστηµάτων

Στρατηγικό Σχεδιασµό Πληροφοριακών Συστηµάτων Μέθοδοι και Τεχνικές για τον Στρατηγικό Σχεδιασµό Πληροφοριακών Συστηµάτων (SISP) Στρατηγική και Διοίκηση Πληροφοριακών Συστηµάτων Μάθηµα 2 No 1 Δοµή της Παρουσίασης l 1. Εισαγωγή l 2. Μεθοδολογία SISP

Διαβάστε περισσότερα

κώστας βεργίδης εισαγωγή στις βασικές έννοιες των επιχειρησιακών διεργασιών γραφείο 322 κτίριο Γ kvergidis@uom.gr 2310 891 637

κώστας βεργίδης εισαγωγή στις βασικές έννοιες των επιχειρησιακών διεργασιών γραφείο 322 κτίριο Γ kvergidis@uom.gr 2310 891 637 εισαγωγή στις βασικές έννοιες των επιχειρησιακών διεργασιών κώστας βεργίδης λέκτορας τμ. Εφαρμοσμένης Πληροφορικής γραφείο 322 κτίριο Γ kvergidis@uom.gr 2310 891 637 διαχείριση επιχειρηματικών διαδικασιών

Διαβάστε περισσότερα

ΕΚΠΑΙΔΕΥΤΙΚΗ ΔΡΑΣΤΗΡΙΟΤΗΤΑ Is είναι βιώσιμη η επιχείρηση

ΕΚΠΑΙΔΕΥΤΙΚΗ ΔΡΑΣΤΗΡΙΟΤΗΤΑ Is είναι βιώσιμη η επιχείρηση ΕΚΠΑΙΔΕΥΤΙΚΗ ΔΡΑΣΤΗΡΙΟΤΗΤΑ Is είναι βιώσιμη η επιχείρηση Ent-teach κεφαλαιο 3 - Ανάλυση Αγοράς Περιγραφή της εκπαιδευτικής δραστηριότητας Αυτή η εκπαιδευτική δραστηριότητα απευθύνεται σε μαθητές από όλους

Διαβάστε περισσότερα

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

ΣΥΝΘΕΣΗ ΚΑΙ ΔΙΑΧΕΙΡΙΣΗ ΟΜΑΔΩΝ ΠΑΡΑΓΩΓΗΣ ΕΦΑΡΜΟΓΩΝ ΠΟΛΥΜΕΣΩΝ ΣΥΝΘΕΣΗ ΚΑΙ ΔΙΑΧΕΙΡΙΣΗ ΟΜΑΔΩΝ ΠΑΡΑΓΩΓΗΣ ΕΦΑΡΜΟΓΩΝ ΠΟΛΥΜΕΣΩΝ Εργασία στην Ενότητα Πληροφορική-Πολυμέσα του ΜΠΣ «Γραφικές Τέχνες Πολυμέσα» του ΕΑΠ Μ. Μαργαριτόπουλος ΠΕΡΙΕΧΟΜΕΝΑ ΠΑΡΟΥΣΙΑΣΗΣ Σκοπός παρουσίασης

Διαβάστε περισσότερα