Διοίκηση έργου
Διομήδης Σπινέλλης
Τμήμα Διοικητικής Επιστήμης και Τεχνολογίας
Οικονομικό Πανεπιστήμιο Αθηνών
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.
Ασκήσεις
- Δημιουργήστε ένα σχέδιο διαχείρισης κινδύνων για το έργο που έχει
αναλάβει η ομάδα σας.