6th Hellenic Conference in Computing, Athens 4-6 December 1997, pp.

6th Hellenic Conference in Computing, Athens 4-6 December 1997, pp. Μοντέλο Ωρίµανσης υνατοτήτων Λογισµικού Capability Maturity Model (CMM) Προσέγγιση Ελληνικών Επιχειρήσεων Κέρστιν Β. Σιάκα και Φίλιππος Χ#Αναστασίου ΤΕΙ Θεσσαλονίκης, Τµήµα πληροφορικής Τ.Θ. 145 61, Τ.Κ. 541 01 Θεσσαλονίκη Τηλ.: 031/791.296 Φαξ: 031/791.290 e-mail:siaka@it.teithe.gr Ερευνητική εργασία Λέξεις Κλειδιά: Εκτίµηση Ποιότητας Λογισµικού, Software Quality Management, Capability Maturity Model, CMM

Μοντέλο Ωρίµανσης υνατοτήτων Λογισµικού Capability Maturity Model (CMM) Προσέγγιση σε Ελληνικές Επιχειρήσεις ΠΕΡΙΛΗΨΗ Το Capability Maturity Model (CMM) είναι ένα µοντέλο εκτίµησης ποιότητας λογισµικού που αναπτύχθηκε από το µηχανολογικό λογισµικό ινστιτούτο (SEI - Software Engineering Institute) [3,8,9,13]. O στόχος ήταν να βοηθηθεί η Αµερικάνικη Αεροπορία να επιλέξει ικανές υπηρεσίες ανάπτυξης λογισµικού. Το SEI προτείνει πέντε επίπεδα ωρίµανσης, όπου το κάθε ένα επίπεδο πρέπει να είναι εδραιωµένο πριν η ανάπτυξη του επόµενου επιχειρηθεί. Για την εκτίµηση του επιπέδου ωρίµανσης προτείνει το CMM έναν κατάλογο από ελέγχους και δίνει την βαθµολογία της µηχανικής συµπεριφοράς σε µία συγκεκριµένη εργασία ή οργάνωση. Προτείνει επίσης κατευθυντήριες γραµµές διεξαγωγής της διαδικασίας εκτίµησης. Το µοντέλο αυτό εξαρτάται από κύριες περιοχές λειτουργίας (key process areas), όπου κάθε περιοχή / τοµέας εµπεριέχει κύριες πρακτικές (practices) οι οποίες πρέπει να εφαρµόζονται για να µπορέσει το µοντέλο να ανιχνεύσει ένα συγκεκριµένο επίπεδο ωρίµανσης. Για την εκτίµηση του επιπέδου ωρίµανσης το SEI έχει αναπτύξει ένα ερωτηµατολόγιο, το οποίο µεταφράσαµε και χρησιµοποιήσαµε σε δύο Ελληνικές Εταιρίες, οι οποίες αναπτύσσουν λογισµικό, για να ανακαλύψουµε το επίπεδο της ποιότητας λογισµικού στην Ελληνική Επιχείρηση. 1. ΕΙΣΑΓΩΓΗ Το λογισµικό παίζει σήµερα καίριο ρόλο σε όλους σχεδόν τους τοµείς της ανθρώπινης κοινωνίας και οικονοµίας. Συχνότατα, η αξιοπιστία του λογισµικού είναι ο κρίσιµος παράγοντας για την οµαλή λειτουργία συστηµάτων, όπου µπορούν να υπάρξουν καταστρεπτικές συνέπειες από τυχόν λειτουργικές ανωµαλίες. Τα προβλήµατα αυτά ανάγονται σε τελευταία ανάλυση, σε προβλήµατα ποιότητας, τα οποία µπορούν να λυθούν µε επαρκή διασφάλιση και βελτίωση της ποιότητας, βελτίωση της διεργασίας, και διαχείριση των διαδικασιών. Σύµφωνα µε τους Oskarsson και Glass [7] το CMM ανταγωνίζεται το ΙSO9001 στην ανάπτυξη λογισµικού. Το CMM βασίζεται στην θεωρία της Ολικής Ποιότητας [8]. Κατά την γνώµη µας είναι καλό όταν µια επιχείρηση θέλει να ξεκινήσει ένα σύστηµα ποιότητας, πρώτα να χρησιµοποιήσει τα διάφορα µοντέλα ποιότητας, όπως CMM, Bootstrap [4] ή SPICE [3], για να ξέρει που βρίσκεται και ποιοι τοµείς είναι προβληµατικοί. Χρησιµοποιώντας ένα από αυτά τα µοντέλα γίνεται πρώτα µια έρευνα της 2

υπάρχουσας κατάστασης και η επιχείρηση κατατάσσεται σε ένα επίπεδο που περιγράφεται στο ανάλογο µοντέλο. Τα επίπεδα ωριµότητας καθορίζονται ανάλογα µε το πόσο µια επιχείρηση λειτουργεί σύµφωνα µε διεθνείς προδιαγραφές, οδηγίες και καθορισµένα πρότυπα. Σ' αυτή την δηµοσίευση περιγράφουµε µια πειραµατική έρευνα η οποία κατατάσσει δύο µεγάλες Ελληνικές επιχειρήσεις στον τοµέα της πληροφορικής, σύµφωνα µε το µοντέλο ωριµότητας CMM, σ' ένα επίπεδο και προσδιορίζει συγχρόνως τα αδύνατα σηµεία των επιχειρήσεων. 2. ΙΑ ΙΚΑΣΙΑ ΒΕΛΤΙΩΣΗΣ ΛΟΓΙΣΜΙΚΟΥ Για τη βελτίωση της διαδικασίας του λογισµικού, ο οργανισµός πρέπει να ακολουθεί τα παρακάτω βήµατα σύµφωνα µε το CMM [5]: 1. Κατανόηση της τρέχουσας κατάστασης 2. Ανάπτυξη ενός οράµατος της επιθυµητής διαδικασίας 3. ηµιουργία καταλόγου απαιτούµενων ενεργειών για βελτίωση διαδικασιών κατά σειρά και κατά προτεραιότητα 4. ηµιουργία ενός πλάνου για την εκτέλεση της απαιτούµενης δράσης 5. έσµευση πόρων για την εκτέλεση του πλάνου 6. Επανάληψη από το πρώτο βήµα 3. ΕΠΙΠΕ Α ΙΑ ΙΚΑΣΙΑΣ ΩΡΙΜΑΝΣΗΣ Το CMM αποτελείται από πέντε επίπεδα όπως φαίνεται στο σχήµα 1. Αυτά παρουσιάζονται αναλυτικά παρακάτω: L5 Βελτιστοποίησης (Optimizing) L4 ιευθυνόµενο (Managed) L3 Ορισµένο (Defined) L2 Επαναλαµβανόµενο (Repeatable) L1 Αρχικό (Initial) Βασικός ιοικητικός Έλεγχος Καθορισµός ιαδικασίας Μέτριση ιαδικασίας Έλεγχος ιαδικασίας Σχήµα 1: Τα πέντε επίπεδα του CMM 3

3.1 ΑΡΧΙΚΟ ΕΠΙΠΕ Ο (Initial / Level 1 / L1) Το αρχικό επίπεδο µπορεί να καλείται χαώδες (ad hoc). Σ' αυτό το επίπεδο οι τυπικοί χειρισµοί δεν είναι οργανωµένοι µε διαµορφωµένες διαδικασίες, δεν υπάρχει εκτίµηση κόστους (προϋπολογισµός), µελέτη σκοπιµότητας και σχέδια. Βοηθήµατα και εργαλεία δεν είναι σταθερά εφαρµοσµένα, ολοκληρωµένα ή πλήρες οµοιόµορφα. Ο έλεγχος αλλαγών είναι χαλαρός και απρόσεχτος και αυτό έχει σαν αποτέλεσµα την µη κατανόηση των προβληµάτων και αυτό µε την σειρά του οδηγεί την εταιρία συχνά σε αδιέξοδο. Εφόσον πολλά προβλήµατα που πρέπει να λυθούν αναβάλλονται ή ακόµη και ξεχνιούνται, η λογισµική εγκατάσταση και υποστήριξη συχνά παρουσιάζει σοβαρά προβλήµατα και τυχόν επιτυχίες εξαρτώνται απο άτοµα και ήρωες [8]. Αν και η οργάνωση σ' αυτό το επίπεδο µπορεί να έχει τυπικές διαδικασίες, σχεδιασµό και παρακολούθηση του έργου της, δεν υπάρχει διευθυντικός µηχανισµός ο οποίος εξασφαλίζει ότι αυτές χρησιµοποιούνται. Ο καλύτερος τρόπος διαπίστωσης αυτής της κατάστασης είναι να παρακολουθείται πώς κάθε οργάνωση συµπεριφέρεται σε µια κρίση. Ο Humphrey [5] θεωρεί ότι η κύρια αιτία σύµφωνα µε την οποία η οργάνωση λειτουργεί µε χαώδης τρόπο είναι ότι δεν υπάρχει η εµπειρία από το όφελος της χρήσης της διαδικασίας ωρίµανσης και έτσι δεν γίνονται κατανοητές οι συνέπειες αυτής της κατάστασης. Επειδή πολλές λογισµικές ενέργειες, όπως σχεδιασµός, εξέταση του κώδικα ή έλεγχος δεδοµένων ανάλυσης, δεν παρουσιάζουν άµεση βελτίωση στο προϊόν θεωρούνται µη χρήσιµα. Στο λογισµικό η κωδικοποίηση και ο έλεγχος δείχνουν πιθανή πρόοδο, αλλά αυτά και µόνο δεν αρκούν. Χωρίς πλάνο και συλλογισµένη ανάλυση των προβληµάτων οδηγείτε η επιχείρηση σε αδιέξοδο. Η βελτίωση της οργάνωσης στο αρχικό επίπεδο, µε την εδραίωση ενός προγράµµατος ελέγχου, µπορεί να επιφέρει βελτίωση στις λειτουργίες. Το πιο σηµαντικό είναι το πρόγραµµα ελέγχου της διεύθυνσης. Βασικό ρόλο στο πρόγραµµα ελέγχου της διεύθυνσης παίζει η διασφάλιση αποτελεσµατικού ελέγχου των δεσµεύσεων. Αυτό απαιτεί κατάλληλη προεργασία, καθαρές υπευθυνότητες, καθολική ενηµέρωση και καθιερωµένες εκτελέσεις. Επίσης για την βελτίωση της οργάνωσης απαιτούνται ο έλεγχος παραλείψεων, η διασφάλιση ποιότητας και ο έλεγχος αλλαγών. Για το λογισµικό το πρόγραµµα ελέγχου της διεύθυνσης ξεκινά µε µια κατανόηση του µεγέθους σπουδαιότητας του έργου. Σε κάθε έργο πρέπει να υπάρχει ένα πλάνο, το οποίο να καθορίζει το χρονοδιάγραµµα και να προκαταλαµβάνει τους απαιτούµενους πόρους. Μια κατάλληλη, πειθαρχηµένη οργάνωση λογισµικής ανάπτυξης πρέπει να έχει µια κύρια διευθυντική εποπτεία. Αυτή περιλαµβάνει επιθεώρηση και έγκριση για όλα τα κύρια αναπτυξιακά πλάνα, πριν την επίσηµη δέσµευση των πόρων. Επίσης, µια τρίµηνη επιθεώρηση προτείνεται από τον Humphrey [5], η οποία πρέπει να είναι διευθυνόµενη και ελεγχόµενη. Η τρίµηνη επιθεώρηση ελέγχει αν επιτεύχθηκαν οι στόχοι του χρονοδιαγράµµατος, του κόστους, της ποιότητας και της παραγωγικότητας του έργου. Η έλλειψη 4

µιας τέτοιας επιθεώρησης έχει σαν συνέπεια ανόµοια αποτελέσµατα και γενικά ανεπαρκή εφαρµογή, καθώς επίσης συχνά και υπερδεσµεύσεις και υψηλό κόστος. Η οµάδα διασφάλισης ποιότητας επιβλέπει ότι το λογισµικό έργο γίνεται σύµφωνα µε τον τρόπο που σχεδιάστηκε να γίνει. Για να είναι αποτελεσµατική η οµάδα διασφάλισης ποιότητας, πρέπει να έχει µια ανεξάρτητη, αυτοκέφαλη γραµµή αναφοράς - έκθεσης στην κύρια διεύθυνση, και αρκετά µέσα, για να παρακολουθεί την εκτέλεση όλων των κύριων πλάνων, εφαρµογών και επαλήθευσης της δράσης. Αυτό γενικά αποτελεί µια οργάνωση της τάξης του 3% µε 6% του µεγέθους της συνολικής οργάνωσης λογισµικού. Ο έλεγχος αλλαγών λογισµικού έχει άµεση επίδραση στα οικονοµικά της επιχείρησης επίσης και στην τεχνική σταθερότητα. Οι απαιτήσεις πρέπει να είναι εδραιωµένες πάνω σε ένα προβλέψιµο χρονοδιάγραµµα - πρόγραµµα και να υποστηρίζονται µε σταθερότητα σε όλη την διάρκεια του κύκλου ανάπτυξης. 3.2. ΕΠΑΝΑΛΑΜΒΑΝΟΜΕΝΟ ΕΠΙΠΕ Ο (Repeatable / Level 2 / L2) Το επαναλαµβανόµενο επίπεδο παρέχει έλεγχο πάνω στον τρόπο εδραίωσης των πλάνων της οργάνωσης και των δεσµεύσεων. Έχει κατορθωθεί επίσης ένας βαθµός από στατιστικό έλεγχο. Υπάρχει η απαιτούµενη πυθαρχία της διαδικασίας για να µπορούν να επαναλαβάνονται προηγούµενες επιτυχίες παροµίων εφαρµογών. Οι κύριες ενέργειες για µετάβαση από το επαναλαµβανόµενο (L2) στο ορισµένο επίπεδο (L3), είναι η εδραίωση µιας οµάδας λειτουργίας (process group), η εδραίωση µιας αρχιτεκτονικής της διαδικασίας ανάπτυξης (development process architecture) και η εισαγωγή µεθόδων µηχανικής λογισµικού (software engineering methods). Η οµάδα λειτουργίας (process group) χειρήζεται ένα σύνολο από τεχνικά µέσα / διαδικασίες που εστιάζονται αποκλειστικά στην βελτίωση της λειτουργίας λογισµικού. Τα καθήκοντα της οµάδας λειτουργίας περιλαµβάνουν καθορισµό της διαδικασίας ανάπτυξης, προσδιορισµό των τεχνολογικών αναγκών και ευκαιριών, συµβουλή / καθοδήγηση των εργασιών και διεξαγωγή τρίµηνης διευθυντικής επιθεώρησης για την κατάσταση της εκτέλεσης του λογισµικού έργου. Το µέγεθος της οµάδας λειτουργίας πρέπει να είναι της τάξης του 1% µε 3% του συνολικού µεγέθους της λογισµικής οργάνωσης σύµφωνα µε τον Humphrey[5]. Μια αρχιτεκτονική της διαδικασίας ανάπτυξης ή κύκλου ζωής (development process architecture) ανάπτυξης περιγράφει τις απαιτούµενες τεχνικές και διευθυντικές ενέργειες, για σωστή εκτέλεση της διαδικασίας ανάπτυξης. Αυτή η διαδικασία πρέπει να είναι προσαρµοσµένη στις ειδικές ανάγκες της οργάνωσης και εξαρτώµενη από το µέγεθος και τη σηµαντικότητα του έργου καθώς επίσης και από την τεχνική φύση του έργου της. Η αρχιτεκτονική είναι µια δοµηµένη αποσύνθεση του κύκλου ανάπτυξης σε εργασίες, κάθε µια από τις οποίες έχει ένα καθορισµένο σετ από προϋποθέσεις, περιγραφές λειτουργιών, διαδικασίες επιβεβαίωσης και προδιαγραφές ολοκλήρωσης του έργου. Η αποσύνθεση συνεχίζεται έως ότου κάθε καθορισµένη εργασία εκτελεστεί από µια µεµονωµένη / ξεχωριστή µονάδα διεύθυνσης. 5

Οι µέθοδοι µηχανικής λογισµικού (software engineering methods) περιλαµβάνουν επιθεώρηση σχεδιασµού και κώδικα, τυπικές µεθόδους σχεδιασµού, βιβλιοθήκη ελέγχου συστήµατος και επεξήγηση µεθόδων ελέγχου. 3.3. ΟΡΙΣΜΕΝΟ ΕΠΙΠΕ Ο (Defined / Level 3 / L3) Με το ορισµένο επίπεδο ο οργανισµός έχει κατορθώσει την βάση για σηµαντική και συνεχής πρόοδο. H διαδικασία λογισµικού ειναι τεκµηριωµένη, τυπωποιηµένη και προσαρµένη για την οργάνωση. Όλες οι οµάδες ανάπτυξης λογισµικού χρησιµοποιούν την ίδια εγγριµένη διαδικασία ανάπτυξης και συντήρισης λογισµικού. Για παράδειγµα, οι οµάδες ανάπτυξης λογισµικού, όταν βρεθούν αντιµέτωπες µε µια κρίση, συνεχίζουν να εκτελούν την διαδικασία όπως έχει ορισθεί. Η βάση για την εξέταση της προόδου έχει τώρα εδραιωθεί και µελετάται πώς θα βελτιωθεί. Η δύναµη του ορισµένου επιπέδου είναι ότι το επίπεδο αυτό είναι µοναδικά ποιοτικό: υπάρχουν δεδοµένα που αποδεικνύουν πόσο ολοκληρωµένο / πλήρες είναι και πόσο αποτελεσµατικό. Υπάρχουν αξιόλογες µελέτες σχετικά µε την αξία της λογισµικής διαδικασίας µέτρησης και για το ποια στοιχεία πρέπει να χρησιµοποιούνται. Με το ορισµένο επίπεδο µπορούµε να εστιάσουµε σε µετρήσεις πάνω σε ιδιαίτερες εργασίες. Η αρχιτεκτονική της διαδικασίας ανάπτυξης είναι κατά συνέπεια µια ουσιώδης προϋπόθεση για αποτελεσµατική µέτρηση. Τα κύρια βήµατα για να προχωρήσουµε από το ορισµένο επίπεδο (L3) στο διευθυνόµενο (L4) είναι σύµφωνα µε τον Paulk [8]: 1. Η εδραίωση ενός ελάχιστου βασικού σετ από λειτουργίες µέτρησης που προσδιορίζουν την ποιότητα και το κόστος κάθε έργου. Το αντικείµενο είναι το ύψος του σχετικού κόστους και το όφελος από κάθε δραστηριότητα, καθώς επίσης το κόστος και το αποτέλεσµα από κάθε λάθος αναζήτηση και επανόρθωση των µεθόδων. 2. Εδραίωση µιας βάσης δεδοµένων µε στοιχεία για το πως χρησιµοποιούνται οι καθωρισµένες διαδικασίες σε όλα τα έργα του οργανισµού και τα µέσα για διεύθυνση και υποστήριξη αυτής. Το κόστος και η απόδoση των δεδοµένων πρέπει να βρίσκονται κάτω από συνεχή επίβλεψη, έτσι ώστε αυτά να είναι εύκολα διαθέσιµα για όλα τα έργα και για διευκόλυνση της λειτουργίας ανάλυσης της παραγωγικότητας και της ποιότητας. 3. Παροχή επαρκών µέσων / εργαλείων για συλλογή των δεδοµένων, υποστήριξη της λειτουργίας τους και συµβουλή των µελών του έργου πάνω στο πώς θα τα χρησιµοποιούν. Καθορισµός ικανών ατόµων για παρακολούθηση της ποιότητας των δεδοµένων, πριν εισαχθούν στη βάση και παροχή οδηγιών πάνω στις µεθόδους ανάλυσης. 4. Εκτίµηση της σχετικής ποιότητας κάθε προϊόντος και ενηµέρωση της διεύθυνσης για το που οι στόχοι ποιότητας δεν επιτεύχθηκαν. Μια ανεξάρτητη οµάδα διασφάλισης ποιότητας πρέπει να εκτιµά την ποιότητα των ενεργειών που αφορούν κάθε έργο και να ανιχνεύει την εξέλιξη σύµφωνα µε το πλάνο. Όταν αυτή η εξέλιξη είναι συγκρίσιµη µε παρόµοιες εργασίες, µια πληροφοριακή εκτίµηση µπορεί γενικά να δηµιουργηθεί. 6

3.4. ΙΕΥΘΥΝΟΜΕΝΟ ΕΠΙΠΕ Ο (Managed / Level 4 / L4) Λεπτοµερείς µετρίσεις της ποιότητας της διαδικασίας λογισµικού και της ποιότητας των προϊόντών γίνονται σε αυτό το επίπεδο. Η διαδικασία ανάπτυξης λογισµικού είναι σαφής και αντιλυπτή απο όλους στον οργανισµό. Τόσο η διαδικασία ανάπτυξης λογισµικού όσο και τα προϊόντα είναι υπό έλεγοχο. Στην πορεία εξέλιξης από το αρχικό επίπεδο (L1) µέχρι και το επαναλαµβανόµενο (L2), το ορισµένο (L3) και το διευθυνόµενο επίπεδο (L4) της οργάνωσης λογισµικού, προσδοκάται η επίτευξη σηµαντικής βελτίωσης της ποιότητας. Το µεγαλύτερο πρόβληµα στο διευθυνόµενο επίπεδο είναι το κόστος της συλλογής των δεδοµένων. Υπάρχει ένας µεγάλος αριθµός πολύτιµων µετρήσεων λογισµικής λειτουργίας, οι οποίες µπορούν να υιοθετηθούν από τον οργανισµό, αλλά η συλλογή των δεδοµένων είναι συνήθως πολύ δαπανηρή. Η προσέγγιση της συλλογής δεδοµένων πρέπει να γίνεται µε προσοχή. Όταν διαφέρουν οι οµάδες συλλεγόµενων δεδοµένων και δεν χρησιµοποιούν ταυτόσηµους ορισµούς, τα αποτελέσµατα δεν είναι συγκρίσιµα. Η επεξεργασία δεδοµένων δεν πρέπει να χρησιµοποιείται για να συγκρίνει εργασίες ή προσωπικό. Ο σκοπός της είναι να "διακοσµεί" το προϊόν που βρίσκεται υπό ανάπτυξη και να παρέχει µια πληροφοριακή βάση για βελτίωση της λειτουργίας. Όταν τέτοια δεδοµένα χρησιµοποιούνται από την διεύθυνση για εκτίµηση προσωπικού ή οµάδων, η αξιοπιστία των ίδιων των δεδοµένων φθείρεται. Τα κύρια βήµατα για την µετάβαση από το διευθυνόµενο επίπεδο στο επίπεδο βελτιστοποίησης είναι σύµφωνα µε τον Paulk [ 8]: 1. Υποστήριξη αυτόµατης λειτουργίας συλλογής δεδοµένων. 2. Βελτιστοποίηση διαδικασίας αλλάζοντας την εστίαση της διεύθυνσης από το προϊόν στην διαδικασία. 3.5. ΕΠΙΠΕ Ο ΒΕΛΤΙΣΤΟΠΟΙΗΣΗΣ (Optimizing / Level 5 / L5) Συνεχή βελτίωση της διαδικασίας ανάπτυξης λογισµικού γίνεται σε αυτό το τελευταίο επίπεδο. Η συνεχή βελτίωση βασίζεται στην µελέτη στατιστικών στοιχείων της µετρικής διαδικασίας, στις καινούργιες τεχνολογίες και πρωτοποριακές ιδεές. Σε διαφορετικό βαθµό, η λειτουργία βελτιστοποίησης εργάζεται σ' όλα τα επίπεδα της διαδικασίας ωρίµανσης. Το βήµα από το διευθυνόµενο επίπεδο (L4) στο επίπεδο βελτιστοποίησης (L5), οπωσδήποτε αποτελεί ένα δείγµα µετακίνησης / εξέλιξης. Σ' αυτό το σηµείο οι διευθυντές ανάπτυξης λογισµικού έχουν µεγαλύτερη εστίαση πάνω στα δικά τους παράγωγα και ζητούν τυπική συλλογή και ανάλυση µόνο σε δεδοµένα, τα οποία απευθείας συσχετίζονται µε την βελτίωση των προϊόντων τους. Με την λειτουργία βελτιστοποίησης η οργάνωση έχει σκοπό να εντοπίσει τα αδύναµα σηµεία της και να τα επιδιορθώσει. Σ' αυτό το 7

επίπεδο τα δεδοµένα είναι διαθέσιµα να δικαιώσουν την τεχνολογία που επιλέχθηκε στην εφαρµογή, που ποικίλει για κάθε έργο. Η λειτουργία βελτιστοποίησης βοηθά τους διευθυντές να κατανοούν, που η βοήθεια είναι αναγκαία και πως αυξάνεται η αποδοτικότητα των εργαζοµένων µε την υποστήριξη των δικών τους αναγκών. Επιτρέπει τα άτοµα στον οργανισµό να επικοινωνούν µε ποιοτικούς και ποσοτικούς όρους. Παρέχει µια δοµή, ώστε τα άτοµα να κατανοούν την εργασία που πρέπει να εκτελέσουν, αλλά και τον τρόπο, για να την βελτιώσουν. 4. ΟΙ ΒΑΣΙΚΕΣ ΑΡΧΕΣ ΣΤΗΝ ΑΛΛΑΓΗ ΤΗΣ ΛΟΓΙΣΜΙΚΗΣ ΙΑ ΙΚΑΣΙΑΣ Οι έξι βασικές αρχές που πρέπει να ισχύουν σύµφωνα µε τον Humphrey [5] στην αλλαγή της λογισµικής διαδικασίας είναι: 1. Οι κύριες αλλαγές στην λογισµική λειτουργία πρέπει να ξεκινούν από την κορυφή. 2. Κάθε ένας πρέπει να συµµετέχει. 3. Αποτελεσµατικές αλλαγές απαιτούν γνώση της τρέχουσας κατάστασης. 4. Οι αλλαγές πρέπει να είναι συνεχείς και να επεκτείνονται. 5. Η διαδικασία αλλαγών στην λογισµική λειτουργία δεν µπορεί να διατηρηθεί χωρίς συνειδητή προσπάθεια και περιοδική ενίσχυση. 6. Η βελτίωση της λογισµικής λειτουργίας απαιτεί επενδύσεις. 5. ΙΕΥΘΥΝΟΝΤΑΣ ΤΑ ΕΠΙΠΕ Α ΩΡΙΜΑΝΣΗΣ 5.1. ΙΕΥΘΥΝΟΝΤΑΣ ΤΟ ΕΠΙΠΕ Ο ΕΝΑ (L1) Η διεύθυνση µιας λειτουργίας λογισµικού εξαρτάται από το επίπεδο ωρίµανσης. Για κάθε επίπεδο η διεύθυνση βασικά ωθεί την µετάβαση προς το επόµενο επίπεδο. Εάν η λειτουργία αυτή βρίσκεται στον πάτο της διαβάθµισης του επιπέδου ένα, δηλαδή χωρίς εδραιωµένο σχεδιασµό ή χωρίς µεθόδους διεύθυνσης, µπορεί είτε να βρει κάποια άλλη οµάδα για την ανάπτυξη λογισµικού, είτε να επιβάλλει στην ήδη υπάρχουσα οµάδα πειθαρχία µέσω συµβολαίου ή διευθυντικού διατάγµατος. Τα κρίσιµα βήµατα είναι: 1. Εγκατάσταση ενός συστήµατος επιθεώρησης διεύθυνσης. Αυτό περιλαµβάνει την κύρια διεύθυνση και διασφαλίζει ότι τα πλάνα είναι παραγόµενα και παρακολουθούνται καθ' όλη την διάρκεια της ανάπτυξης του λογισµικού. 2. Εµµονή πάνω σε ένα περιεκτικό / πλήρες πλάνο ανάπτυξης. Αυτό πρέπει να ακολουθεί το βασικό διάγραµµα, συµπεριλαµβάνοντας εκτιµήσεις µεγέθους κώδικα και εκτιµήσεις πόρων. 3. Τακτοποίηση / οργάνωση µιας λειτουργίας ιεύθυνσης ιαµόρφωσης Λογισµικού (SCM- Software Configuration Management). Αυτό είναι κρίσιµο για την διατήρηση του ελέγχου και πρέπει να είναι στην κατάλληλη λειτουργία πριν την ολοκλήρωση του λεπτοµερειακού 8

σχεδιασµού. Επίσης αυτές οι λειτουργίες πρέπει να είναι επεκτεινόµενες για να συµπεριλαµβάνουν απαιτήσεις και σχεδιασµό. 4. Εξασφάλιση ότι η οργάνωση ιασφάλισης Ποιότητας Λογισµικού (SQA-Software Quality Assurance) είναι εδραιωµένη και επαρκώς στελεχωµένη για επιθεώρηση ενός λογικού δείγµατος των προϊόντων εργασίας. Μέχρις ότου υπάρξει η απόδειξη ότι το έργο είναι κατασκευασµένο σύµφωνα µε το πλάνο, είναι σηµαντική µία 100% επιθεώρηση. Με επιτυχή εµπειρία η δειγµατοληψία επί της εκατό µπορεί να µειωθεί. 5. Εφαρµογή των αρχών του διαγράµµατος, εδραίωση πινάκων ποσοστών (rate sharts) για ανίχνευση του πλάνου και χρησιµοποίηση κύριων ορόσηµων πλάνων (milestones) µε προσδοκούµενους πόρους δαπάνης / κατανάλωσης. Τυπικά τα ορόσηµα πλάνα είναι ολοκληρωµένες απαιτήσεις και εγκεκριµένες, εγκεκριµένη και επιθεωρηµένη ιδέα λειτουργίας, ολοκληρωµένος και εγκεκριµένος υψηλού επιπέδου σχεδιασµός. Παρόµοια, πίνακες ποσοστών µπορεί να είναι εδραιωµένοι για κάθε φάση του ελέγχου. 6. Μέχρι η οργάνωση του πρώτου επιπέδου αποδείξει την ικανότητά της για εκτέλεση του πλάνου, το παραδοσιακό σύστηµα διεύθυνσης πρέπει να διατηρηθεί µε οποιοδήποτε τρόπο. Αυτό είναι σηµαντικό για να εξασφαλίσει ότι κάθε νέο σύστηµα διεύθυνσης εργάζεται πριν την εγκατάλειψη του παλιού. 5.2. ΙΕΥΘΥΝΟΝΤΑΣ ΤΟ ΕΠΙΠΕ Ο ΥΟ (L2) Στο επίπεδο δύο, η λειτουργία διεύθυνσης παρακινεί την οργάνωση να βελτιώσει την λειτουργία ωρίµανσης της. Η αιτία για παρακίνηση της βελτίωσης πέρα από τον εντυπωσιασµό και την επιβλητικότητα είναι ότι η οργάνωση είναι λογικά εκλεπτυσµένη και έχει πολλές εφαρµογές να εκτελέσει. Εκτός των βασικών στοιχείων που εξετάσθηκαν στο χαµηλότερο επίπεδο ωρίµανσης, πρέπει να είναι προσεγµένα και τα ακόλουθα στοιχεία: 1. Επιθεώρηση του προσωπικού της ιασφάλισης Ποιότητας Λογισµικού (SQA) για να οριστεί εάν αυτό είναι ικανοποιητικό / επαρκές στον χειρισµό του προβλεπόµενου φορτίου εργασίας. Ενώ πολλές οργανώσεις λογισµικού έχουν λειτουργίες SQA, αυτές είναι συχνά διεσπαρµένα / σποραδικά στελεχωµένες και µπορούν να επιθεωρήσουν µόνο ένα µικρό ποσοστό του έργου. 2. Εξασφάλιση ότι η λειτουργία ιεύθυνσης ιαµόρφωσης Λογισµικού (SCM) χρησιµοποιείται, για να ελέγχει την δηµιουργία του προϊόντος σε όλη την διάρκεια της ανάπτυξής του και όχι µόνο κατά την διάρκεια του ελέγχου αποδοχής / έγκρισης του τελικού προϊόντος. 3. Εδραίωση κάποιων κύριων λειτουργιών και πρότυπων προϊόντων, όπως σχεδιασµός, κωδικοποίηση, έλεγχος και επιθεώρηση. 4. Εξασφάλιση ότι η επιθεώρηση του σχεδιασµού και του κώδικα είναι θεσπισµένη. 5. Εδραίωση µιας οµάδας λειτουργίας µηχανικής λογισµικού (SEPG / Software Engineering Process Group) για να υποστηρίζει το έργο. 6. Μέχρις ότου η SEPG εδραιωθεί, οι παραδοσιακοί µέθοδοι διεύθυνσης πρέπει να διατηρούνται, τουλάχιστον στις περισσότερες περιπτώσεις. Εφόσον οι παραδοσιακοί προσδιορισµοί και επιθεωρήσεις υπηρετούν ένα χρήσιµο αντικείµενο στο χαµηλό επίπεδο οργάνωση ωρίµανσης, 9

ο συνδυασµός τους µε µια οµάδα λειτουργίας µηχανικής λογισµικού παρέχει µια πολύ µεγαλύτερη εγγύηση ότι µια αποτελεσµατική εργασία εκτελείται. 5.3. ΙΕΥΘΥΝΟΝΤΑΣ ΤΟ ΕΠΙΠΕ Ο ΤΡΙΑ ΩΡΙΜΑΝΣΗΣ (L3) ΚΑΙ ΠΑΝΩ Στο επίπεδο τρία και πάνω η οργάνωση είναι αποτελεσµατική διευθύνοντας τις δικές της λειτουργίες. Η βασική επιτήρηση που είναι αναγκαία, είναι η εξασφάλιση της ενηµέρωσης της κατάστασης και η διατήρηση µιας έµφασης πάνω στην εκτενέστερη βελτίωση της λειτουργίας. Οι κύριες περιοχές για εστίαση είναι: 1. Εδραίωση ενός περιεκτικού / εκτεταµένου προγράµµατος µε λειτουργία µέτρησης και ανάλυσης. Αυτά τα δεδοµένα διατηρούνται σε µια βάση δεδοµένων και µε την χρήση της SQA και της SEPG οι διευθυντές του έργου παρακολουθούν την ποιότητα των προϊόντων και των εργασιών. 2. Εξασφάλιση ότι τα κατάλληλα ποσοτικά πλάνα ποιότητας είναι εδραιωµένα και παρακολουθούµενα. Όταν αυτά τα πλάνα αρχίζουν να µην καλύπτουν, διορθωτικά πλάνα δράσης είναι απαιτούµενα. 3. Ξεκίνηµα ενός εκτεταµένου προγράµµατος λήψης προστασίας. 4. Εδραίωση µιας στρατηγικής και ενός πλάνου για υποστήριξη του περιβάλλοντος λειτουργίας. 6. ΣΥΣΧEΤΗΣΗ ΑΝΑΜEΣΑ ΣΤΟ ΙSO9001 ΚΑΙ ΤΟ CMM Έχουν δηµοσιευθεί διάφορα άρθρα, τα οποία συζητούν την συσχέτιση ανάµεσα στο ΙSO9001 και το CMM [1,2,10,12]. Στα περισσότερα αναφέρεται ότι µια οργάνωση που έχει αποκτήσει ISO πιστοποίηση απαιτείται να βρίσκεται στο δεύτερο επίπεδο σύµφωνα µε το µοντέλο CMM. Υπάρχουν εξαιρέσεις από τον κανόνα [6], αλλά αυτές συνήθως εµφανίζονται σε οργανισµούς που µόλις έχουν ξεκινήσει ένα σύστηµα ποιότητας λογισµικού. Οι σηµαντικότερες διαφορές µεταξύ του ΙSO9001 και του CMM αναφέρονται παρακάτω: ΙSO µοντέλο: Η κύρια σηµασία του µοντέλου ISO είναι το γεγονός πως παρέχει στους οργανισµούς καθοδήγηση στο τι να συµπεριλάβουν στην ποιότητά τους, για να επιτύχουν συµβιβασµό µε τις απαιτήσεις του ISO9001. Το µοντέλο δεν αναφέρει τίποτα για το ποιες µεθόδους θα πρέπει να χρησιµοποιήσουν οι οργανισµοί, για να ικανοποιήσουν τις απαιτήσεις αυτές - η επιλογή µεθόδου για εγκατάσταση ενός συστήµατος ποιότητας αφήνεται αποκλειστικά στον συγκεκριµένο οργανισµό. CMM: Εκτός από το να δίνει έναν ορισµό του πως θα πρέπει να είναι η πρότυπη λειτουργία σε έναν οργανισµό, παρέχει στον οργανισµό µια καλή βοήθεια ως προς τον τρόπο µε τον οποίο θα πρέπει να καθοδηγηθεί η βελτίωση. Τα επίπεδα ωριµότητας και οι περιοχές κυρίας λειτουργίας για µετάβαση ανάµεσα στα επίπεδα ωρίµανσης, ευρέως διευκολύνουν την διαδικασία εγκαθίδρυσης µιας πρότυπης λειτουργίας και την διατήρηση / υποστήριξη αυτής. 10

Ο Rozman et.al. [11] σηµειώνουν ότι το µοντέλο ISO διαπραγµατεύεται µε τα συστήµατα διεύθυνσης ποιότητας, ενώ το CMM ασχολείται κυρίως µε την λειτουργία ανάπτυξης του λογισµικού. Η σύγκριση των δύο µοντέλων είναι δύσκολη λόγω του γεγονότος ότι το ISO µοντέλο είναι γραµµένο σε µορφή κειµένου, στο οποίο η εξήγηση του νοήµατος ενός ορισµένου τοµέα και των αντικειµένων του, διαδικασίες και τεκµηριώσεις που πρόκειται να περιληφθούν σε ένα συγκεκριµένο τοµέα, είναι συµπλεκόµενα, ενώ αντίθετα το CMM ορίζεται αρκετά τυπικά, έτσι ώστε όλοι οι τοµείς λειτουργίας να είναι ορισµένοι µε ακρίβεια από τα κοινά τους χαρακτηριστικά (στόχοι, δεσµεύσεις για εκτέλεση, δυνατότητα για εκτέλεση, ενέργειες για εκτέλεση, µέτρηση και αναλύσεις, επιβεβαίωση εφαρµογής). Στο εγχειρίδιο λειτουργίας για το CMM κάθε ένα από τα κοινά χαρακτηριστικά είναι ακόµη πιο ακριβές παρουσιασµένο και επιπλέον επεξηγηµένο µε διάφορα παραδείγµατα. Οι Oskarsson και Glass [7] αναφέρουν ότι θέµατα σχετικά µε τους πελάτες δεν καλύπτονται από το CMM σε αντίθεση µε το ISO. Προτείνουν επίσης σε περίπτωση επιλογής ανάµεσα στα δύο µοντέλα πρώτα την χρήση του ISO9001, για να αποκτήσουν την πιστοποίηση, λόγω του ότι είναι πιο αποδεκτή διεθνώς και απαιτείται σε πολλούς διαγωνισµούς, και µετά την χρήση του CMM για παραπέρα βελτίωση. Σε αντίθεση µε τους Oskarsson και Glass [7] εµείς θεωρούµε ότι είναι καλό όταν µια επιχείρηση θέλει να ξεκινήσει ένα σύστηµα ποιότητας πρώτα να χρησιµοποιήσει το µοντέλο αυτοεκτίµησης του CMM, για να ξέρει που βρίσκεται και ποιοι τοµείς είναι προβληµατικοί και µετά να επιχειρήσει την απόκτηση της πιστοποίησης του ISO9001. Μετά την απόκτηση της πιστοποίησης προτείνουµε την χρήση και πάλι του CMM η κάποιου άλλου µοντέλου ωρίµανσης για παραπέρα και συνεχή βελτίωση της ποιότητας του λογισµικού. 7. ΠΡΟΣΕΓΓΙΣΗ ΣΕ ΕΛΛΗΝΙΚΕΣ ΕΠΙΧΕΙΡΗΣΕΙΣ Η έρευνα αυτή χρησιµοποιεί για την εκτίµηση του επιπέδου ωρίµανσης ένα ερωτηµατολόγιο του SEI [11], το οποίο µεταφράσαµε στα Ελληνικά και χρησιµοποιήσαµε σε δύο Ελληνικές Εταιρίες, οι οποίες αναπτύσσουν λογισµικό (Software House). Η πρώτη εταιρία (εταιρία 1) κάνει προετοιµασία για την απόκτηση της πιστοποίησης του ISO9001 ενώ η δεύτερη (εταιρία 2) έχει ήδη αποκτήσει την πιστοποίηση του ISO9001. Και οι δύο εταιρίες έχουν προσωπικό της τάξης γύρο στα 25-30 άτοµα. Παρακάτω περιγράφουµε συνοπτικά το ερωτηµατολόγιο που χρησιµοποιήσαµε. 7.1 ΕΡΩΤΗΜΑΤΟΛΟΓΙΟ Το ερωτηµατολόγιο αποτελείται από 85 ερωτήσεις συνολικά. Οι ερωτήσεις χωρίζονται ώς εξής: 33 ερωτήσεις για το επίπεδο 2 (21 L2-ερωτήσεις, 12 L2#-ερωτήσεις) 31 ερωτήσεις για το επίπεδο 3 (18 L3-ερωτήσεις, 13 L3#- ερωτήσεις) 16 ερωτήσεις για το επίπεδο 4 ( 4 L4- ερωτήσεις, 12 L4#- ερωτήσεις) 5 ερωτήσεις για το επίπεδο 5 ( 1 L5- ερωτήσεις, 4 L5#- ερωτήσεις) Οι ερωτήσεις που έχουν το σηµάδι (#) έχουν µεγαλύτερη σπουδαιότητα από τις άλλες στο επίπεδο. Οι ερωτήσεις απαντώνται µε Ναι / Όχι. 11

Οι ερωτήσεις σε κάθε επίπεδο είναι διαχωρισµένες σε 7 κύριες περιοχές λειτουργίας (key process areas) ως εξής: 1. Οργάνωση 2. Πόροι, Προσωπικό και Εκπαίδευση 3. Τεχνολογική ιεύθυνση 4. Τεκµηρίωση Προτύπων και ιαδικασιών 5. Μετρική διαδικασία 6. εδοµένα ιεύθυνσης και Ανάλυσης 7. ιαδικασία ελέγχου 7.2 ΒΑΘΜΟΛΟΓΙΑ (SCORING) Όλες οι επιχειρήσεις θεωρούνται ότι βρίσκονται στο πρώτο επίπεδο (L1). Για να φτάσει η επιχείρηση στο δεύτερο επίπεδο (L2), το 80% από όλες τις ερωτήσεις που προσδιορίζουν το επίπεδο L2 πρέπει να έχουν Ναι για απάντηση και το 90% από όλες τις ερωτήσεις L2# πρέπει να έχουν και αυτές απάντηση Ναι. Για να φτάσει η επιχείρηση στο τρίτο επίπεδο (L3) (συµπεριλαµβανοµένων των ερωτήσεων από τα προηγούµενα επίπεδα), το 80% από όλες τις ερωτήσεις που προσδιορίζουν το L3 πρέπει να έχουν Ναι για απάντηση και το 90% από όλες τις ερωτήσεις L3# πρέπει και αυτές να έχουν Ναι για απάντηση. Για να φτάσει η επιχείρηση στο επίπεδο 4 και 5, οι ερωτήσεις από προηγούµενα επίπεδα περιλαµβάνονται και τα 80% και 90% κριτήρια χρησιµοποιούνται το ίδιο. Ο πίνακας 1 δείχνει τα ποσοστά επιτυχούς λειτουργίας κύριων περιοχών λειτουργίας (key process areas) των δύο επιχειρήσεων και ο πίνακας 2 τα ποσοστά επιτυχούς λειτουργίας των πέντε επιπέδων. Εταιρία 1 Εταιρία 2 Οργάνωση 71,4% 85,7% Πόροι / Προσωπικό / Εκπαίδευση 40,0% 60,0% Τεχνολογική ιεύθυνση 100,0% 60,0% Τεκµηρίωση Προτύπων και ιαδικασιών 50,0% 88,9% Μετρική ιαδικασία 26,5% 57,9% ιεύθυνση και Ανάλυση εδοµένων 55,5% 33,3% Έλεγχος ιαδικασιών 59,0% 86,3% Πίνακας 1. Ποσοστά επιτυχούς λειτουργίας κύριων περιοχών λειτουργίας L2 L2# L3 L3# L4 L4# L5 L5# 12

Εταιρία 1 42,0 83,3 55,5 55,5 25 50 0 75 Εταιρία 2 76,2 91,7 88,9 53,8 75 50 100 25 Πίνακας 2. Ποσοστά επιτυχούς λειτουργίας επιπέδων Παρατηρώντας τους πίνακες βλέπουµε ότι η εταιρία 1, που δεν έχει την πιστοποίηση του ISO9001 παραµένει στο πρώτο επίπεδο, ενώ η εταιρία 2 έχοντας ποσοστό 76,2 πλησιάζει το 80 % και µπορούµε να θεωρήσουµε ότι έχει φτάσει στο δεύτερο επίπεδο και πλησιάζει το τρίτο επίπεδο. Πρέπει να τονίσουµε ότι γενικά τα αποτελέσµατα παγκόσµια έχουν δείξει ότι η µεγάλη πλειοψηφία των οργανισµών βρίσκονται στο πιο χαµηλό επίπεδο, στο πρώτο επίπεδο [11]. Η κύρια περιοχή λειτουργίας της εταιρίας 1 που λειτουργεί αρκετά ικανοποιητικά είναι η οργάνωση ενώ η τεχνολογική διεύθυνση λειτουργεί άψογα. Εκεί που υστερεί είναι στις περιοχές πόροι / προσωπικό / εκπαίδευση, τεκµηρίωση προτύπων και διαδικασιών, µετρική διαδικασία, διεύθυνση και ανάλυση δεδοµένων και έλεγχος διαδικασιών. Οι κύριες περιοχές λειτουργίας της εταιρίας 2 που λειτουργούν αρκετά ικανοποιητικά είναι η οργάνωση, τεκµηρίωση προτύπων και διαδικασιών και ο έλεγχος διαδικασιών ενώ η διεύθυνση και ανάλυση δεδοµένων βρίσκονται σε πολύ χαµηλό επίπεδο. Από τα παραπάνω στοιχεία και σύµφωνα µε της απαιτήσεις του ISO µπορούµε να συµπεράνουµε ότι µε την πιστοποίηση του ISO9001 η εταιρία 2 έχει σηµαντική βελτίωση στις περιοχές τεκµηρίωση προτύπων και διαδικασιών και στον έλεγχο διαδικασιών. 8. ΣΥΝΟΨΗ Το CMM δηµιουργήθηκε για την βελτίωση λογισµικού κυρίως µεγάλων επιχειρήσεων της Αµερικής. Σε Ευρωπαϊκό επίπεδο έχουν δηµιουργηθεί δύο άλλα µοντέλα, το Bootstrap [4] και το SPICE [3], τα οποία όµως βασίστηκαν κυρίως στο CMM, έχοντας κάποιες παραλλαγές. Συµπεραίνουµε λοιπόν ότι το CMM είναι ένα σηµαντικό εργαλείο που πρέπει να γνωρίζει κάθε επιχείρηση που αναπτύσσει λογισµικό. Το CMM µε την σειρά του συσχετίζεται στενά µε το ISO, εποµένως η χρήση και των δύο µοντέλων είναι απαραίτητη σε µια επιχείρηση. Τελειώνοντας προτείνουµε να χρησιµοποιήσει µια επιχείρηση πρώτα το µοντέλο αυτοεκτίµησης του CMM για να ανακαλύψει τα ποσοστά επιτυχίας των κύριων περιοχών λειτουργίας και µετά να επιχειρήσει την απόκτηση της πιστοποίησης του ISO9001. Μετά την απόκτηση της πιστοποίησης προτείνουµε την χρήση και πάλι του CMM η κάποιου άλλου µοντέλου ωρίµανσης για παραπέρα και συνεχή βελτίωση της ποιότητας του λογισµικού. 13

ΒΙΒΛΙΟΓΡΑΦΙΑ [ 1] Bamford R.C. & Deibler W.J 1993, Comparing Contrasting ISO9001 and the SEI Capability Maturity Model, IEEE Computer, Oct. 1993, pp. 68-70 [ 2] Bisset A., Siddiqi J. Ι.A., 1995, How will the Capability Maturity Model fare in Europe? Conference on Software Quality Management, Seville 1995, pp. 171-182 [ 3] Dorling Alec, 1993, SPICE, Software Process Improvement and Capability determination, Software Quality Journal, 2, 1993 pp. 209-224 [ 4] Haase Volmar H. Lebsanft Ernst (1995) Measurement of Software Process Quality: Assessment and Self-assessments, International Conference on Software Quality, Maribor, 1995, pp. 9-18 [ 5] Humphrey Watts S., 1989, Managing the Software Process, Addison Wesley, Μ.Α. [ 6] Mohamed W.E.A., Siakas K.V.,1995, Assessing Software Quality Management Maturity (SQMM): A new model incorporating technical as well as cultural factors, Conference on Software Quality Management, Seville 1995, pp.325-336 [ 7] Oskarsson Osten, Glass Robert L., 1996, An ΙSO 9000 Approach To Building Quality Software, Prentice Hall PRT, New Jersey [ 8] Paulk Mark C., 1995, The Evaluation of the SEI s Capability Maturity Model for Software, Software Process, Improvement and Practice, Vol 1.Aug 95, pp. 3-15 [ 9] Paulk Mark, 1993, Capability Maturity Model, Software Engineering Institute Technical Report, CMU / SEI93 [10] Paulk M.C. 1993, Comparing ISO9001 and the Capability Maturity Model for Software, Software Quality Journal, 2 Dec. 1993, pp.245-256 [11] Rozman Ivan, Horvat Romana V., Hericko Marjan, Lah Ivan, 1995, PROCESSUS- Assessment and Improvement of Software Process Quality, International Conference on Software Quality, Maribor, 1995, pp.19-25 [12] Saiedian Hossein, McClanahan Laura M 1996, Frameworks for quality software process: SEI Capability Maturity Model versus ISO9000, Software Quality 5 Journal, Vol 1, March 1996, pp. 1-24 [13] Software Engineering Institute, 1993, Key Practices of the Capability Maturity Model, Version 1.1., CMU/SEI-93 14