Theory vs Reality Ανδρέας Σκάλκος ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΙΓΑΙΟΥ

Παρουσίαση με θέμα: "Theory vs Reality Ανδρέας Σκάλκος ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΙΓΑΙΟΥ"— Μεταγράφημα παρουσίασης:

1 Theory vs Reality Ανδρέας Σκάλκος 10-11-2008 ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΙΓΑΙΟΥ
ΤΜΗΜΑ ΜΗΧΑΝΙΚΩΝ ΠΛΗΡΟΦΟΡΙΑΚΩΝ ΚΑΙ ΕΠΙΚΟΙΝΩΝΙΑΚΩΝ ΣΥΣΤΗΜΑΤΩΝ ΤΕΧΝΟΛΟΓΙΑ ΛΟΓΙΣΜΙΚΟΥ ΑΚΑΔΗΜΑΪΚΟ ΕΤΟΣ: Theory vs Reality Ανδρέας Σκάλκος

2 Πραγματικός κόσμος (1/2)
Στον πραγματικό κόσμο, η ανάπτυξη λογισμικού είναι χαοτική και πιο δύσκολη, από ότι στην θεωρία. Αλλαγές χρειάζονται συνέχεια ένα προϊόν λογισμικού (software product) είναι ένα μοντέλο του πραγματικού κόσμου, ο οποίος όμως συνέχεια αλλάζει, ακόμα και κατα την διάρκεια που το λογισμικό αναπτύσσεται. Οι επαγγελματίες κατασκευαστές λογισμικού (software developers) είναι άνθρωποι, άρα είναι αυτονόητο ότι κάνουν λάθη.

3 Πραγματικός κόσμος (2/2)
Κατά την διάρκεια της κατασκευής του λογισμικού γενικώς αλλά και των portals ειδικότερα, οι απαιτήσεις (requirements) του πελάτη αλλάζουν. Παράδειγμα: Κατά την διάρκεια ανάπτυξης ενός portal είναι πιθανό να αλλάξουν μέλη του οργανισμού ή ο οργανισμός να επεκταθεί και σε άλλες δραστηριότητες ή σε άλλες γεωγραφικές περιοχές. Αυτές οι αλλαγές μπορεί να είναι Πολύ καλές, θετικές, για τον οργανισμό αλλά Καταστροφικές για τη διαδικασία ανάπτυξης του ζητούμενου προϊόντος λογισμικού

4 Ομάδα έργου-Συμφωνική ορχήστρα ή one man show?
Σε μεγάλα έργα η ομάδα έργου λειτουργεί όπως μια συμφωνική ορχήστρα ή ένα μουσικό συγκρότημα. Κάθε ένα από τα μέλη της πρέπει να γνωρίζει πολύ καλά το αντικείμενο με το οποίο ασχολείται (ανάλυση, σχεδιασμός, συγγραφή κώδικα, γραφικά, testing κ.α). Ο διευθυντής της ορχήστρας (leader, surgeon, project manager) οφείλει να γνωρίζει όλα τα αντικείμενα (όχι απαραίτητα σε βάθος) πρέπει όμως να είναι πολύ καλός τουλάχιστον σε ένα. Σε μικρές εταιρίες η συμφωνική ορχήστρα πρέπει να συρρικνωθεί σε ελάχιστα άτομα (μερικές φορές ακόμα και σε ένα).

5 Βασικές διαδικασίες ανάπτυξης λογισμικού
Συγγραφή αρχικής πρότασης Προγραμματισμός (planning) έργου Καθορίζονται οι βασικές προδιαγραφές του λογισμικού, γίνεται η κοστολόγηση του έργου, η τιμολόγηση του έργου, η εκτίμηση μεγεθών, η μελέτη του εφικτού, η ανάλυση ρίσκου. Ανάθεση έργου σε ανθρώπινο δυναμικό Επίβλεψη έργου (project monitoring) Τεκμηρίωση (documentation) και Εκπροσώπηση.

6 Συγκεκριμένα προβλήματα (1/6)
Πόσο κοστίζει; Είναι πάντα η πρώτη ερώτηση που δέχεστε από τον πελάτη. Απάντηση όπως πλέον γνωρίζετε από την θεωρία δεν μπορεί να υπάρξει στην πρώτη συνάντηση και χωρίς να έχουν αναλυθεί οι απαιτήσεις του πελάτη.

7 «...το θέλω χθές» (2/6) Στις μικρές εταιρείες, με λίγο προσωπικό, οι ρόλοι του κάθε εμπλεκόμενου δεν είναι πάντα διακριτοί. Δεν ακολοθούνται κατά την ανάπτυξη του λογισμικού τα θεωρητικά μοντέλα όπως διδάσκονται Συνήθως ο χρόνος πιέζει. «...το θέλω χθές». Δεν μπορούν να καλυφθούν οικονομικά προσλήψεις (ή συνεργασίες). Ανεπαρκείς διαθέσιμοι πόροι.

8 Συγκεκριμένα προβλήματα (3/6)
Οι πελάτες «θέλουν κάτι» αλλά δεν ξέρουν ακριβώς τι είναι αυτό; Συχνά σας δηλώνουν «θέλω να αναπτύξω ένα site/ portal για την επιχείρηση μου». Όμως στην ουσία δεν γνωρίζουν ούτε τα πιθανά οφέλη από μια τέτοια επένδυση, ούτε τις δυνατότητες της τεχνολογίας, ούτε ποιες λειτουργίες τις επιχειρησής τους πιθανά θα επιβαρυνθούν από την ανάπτυξη μιας τέτοιας εφαρμογής (π.χ λογιστήριο, τραπεζικές συναλλαγές) Παράδειγμα 1: Νέος πελάτης σας, ζητάει να του αναπτύξετε ηλεκτρονικό κατάστημα για την πώληση αθλητικών ειδών (π.χ προιόντα Adidas). Ήδη η Adidas έχει ηλεκτρονικό κατάστημα ενώ υπάρχουν και άλλα δεκάδες ίδια καταστήματα στο διαδίκτυο. Επιπλέον θα πρέπει να επιβαρυνθεί η λειτουργία του λογιστηρίου με την παρακολούθηση συνεχών κινήσεων μέσω τραπεζών. Τον παρακινείτε ή τον αποτρέπετε; Παράδειγμα 2: Οργανισμός σας ζητάει να αναπτυχθεί σύστημα μέσω του οποίου να γίνεται online πληρωμή λογαριασμών από τους πολίτες (ύδρευση, πρόστιμα κ.α).

9 Συγκεκριμένα προβλήματα (4/6)
«Άλλα σου είχα πει...» Στην πορεία ο πελάτης αλλάζει συνεχώς γνώμη ή ζητά περισσότερα από αυτά που έχουν συμφωνήσει, αμφισβητώντας ακόμα και τα έγγραφα προδιαγραφής απαιτήσεων.

10 Συγκεκριμένα προβλήματα (5/6)
Δεν παρέχουν τα δεδομένα, και συνήθως ζητούν να τους εξυπηρετήσετε εσείς. είναι αδύνατο για κάποιον που αναπτύσσει portals και έχει ποικιλία πελατών να γνωρίζει λεπτομέρειες για την όποια επιχείρηση. πως μπορεί να ξέρει κάποιος πως λειτουργεί ένα ξενοδοχείο, ή ακόμη χειρότερα πως μπορεί να ξέρει κάποιος πως λειτουργεί το συγκεκριμένο ξενοδοχείο; Δεν αναλαμβάνουν το επιπλέον κόστος πέραν αυτού που έχει να κάνει με την ανάπτυξη του λογισμικού.

11 Συγκεκριμένα προβλήματα (6/6)
Η δημιουργία μια νέας front-end επιχειρησιακής διαδικασίας (δημιουργία portal, ηλεκτρονικούς καταλόγους κτλ.) σχετίζεται άμεσα με back-end δραστηριότητες (επεξεργασία πληρωμής, άθροιση και εκτέλεση παραγγελιών κτλ) τις οποίες και μεταβάλλει. Διαλειτουργικότητα (οργανωσιακή, σημασιολογική, τεχνική).

12 Βασικά χαρακτηριστικά
Ο χρόνος (Time): Για να μπορέσει ο υπεύθυνος διαχείρισης του έργου λογισμικού (Software Project Manager) να το παραδώσει εγκαίρως θα πρέπει να κάνει σωστό αρχικό προγραμματισμό του έργου (Project Planning) και να επιβλέπει συνεχώς όλες τις διαδικασίες του έργου (Project Monitoring) συγκρίνοντας τον αρχικό προγραμματισμό του έργου με τον πραγματοποιηθέντα. Το κόστος (Cost): Θα πρέπει να γίνει από τον υπεύθυνο του έργου όσο το δυνατόν πιο ακριβής εκτίμηση του κόστους χρησιμοποιώντας διάφορες τεχνικές εκτίμησης ή και εμπειρικά μοντέλα, φροντίζοντας να γίνει η κατανομή των απαραίτητων πόρων που αφορούν τον τεχνικό εξοπλισμό, το προσωπικό, την εκπαίδευση, τα εργαλεία ανάπτυξης του λογισμικού κ.τ.λ. Η ποιότητα (Quality): Απαιτεί από τον υπεύθυνο του έργου να παρέχει τους μηχανισμούς για την έγκαιρη αναφορά και επίλυση των προβλημάτων που δημιουργούνται κατά την διάρκεια του έργου καθώς και συνεχή επίβλεψη ότι το λογισμικό που αναπτύσσεται είναι σύμφωνο με τις προδιαγραφές που έχουν συμφωνηθεί με τον πελάτη και ότι καλύπτει και τις αντίστοιχες ανάγκες του πελάτη.

13 Τελικά Το θεωρητικό υπόβαθρο είναι απαραίτητο.
Η εμπειρία είναι το ουσιώδες κλειδί για την σωστή εκτίμηση των καταστάσεων που θα αντιμετωπίσει ο διαχειριστής του έργου λογισμικού και για την σχετικά ακριβή πρόβλεψη των επιπτώσεων των αποφάσεων, που θα χρειαστεί να πάρει κατά την διάρκεια του έργου.

14 Με εικόνες

15 Σας ευχαριστώ! «Εισαγωγή στη Τεχνολογία Λογισμικού» Εμμ. Σκορδαλάκης
«Διαχείρηση και Ποιότητα Λογισμικού» Μιχάλης Ξένος «Εγκυροποίηση Λογισμικού» Αχιλλέας Καμέας «Ανάπτυξη εκπαιδευτικού λογισμικού για τη Διαχείρηση Έργων Λογισμικού», Χρήστος Φιλιππόπουλος «The mythical man-month» Frederick P. Brooks, Jr