Βιβλιοθήκη ΟΠΑ - Ψηφιακό Αποθετήριο

ΠΥΞΙΔΑ Ιδρυματικό Αποθετήριο
και Ψηφιακή Βιβλιοθήκη

Όνομα χρήστη
Κωδικός πρόσβασης

Συλλογές :	Ιδρυματικό Αποθετήριο ΟΠΑ / AUEB Institutional Repository Σχολή Επιστημών και Τεχνολογίας της Πληροφορίας / School of Informatics Τμήμα Πληροφορικής / Department of Informatics Μεταπτυχιακές Εργασίες / Postgraduate dissertations

Τίτλος :	Η διαχείριση της συντήρησης του λογισμικού

Δημιουργός :	Μαρτσούκος, Γεώργιος-Φανούριος

Συντελεστής :	Γιακουμάκης, Εμμανουήλ (Επιβλέπων καθηγητής) Μαλεύρης, Νικόλαος (Εξεταστής) Οικονομικό Πανεπιστήμιο Αθηνών, Τμήμα Πληροφορικής (Degree granting institution)

Τύπος :	Text

Φυσική περιγραφή :	183σ.

Γλώσσα :	el

Περίληψη :	Η ανάπτυξη του λογισμικού έχει πολλές φάσεις. Η συντήρηση λογισμικού αποτελεί το τελευταίο στάδιο του κύκλου ζωής του λογισμικού. Αφότου το σύστημα έχει παραδοθεί στον πελάτη, η φάση της συντήρησης στοχεύει στο να το διατηρήσει λειτουργικό. Με το πέρασμα των ετών, πολλοί συγγραφείς επιχείρησαν να κατηγοριοποιήσουν τη συντήρηση λογισμικού. Με βάση το πρότυπο ISO/IEC 14764 η συντήρηση λογισμικού μπορεί να διακριθεί σε διορθωτική, προσαρμοστική, βελτιστοποιητική και προληπτική συντήρηση. Η διορθωτική συντήρηση ασχολείται με την επιδιόρθωση εντοπισμένων σφαλμάτων σε ένα σύστημα. Η προσαρμοστική συντήρηση πραγματοποιείται προκειμένου ένα σύστημα να προσαρμοστεί στο μεταβαλλόμενο περιβάλλον του. Η βελτιστοποιητική συντήρηση πραγματοποιείται με σκοπό να βελτιωθούν τα χαρακτηριστικά ενός συστήματος, ενώ η προληπτική συντήρηση γίνεται για να αποτρέψει την εμφάνιση πιθανών σφαλμάτων σε ένα σύστημα. Από τις παραπάνω τέσσερις κατηγορίες, περίπου ο μισός χρόνος συντήρησης υπολογίζεται ότι αφιερώνεται στη βελτιστοποιητική συντήρηση. Πολλοί ερευνητές προσπάθησαν να περιγράψουν μέσα από διάφορα μοντέλα τις διαδικασίες συντήρησης λογισμικού. Παραδείγματα τέτοιων μοντέλων είναι το μοντέλο γρήγορης επιδιόρθωσης, το επαναληπτικό βελτιωτικό μοντέλο, το μοντέλο πλήρους επαναχρησιμοποίησης, το μοντέλο του Boehm, το μοντέλο του Osborne και το σταδιακό μοντέλο. Η ανάπτυξη των παραπάνω μοντέλων προετοίμασε το έδαφος για τη συγγραφή πρότυπων μοντέλων συντήρησης τα οποία περιγράφουν τις δραστηριότητες συντήρησης μέσα από διαφορετικές φάσεις. Τέτοιου είδους πρότυπα μοντέλα είναι τα ISO/IEC 14764, IEEE 1219 και ISO/IEC 12207. Σκοπός αυτών των μοντέλων είναι να παρέχουν στους συντηρητές λογισμικού ένα ολοκληρωμένο πλαίσιο εντός του οποίου θα συντηρούν το λογισμικό χρησιμοποιώντας βέλτιστες πρακτικές. Παρόλη τη χρησιμότητα τους, υπάρχουν ακόμη πολλά περιθώρια βελτίωσης τους. Τα τελευταία χρόνια, όλο και περισσότεροι οργανισμοί και επιχειρήσεις επιλέγουν τη λύση της εξωτερικής ανάθεσης των δραστηριοτήτων συντήρησης των συστημάτων λογισμικού τους. Διάφοροι λόγοι, όπως αυτοί της παροχής καλύτερων υπηρεσιών, της επικέντρωσης του εσωτερικού δυναμικού του ΙΤ τμήματος περισσότερο σε στρατηγικούς στόχους της επιχείρησης και άλλοι, ευνοούν την ευδοκίμηση μιας τέτοιας στρατηγικής. Η εισαγωγή υπεργολάβων στη φάση της συντήρησης λογισμικού πέρα από τις προκλήσεις κρύβει και διάφορους κινδύνους, γι’αυτό και οι επιχειρήσεις θα πρέπει να είναι ιδιαίτερα προσεκτικές στην επιλογή αυτών.Σημαντικό ρόλο στην επίτευξη μιας εποικοδομητικής σχέσης μεταξύ της επιχείρησης και του υπεργολάβου διαδραματίζει το Συμφωνητικό Παροχής Υπηρεσιών (SLA). Ένα σωστά ορισμένο SLA είναι συνταγμένο και από τα δύο εμπλεκόμενα μέρη και δομημένο με τρόπο που αποσαφηνίζει τις υποχρεώσεις και τις ευθύνες τους.Ένα από τα πιο σημαντικά σημεία δόμησης ενός SLA και πολλές φορές προάγγελος επιτυχίας του ή μη είναι αυτό της επιλογής των κατάλληλων μετρικών που θα μετρήσουν την ποιότητα της εργασίας που θα πραγματοποιήσει ο πάροχος των υπηρεσιών συντήρησης. Η επιλογής τους αποτελεί μία δύσκολη διαδικασία και κατά τη διάρκεια αυτής, θα πρέπει να λαμβάνονται υπόψη διάφορες παράμετροι, όπως η εμπειρία του οργανισμού με τις μετρικές, το κόστος και ο χρόνος που χρειάζονται για τη συλλογή τους και άλλοι. Διάφορες μετρικές ποιότητας συντήρησης λογισμικού μπορούν να χρησιμοποιηθούν σε ένα SLA συντήρησης όπως η εναπομένουσα επιδιόρθωση και ο δείκτης διαχείρισης εναπομένουσας επιδιόρθωσης, ο χρόνος απόκρισης επιδιόρθωσης και η αποκρισιμότητα επιδιόρθωσης, το ποσοστό ληξιπρόθεσμων επιδιορθώσεων και η ποιότητα επιδιόρθωσης. Επιπρόσθετες δημοφιλείς μετρικές οι οποίες μπορούν να χρησιμοποιηθούν σε ένα SLA συντήρησης είναι η διαθεσιμότητα και ο χρόνος μη διαθεσιμότητας του συστήματος, η αξιοπιστία του, η αποτελεσματικότητα του παρόχου, η ικανοποίηση της επιχείρησης, ο όγκος της εργασίας του παρόχου και άλλες. Αξιολογήσεις και συμπεράσματα για την πορεία της συνεργασίας μεταξύ παρόχου και επιχείρησης για μία ορισμένη χρονική περίοδο μπορούν να εξαχθούν μέσα από τη σύνταξη των Αναφορών Επιπέδου Υπηρεσιών (SLRs). Αυτού του είδους οι αναφορές, οι οποίες συντάσσονται κατόπιν συνεννόησης και των δύο εμπλεκόμενων μερών του SLA, αναλύουν κατά πόσο το SLA είναι καλά ορισμένο και είναι σωστά επιλεγμένες οι βέλτιστες μετρικές. Οι SLRs θα πρέπει να συντάσσονται τακτικά, ιδιαίτερα κατά το αρχικό στάδιο της συνεργασίας των δύο συμβαλλόμενων πλευρών. Κρίνεται σκόπιμο επιχειρήσεις οι οποίες δε διαθέτουν προηγούμενη εμπειρία σύνταξης SLAs να ζητήσουν επαγγελματική βοήθεια για να τους καθοδηγήσει στη δημιουργία των πρώτων τους SLAs.Το κόστος συντήρησης λογισμικού αντιστοιχεί περίπου στο 50-75% του συνολικού κόστους του κύκλου ζωής του λογισμικού. Σύμφωνα μάλιστα με ορισμένες μελέτες το ποσοστό αυτό φτάνει ακόμα και στο 90%. Μια σειρά τεχνικών και διοικητικών προβλημάτων οδηγούν στην αύξηση του κόστους της συντήρησης λογισμικού. Παραδείγματα τέτοιων είναι οι γρήγορες αλλαγές στις προτεραιότητες της διοίκησης, οι ανεπαρκείς μέθοδοι ελέγχου, οι δυσκολίες μέτρησης των επιδόσεων των συντηρητών και οι δυσκολίες κατανόησης του προγράμματος που πρόκειται να συντηρηθεί. Η εκτίμηση του κόστους της συντήρησης λογισμικού είναι η διαδικασία πρόβλεψης της προσπάθειας που θα απαιτηθεί για τη συντήρηση ενός συστήματος λογισμικού. Προκειμένου να εξαχθεί μία σωστή εκτίμηση θα πρέπει να ληφθούν υπόψη διάφοροι παράγοντες όπως το μέγεθος και η πολυπλοκότητα του συντηρήσιμου συστήματος. Οι μετρικές μεγέθους ενός συντηρήσιμου συστήματος μπορούν να κατηγοριοποιηθούν στις μετρικές βασισμένες στην κωδικοποίηση και στις μετρικές λειτουργικού μεγέθους. Στην πρώτη περίπτωση ανήκουν μετρικές, όπως η SLOC, οι οποίες μετρούν το μέγεθος του συντηρήσιμου συστήματος με βάση τις αλλαγμένες γραμμές του πηγαίου κώδικα του. Στη δεύτερη περίπτωση ανήκουν μετρικές, όπως οι FPA και COSMIC-FFP, οι οποίες μετρούν τον αριθμό των λειτουργικών σημείων του.Διάφορα μοντέλα κατά μήκος των ετών έχουν προταθεί και χρησιμοποιηθεί για την εκτίμηση του κόστους της συντήρησης λογισμικού. Αρκετά από αυτά, χρησιμοποιούνται εξίσου τόσο για την εκτίμηση του κόστους ενός υπό ανάπτυξη συστήματος, όσο και για την εκτίμηση του κόστους άλλων δραστηριοτήτων. Τα μοντέλα μπορούν να ταξινομηθούν σε δύο κύριες κατηγορίες: τα αλγοριθμικά και τα μη αλγοριθμικά. Η κάθε κατηγορία έχει τα δυνατά και τα αδύνατα σημεία της. Στην κατηγορία των μη αλγοριθμικών μοντέλων διακρίνουμε διάφορες μεθόδους όπως την εκτίμηση κατ’αναλογία, την τεχνική κρίσης από κάποιον εμπειρογνώμονα, την τεχνική των Δελφών, τις τεχνικές από Πάνω προς τα Κάτω και από Κάτω προς τα Πάνω. Κύριο χαρακτηριστικό αυτής της κατηγορίας είναι ότι η εκτίμηση του κόστους της συντήρησης βασίζεται στην εμπειρία που έχει αποκομίσει η ομάδα συντήρησης από προηγούμενα συντηρήσιμα συστήματα. Στην κατηγορία των αλγοριθμικών μοντέλων, ανάλογα με το βαθμό λεπτομέρειας της εστίασης της εκτίμησης τους, διακρίνουμε τα μοντέλα σε επίπεδο φάσης, τα μοντέλα σε επίπεδο έκδοσης και τα μοντέλα σε επίπεδο εργασιών. Στην πρώτη ομάδα ανήκουν τα μοντέλα τα οποία χρησιμοποιούνται πρωτίστως για την κοστολόγηση ενός συστήματος που πρόκειται να αναπτυχθεί και τα οποία μπορούν να χρησιμοποιηθούν και για την κοστολόγηση της συντήρησης ενός συστήματος. Υπάρχουν διάφορα τέτοια μοντέλα όπως τα COCOMO, PRICE-S, Knowledge Plan, SLIM και άλλα, με ποιο γνωστό εξ’ αυτών το COCOMO. Το COCOMO μοντέλο έχει χρησιμοποιηθεί για την κοστολόγηση χιλιάδων έργων λογισμικού. Η ευρεία χρήση του προκύπτει από το γεγονός ότι είναι ένα ανοικτό μοντέλο, πράγμα που σημαίνει ότι όλες οι λεπτομέρειες του είναι δημοσιευμένες, εν αντιθέσει με τα υπόλοιπα ιδιόκτητα μοντέλα αυτής της ομάδας. Στη δεύτερη ομάδα ανήκουν τα μοντέλα τα οποία χρησιμοποιούνται για την κοστολόγηση της συντήρησης ενός συστήματος όταν αυτό μεταβαίνει από μία έκδοση σε μία επόμενη. Διάφορες μελέτες που πραγματοποιήθηκαν ανέδειξαν τέτοιου είδους μοντέλα, όπως το Mancost. Στην τρίτη ομάδα ανήκουν τα μοντέλα τα οποία χρησιμοποιούνται για την κοστολόγηση των επιμέρους εργασιών συντήρησης οι οποίες προκύπτουν ως απόρροια αιτημάτων αλλαγής ή αναφορών λάθους. Διάφορες μελέτες που πραγματοποιήθηκαν ανέδειξαν τέτοιου είδους μοντέλα, όπως το SoftCalc. Κύριο χαρακτηριστικό της κατηγορίας των αλγοριθμικών μοντέλων είναι η χρησιμοποίηση διαφόρων μαθηματικών τύπων και χαρακτηριστικών (παραμέτρων). Προκειμένου τα αλγοριθμικά μοντέλα να πετύχουν πιο ακριβείς εκτιμήσεις είναι σημαντικό να βαθμονομούνται με πραγματικά δεδομένα από παρόμοιες εργασίες συντήρησης. Απόλυτη ακρίβεια κοστολόγησης των εργασιών της συντήρησης λογισμικού δε μπορεί να υπάρξει. Τις περισσότερες φορές, η καλύτερη προσέγγιση μιας όσο το δυνατόν πιο ακριβούς εκτίμησης είναι ένας συνδυασμός αλγοριθμικών και μη αλγοριθμικών μοντέλων. Ωστόσο, στην πράξη η εκτίμηση του κόστους της συντήρησης στηρίζεται πολύ περισσότερο στην εμπειρία από ότι στα αλγοριθμικά μοντέλα.Δυστυχώς, παρόλη τη σημασία της φάσης της συντήρησης λίγη σημασία έχει δοθεί στην ανάπτυξη μοντέλων για την κοστολόγηση αυτής καθαυτής της συντήρησης λογισμικού. Η ανάγκη δημιουργίας τέτοιων μοντέλων επιτείνεται από το γεγονός του ότι πολλά από τα προαναφερθέντα μοντέλα κατασκευάστηκαν για την κάλυψη συγκεκριμένων αναγκών εκτίμησης συντήρησης και δε μπορούν να επεκταθούν για την εκτίμηση όλων των συντηρήσιμων συστημάτων. Αυτό οδηγεί σε άστοχες προβλέψεις που επηρεάζουν αρνητικά τους προϋπολογισμούς των επιχειρήσεων.Σε μία δύσκολη οικονομικά εποχή όπως είναι η σημερινή, όλο και περισσότερες επιχειρήσεις επιλέγουν την ανάπτυξη και συντήρηση των συστημάτων τους με λογισμικό ανοικτού κώδικα σε μία απελπισμένη προσπάθεια να περιορίσουν τα ΙΤ έξοδα τους. Εντούτοις, πέρα από τα αδιαμφισβήτητα οφέλη που μπορούν να αποκομίσουν, θα πρέπει να είναι ιδιαίτερα προσεκτικές με τη χρήση του λογισμικού ανοικτού κώδικα, καθώς μπορούν να βρεθούν αντιμέτωπες με απρόβλεπτες καταστάσεις. Η συντήρηση στο λογισμικό κλειστού κώδικα και στο λογισμικό ανοικτού κώδικα παρουσιάζει ομοιότητες και διαφορές. Οι διαδικασίες συντήρησης στο λογισμικό κλειστού κώδικα, όπως προαναφέραμε, έχουν περιγραφεί σε διάφορα πρότυπα. Μέσα από μία έρευνα που διεξήχθη το 2005 παρατηρήθηκε ότι οι διαδικασίες συντήρησης στο λογισμικό ανοικτού κώδικα είναι αρκετά παρόμοιες με εκείνες που περιγράφονται στο πρότυπο ISO/IEC 14764. Οι κύριες διαφορές που εντοπίστηκαν σε σχέση με το πρότυπο εστιάζονται στην απουσία της δραστηριότητας της απόσυρσης και τη δυσνόητη συμπεριφορά της δραστηριότητας της μετανάστευσης. Επιπρόσθετα, δύο από τις κύριες διαφορές μεταξύ της συντήρησης στο λογισμικό ανοικτού κώδικα σε σχέση με την αντίστοιχη στο κλειστό λογισμικό είναι η τάση που έχει η πρώτη να είναι λιγότερο εντροπική, πράγμα που οδηγεί σε μικρότερα μελλοντικά κόστη συντήρησης και πολλές φορές περισσότερο χρονοβόρα, καθώς η συντήρηση στα έργα ανοικτού λογισμικού εναπόκειται στην οικειοθελή συνεισφορά διαφόρων διάσπαρτων προγραμματιστών. Στη διαδικασία της συντήρησης στο λογισμικό ανοικτού κώδικα διαδραματίζουν πολύ σημαντικό ρόλο δύο συστήματα διαχείρισης: τα Συστήματα Διαχείρισης Ελαττωμάτων (DMS) και τα Συστήματα Διαχείρισης Εκδόσεων (VMS). Τα DMS παρέχουν τη δυνατότητα στους χρήστες ενός συστήματος να αναφέρουν σφάλματα τα οποία εντόπισαν σε αυτό. Από εκεί και ύστερα, οι προγραμματιστές του συστήματος μπορούν να διαχειριστούν τα σφάλματα που αναφέρθηκαν. Υπάρχουν πολλά διαφορετικά DMS, όπως τα GNATS, Bugzilla, Request Tracker και άλλα. Τα VMS ασχολούνται με την τροποποίηση του πηγαίου κώδικα που οδήγησε στην αναφορά σφάλματος. Αυτού του είδους τα συστήματα παρέχουν δυνατότητες διαχείρισης εκδόσεων, πράγμα που καθιστά εύκολη τη διαχείριση του κώδικα από τους προγραμματιστές και αποτρέπει τις μεταξύ τους συγκρούσεις. Ανάλογα με τον τρόπο επικοινωνίας των προγραμματιστών διακρίνονται στα Συγκεντρωτικά VMS (CVMS) και στα Κατανεμημένα VMS (DVMS). Παραδείγματα CVMS είναι τα SVN και CVS, ενώ παραδείγματα DVMS είναι τα Monotone και Mercurial. Μεγαλύτερες μελέτες και έρευνες απαιτούνται για τη διερεύνηση της συντήρησης στο λογισμικό ανοικτού κώδικα. Software development has lots of phases. Software maintenance is the last stage of software life cycle. After the system has been delivered to the customer, maintenance phase aims to keep it up to date. Over the years, many authors have attempted to categorize software maintenance. According to the ISO/IEC 14764 standard, software maintenance can be divided into corrective, adaptive, perfective and preventive maintenance. Corrective maintenance aims to repair detected errors in a system. Adaptive maintenance is carried out in order to adapt a system to its changing environment. Perfective maintenance is performed in order to improve the characteristics of a system, while preventive maintenance aims to prevent the occurrence of potential errors in a system. As for the time consumed for each phase, about half of the total software maintenance’s duration is estimated to be devoted to perfective maintenance.Many authors have tried to describe, using various models, the procedures of software maintenance. Examples of such models are the quick-fix model, the iterative enhancement model, the full-reused model, the Boehm’s model, the Osborne’s model and the staged model. The development of these models led to the development of standard process models. These models include ISO/IEC 14764, IEEE 1219 and ISO/IEC 12207. The purpose of these models is to provide software maintainers a complete framework within which they are able to maintain the software using best practices. Despite their usefulness, there is still space for improvement. In recent years, more and more software organizations and companies choose the option of outsourcing their software maintenance activities. Various reasons, such as providing better services, focus of internal staff of the IT department on more strategic business objectives and others, promote the option of such a business strategy. The introduction of subcontractors in the process of software maintenance holds not only benefits, but also a number of risks, and therefore companies should be particularly careful in selecting them. Important role in achieving a constructive relationship between the firm and the subcontractor holds the Service Level Agreement (SLA). A properly specified SLA is prepared by both parties and structured in a way that clarifies the obligations and responsibilities of both parties. One of the most important key points of building a SLA and often a precursor of success or failure is the selection of appropriate metrics to measure the quality of work carried out by the provider of maintenance services. Their selection is a difficult process and during that, various parameters should be taken into account, such as the experience of organization with the metrics, cost and time needed for collection and others. Several software maintenance quality metrics can be used in an outsourcing maintenance contract like Fix Backlog and Backlog Management Index, Fix Response Time and Fix Responsiveness, Percent Delinquent Fixes and Fix Quality. Additional popular metrics that can be used in a software maintenance SLA are the availability and downtime of a system, the reliability of a system, the effectiveness of the service provider, the satisfaction of the organization, the volume of provider’s work and others. Evaluations and conclusions about the quality of cooperation between the provider and the firm for a certain period can be exported through the preparation of Service Level Reports (SLRs). Such reports, which are prepared by both parties involved in the SLA, analyze whether the SLA is well defined and the best metrics are properly selected. SLRs should be prepared regularly, especially during the initial stage of cooperation between the two contracting parties.It is suggested that firms which do not have previous experience in working with SLAs require professional help to guide them in creating their first SLAs.Software maintenance cost is estimated to be about 50-75% of the total cost of the software life cycle. Moreover, according to some studies this percentage can be even 90%. A series of technical and managerial problems lead to an increased cost of software maintenance. Examples of these problems are rapid changes in the priorities of managers, inadequate testing methods due to lack of time or lack of understanding of testing methods, difficulties of measuring the performance of maintainers and difficulties of understanding the program to be maintained. The estimation of the software maintenance cost is the process of predicting the effort that will be required to maintain a software system. In order to extract a correct estimation various factors such as the size and complexity of the maintainable system should be taken into account. Sizing metrics of a maintainable system can be classified into code-based sizing metrics and functional sizing metrics. In the first case metrics such as SLOC are included, which measure the size of the maintainable system based on the lines of source code which changed. In the second case metrics such as FPA and COSMIC-FFP are included, which measure the number of function points of the maintainable system. Along the years, various models have been proposed and used to estimate the cost of software maintenance. Many of them are used not only to estimate the cost of the development of new software, but also to estimate the cost of other activities. Models can be classified into two main categories: algorithmic and non-algorithmic. Each category has its strengths and weaknesses. In the category of non-algorithmic models several methods are included such as the estimation by analogy, the expert judgment technique, the Delphi technique and the top-down and bottom-up techniques. The main characteristic of this type is that the software maintenance cost estimation is based on the experience gained by the maintenance team from previous maintainable systems. In the category of algorithmic models, depending on the degree of detail of their estimation, phase-level models, release–level models and task-level models exist. The first group includes models which are primarily used for costing new software that is being developed, but they can be also used for the cost estimation of a maintainable system. These include several models such as COCOMO, PRICE-S, Knowledge Plan, SLIM and others, with the most known of them being COCOMO. COCOMO model has been used for the cost estimation of thousands of software projects. Its widespread use stems from the fact that is an open model, which means that all of its details are published, in contrast to all others proprietary models of this group. The second group includes models that are used for the cost estimation of a maintainable system when a new version is developed. Several studies have developed such models as the Mancost. The third group includes models that are used for the cost estimation of individual maintenance tasks which arise as a result of modification requests or error reports. Several studies have developed such models as the SoftCalc. The main characteristic of the category of algorithmic models is the use of different formulas and attributes (called parameters). Algorithmic models work best when they are calibrated with actual data from similar software maintenance tasks.It is not possible to achieve absolute accuracy in the estimation of the cost of software maintenance tasks. Usually, the best approach to the most possible accurate estimation is a combination of algorithmic and non-algorithmic models. However, in practice cost estimation is based on much more on experience than algorithmic models.Unfortunately, despite the importance of the maintenance phase, developing models specific for the cost estimation of maintainable systems has not been given the appropriate attention. Moreover, the need for new models is urgent because many of the models that are presented above were built to address certain maintenance estimation needs and cannot be extended to estimate all maintainable systems. This results in wrong estimations which negatively affect the budget of firms. In difficult financial years such as nowadays, more and more companies choose the use of open source software for the development and maintenance of their systems in a desperate effort to reduce IT costs. However, beyond the undeniable benefits that can accrue, firms should be particularly careful with the use of open source, due to unforeseen situations that may occur. The maintenance in commercial closed software and open source software has similarities and differences. Maintenance procedures in closed source software, as we mentioned above, have been described in various standards. Through a survey, which was conducted in 2005, it has been observed that the maintenance procedures in open source software are quite similar to those described in standard ISO/IEC 14764. The main differences, which are identified in relation to the standard model, are focused on a lack of the retirement activity and the obscure migration activity. Additionally, two of the main differences between the maintenance of the open source software compared to the corresponding of the closed software are the trend of the open software to be less entropic, leading to lower future maintenance costs, and often more time-consuming, as maintenance in open source software depends on the voluntary contribution of various distributed developers. Ιn the process of maintenance in open source software two management systems play a very important role: Defect Management Systems (DMS) and Version Management Systems (VMS). DMS allow system users to report bugs that are found in it. Then, the developers of the system can handle the errors reported. There are many different DMS, such as GNATS, Bugzilla, Request Tracker and more. The VMS are involved in modifying the source code that led to the error report. These systems provide version management capabilities, making it easy for developers to manage the code and avoiding the conflicts between them. Depending on how developers contact each other they are divided in Centralized VMS (CVMS) and Distributed VMS (DVMS). Examples of CVMS are SVN and CVS, while examples of DVMS are Monotone and Mercurial. Larger studies and research are needed to explore open source software maintenance.

Περίληψη :

Η ανάπτυξη του λογισμικού έχει πολλές φάσεις. Η συντήρηση λογισμικού αποτελεί το τελευταίο στάδιο του κύκλου ζωής του λογισμικού. Αφότου το σύστημα έχει παραδοθεί στον πελάτη, η φάση της συντήρησης στοχεύει στο να το διατηρήσει λειτουργικό. Με το πέρασμα των ετών, πολλοί συγγραφείς επιχείρησαν να κατηγοριοποιήσουν τη συντήρηση λογισμικού. Με βάση το πρότυπο ISO/IEC 14764 η συντήρηση λογισμικού μπορεί να διακριθεί σε διορθωτική, προσαρμοστική, βελτιστοποιητική και προληπτική συντήρηση. Η διορθωτική συντήρηση ασχολείται με την επιδιόρθωση εντοπισμένων σφαλμάτων σε ένα σύστημα. Η προσαρμοστική συντήρηση πραγματοποιείται προκειμένου ένα σύστημα να προσαρμοστεί στο μεταβαλλόμενο περιβάλλον του. Η βελτιστοποιητική συντήρηση πραγματοποιείται με σκοπό να βελτιωθούν τα χαρακτηριστικά ενός συστήματος, ενώ η προληπτική συντήρηση γίνεται για να αποτρέψει την εμφάνιση πιθανών σφαλμάτων σε ένα σύστημα. Από τις παραπάνω τέσσερις κατηγορίες, περίπου ο μισός χρόνος συντήρησης υπολογίζεται ότι αφιερώνεται στη βελτιστοποιητική συντήρηση. Πολλοί ερευνητές προσπάθησαν να περιγράψουν μέσα από διάφορα μοντέλα τις διαδικασίες συντήρησης λογισμικού. Παραδείγματα τέτοιων μοντέλων είναι το μοντέλο γρήγορης επιδιόρθωσης, το επαναληπτικό βελτιωτικό μοντέλο, το μοντέλο πλήρους επαναχρησιμοποίησης, το μοντέλο του Boehm, το μοντέλο του Osborne και το σταδιακό μοντέλο. Η ανάπτυξη των παραπάνω μοντέλων προετοίμασε το έδαφος για τη συγγραφή πρότυπων μοντέλων συντήρησης τα οποία περιγράφουν τις δραστηριότητες συντήρησης μέσα από διαφορετικές φάσεις. Τέτοιου είδους πρότυπα μοντέλα είναι τα ISO/IEC 14764, IEEE 1219 και ISO/IEC 12207. Σκοπός αυτών των μοντέλων είναι να παρέχουν στους συντηρητές λογισμικού ένα ολοκληρωμένο πλαίσιο εντός του οποίου θα συντηρούν το λογισμικό χρησιμοποιώντας βέλτιστες πρακτικές. Παρόλη τη χρησιμότητα τους, υπάρχουν ακόμη πολλά περιθώρια βελτίωσης τους. Τα τελευταία χρόνια, όλο και περισσότεροι οργανισμοί και επιχειρήσεις επιλέγουν τη λύση της εξωτερικής ανάθεσης των δραστηριοτήτων συντήρησης των συστημάτων λογισμικού τους. Διάφοροι λόγοι, όπως αυτοί της παροχής καλύτερων υπηρεσιών, της επικέντρωσης του εσωτερικού δυναμικού του ΙΤ τμήματος περισσότερο σε στρατηγικούς στόχους της επιχείρησης και άλλοι, ευνοούν την ευδοκίμηση μιας τέτοιας στρατηγικής. Η εισαγωγή υπεργολάβων στη φάση της συντήρησης λογισμικού πέρα από τις προκλήσεις κρύβει και διάφορους κινδύνους, γι’αυτό και οι επιχειρήσεις θα πρέπει να είναι ιδιαίτερα προσεκτικές στην επιλογή αυτών.Σημαντικό ρόλο στην επίτευξη μιας εποικοδομητικής σχέσης μεταξύ της επιχείρησης και του υπεργολάβου διαδραματίζει το Συμφωνητικό Παροχής Υπηρεσιών (SLA). Ένα σωστά ορισμένο SLA είναι συνταγμένο και από τα δύο εμπλεκόμενα μέρη και δομημένο με τρόπο που αποσαφηνίζει τις υποχρεώσεις και τις ευθύνες τους.Ένα από τα πιο σημαντικά σημεία δόμησης ενός SLA και πολλές φορές προάγγελος επιτυχίας του ή μη είναι αυτό της επιλογής των κατάλληλων μετρικών που θα μετρήσουν την ποιότητα της εργασίας που θα πραγματοποιήσει ο πάροχος των υπηρεσιών συντήρησης. Η επιλογής τους αποτελεί μία δύσκολη διαδικασία και κατά τη διάρκεια αυτής, θα πρέπει να λαμβάνονται υπόψη διάφορες παράμετροι, όπως η εμπειρία του οργανισμού με τις μετρικές, το κόστος και ο χρόνος που χρειάζονται για τη συλλογή τους και άλλοι. Διάφορες μετρικές ποιότητας συντήρησης λογισμικού μπορούν να χρησιμοποιηθούν σε ένα SLA συντήρησης όπως η εναπομένουσα επιδιόρθωση και ο δείκτης διαχείρισης εναπομένουσας επιδιόρθωσης, ο χρόνος απόκρισης επιδιόρθωσης και η αποκρισιμότητα επιδιόρθωσης, το ποσοστό ληξιπρόθεσμων επιδιορθώσεων και η ποιότητα επιδιόρθωσης. Επιπρόσθετες δημοφιλείς μετρικές οι οποίες μπορούν να χρησιμοποιηθούν σε ένα SLA συντήρησης είναι η διαθεσιμότητα και ο χρόνος μη διαθεσιμότητας του συστήματος, η αξιοπιστία του, η αποτελεσματικότητα του παρόχου, η ικανοποίηση της επιχείρησης, ο όγκος της εργασίας του παρόχου και άλλες. Αξιολογήσεις και συμπεράσματα για την πορεία της συνεργασίας μεταξύ παρόχου και επιχείρησης για μία ορισμένη χρονική περίοδο μπορούν να εξαχθούν μέσα από τη σύνταξη των Αναφορών Επιπέδου Υπηρεσιών (SLRs). Αυτού του είδους οι αναφορές, οι οποίες συντάσσονται κατόπιν συνεννόησης και των δύο εμπλεκόμενων μερών του SLA, αναλύουν κατά πόσο το SLA είναι καλά ορισμένο και είναι σωστά επιλεγμένες οι βέλτιστες μετρικές. Οι SLRs θα πρέπει να συντάσσονται τακτικά, ιδιαίτερα κατά το αρχικό στάδιο της συνεργασίας των δύο συμβαλλόμενων πλευρών. Κρίνεται σκόπιμο επιχειρήσεις οι οποίες δε διαθέτουν προηγούμενη εμπειρία σύνταξης SLAs να ζητήσουν επαγγελματική βοήθεια για να τους καθοδηγήσει στη δημιουργία των πρώτων τους SLAs.Το κόστος συντήρησης λογισμικού αντιστοιχεί περίπου στο 50-75% του συνολικού κόστους του κύκλου ζωής του λογισμικού. Σύμφωνα μάλιστα με ορισμένες μελέτες το ποσοστό αυτό φτάνει ακόμα και στο 90%. Μια σειρά τεχνικών και διοικητικών προβλημάτων οδηγούν στην αύξηση του κόστους της συντήρησης λογισμικού. Παραδείγματα τέτοιων είναι οι γρήγορες αλλαγές στις προτεραιότητες της διοίκησης, οι ανεπαρκείς μέθοδοι ελέγχου, οι δυσκολίες μέτρησης των επιδόσεων των συντηρητών και οι δυσκολίες κατανόησης του προγράμματος που πρόκειται να συντηρηθεί. Η εκτίμηση του κόστους της συντήρησης λογισμικού είναι η διαδικασία πρόβλεψης της προσπάθειας που θα απαιτηθεί για τη συντήρηση ενός συστήματος λογισμικού. Προκειμένου να εξαχθεί μία σωστή εκτίμηση θα πρέπει να ληφθούν υπόψη διάφοροι παράγοντες όπως το μέγεθος και η πολυπλοκότητα του συντηρήσιμου συστήματος. Οι μετρικές μεγέθους ενός συντηρήσιμου συστήματος μπορούν να κατηγοριοποιηθούν στις μετρικές βασισμένες στην κωδικοποίηση και στις μετρικές λειτουργικού μεγέθους. Στην πρώτη περίπτωση ανήκουν μετρικές, όπως η SLOC, οι οποίες μετρούν το μέγεθος του συντηρήσιμου συστήματος με βάση τις αλλαγμένες γραμμές του πηγαίου κώδικα του. Στη δεύτερη περίπτωση ανήκουν μετρικές, όπως οι FPA και COSMIC-FFP, οι οποίες μετρούν τον αριθμό των λειτουργικών σημείων του.Διάφορα μοντέλα κατά μήκος των ετών έχουν προταθεί και χρησιμοποιηθεί για την εκτίμηση του κόστους της συντήρησης λογισμικού. Αρκετά από αυτά, χρησιμοποιούνται εξίσου τόσο για την εκτίμηση του κόστους ενός υπό ανάπτυξη συστήματος, όσο και για την εκτίμηση του κόστους άλλων δραστηριοτήτων. Τα μοντέλα μπορούν να ταξινομηθούν σε δύο κύριες κατηγορίες: τα αλγοριθμικά και τα μη αλγοριθμικά. Η κάθε κατηγορία έχει τα δυνατά και τα αδύνατα σημεία της. Στην κατηγορία των μη αλγοριθμικών μοντέλων διακρίνουμε διάφορες μεθόδους όπως την εκτίμηση κατ’αναλογία, την τεχνική κρίσης από κάποιον εμπειρογνώμονα, την τεχνική των Δελφών, τις τεχνικές από Πάνω προς τα Κάτω και από Κάτω προς τα Πάνω. Κύριο χαρακτηριστικό αυτής της κατηγορίας είναι ότι η εκτίμηση του κόστους της συντήρησης βασίζεται στην εμπειρία που έχει αποκομίσει η ομάδα συντήρησης από προηγούμενα συντηρήσιμα συστήματα. Στην κατηγορία των αλγοριθμικών μοντέλων, ανάλογα με το βαθμό λεπτομέρειας της εστίασης της εκτίμησης τους, διακρίνουμε τα μοντέλα σε επίπεδο φάσης, τα μοντέλα σε επίπεδο έκδοσης και τα μοντέλα σε επίπεδο εργασιών. Στην πρώτη ομάδα ανήκουν τα μοντέλα τα οποία χρησιμοποιούνται πρωτίστως για την κοστολόγηση ενός συστήματος που πρόκειται να αναπτυχθεί και τα οποία μπορούν να χρησιμοποιηθούν και για την κοστολόγηση της συντήρησης ενός συστήματος. Υπάρχουν διάφορα τέτοια μοντέλα όπως τα COCOMO, PRICE-S, Knowledge Plan, SLIM και άλλα, με ποιο γνωστό εξ’ αυτών το COCOMO. Το COCOMO μοντέλο έχει χρησιμοποιηθεί για την κοστολόγηση χιλιάδων έργων λογισμικού. Η ευρεία χρήση του προκύπτει από το γεγονός ότι είναι ένα ανοικτό μοντέλο, πράγμα που σημαίνει ότι όλες οι λεπτομέρειες του είναι δημοσιευμένες, εν αντιθέσει με τα υπόλοιπα ιδιόκτητα μοντέλα αυτής της ομάδας. Στη δεύτερη ομάδα ανήκουν τα μοντέλα τα οποία χρησιμοποιούνται για την κοστολόγηση της συντήρησης ενός συστήματος όταν αυτό μεταβαίνει από μία έκδοση σε μία επόμενη. Διάφορες μελέτες που πραγματοποιήθηκαν ανέδειξαν τέτοιου είδους μοντέλα, όπως το Mancost. Στην τρίτη ομάδα ανήκουν τα μοντέλα τα οποία χρησιμοποιούνται για την κοστολόγηση των επιμέρους εργασιών συντήρησης οι οποίες προκύπτουν ως απόρροια αιτημάτων αλλαγής ή αναφορών λάθους. Διάφορες μελέτες που πραγματοποιήθηκαν ανέδειξαν τέτοιου είδους μοντέλα, όπως το SoftCalc. Κύριο χαρακτηριστικό της κατηγορίας των αλγοριθμικών μοντέλων είναι η χρησιμοποίηση διαφόρων μαθηματικών τύπων και χαρακτηριστικών (παραμέτρων). Προκειμένου τα αλγοριθμικά μοντέλα να πετύχουν πιο ακριβείς εκτιμήσεις είναι σημαντικό να βαθμονομούνται με πραγματικά δεδομένα από παρόμοιες εργασίες συντήρησης. Απόλυτη ακρίβεια κοστολόγησης των εργασιών της συντήρησης λογισμικού δε μπορεί να υπάρξει. Τις περισσότερες φορές, η καλύτερη προσέγγιση μιας όσο το δυνατόν πιο ακριβούς εκτίμησης είναι ένας συνδυασμός αλγοριθμικών και μη αλγοριθμικών μοντέλων. Ωστόσο, στην πράξη η εκτίμηση του κόστους της συντήρησης στηρίζεται πολύ περισσότερο στην εμπειρία από ότι στα αλγοριθμικά μοντέλα.Δυστυχώς, παρόλη τη σημασία της φάσης της συντήρησης λίγη σημασία έχει δοθεί στην ανάπτυξη μοντέλων για την κοστολόγηση αυτής καθαυτής της συντήρησης λογισμικού. Η ανάγκη δημιουργίας τέτοιων μοντέλων επιτείνεται από το γεγονός του ότι πολλά από τα προαναφερθέντα μοντέλα κατασκευάστηκαν για την κάλυψη συγκεκριμένων αναγκών εκτίμησης συντήρησης και δε μπορούν να επεκταθούν για την εκτίμηση όλων των συντηρήσιμων συστημάτων. Αυτό οδηγεί σε άστοχες προβλέψεις που επηρεάζουν αρνητικά τους προϋπολογισμούς των επιχειρήσεων.Σε μία δύσκολη οικονομικά εποχή όπως είναι η σημερινή, όλο και περισσότερες επιχειρήσεις επιλέγουν την ανάπτυξη και συντήρηση των συστημάτων τους με λογισμικό ανοικτού κώδικα σε μία απελπισμένη προσπάθεια να περιορίσουν τα ΙΤ έξοδα τους. Εντούτοις, πέρα από τα αδιαμφισβήτητα οφέλη που μπορούν να αποκομίσουν, θα πρέπει να είναι ιδιαίτερα προσεκτικές με τη χρήση του λογισμικού ανοικτού κώδικα, καθώς μπορούν να βρεθούν αντιμέτωπες με απρόβλεπτες καταστάσεις. Η συντήρηση στο λογισμικό κλειστού κώδικα και στο λογισμικό ανοικτού κώδικα παρουσιάζει ομοιότητες και διαφορές. Οι διαδικασίες συντήρησης στο λογισμικό κλειστού κώδικα, όπως προαναφέραμε, έχουν περιγραφεί σε διάφορα πρότυπα. Μέσα από μία έρευνα που διεξήχθη το 2005 παρατηρήθηκε ότι οι διαδικασίες συντήρησης στο λογισμικό ανοικτού κώδικα είναι αρκετά παρόμοιες με εκείνες που περιγράφονται στο πρότυπο ISO/IEC 14764. Οι κύριες διαφορές που εντοπίστηκαν σε σχέση με το πρότυπο εστιάζονται στην απουσία της δραστηριότητας της απόσυρσης και τη δυσνόητη συμπεριφορά της δραστηριότητας της μετανάστευσης. Επιπρόσθετα, δύο από τις κύριες διαφορές μεταξύ της συντήρησης στο λογισμικό ανοικτού κώδικα σε σχέση με την αντίστοιχη στο κλειστό λογισμικό είναι η τάση που έχει η πρώτη να είναι λιγότερο εντροπική, πράγμα που οδηγεί σε μικρότερα μελλοντικά κόστη συντήρησης και πολλές φορές περισσότερο χρονοβόρα, καθώς η συντήρηση στα έργα ανοικτού λογισμικού εναπόκειται στην οικειοθελή συνεισφορά διαφόρων διάσπαρτων προγραμματιστών. Στη διαδικασία της συντήρησης στο λογισμικό ανοικτού κώδικα διαδραματίζουν πολύ σημαντικό ρόλο δύο συστήματα διαχείρισης: τα Συστήματα Διαχείρισης Ελαττωμάτων (DMS) και τα Συστήματα Διαχείρισης Εκδόσεων (VMS). Τα DMS παρέχουν τη δυνατότητα στους χρήστες ενός συστήματος να αναφέρουν σφάλματα τα οποία εντόπισαν σε αυτό. Από εκεί και ύστερα, οι προγραμματιστές του συστήματος μπορούν να διαχειριστούν τα σφάλματα που αναφέρθηκαν. Υπάρχουν πολλά διαφορετικά DMS, όπως τα GNATS, Bugzilla, Request Tracker και άλλα. Τα VMS ασχολούνται με την τροποποίηση του πηγαίου κώδικα που οδήγησε στην αναφορά σφάλματος. Αυτού του είδους τα συστήματα παρέχουν δυνατότητες διαχείρισης εκδόσεων, πράγμα που καθιστά εύκολη τη διαχείριση του κώδικα από τους προγραμματιστές και αποτρέπει τις μεταξύ τους συγκρούσεις. Ανάλογα με τον τρόπο επικοινωνίας των προγραμματιστών διακρίνονται στα Συγκεντρωτικά VMS (CVMS) και στα Κατανεμημένα VMS (DVMS). Παραδείγματα CVMS είναι τα SVN και CVS, ενώ παραδείγματα DVMS είναι τα Monotone και Mercurial. Μεγαλύτερες μελέτες και έρευνες απαιτούνται για τη διερεύνηση της συντήρησης στο λογισμικό ανοικτού κώδικα.
Software development has lots of phases. Software maintenance is the last stage of software life cycle. After the system has been delivered to the customer, maintenance phase aims to keep it up to date. Over the years, many authors have attempted to categorize software maintenance. According to the ISO/IEC 14764 standard, software maintenance can be divided into corrective, adaptive, perfective and preventive maintenance. Corrective maintenance aims to repair detected errors in a system. Adaptive maintenance is carried out in order to adapt a system to its changing environment. Perfective maintenance is performed in order to improve the characteristics of a system, while preventive maintenance aims to prevent the occurrence of potential errors in a system. As for the time consumed for each phase, about half of the total software maintenance’s duration is estimated to be devoted to perfective maintenance.Many authors have tried to describe, using various models, the procedures of software maintenance. Examples of such models are the quick-fix model, the iterative enhancement model, the full-reused model, the Boehm’s model, the Osborne’s model and the staged model. The development of these models led to the development of standard process models. These models include ISO/IEC 14764, IEEE 1219 and ISO/IEC 12207. The purpose of these models is to provide software maintainers a complete framework within which they are able to maintain the software using best practices. Despite their usefulness, there is still space for improvement. In recent years, more and more software organizations and companies choose the option of outsourcing their software maintenance activities. Various reasons, such as providing better services, focus of internal staff of the IT department on more strategic business objectives and others, promote the option of such a business strategy. The introduction of subcontractors in the process of software maintenance holds not only benefits, but also a number of risks, and therefore companies should be particularly careful in selecting them. Important role in achieving a constructive relationship between the firm and the subcontractor holds the Service Level Agreement (SLA). A properly specified SLA is prepared by both parties and structured in a way that clarifies the obligations and responsibilities of both parties. One of the most important key points of building a SLA and often a precursor of success or failure is the selection of appropriate metrics to measure the quality of work carried out by the provider of maintenance services. Their selection is a difficult process and during that, various parameters should be taken into account, such as the experience of organization with the metrics, cost and time needed for collection and others. Several software maintenance quality metrics can be used in an outsourcing maintenance contract like Fix Backlog and Backlog Management Index, Fix Response Time and Fix Responsiveness, Percent Delinquent Fixes and Fix Quality. Additional popular metrics that can be used in a software maintenance SLA are the availability and downtime of a system, the reliability of a system, the effectiveness of the service provider, the satisfaction of the organization, the volume of provider’s work and others. Evaluations and conclusions about the quality of cooperation between the provider and the firm for a certain period can be exported through the preparation of Service Level Reports (SLRs). Such reports, which are prepared by both parties involved in the SLA, analyze whether the SLA is well defined and the best metrics are properly selected. SLRs should be prepared regularly, especially during the initial stage of cooperation between the two contracting parties.It is suggested that firms which do not have previous experience in working with SLAs require professional help to guide them in creating their first SLAs.Software maintenance cost is estimated to be about 50-75% of the total cost of the software life cycle. Moreover, according to some studies this percentage can be even 90%. A series of technical and managerial problems lead to an increased cost of software maintenance. Examples of these problems are rapid changes in the priorities of managers, inadequate testing methods due to lack of time or lack of understanding of testing methods, difficulties of measuring the performance of maintainers and difficulties of understanding the program to be maintained. The estimation of the software maintenance cost is the process of predicting the effort that will be required to maintain a software system. In order to extract a correct estimation various factors such as the size and complexity of the maintainable system should be taken into account. Sizing metrics of a maintainable system can be classified into code-based sizing metrics and functional sizing metrics. In the first case metrics such as SLOC are included, which measure the size of the maintainable system based on the lines of source code which changed. In the second case metrics such as FPA and COSMIC-FFP are included, which measure the number of function points of the maintainable system. Along the years, various models have been proposed and used to estimate the cost of software maintenance. Many of them are used not only to estimate the cost of the development of new software, but also to estimate the cost of other activities. Models can be classified into two main categories: algorithmic and non-algorithmic. Each category has its strengths and weaknesses. In the category of non-algorithmic models several methods are included such as the estimation by analogy, the expert judgment technique, the Delphi technique and the top-down and bottom-up techniques. The main characteristic of this type is that the software maintenance cost estimation is based on the experience gained by the maintenance team from previous maintainable systems. In the category of algorithmic models, depending on the degree of detail of their estimation, phase-level models, release–level models and task-level models exist. The first group includes models which are primarily used for costing new software that is being developed, but they can be also used for the cost estimation of a maintainable system. These include several models such as COCOMO, PRICE-S, Knowledge Plan, SLIM and others, with the most known of them being COCOMO. COCOMO model has been used for the cost estimation of thousands of software projects. Its widespread use stems from the fact that is an open model, which means that all of its details are published, in contrast to all others proprietary models of this group. The second group includes models that are used for the cost estimation of a maintainable system when a new version is developed. Several studies have developed such models as the Mancost. The third group includes models that are used for the cost estimation of individual maintenance tasks which arise as a result of modification requests or error reports. Several studies have developed such models as the SoftCalc. The main characteristic of the category of algorithmic models is the use of different formulas and attributes (called parameters). Algorithmic models work best when they are calibrated with actual data from similar software maintenance tasks.It is not possible to achieve absolute accuracy in the estimation of the cost of software maintenance tasks. Usually, the best approach to the most possible accurate estimation is a combination of algorithmic and non-algorithmic models. However, in practice cost estimation is based on much more on experience than algorithmic models.Unfortunately, despite the importance of the maintenance phase, developing models specific for the cost estimation of maintainable systems has not been given the appropriate attention. Moreover, the need for new models is urgent because many of the models that are presented above were built to address certain maintenance estimation needs and cannot be extended to estimate all maintainable systems. This results in wrong estimations which negatively affect the budget of firms. In difficult financial years such as nowadays, more and more companies choose the use of open source software for the development and maintenance of their systems in a desperate effort to reduce IT costs. However, beyond the undeniable benefits that can accrue, firms should be particularly careful with the use of open source, due to unforeseen situations that may occur. The maintenance in commercial closed software and open source software has similarities and differences. Maintenance procedures in closed source software, as we mentioned above, have been described in various standards. Through a survey, which was conducted in 2005, it has been observed that the maintenance procedures in open source software are quite similar to those described in standard ISO/IEC 14764. The main differences, which are identified in relation to the standard model, are focused on a lack of the retirement activity and the obscure migration activity. Additionally, two of the main differences between the maintenance of the open source software compared to the corresponding of the closed software are the trend of the open software to be less entropic, leading to lower future maintenance costs, and often more time-consuming, as maintenance in open source software depends on the voluntary contribution of various distributed developers. Ιn the process of maintenance in open source software two management systems play a very important role: Defect Management Systems (DMS) and Version Management Systems (VMS). DMS allow system users to report bugs that are found in it. Then, the developers of the system can handle the errors reported. There are many different DMS, such as GNATS, Bugzilla, Request Tracker and more. The VMS are involved in modifying the source code that led to the error report. These systems provide version management capabilities, making it easy for developers to manage the code and avoiding the conflicts between them. Depending on how developers contact each other they are divided in Centralized VMS (CVMS) and Distributed VMS (DVMS). Examples of CVMS are SVN and CVS, while examples of DVMS are Monotone and Mercurial. Larger studies and research are needed to explore open source software maintenance.

Λέξη κλειδί :	Συντήρηση λογισμικού Μοντέλα εκτίμησης κόστους Μοντέλα εκτίμησης προσπάθειας Συμβόλαιο εξωτερικής ανάθεσης Συμφωνητικό παροχής υπηρεσιών Μετρικές ποιότητας λογισμικού Μοντέλα διαδικασιών συντήρησης Λογισμικό ανοικτού κώδικα Software maintenance Cost estimation models Effort estimation models Outsourcing contract Service Level Agreements (SLAs) Software quality metrics Maintenance process models Open source software

Λέξη κλειδί :

Συντήρηση λογισμικού
Μοντέλα εκτίμησης κόστους
Μοντέλα εκτίμησης προσπάθειας
Συμβόλαιο εξωτερικής ανάθεσης
Συμφωνητικό παροχής υπηρεσιών
Μετρικές ποιότητας λογισμικού
Μοντέλα διαδικασιών συντήρησης
Λογισμικό ανοικτού κώδικα
Software maintenance
Cost estimation models
Effort estimation models
Outsourcing contract
Service Level Agreements (SLAs)
Software quality metrics
Maintenance process models
Open source software

Ημερομηνία :	29-02-2012

Άδεια χρήσης :

Αρχείο: Martsoukos_2012.pdf

Τύπος: application/pdf

Είσοδος