Πρακτικά 17ου Συνεδρίου Ε.Ε.Ε.Ε. «ιαχείριση Κινδύνων» Πανεπιστήµιο Πατρών, 16-18 Ιουνίου 2005, Σελ. 391-402 Αντικειµενοστραφής µοντελοποίηση των διαδικασιών της ανάπτυξης λογισµικού Βασίλης Χ. Γερογιάννης Τµήµα ιοίκησης και ιαχείρισης Έργων, Σχολή ιοίκησης και Οικονοµίας, Ανώτατο Τεχνολογικό Εκπαιδευτικό Ίδρυµα Λάρισας, 41110, Λάρισα, E-mail: gerogian@teilar.gr Περίληψη Το άρθρο προτείνει την εφαρµογή της αντικειµενοστραφούς προσέγγισης (object-oriented approach) για την περιγραφή των διαδικασιών που πραγµατοποιούνται κατά την ανάπτυξη ενός συστήµατος λογισµικού. Παρουσιάζονται οι ερευνητικές κατευθύνσεις του έργου MISSION-SPM, το οποίο λαµβάνει χώρα στο πλαίσιο του προγράµµατος ΑΡΧΙΜΗ ΗΣ ΙΙ. Η βασική ιδέα του έργου MISSION-SPM είναι ότι τόσο τα στατικά χαρακτηριστικά, όσο και η δυναµική συµπεριφορά των διαδικασιών της ανάπτυξης λογισµικού δύνανται να αναπαρασταθούν συστηµατικά χρησιµοποιώντας τα διαγράµµατα που παρέχει µια αντικειµενοστραφής γλώσσα προδιαγραφών, όπως είναι η Ενοποιηµένη Γλώσσα Μοντελοποίησης (Unified Modeling Language). Η χρήση αντικειµενοστραφών µοντέλων παρέχει αρκετά πλεονεκτήµατα, όπως αφαιρετική αναπαράσταση, αυξηµένη δυνατότητα κατανόησης και συστηµατική διαχείριση των σύνθετων δοµών ενός έργου ανάπτυξης λογισµικού. Λέξεις Κλειδιά: ιαχείριση Έργων Λογισµικού, ιαδικασίες Ανάπτυξης Λογισµικού, Αντικειµενοστραφής Μοντελοποίηση.
392 Β. Γερογιάννης 1. Εισαγωγή Σύγχρονες έρευνες δείχνουν ότι µόνο στις Η.Π.Α. διατίθενται κάθε χρόνο περίπου 275 δισεκατοµµύρια δολάρια σε έργα λογισµικού (Wallace & Keil, 2004). Ένα σηµαντικό µέρος (πάνω από 75%) από αυτά τα έργα παρουσιάζουν προβλήµατα: πολλά έργα καταλήγουν σε πλήρη αποτυχία, άλλα ξεπερνούν τις αρχικές εκτιµήσεις κόστους, άλλα παρουσιάζουν καθυστερήσεις, ενώ άλλα παρέχουν διαφορετικά παραδοτέα και υπηρεσίες από αυτές που προτάθηκαν αρχικά. Οι θεωρητικές και µόνο γνώσεις των τεχνικών της διαχείρισης έργων - π.χ. η γνώση του Project Management Body of Knowledge (PMBOK, 2000) - δεν είναι εποµένως αρκετές για την πετυχηµένη οργάνωση ενός έργου. Η διαχείριση έργων και, ειδικότερα, η διαχείριση έργων ανάπτυξης λογισµικού συνιστούν το ερευνητικό υπόβαθρο του παρόντος άρθρου. Ο κύριος στόχος της διαχείρισης σε ένα έργο λογισµικού είναι να εξασφαλιστεί ότι το τελικό πληροφοριακό σύστηµα θα παραδοθεί εγκαίρως, θα ικανοποιεί τις ανάγκες των τελικών χρηστών, θα λαµβάνει υπόψη τις απαιτήσεις ποιότητας και απόδοσης και, ταυτόχρονα, θα διατηρεί το κόστος ανάπτυξης στα προβλεπόµενα όρια (Basili & Musa, 1991; Murch, 2001). Μια διαδικασία ανάπτυξης λογισµικού παρέχει µία συστηµατική προσέγγιση για την ανάλυση, σχεδιασµό, κατασκευή και εξέλιξη ενός έργου πληροφορικής (Royce, 1998). Μια διαδικασία διαιρείται σε συγκεκριµένες φάσεις (π.χ. καθορισµός απαιτήσεων, προσδιορισµός προδιαγραφών, σχεδιασµός, υλοποίηση, έλεγχος). Κάθε φάση της ανάπτυξης (development phase) περιλαµβάνει δραστηριότητες που υλοποιούνται από το προσωπικό της οµάδας του έργου (π.χ. µηχανικοί λογισµικού, σχεδιαστές, προγραµµατιστές, µέλη της οµάδας ελέγχου κλπ.). Η φάση του ελέγχου (testing), για παράδειγµα, περιλαµβάνει δραστηριότητες όπως τον µοναδιαίο έλεγχο (unit testing), τον έλεγχο των προγραµµατιστικών ενοτήτων (module testing), τον καθορισµό και την τροποποίηση των προδιαγραφών του ελέγχου (testing specifications), την αλλαγή του αρχικού σχεδιασµού και του κώδικα (design / code modification) κλπ. Κάθε δραστηριότητα έχει ένα σύνολο εισόδων και παρέχει αντίστοιχα εξαγόµενα (παραδοτέα), π.χ. το σύνολο των προδιαγραφών του ελέγχου, τον ίδιο τον κώδικα (µε λιγότερα ή καθόλου σφάλµατα), µια αναφορά σφαλµάτων, ένα χρονοδιάγραµµα για τη φάση του ελέγχου (testing plan) κλπ.
17ο Συνέδριο της Ε.Ε.Ε.Ε. «ιαχείριση Κινδύνων» 393 Στο άρθρο παρουσιάζεται µια προσέγγιση που έχει ως σκοπό να διαχειριστεί, όσο το δυνατόν πιο ικανοποιητικά, την πολυπλοκότητα και την ποικιλία των απαιτήσεων που χαρακτηρίζουν τις διαδικασίες ανάπτυξης λογισµικού. Η προσέγγιση υλοποιείται στο έργο MISSION-SPM (Model based Ιntegrated Environment to Support Simulation in Software Project Management) στο πλαίσιο του ερευνητικού προγράµµατος ΑΡΧΙΜΗ ΗΣ ΙΙ. Στο έργο προτείνεται η αξιοποίηση µοντέλων για την αναπαράσταση και την ανάλυση των διαδικασιών της ανάπτυξης λογισµικού (model-based software development). Βασικός στόχος του έργου είναι µια ενιαία αρχιτεκτονική αναφοράς (unified reference architecture) που θα ενσωµατώνει µοντέλα προσανατολισµένα προς τη διαχείριση σύνθετων έργων. Η αρχιτεκτονική θα υποστηρίζει τη γραφική αναπαράσταση (άρα και την αυξηµένη δυνατότητα κατανόησης), καθώς και την ανάλυση των διαδικασιών ανάπτυξης λογισµικού. Η µοντελοποίηση είναι σηµαντική (Jacobson, 1992) διότι παρέχει τη δυνατότητα επικέντρωσης στις σηµαντικές λεπτοµέρειες που είναι απαραίτητο να κατανοηθούν πριν την υλοποίηση ενός συστήµατος ή µιας διαδικασίας. Παρέχει τη δυνατότητα πειραµατισµού µε διαφορετικές προσεγγίσεις για το ίδιο πρόβληµα, δίνει τη δυνατότητα σχεδιασµού και παρακολούθησης της προόδου ενός έργου. ίνει επίσης τη δυνατότητα µιας κοινής γλώσσας για την επικοινωνία όσων εµπλέκονται στη διαδικασία ανάπτυξης. 2. Ερευνητικό υπόβαθρο Οι δραστηριότητες της διαχείρισης ενός έργου λογισµικού αφορούν κυρίως τρεις διαστάσεις (Royce, 1998): (i) τη διαχείριση των διαδικασιών (process management), (ii) τη διαχείριση των πόρων (resource management), και (iii) τη διαχείριση των προϊόντων του έργου (product/configuration management). Προκειµένου να καλυφθούν οι απαιτήσεις αυτών των τύπων διαχείρισης, οι σύγχρονες ερευνητικές προσπάθειες ταξινοµούνται σε τρεις περιοχές που παρουσιάζονται στις επόµενες τρεις υποενότητες. 2.1 Υιοθέτηση µοντέλων από το χώρο των τυπικών προδιαγραφών Τα κλασικά δικτυακά µοντέλα για τον προγραµµατισµό των διαδικασιών ενός έργου δεν είναι πάντοτε επαρκή για να περιγράψουν σύνθετα έργα λογισµικού. Για παράδειγµα, οι τεχνικές PERT, CPM και δένδρα αποφάσεων (Mehrez et al., 1995) παρουσιάζουν εγγενείς αδυναµίες στο να περιγράψουν χαρακτηριστικά όπως είναι η ταυτόχρονη και η επαναλαµβανόµενη εκτέλεση δραστηριοτήτων, οι σύνθετες εξαρτήσεις προήγησης µεταξύ των δραστηριοτήτων, οι απαιτήσεις σε
394 Β. Γερογιάννης πόρους, οι δυναµικές αλλαγές σε αναθέσεις πόρων και προσωπικού, οι σύνθετες χρονικές απαιτήσεις και οι χρονικές παράµετροι των δραστηριοτήτων. Για τη λύση των προβληµάτων προτείνονται εκδόσεις τυπικών µοντέλων προδιαγραφών (formal specification models) που προσανατολίζονται στην αναπαράσταση των παραµέτρων της διαχείρισης έργων. Συνεισφορά στο πεδίο αυτό έχουν µοντέλα µε χαρακτηριστικά γραφηµάτων, όπως είναι τα ίκτυα Petri (Petri Nets) (Liu & Horowitz, 1989; Chang & Christensen, 1999; Min et al., 2000). Η χρήση ισχυρών σε εκφραστική και αναλυτική ικανότητα τυπικών µοντέλων βρίσκει εφαρµογή, όχι µόνο κατά την αναπαράσταση και την επαλήθευση των ιδιοτήτων των διαδικασιών, αλλά και στη λήψη αποφάσεων, π.χ. για τη βέλτιστη ανάθεση δραστηριοτήτων σε πόρους (Min et al., 2000). Αυτό συµβαίνει εάν τα µοντέλα συνδυαστούν µε τεχνικές ανάλυσης, π.χ. η ανάλυση προσιτότητας (reachability analysis) στα ίκτυα Petri (Gerogiannis et al., 1998), αλλά και µε µεταευρετικές τεχνικές, όπως είναι οι γενετικοί αλγόριθµοι (Chang & Christensen, 1999). 2.2 Εφαρµογή βασικών αρχών της τεχνολογίας λογισµικού Η πιο διαδεδοµένη γλώσσα περιγραφής συστηµάτων λογισµικού αλλά και επιχειρηµατικών διαδικασιών είναι η Ενοποιηµένη Γλώσσα Μοντελοποίησης (Unified Modeling Language - UML) (OMG, 2003). H UML αποτελεί µια πρότυπη γλώσσα που ακολουθεί τις αρχές της αντικειµενοστραφούς ανάλυσης και σχεδιασµού (Jacobson, 1992). Η αντικειµενοστραφής προσέγγιση βασίζεται στην ιδέα των κλάσεων αντικειµένων, οντοτήτων δηλαδή του πραγµατικού κόσµου που ενσωµατώνουν τόσο δεδοµένα όσο και µεθόδους που επενεργούν στα δεδοµένα. Σήµερα τα συστήµατα και οι διαδικασίες που σχεδιάζονται ή υλοποιούνται είναι σχεδόν στο σύνολό τους αντικειµενοστραφή. Αυτό οφείλεται στα πλεονεκτήµατα που παρέχει η αντικειµενοστραφής προσέγγιση: αφαιρετική αναπαράσταση, κατανόηση σύνθετων συστηµάτων, επαναχρησιµοποίηση, εύκολη προσαρµογή των συστηµάτων και των διαδικασιών. Οι αρχές της αντικειµενοστραφούς προσέγγισης βρίσκουν εφαρµογή στα διαγράµµατα της UML (OMG, 2003). Τα διαγράµµατα περιπτώσεων χρήσης (use-case diagrams) µπορούν να περιγράψουν τη λειτουργικότητα, ενώ τα διαγράµµατα κλάσεων (class diagrams) µπορούν να περιγράψουν τη δοµή µιας διαδικασίας. Ένα διάγραµµα καταστάσεων (state diagram) µπορεί να αναπαραστήσει τη συµπεριφορά και τις καταστάσεις στις οποίες µπορεί να βρεθεί µια δραστηριότητα σε µια φάση της διαδικασίας (ανενεργή, υπό έναρξη, υπό διακοπή, σε αναµονή, υπό εκτέλεση, περατωµένη κλπ.). Τα διαγράµµατα ακολουθίας (sequential diagrams), δραστηριοτήτων (activity diagrams) και συνεργασίας (collaboration diagrams) περιγράφουν (το καθένα από µια
17ο Συνέδριο της Ε.Ε.Ε.Ε. «ιαχείριση Κινδύνων» 395 διαφορετική οπτική) την αλληλεπίδραση µεταξύ των αντικειµένων και των δρώντων στοιχείων (actors) που εµπλέκονται σε µια διαδικασία. Τα µοντέλα της UML συνεπώς χρησιµοποιούνται για να αναπαραστήσουν, εκτός από συστήµατα, και τις ίδιες τις διαδικασίες που οδηγούν στην ανάπτυξη των συστηµάτων. Για παράδειγµα, µπορούν να περιγράψουν την επαναληπτική εκτέλεση των δραστηριοτήτων σε ένα έργο λογισµικού, σύµφωνα µε τις αρχές της διαδικασίας ανάπτυξης λογισµικού που είναι γνωστή ως Ενοποιηµένη Προσέγγιση (Unified Process - UP) (Jacobson et al., 1999; Krutchen, 2000; OMG, 2003). Η UP είναι µια επαναληπτική διαδικασία ανάπτυξης. Λαµβάνοντας υπόψη την πολυπλοκότητα που απαιτείται για την ανάπτυξη ενός συστήµατος σήµερα, µια ακολουθιακή προσέγγιση είναι, πολλές φορές, µη ρεαλιστική. Μια επαναληπτική προσέγγιση επιτυγχάνει την αυξανόµενη κατανόηση του προβλήµατος µέσω της συνεχούς εκλέπτυνσης της λύσης. Μια επαναληπτική προσέγγιση προσφέρει την ευελιξία που απαιτείται στην ανάπτυξη των σύγχρονων συστηµάτων λόγω των τακτικών αλλαγών στις απαιτήσεις και στους επιχειρησιακούς στόχους. Σύµφωνα µε τη UP, ο κύκλος ζωής ανάπτυξης λογισµικού έχει τέσσερις φάσεις: τη σύλληψη, όπου παρουσιάζεται η αρχική ιδέα του συστήµατος, την επεξεργασία, όπου περιγράφεται η υψηλού επιπέδου αρχιτεκτονική, την κατασκευή, όπου σχεδιάζεται και κατασκευάζεται το λογισµικό, και τη µετάβαση (transition), όπου το λογισµικό υπόκειται σε έλεγχο και τελικά παραδίδεται στους χρήστες. Σε κάθε φάση εκτελείται ένας αριθµός επαναλήψεων και σε κάθε επανάληψη εκτελείται ένας αριθµός διαδικασιών, όπου κάθε διαδικασία περιγράφεται µε ένα αριθµό ροών εργασιών (workflows).
396 Β. Γερογιάννης Σχήµα 1: ιάγραµµα ραστηριοτήτων της ιαχείρισης Έργων στην Ενοποιηµένη Προσέγγιση (Πηγή: Krutchen, 2000) Στο Σχήµα 1 παρουσιάζεται µε διάγραµµα δραστηριοτήτων η ροή εργασιών, σύµφωνα µε τη UP, κατά τη διαχείριση ενός έργου (Jacobson et al., 1999). Η ροή εργασιών περιλαµβάνει τον προγραµµατισµό του έργου και των επαναλήψεων, τη διαχείριση κινδύνου και την παρακολούθηση του έργου. Ο προγραµµατισµός του έργου έχει στόχο την ανάπτυξη του πλάνου διαχείρισης: ένα παραδοτέο που χρησιµοποιείται για να καθοδηγήσει την εκτέλεση του έργου, τεκµηριώνει τις αποφάσεις που έχουν ληφθεί αναφορικά µε τις εναλλακτικές λύσεις, καθορίζει τις δραστηριότητες και τα πρότυπα που θα εφαρµοστούν καθώς και τον τρόπο µε τον οποίο θα γίνεται η επικοινωνία µέσα στο έργο. Εκτός από τη UP υπάρχουν πολλές διαδικασίες ανάπτυξης λογισµικού, όπως η extreme Programming (Beck & Andres, 2004) και η Catalysis (Desmond & Cameron, 1999). Καθεµιά θεωρείται ως πιο κατάλληλη για κάποιο συγκεκριµένο τύπο λογισµικού, π.χ. η Catalysis θεωρείται κατάλληλη για συστήµατα βασισµένα σε συστατικά (component based systems) (Szyperski, 1988). Η UML είναι ουδέτερη από διαδικασίες. εν επιβάλλει κάποια διαδικασία και µπορεί να χρησιµοποιηθεί σε συνδυασµό µε διάφορες διαδικασίες. Η διαγραµµατική σχεδίαση υποστηρίζεται από εργαλεία, τα λεγόµενα UML tools (π.χ. Rational Rose, Argo UML, Poseidon for UML). Για το διάγραµµα στο Σχήµα 1 χρησιµοποιήθηκε το εργαλείο Rational Rose.
17ο Συνέδριο της Ε.Ε.Ε.Ε. «ιαχείριση Κινδύνων» 397 Προς την κατεύθυνση της χρήσης µοντέλων για την περιγραφή διαδικασιών και συστηµάτων, προσανατολίζονται διεθνείς πρωτοβουλίες µε σηµαντικότερη τη Model Driven Architecture (MDA) (Kleppe et al., 2003) της Object Management Group (OMG), µιας διεθνούς ένωσης που έχει καθορίσει τη σύνταξη της UML και έχει ως γενικό σκοπό τον καθορισµό προτύπων για την περιγραφή συστηµάτων. Aποτέλεσµα της πρωτοβουλίας MDA είναι η υιοθέτηση profiles για την τυποποίηση κάθε διαδικασίας λογισµικού. Παράδειγµα αποτελεί το Software Process Engineering Metamodel - SPEM (OMG, 2005), ένα πρότυπο που περιγράφει συστηµατικά κάθε διαδικασία ανάπτυξης. Το SPEM χρησιµοποιείται για να περιγραφούν οι ροές εργασίας σε οποιαδήποτε φάση της ανάπτυξης, να προσδιοριστούν τα παραγόµενα προϊόντα και να καθοριστούν οι ρόλοι του ανθρώπινου δυναµικού που συµµετέχει σε ένα έργο λογισµικού. Το SPEM παρέχει κοινή γλώσσα και γενικούς κανόνες για την περιγραφή κάθε διαδικασίας ανάπτυξης (UP, extreme Programming, Catalysis κλπ.) αλλά και κάθε διαδικασίας που µπορεί να εφαρµόζεται in-house στο εργασιακό περιβάλλον µιας εταιρείας ανάπτυξης λογισµικού. Η συγκεκριµενοποίηση των UML διαγραµµάτων, που προέκυψαν µε βάση το SPEM, µοντελοποιεί την υλοποίηση της διαδικασίας σε ένα συγκεκριµένο έργο ανάπτυξης λογισµικού. 2.3 Αξιοποίηση µοντέλων προσοµοίωσης Η εφαρµογή µεθόδων προσοµοίωσης σε διαδικασίες ανάπτυξης λογισµικού αποτελεί έναν τρίτο κλάδο της έρευνας. Η προσοµοίωση δίνει τη δυνατότητα να αναλυθούν ποιοτικά και κυρίως ποσοτικά κρίσιµα εναλλακτικά σενάρια εκτέλεσης ενός έργου, εξετάζοντας µια σειρά από υποθέσεις ( what-if ερωτήσεις). Το αποτέλεσµα είναι ένα µοντέλο προσοµοίωσης για τα προϊόντα και για την ίδια τη διαδικασία εκτέλεσης του έργου. Σε µοντέλα προσοµοίωσης διακριτού ή συνεχούς χρόνου καταλήγουν και τα ίκτυα Petri (Gerogiannis et al., 1998). Πεδία εφαρµογής της προσοµοίωσης αποτελούν: Η στρατηγική διαχείριση. Η προσοµοίωση βοηθά να απαντηθούν ερωτήµατα, όπως αν πρέπει οι δραστηριότητες να είναι κατανεµηµένες γεωγραφικά ή όχι, ποιες είναι οι επιπτώσεις της ανάθεσης προσωπικού, σε ποιο βαθµό πρέπει να (επανα-)χρησιµοποιούνται διαθέσιµα συστατικά λογισµικού (Bertolino & Mirandola, 2004). Ο προγραµµατισµός των δραστηριοτήτων του έργου (planning). Ένα µοντέλο προσοµοίωσης µπορεί να εξεταστεί για να ληφθούν συµπεράσµατα για την υλοποίηση ενός έργου, όπως είναι η χρονική διάρκεια της εκτέλεσης και το κόστος της διαχείρισης των εµπλεκόµενων ανθρώπινων πόρων. Ένα µοντέλο µπορεί να παρέχει εκτίµηση προσπάθειας, κόστους, χρόνου
398 Β. Γερογιάννης περάτωσης ενός έργου, πρόβλεψη για το πλήθος του προσωπικού κάθε ειδικότητας που απαιτείται, ανάλυση των περιορισµών ανάθεσης πόρων, των κινδύνων και των παραγόντων αποτυχίας (Min et al., 2000). Η εκπαίδευση των διαχειριστών έργων. Η διαχείριση έργων λογισµικού είναι σύνθετη αλλά ταυτόχρονα ιδιαίτερα πρακτική διαδικασία. Η προσοµοίωση επιτρέπει στους διαχειριστές έργων να πειραµατίζονται µε εναλλακτικά σενάρια και επιλογές (Drappa & Ludewig, 2000). 3. Αρχιτεκτονική αναφοράς και βασικά υποσυστήµατα Η αρχιτεκτονική του MISSION-SPM ενσωµατώνει, καταρχάς, στο επίπεδο της αναπαράστασης µοντέλα της UML σε συνδυασµό µε τυποποιηµένα profiles περιγραφής διαδικασιών ανάπτυξης που επεκτείνουν τη UML, ώστε να υποστηρίζει την ανάλυση και σχεδιασµό έργων λογισµικού και την προδιαγραφή των εµπλεκόµενων πόρων. Στο πλαίσιο αυτό ακολουθούνται οι αρχές που ορίζονται από το πρότυπο SPEM (OMG, 2005). Κατά δεύτερο λόγο, στο επίπεδο της ανάλυσης (χρονικός προγραµµατισµός έργου, ανάλυση κόστους-προσπάθειας-απόδοσης, βαθµός χρησιµοποίησης πόρων), η αρχιτεκτονική ενσωµατώνει τυπικά µοντέλα προδιαγραφών, όπως είναι τα ίκτυα Petri. Στην αρχιτεκτονική περιλαµβάνονται δύο βασικά υποσυστήµατα. Το πρώτο είναι το υποσύστηµα του σχεδιασµού, όπου ο χρήστης-διαχειριστής έργων σχεδιάζει σε UML τις διαδικασίες, τους πόρους και τα προϊόντα για ένα έργο λογισµικού. Στο υποσύστηµα αυτό περιλαµβάνονται συστατικά που υποστηρίζουν: i) τον σχεδιασµό του πλάνου εκτέλεσης (planning component), ii) την προδιαγραφή κάθε φάσης µε βάση τον κύκλο ζωής και των αλληλεξαρτήσεων των φάσεων µεταξύ τους (project component), iii) την αναπαράσταση των διαθέσιµων πόρων (resource component), και iv) τον καθορισµό των προϊόντων-αποτελεσµάτων (configuration component). Το δεύτερο βασικό υποσύστηµα είναι το υποσύστηµα της ανάλυσης (analysis subsystem), όπου τα µοντέλα του σχεδιασµού µετατρέπονται σε ισοδύναµα τυπικά µοντέλα µε σκοπό την επαλήθευση (verification) των ιδιοτήτων του σχεδιασµού. Τέλος, σε ένα τρίτο υποσύστηµα, στο υποσύστηµα της προσοµοίωσης (simulation-runtime subsystem) ενσωµατώνονται συστατικά που υποστηρίζουν τον καθορισµό διαφορετικών σεναρίων για την εκτέλεση (scenario modeling component) και την προσοµοίωση (simulation component). 4. Παράδειγµα
17ο Συνέδριο της Ε.Ε.Ε.Ε. «ιαχείριση Κινδύνων» 399 Στη συνέχεια περιγράφουµε ένα παράδειγµα που παρουσιάζει την προσέγγιση που ακολουθούµε, κάνοντας χρήση των όρων της UML και της ορολογίας του προτύπου SPEM, αναφορικά µε την περιγραφή της δοµής ενός έργου (γενικά) και ενός έργου λογισµικού (ειδικότερα). Θα προκύψει ένα διάγραµµα κλάσεων όπου θα παρουσιαστούν τα ονόµατα των σχετικών κλάσεων οντοτήτων, ο τύπος και τα ονόµατα των εµπλεκόµενων σχέσεων. Έστω η ακόλουθη γενική περιγραφή της δοµής και των χαρακτηριστικών ενός έργου: «Ο κύκλος ζωής ενός έργου περιλαµβάνει µία ή περισσότερες επιµέρους φάσεις. Σε κάθε φάση εκτελείται τουλάχιστον µία διαδικασία. Κάθε διαδικασία µε τη σειρά της µπορεί να αναλύεται σε επιµέρους διαδικασίες. Εν τέλει µια διαδικασία αναλύεται σε µια ή περισσότερες δραστηριότητες. Ποιος επιτελεί τις δραστηριότητες; Οι συµµετέχοντες στο έργο. Κάθε συµµετέχων στο έργο µπορεί να εκτελεί τουλάχιστον µία δραστηριότητα. Οι δραστηριότητες παράγουν τα παραδοτέα αποτελέσµατα (προϊόντα) του έργου. Είναι δυνατόν όµως να υπάρχουν και δραστηριότητες που να µην οδηγούν σε παραδοτέα. Κάθε δραστηριότητα µπορεί να χρησιµοποιεί τους πόρους του έργου». Θα εφαρµόσουµε µια λεκτική ανάλυση της περιγραφής του προβλήµατος, κατά την οποία τα ουσιαστικά και οι ονοµαστικές φράσεις γίνονται κλάσεις οντοτήτων ή πεδία κλάσεων, ενώ τα ρήµατα και οι ρηµατικές φράσεις γίνονται µέθοδοι και σχέσεις (Jacobson, 1992). Στην προηγούµενη λοιπόν περιγραφή οι κλάσεις αντικειµένων έχουν υπογραµµιστεί. Ακολούθως παρουσιάζουµε κάθε πρόταση περιγράφοντας την επιλογή µας για τον τύπο της αντίστοιχης σχέσης: (i) «Ο κύκλος ζωής ενός έργου περιλαµβάνει µία ή περισσότερες επιµέρους φάσεις»: σχέση συναρµολόγησης (aggregation) µεταξύ της κλάσης «Κύκλος Ζωής Έργου» και της κλάσης «Φάση». Η σχέση έχει πολλαπλότητα (multiplicity) 1..* (ένα προς πολλά) (ii) «Σε κάθε φάση πραγµατοποιείται τουλάχιστον µία διαδικασία»: σχέση συναρµολόγησης µεταξύ της κλάσης «Φάση» και της κλάσης «ιαδικασία». Η σχέση έχει πολλαπλότητα 1..*. (iii) «Κάθε διαδικασία µε τη σειρά της µπορεί να αναλύεται σε επιµέρους διαδικασίες»: σχέση συναρµολόγησης από την κλάση «ιαδικασία» στον εαυτό της. Η σχέση έχει πολλαπλότητα 0..*. (iv) «Μια διαδικασία εν τέλει αναλύεται σε ένα ή περισσότερα βήµατα-δραστηριότητες»: σχέση συναρµολόγησης µεταξύ της κλάσης «ιαδικασία» και της κλάσης «ραστηριότητα». Η σχέση έχει πολλαπλότητα 1..*. (v) «Ποιος επιτελεί τις δραστηριότητες; Οι συµµετέχοντες στο έργο»: συσχέτιση (association), µε όνοµα «εκτελεί», µεταξύ της κλάσης «Συµµετέχων στο Έργο» και της κλάσης «ραστηριότητα». Η συσχέτιση από την πλευρά της κλάσης «Συµµετέχων στο Έργο» έχει πολλαπλότητα 1..*, αφού µια δραστηριότητα µπορεί να εκτελείται από πολλούς συµµετέχοντες. (vi) «Κάθε συµµετέχων στο έργο µπορεί να εκτελεί τουλάχιστον µία δραστηριότητα»: η
400 Β. Γερογιάννης συσχέτιση από την πλευρά της κλάσης «ραστηριότητα» θα έχει πολλαπλότητα 1..*, αφού ένας συµµετέχων εκτελεί µία η περισσότερες δραστηριότητες. (vii) «Οι δραστηριότητες παράγουν τα παραδοτέα αποτελέσµατα του έργου. Είναι δυνατόν όµως να υπάρχουν και δραστηριότητες που να µην οδηγούν σε παραδοτέα»: συσχέτιση (µε όνοµα «παράγει») µεταξύ της κλάσης «ραστηριότητα» και της κλάσης «Αποτέλεσµα του Έργου». Η συσχέτιση από την πλευρά της κλάσης «Αποτέλεσµα του Έργου» έχει πολλαπλότητα 0..*, αφού µια δραστηριότητα µπορεί να παράγει αποτελέσµατα αλλά µπορεί και να µην παράγει κανένα αποτέλεσµα. (viii) «Κάθε δραστηριότητα µπορεί να χρησιµοποιεί τους πόρους του έργου»: συσχέτιση (µε όνοµα «χρησιµοποιεί») µεταξύ της κλάσης «ραστηριότητα» και της κλάσης «Πόρος». Η συσχέτιση από την πλευρά της σχέσης «Πόρος» έχει πολλαπλότητα 0.. *, αφού µια δραστηριότητα µπορεί να χρησιµοποιεί πόρους (εποµένως µπορεί και να µη χρησιµοποιεί τους πόρους του έργου). To διάγραµµα κλάσεων που παρουσιάζει µε οπτικό τρόπο όλες τις επιλογές δίνεται στο Σχήµα 2. Κάθε συστατικό σχολιάζεται πάνω στο διάγραµµα µε µια αντίστοιχη πρόταση από την περιγραφή. Ο κύκλος ζωής ενός έργου περιλαµβάνει µία ή περισσότερες επιµέρους φάσεις. Σε κάθε φάση πραγµατοποιείται τουλάχιστον µία διαδικασία. Κάθε διαδικασία µπορεί να αναλύεται σε επιµέρους διαδικασίες. Κύκλος Ζωής Έργου 1..* Φάση 1..* ιαδικασία 0..* Συµµετέχων στο Έργο εκτελεί Μια δραστηριότητα εκτελείται από έναν τουλάχιστον από τους συµµετέχοντες στο έργο. 1..* 1..* Κάθε συµµετέχων στο έργο µπορεί να εκτελεί τουλάχιστον µία δραστηριότητα. 1..* ραστηριότητα χρησιµοποιεί 0..* Πόρος Μια διαδικασία αναλύεται σε µία ή περισσότερες δραστηριότητες. παράγει Κάθε δραστηριότητα µπορεί να χρησιµοποιεί τους πόρους του έργου. 0..* Οι δραστηριότητες παράγουν τα αποτελέσµατα του έργου. Υπάρχουν δραστηριότητες που δεν οδηγούν σε παραδοτέα. Αποτέλεσµα του Έργου Σχήµα 2: ιάγραµµα κλάσεων της UML που παρουσιάζει τη δοµή ενός έργου 5. Συµπεράσµατα Στο άρθρο παρουσιάστηκαν οι σύγχρονες κατευθύνσεις της έρευνας στην περιοχή της διαχείρισης διαδικασιών σε έργα λογισµικού. Επικεντρωθήκαµε στο ανοικτό ερευνητικό πρόβληµα της ενοποιηµένης αναπαράστασης της δοµής και της δυναµικής συµπεριφοράς των σύνθετων δραστηριοτήτων (των ροών εργασίας) που πραγµατοποιούνται κατά την εκτέλεση µιας διαδικασίας. Στο
17ο Συνέδριο της Ε.Ε.Ε.Ε. «ιαχείριση Κινδύνων» 401 πρόβληµα αυτό εστιάζουν και οι στόχοι του ερευνητικού έργου MISSION-SPM. Στο έργο υιοθετούνται σύγχρονες πρότυπες πρακτικές (π.χ. το πρότυπο SPEM) και µεθοδολογίες που χρησιµοποιούν τις αρχές της αντικειµενοστραφούς προσέγγισης (σε συνδυασµό µε τα µοντέλα της UML) για την οπτική περιγραφή κάθε διαδικασίας ανάπτυξης λογισµικού. Στο άρθρο παρουσιάστηκαν τα υποσυστήµατα της αρχιτεκτονικής που προτείνει το έργο MISSION-SPM και δόθηκε ένα απλό παράδειγµα, όπου περιγράψαµε τον τρόπο µε τον οποίο προκύπτει ένα διάγραµµα κλάσεων της UML για την αναπαράσταση της δοµής ενός έργου. Μια άλλη ερευνητική προτεραιότητα στο MISSION - SPM είναι η υιοθέτηση τυπικών µοντέλων µε ισχυρό υπόβαθρο ανάλυσης που θα περιγράφουν, σε ένα χαµηλότερο επίπεδο αφαίρεσης, τις διαδικασίες που σχεδιάστηκαν, στο υψηλότερο επίπεδο αφαίρεσης, µε τα διαγράµµατα της UML. Για τον σκοπό αυτό θα αξιοποιηθούν τεχνικές που πραγµατοποιούν µετατροπή των διαγραµµάτων της UML σε ισοδύναµες προδιαγραφές ικτύων Petri (Baresi και Pezze, 2001). Η χρήση τυπικών µοντέλων έχει ως στόχο τη δυνατότητα τυπικής επαλήθευσης της ορθότητας των ιδιοτήτων του σχεδιασµού καθώς και τον υπολογισµό µέτρων απόδοσης που είναι σηµαντικά, κυρίως για την παρακολούθηση και τη διαχείριση των χρονικών παραµέτρων µιας διαδικασίας. Βιβλιογραφία Baresi, L. and Pezze, M. (2001). Improving UML with Petri Nets, Electronic Notes in Theoretical Computer Science, 44, 1-13. Basili, V. R. & Musa, J. D. (1991). The future engineering of software: A management perspective, IEEE Computer, Sep. 1991, 90-96. Beck, K. & Andres, C. (2004). Extreme Programming Explained: Embrace Change, Addison - Wesley. Bertolino, A. & Mirandola, R. (2004). Software performance engineering of component-based systems, Proceedings of the 4th International Workshop on Software & Performance, 238-242. Cantor, M. (1998). Object-Oriented Project Management with UML, John Wiley & Sons. Chang, C. & Christensen, M. (1999). Net Practice in Software Project Management. IEEE Software, 16 (6), 80-88. Desmond, F. D. & Cameron, A. W. (1999). Objects, Components & Frameworks with UML: the Catalysis Approach, Addison-Wesley. Drappa, A. & Ludewig, J. (2000). Simulation in Software Engineering Training, Proceedings of the 22nd Int. Conference on Software Engineering, Ireland, 199-208.
Β. Γερογιάννης 402 Gerogiannis, V. C., Kameas, A. & Pintelas, P., (1998). Classification & Comparative Study of High-Level Petri Nets, Journal of Systems & Software, 43, 133-160. Jacobson, I., (1992). Object-Oriented Software Engineering A Use Case Driven Approach, ACM Press / Addison-Wesley. Jacobson, I., Booch, G. & Rumbaugh, J. (1999). The Unified Software Development Process, Addison-Wesley. Kleppe, A., Warner J. & Bast, W. (2003). MDA-Explained: The Model Driven Architecture, Addison-Wesley. Krutchen, P., (2000). The Rational Unified Process, An Introduction, Addison-Wesley. Liu, L. C. & Horowitz, E. (1989). A Formal Model for Software Project Management, IEEE Transactions on Software Engineering, 15 (10), 280-1293. Mehrez, A., Muzumdar, M., Acar, W. & Weinroth, G. (1995). A Petri-Net Model View of Decision Making: an Operational Management Analysis, Omega International Journal in Management Science, 23 (1), 63-78. Min, S.Y., Lee, D.H. & Bae, D.H. (2000). SoftPM: a SW Process Management System Reconciling Formalism with Easiness, Information & Software Technology, 42, 1-16. Murch, R. (2001). PM Best Practices for IT Professionals, Prenctice Hall. OMG (2003). Unified Modeling Language, Ver. 1.5 (http://www.omg.org). OMG (2005). Software Process Engineering Metamodel, Ver. 1.1. PMBOK (2000). A Guide to the Project Management Body of Knowledge, PMI Institute. Royce, W. (1998). Software Project Management: a Unified Framework, Addison-Wesley. Szyperski, C. (1988). Component Software: Beyond Object-Oriented Programming, Addison-Wesley. Wallace, L. & Keil, M. (2004). Software Project Risks & Their Effect on Outcomes, Communications of the ACM, 47 (4), 68-73.