Διοίκηση έργου
Διομήδης Σπινέλλης
Τμήμα Διοικητικής Επιστήμης και Τεχνολογίας
Οικονομικό Πανεπιστήμιο Αθηνών
dds@aueb.gr
Οι δυσκολίες
-  Το προϊόν δεν έχει φυσική έκφανση
-  Δεν υπάρχουν κοινώς αποδεκτές και κοινές διεργασίες υλοποίησης
-  Τα μεγάλα έργα κατασκευάζονται κατά παραγγελία για συγκεκριμένες απαιτήσεις
-  Υπάρχει η ψευδαίσθηση πως το λογισμικό είναι εύπλαστο
-  Μικρές αλλαγές στο λογισμικό επηρεάζουν συχνά δυσανάλογα πολλά τμήματα
-  Δε χρησιμοποιούνται συχνά έτοιμα εξαρτήματα
 
Ενέργειες της διαχείρισης
-  Συγγραφή προτάσεων και προσφορών
-  Προγραμματισμός και οργάνωση του έργου
-  Κοστολόγηση
-  Έλεγχος και επιθεώρηση
-  Επιλογή και αξιολόγηση προσωπικού
-  Συγγραφή αναφορών και παρουσιάσεις
-  Επαφή με τον πελάτη
Στοιχεία της διαχείρισης
Η αποτελεσματική διαχείριση ασχολείται με τέσσερα βασικά στοιχεία:
-  Πρόσωπα
	
	-  Διοικητικό προσωπικό
	
-  Υπεύθυνοι έργου
	
-  Στελέχη υλοποίησης
	
-  Πελάτες
	
-  Τελικοί χρήστες
	
 
-  Προϊόν
-  Διεργασία
-  Έργο
Τεκμηρίωση σχεδιασμού
Ο τρόπος διαχείρισης ενός έργου περιγράφεται από τα παρακάτω σχέδια:
-  Σχέδιο ποιότητας
-  Σχέδιο επικύρωσης και ελέγχου
-  Σχέδιο διαχείρισης σχηματισμών
-  Σχέδιο συντήρησης
-  Σχέδιο ανάπτυξης του προσωπικού
Το σχέδιο του έργου
-  Εισαγωγή
	
	-  Στόχοι
	
-  Περιορισμοί (κόστος, χρόνος)
	
 
-  Οργάνωση
	
	-  Οργάνωση σε ομάδες
	
-  Ευθύνες
	
 
-  Ανάλυση κινδύνων (risk analysis)
-  Ανάγκες σε υλικό και λογισμικό
	
	-  Κόστος
	
-  Χρονοδιάγραμμα υλοποίησης παραγγελιών
	
 
-  Διαίρεση του έργου σε πακέτα εργασίας (workpackages)
	
	-  Πακέτα εργασίας
	
-  Παραδοτέα (deliverables)
	(προς τον πελάτη) Παράδειγμα:
		
		-  Μελέτη σκοπιμότητας
		
-  Απαιτήσεις συστήματος
		
-  Αρχέτυπο
		
-  Αρχιτεκτονικός σχεδιασμός
		
-  Αποτελέσματα ελέγχων
		
-  Λογισμικό
		
 
-  Ορόσημα (milestones)
	(παραδοτέα ή άλλα καλά καθορισμένα αποτελέσματα (π.χ. μεταγλώττιση χωρίς λάθη)
	
 
-  Χρονοδιάγραμμα
-  Μηχανισμοί ελέγχου και αναφορών
Ο ρόλος της δέσμευσης
Μεγάλα έργα απαιτούν τη συνεργασία πολλών ανθρώπων που να 
θέλουν και να μπορούν να δεσμευτούν για την επιτυχία
του έργου.
Για να είναι ουσιαστική και αποτελεσματική η δέσμευση θα πρέπει (Humphrey 1989):
-  Το πρόσωπο που δεσμεύεται να το κάνει με τη θέλησή του.
-  Η δέσμευση να μη γίνει πρόχειρα: να έχουν
εξεταστεί προσεκτικά το μέγεθος της εργασίας, οι πόροι και το χρονοδιάγραμμα.
-  Να υπάρχει συμφωνία για το τι πρέπει να εκτελεστεί,
από ποιον και πότε.
-  Η δέσμευση να διατυπωθεί ανοικτά και δημόσια.
-  Το πρόσωπο που έχει δεσμευτεί προσπαθεί να τηρήσει
τις υποσχέσεις του ακόμα και με εξωτερική βοήθεια.
-  Αν η δέσμευση δεν μπορεί να τηρηθεί στα προκαθορισμένα
πλαίσια δίνεται έγκαιρα προειδοποίηση και συμφωνείται νέο
χρονοδιάγραμμα.
(βλέπε και 
The Decision Cycle in the IT Industry)Διαχείριση κινδύνων
Η διαχείριση κινδύνων (risk management)
ενός έργου περιλαμβάνει τα παρακάτω στάδια
-  Προσδιορισμός των κινδύνων
-  Ανάλυση των κινδύνων ως προς 
	
	-  την πιθανότητα (%)
	
-  τα αποτελέσματα (καταστροφικά, σοβαρά, υποφερτά, ασήμαντα)
	
 
-  Προγραμματισμός διαχείρισης
	
-  Παρακολούθηση των κινδύνων και αναθεώρηση του σχεδίου
Κίνδυνοι του έργου
Τα αποτελέσματα ενός κινδύνου μπορούν να επηρεάσουν:
-   Το έργο
-   Το προϊόν
-   Την επιχείρηση
Χωρίζουμε τους κινδύνους στις παρακάτω κατηγορίες:
-  Τεχνολογία
-  Προσωπικό
-  Οργάνωση και δομή της επιχείρησης
-  Εργαλεία
-  Απαιτήσεις
-  Εκτίμηση
Οι σημαντικότεροι κίνδυνοι
Σύμφωνα με τον Boehm (1991) οι σημαντικότεροι κίνδυνοι ενός έργου 
ανάπτυξης λογισμικού είναι:
-  Έλλειψη προσωπικού
-  Μη ρεαλιστικό χρονοδιάγραμμα
-  Κακή κατανόηση των απαιτήσεων
-  Δύσχρηστη διεπαφή του χρήστη με το λογισμικό
-  Λογισμικό υπερβολικά περίπλοκο για τις ανάγκες του πελάτη
-  Μη ύπαρξη ελέγχου σε αλλαγές απαιτήσεων
-  Προβλήματα σε επαναχρησιμοποιούμενα εξαρτήματα ή σε εξωτερικό λογισμικό
-  Προβλήματα σε έργα που εκτελούνται από τρίτους
-  Χαμηλός χρόνος απόκρισης
-  Έργο πέρα από τις δυνατότητες της τεχνολογίας
Επιτήρηση
Η πρόοδος του έργου πρέπει να ελέγχεται σε τακτικά διαστήματα.
Ο έλεγχος γίνεται με αναφορές και σε συναντήσεις του έργου.
Στοιχεία προς έλεγχο μπορεί να είναι:
-  Τα ορόσημα που έχουν / δεν έχουν επιτευχθεί
-  Ανάλωση πόρων
-  Ανοικτά θέματα
-  Σχόλια του προσωπικού
-  Χρήση της τεχνολογίας
-  Παραγωγικότητα
-  Ποιότητα
Οργάνωση ομάδων
Μπορούμε να οργανώσουμε τις ομάδες υλοποίησης με τους παρακάτω τρόπους:
Επιλέγουμε το είδος της ομάδας σύμφωνα με τους παρακάτω παράγοντες:
-  Δυσκολία του προβλήματος (δύσκολο -> DD)
-  Μέγεθος του προβλήματος (μεγάλος -> CC, CD)
-  Χρόνος που η ομάδα θα βρίσκεται μαζί (μεγάλος -> DD)
-  Κατά πόσο το πρόγραμμα μπορεί να χωριστεί σε μικρότερα τμήματα (αν ναι -> CC, CD)
-  Απαιτούμενη ποιότητα και αξιοπιστία (μεγάλη -> CC, CD)
-  Αυστηρότητα στην τήρηση του χρόνου παράδοσης (αν ναι -> CC)
-  Απαιτούμενη από το έργο επικοινωνία μεταξύ των μελών 
Παράδειγμα στελέχωσης
Η εταιρία NuMega (Sullivan 2001) οργανώνει την ανάπτυξη των προϊόντων γύρω από
δύο ομάδες:
-  Κύρια ομάδα.  Ασχολείται με
	
	-  Διαχείριση του έργου
	
-  Ανάπτυξη λογισμικού
	
-  Διασφάλιση ποιότητας
	
-  Εκπαίδευση χρηστών
	
-  Ευχρηστία (usability) λογισμικού
	
-  Διεπαφή χρήστη
	
-  Οργάνωση της τελικής έκδοσης
	
 
-  Ομάδα υποστήριξης.  Ασχολείται με
	
	-  Διαχείριση του προϊόντος
	
-  Διάθεση στην αγορά
	
-  Υποστήριξη
	
-  Διαχείριση του ελέγχου beta
	
 
Στον υπεύθυνο του έργου αναφέρονται οι παρακάτω:
	-  Υπεύθυνος ανάπτυξης λογισμικού
	
-  Υπεύθυνος διασφάλισης ποιότητας
	
-  Υπεύθυνος χρηστών
	
-  Υπεύθυνος ευχρηστίας λογισμικού
	
-  Υπεύθυνος οργάνωσης της τελικής έκδοσης
	
O υπεύθυνος του έργου ασχολείται με:
	-  Στελέχωση
	
-  Διαχείριση ανθρώπινου δυναμικού
	
-  Καθορισμός και εκτέλεση του σχεδίου του έργου
	
-  Σύνδεση μεταξύ των ομάδων
	
-  Τήρηση του χρονοδιαγράμματος
	
O υπεύθυνος ανάπτυξης λογισμικού επιβλέπει τους υπεύθυνους ανά 
λειτουργική απαίτηση και ασχολείται με:
	-  Αρχιτεκτονική και τεχνικά στοιχεία του έργου
	
-  Επιλογή εργαλείων, τεχνολογιών και προτύπων
	
-  Το ρόλο του Μέντορα στα άλλα μέλη της ομάδας
	
-  Επίβλεψη των προβλημάτων του έργου
	
-  Συγγραφή κώδικα
	
O υπεύθυνος λειτουργικής απαίτησης επιβλέπει τους προγραμματιστές 
και ασχολείται με:
	-  Εναρμόνιση της αρχιτεκτονικής με τους άλλους υπεύθυνους
	
-  Έλεγχο και συγγραφή των απαιτήσεων
	
-  Σχεδιασμό της συγκεκριμένης λειτουργίας
	
-  Παροχή βοήθειας στην ομάδα διασφάλισης ποιότητας
	
-  Συγγραφή κώδικα
	
Καθήκοντα μετά την υλοποίηση
Μετά την υλοποίηση του έργου καλό είναι να γίνεται μια ανάλυση
με τα παρακάτω στοιχεία:
-  Παρατηρήσεις σχετικά με την αποτελεσματικότητα των μεθόδων που χρησιμοποιήθηκαν
-  Προβλήματα που παρουσιάστηκαν και πως θα μπορούσαν να αποφευχθούν
-  Προτάσεις για βελτίωση της διεργασίας ανάπτυξης
-  Λογισμικό που αναπτύχθηκε και μπορεί να επαναχρησιμοποιηθεί
Βιβλιογραφία
- Εμμανουήλ Σκορδαλάκης.
Εισαγωγή στην Τεχνολογία Λογισμικού, σελίδες 159-179.
Εκδόσεις Συμμετρία, 1991.
 
- Barry Boehm.
Software risk management: Principles and practices.
IEEE Software, 9(1):32–39, January/February 1991.
- Watts S. Humphrey.
Managing the Software Process, pages 69–82.
Addison-Wesley, 1989.
- Institute of Electrical and
  Electronics Engineers, Inc., New York, NY, USA.
Software Productivity Metrics, 1992.
IEEE Standard 1045-1992.
- Institute of Electrical and
  Electronics Engineers, Inc., New York, NY, USA.
Adoption of PMI Standard- A Guide to the Project Management Body of
  Knowledge, 1998.
IEEE Standard 1490-1998.
- Institute of Electrical and
  Electronics Engineers, Inc., New York, NY, USA.
Software Life Cycle Processes-Risk Management, 2001.
IEEE Standard 1540-2001.
- Roger S. Pressman.
Software Engineering: A Practitioner's Approach, pages 118–132.
McGraw-Hill, 1987.
- Roger S. Pressman.
Software Engineering: A Practitioner's Approach, pages 54–190.
McGraw-Hill, fifth edition, 2000.
European Adaptation. Adapted by Darrel Ince.
- Ian Sommerville.
Software Engineering, pages 71–92.
Addison-Wesley, sixth edition, 2001.
- Ed Sullivan.
Under
  Pressure and On Time, pages 42–60.
Microsoft Press, Redmond, Washington, USA, 2001.
Ασκήσεις
-  Δημιουργήστε ένα σχέδιο διαχείρισης κινδύνων για το έργο που έχει
αναλάβει η ομάδα σας.