Αρχείο άρθρων για την κατηγορία ‘Ποιότητα’

Το παρακάτω κείμενο αποτελεί μια προσαρμογή – διασκευή ενός case -study που διάβασα πρόσφατα.

Υπήρχε κάποτε μια εταιρεία λογισμικού. Οι managers ήταν παθιασμένοι με τον σχεδιασμό. Είχαν σχέδια για τα πάντα. Και αν ένα bug βρίσκονταν, αλλά δεν ήταν επίσημα συνδεμένο με ένα σενάριο ελέγχου,  γίνονταν διαρκώς πιεστικές και διερευνητικές ερωτήσεις για τα αίτια. Όλα χρειάζονται ένα σχέδιο. Τίποτα δεν γίνονταν χωρίς σχέδιο. Θεωρούσαν ότι είναι δυνατόν να προγραμματίσουν  τα πάντα. Τίποτα από αυτά που μπορεί να αντιμετώπιζαν δεν μπορούσε να μην έχει πρώτα σχεδιαστεί ή προβλεφθεί.

Ένα απόγευμα της Δευτέρας για πρώτη φορά παρουσίασαν στον κόσμο, ολοκληρωμένο το νέο λογισμικό τους . Ήταν αναμενόμενο ότι τίποτα δεν θα πάει στραβά. Είχαν κάνει χιλιάδες ώρες προγραμματισμένων δοκιμών. Είχαν προγραμματιστεί τα χαρακτηριστικά, οι απαιτήσεις, ο σχεδιασμός, οι εφαρμογές και οι υποδομές στο νιοστό βαθμό. Το προϊόν επρόκειτο να «σκίσει». Τίποτα δεν μπορούσε να σταθεί εμπόδιο στην επιτυχία.

Είχε προσκληθεί ακόμα και ο μεγαλύτερος πελάτης τους, στο χώρο του ξενοδοχείου, για να παρακολουθήσει την κυκλοφορία του νέου λογισμικού σε όλο της το μεγαλείο. Σχεδίαζαν αυτή την ημέρα εδώ και  6 μήνες. Η σαμπάνια έρεε άφθονη, πολύ ευθυμία κυριαρχούσε στον χώρο και όλοι χτυπούσαν ελαφρά ο ένας την πλάτη του άλλου. ”Μια καλή δουλειά» ανακοίνωσε ο επικεφαλής σχεδιασμού.

Ξαφνικά εμφανίστηκε ένα bug (σφάλμα) στην οθόνη. Ένα bug. Πώς συνέβη αυτό; Πανικός!!! Ένα bug. Έχουμε ένα σχέδιο για αυτό; Τι εννοείς, ΟΧΙ! Ένα bug. Ένα μεγάλο, άσχημο και αποτρόπαιο bug (σφάλμα).

“Ας συγκεντρωθούν αμέσως  τα “στρατεύματα”, φώναξε ο επικεφαλής σχεδιασμού. Αλλά προτού να μπορέσει να συγκεντρώσει τα “στρατεύματα” και προς μεγάλη του έκπληξη, το bug πήδηξε από την οθόνη και έκανε μια γρήγορη μεταβολή προς τις σκάλες!!!

Ο Γενικός Διευθυντής Σχεδιασμού κυνήγησε το bug  μέχρι τις σκάλες. Αλλά ο Γενικός Διευθυντής Σχεδιασμού δεν θα μπορούσε να πιάσει το bug.

“Τρέξτε όσο πιο γρήγορα μπορείτε. Δεν μπορείτε να με πιάσετε, ξεγλίστρησα μέσω του σχεδίου σας.” Φώναξε το bug.

Ο Υπεύθυνος Έργου είδε τι συνέβαινε και το κυνήγησε επίσης. Έτσι, ο Διευθυντής Σχεδιασμού και ο Υπεύθυνος Έργου το κυνήγησαν, αλλά δεν μπορούσαν να πιάσουν το bug.

“Τρέξτε όσο πιο γρήγορα μπορείτε. Δεν μπορείτε να με πιάσετε ξεγλίστρησα μέσω του σχεδίου σας.” Φώναξε το bug.

Το bug έτρεξε προς το χώρο της ανάπτυξης, όπου η ομάδα ανάπτυξης παρατηρούσε τι συνέβαινε. Ακολούθησε και εκεί πολύ κυνηγητό. Έτσι, ο Διευθυντής Σχεδιασμού, ο Υπεύθυνος Έργου και οι προγραμματιστές συνέχισαν όλοι να το κυνηγούν, αλλά κανένας τους δεν μπορούσε να πιάσει το bug.

“Τρέξτε όσο πιο γρήγορα μπορείτε. Δεν μπορείτε να με πιάσετε ξεγλίστρησα, μέσω του σχεδίου σας.” Φώναξε το bug..

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

Έτσι, ο Διευθυντής Σχεδιασμού, ο Υπεύθυνος Έργου οι προγραμματιστές και ο Υπεύθυνος Υποστήριξης συνέχισαν να το κυνηγούν χωρίς όμως αποτέλεσμα.

“Τρέξτε όσο πιο γρήγορα μπορείτε. Δεν μπορείτε να με πιάσετε ξεγλίστρησα, μέσω του σχεδίου σας”. Φώναξε το bug.

Το bug από τώρα είχε αρχίσει να κουράζεται και ξέπνοο κρύφτηκε στον ψύκτη νερού. Ενώ βρίσκονταν κρυμμένο στο δοχείο ψύξης νερού, συνειδητοποίησε ότι στεκόταν δίπλα στον Διευθύνοντα Σύμβουλο, ο οποίος καθώς το παρατηρούσε του έπεσε κάτω το ποτήρι με το νερό. Χωρίς περαιτέρω δισταγμό το σφάλμα έκανε μεταβολή και όρμησε για τα δωμάτια με τους servers(διακομιστές). Ο Διευθύνων Σύμβουλος το κυνήγησε.

Τόσο ο Διευθυντής Σχεδιασμού, ο Υπεύθυνος Έργου, οι Προγραμματιστές ,ο Υπεύθυνος Υποστήριξης και ο Διευθύνων Σύμβουλος συνέχισαν όλοι να το  κυνηγούν, αλλά μάταια.

“Τρέξτε όσο πιο γρήγορα μπορείτε. Δεν μπορείτε να με πιάσετε ξεγλίστρησα, μέσω του σχεδίου σας”. Φώναξε το bug.

Στον διάδρομο για την αίθουσα με τους διακομιστές το σφάλμα παρατήρησε έναν άνδρα που κρατούσε ανοικτή μια πόρτα. “Γρήγορα. Έλα εδώ ” φώναξε ο άνδρας. Το bug ήταν αρχικά επιφυλακτικό, αλλά o άνδρας έμοιαζε υπομονετικός και με κατανόηση. Το bug πλησίασε διστακτικά. Μπήκε στο δωμάτιο και παρατήρησε ένα ανοιχτό παράθυρο που οδηγούσε σε ένα μικρό μπαλκόνι.

“Εδώ. Έλα πάνω σε αυτό το παράθυρο και θα είσαι ελεύθερος », είπε ο άνδρας με ένα σαρδόνιο χαμόγελο. ”Φύγε. Γεύσου την ελευθερία. Νιώσε την αύρα της. ”

Το bug κοίταξε αυτάρεσκα καθώς ανέβαινε στο κοντινό τραπέζι.

“Εδώ, επέτρεψε μου να σε βοηθήσω.” Είπε ο άνδρας. Ο άνδρας έδωσε στο bug ένα χέρι βοήθειας να σκαρφαλώσει στο τραπέζι.

Κραυγές και αποδοκιμασίες αντηχούν τώρα έξω από την πόρτα. Το bug ήταν σχεδόν στο παράθυρο.

“Επέτρεψε μου να σε βάλω στο περβάζι του παραθύρου.” Είπε ο άνδρας. Το bug χαμογέλασε ειρωνικά  καθώς ένιωθε το δροσερό αεράκι όλο και ισχυρότερο.

“Είμαι ελεύθερο” σκέφτηκε το bug. Καθώς περπάτησε προς το περβάζι του παραθύρου με τη βοήθεια του άνδρα, παρατήρησε την κάρτα ασφαλείας που μόλις διακρίνονταν στο πουκάμισο του. Στο πρόσωπο του bug σχηματίστηκε μια έκφραση φρίκης καθώς διάβασε τις τελευταίες λέξεις της κάρτας. ”…….- Software Tester”.

Ο άνδρας έδωσε στο μικρό bug μια ώθηση έξω από το περβάζι του παραθύρου, το οποίο κατέληγε σε ένα μικρό μπαλκόνι. Στο μπαλκόνι κάθονταν περίπου 200 γλάροι.

200 πεινασμένοι γλάροι.

200 πολύ πεινασμένοι γλάροι που έτρεχαν ήδη τα σάλια τους βλέποντας τον ανέλπιστο μεζέ να χάνει την ισορροπία  του και να πέφτει προς το μέρος τους ..

Δύσκολα ένα σχέδιο είναι τέλειο. Σχεδόν ποτέ. Για αυτό καλό είναι να υπάρχουν πάντα οι “γλάροι” για την περίπτωση που “στραβώσει” κάτι!!!

Πολλοί από εμάς έχουν μπει στον πειρασμό ή στην διαδικασία να συγκρίνουν διάφορα λογισμικά για να διαπιστώσουν ποιο είναι το καλύτερο.Η υπεροχή ενός λογισμικού σε σχέση με κάποιο άλλο μπορεί να καθοριστεί με βάση πλήθος κριτηρίων (τεχνικά χαρακτηριστικά,φιλικότητα στον χρήστη,κόστος συντήρησης , ελάχιστες απαιτήσεις λειτουργίας,φάσμα κάλυψης συγκεκριμένων αναγκών κλπ) που χρειάζονται πολλές παράγραφοι για να αναλυθούν .Υπάρχει όμως το τέλειο λογισμικό?Ακόμα και ο χαρακτηρισμός “τέλειο” είναι συζητήσιμος.Τι αποτελεί το τέλειο?Έχει παραχθεί?Και αν όχι γιατί?

Για το μεγαλύτερο μέρος της ανθρώπινης ιστορίας, δημιουργήσαμε κάθε προϊόν με το χέρι, και κάναμε το κάθε προϊόν λίγο καλύτερο από το προηγούμενο. Δηλαδή, οι πρόγονοί μας χρησιμοποιούσαν την φυσική και  συνεχή εξέλιξη των προϊόντων.

Αλλά κατά τη διάρκεια της βιομηχανικής επανάστασης, επινοήσαμε την ιδέα της μαζικής παραγωγής. Ξαφνικά ο σχεδιασμός έγινε πολύ πιο σημαντικός. Σχεδιαστικά λάθη δεν μπορούσαν να διορθωθούν άμεσα στην επόμενη παραγωγή προϊόντων, αλλά να τίθενται αμέσως σε χιλιάδες προϊόντα.

Τότε εφευρέθηκε το λογισμικό, κάνοντας τα πράγματα χειρότερα. Το λογισμικό ελαχιστοποιεί το κόστος παραγωγής θέτοντας ακόμα μεγαλύτερη πίεση στους σχεδιαστές. Αυτό οδήγησε σε δεκαετίες προσπαθειών μέχρι να τελειοποιηθεί το λογισμικό για πρώτη φορά. Εφηύραμε διαδικασίες, τυπικές μεθόδους, προδιαγραφές, περίπλοκα κριτήρια δοκιμών, γλώσσες μοντελοποίησης σχεδιασμού … όλα με στόχο την παραγωγή  σωστού λογισμικού  πριν από την μαζική παραγωγή του σε χιλιάδες αντίτυπα.

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

Με απλά λόγια: Ο άνθρωπος δεν είναι εκ φύσεως καλός στο να είναι τέλειος!

Ωστόσο, είμαστε καλοί στην προσέγγιση και τη βελτίωση. Στην πραγματικότητα, οι πρόγονοί μας έχουν χρησιμοποιήσει αυτή την προσέγγιση για χιλιάδες χρόνια. Και ο τομέας του λογισμικού έρχεται σε αυτόν τον πλήρη κύκλο .

Μεγάλα τμήματα της βιομηχανίας λογισμικού έχουν δει πρόσφατα τεράστιες αλλαγές στη διαδικασία ανάπτυξης. Web εφαρμογές, ενημερώσεις που παραδίδονται μέσω του διαδικτύου, τεχνολογία cloud,καθώς και η δυνατότητα να προωθούνται ενημερώσεις σε κινητές συσκευές που μας επιτρέπουν να αναβαθμίζουμε το λογισμικό σε καθημερινή ή ακόμα και σε ωριαία βάση. Δηλαδή, έχουμε την επιστροφή στις ρίζες μας, της συνεχής εξέλιξης, όπως ακριβώς και οι πρόγονοί μας έκαναν εδώ και χιλιετίες.

Η δημιουργία συχνών αναβαθμίσεων όπου θα δοκιμάζουμε κάτι, θα γίνεται ο εντοπισμός πιθανών προβλημάτων και στη συνέχεια θα γίνονται γρήγορα οι αλλαγές είναι μια φυσική ανθρώπινη διαδικασία που εφαρμόζεται κατά κόρον και στη βιομηχανία. Η Google π.χ εν μέρει δίνει έμφαση στον “γρήγορο καθορισμό” παρά στην “πρόληψη”, μέσα από την εφαρμογή ενός πολύ σύντομου εξελικτικού κύκλου (test-fix-update) [1].

Αυτή η προσέγγιση θα είναι ύποπτη για πολλούς ακαδημαϊκούς. Πολλοί έμαθαν την τέχνη σε ένα περιβάλλον όπου οι νέες εκδόσεις βγαίνουν κάθε 4 ή 5 χρόνια, και από δασκάλους που τόνιζαν την κρισιμότητα ασφαλούς λογισμικού, όπου εξελικτική test-fix-update διαδικασία θεωρείται επικίνδυνη (αν συντρίψουμε το αεροπλάνο, δεν περιμένουμε άλλη μια ευκαιρία!). Αλλά για ένα μεγάλο (και αυξανόμενο) τμήμα της βιομηχανίας λογισμικού, αυτή η διαδικασία λειτουργεί. Οι γοργοί ρυθμοί ανάπτυξης και εξέλιξης της τεχνολογίας αλλά και του περιβάλλοντος που ζούμε , επιβάλλουν ταχύτατους μηχανισμούς ενεργειών και διαρκής προσαρμογή στα νέα δεδομένα που διαμορφώνονται.Και ναι, αυτό έχει σοβαρό αντίκτυπο στο λογισμικό. Η συνεχής προσπάθεια όμως για την εξέλιξη, την καλύτερη προσέγγιση και την βελτίωση του λογισμικού κρίνεται απαραίτητη.Ίσως (?) να μην παραχθεί ποτέ το “τέλειο” λογισμικό.Αυτό που όμως δεν θα εκλείψει , είναι η προσπάθεια και το όραμα για την συνεχή βελτίωσή του.

[1] Patrick Copeland. Testing, Culture, and Infrastructure: Google’s Innovation Feature Factory (Keynote Address), proceedings of the 3rd International Conference on Software Testing, Verification and Validation, April 2010, IEEE Computer Society Press.

Philip Crosby ’79 -> Το Πρόβλημα με την διαχείριση ποιότητας δεν είναι αυτά που οι άνθρωποι δεν ξέρουν , αλλά αυτά που νομίζουν ότι ξέρουν.

Η Ποιότητα μοιάζει με το σεξ:

• Ολους τους ενδιαφέρει
• Ολοι νομίζουν ότι το καταλαβαίνουν
• Ολοι νομιζουν ότι ειναι απλά θέμα ενστίκτου
• Οι Περισσότεροι νομιζουν οτι τα προβλήματα προέρχονται πάντα από τους άλλους.

Σε τι συνίσταται η ποιότητα?
Ποια είναι τα μέτρα ποιότητας ενός αντικειμένου για παράδειγμα μια καρέκλας;

Θα μπορούσε να είναι

• H ποιότητα κατασκευής ; ( π.χ αντοχή )
• H αισθητική αξία ;  ( π.χ κομψότητα )
• Καταλληλότητα  ; ( π.χ άνεση )

Ενδεχομένως ναι και πολλά άλλα ίσως. Πως θα μπορούσες να ισχυριστείς όμως  ότι αυτή η καρέκλα είναι ποιοτικότερη από την άλλη από την στιγμή που όλα τα μέτρα ποιότητας είναι σχετικά;
Για το Λογισμικό τα πράγματα είναι ακόμα πιο ασαφή καθώς η ποιότητα κατασκευής δεν είναι κάτι χειροπιαστό , αισθητική αξία ενδεχομένως μόνο το interface Θα μπορούσε να έχει  , όσο για την καταλληλότητα  θα πρέπει πρώτα να κατανοηθεί ο σκοπός του.

Ανεξαρτήτως πάντως της αδυναμίας ορισμού και καθορισμού  απολύτων μέτρων  ποιότητας  υπάρχει κάτι  , μέσα από το οποίο θα αντικατροπτίζεται  η ποιότητα ενός προιόντος ή μιας Υπηρεσίας.
Η Ικανοποίηση των απαιτήσεων του πελάτη , ακόμα και αυτών που δεν έχουν εκφραστεί.

Γιατί σε τελική ανάλυση : Ποιότητα είναι όταν επιστρέφει ο πελάτης και όχι το προϊόν.

Εαν λοιπόν συμφωνήσουμε πρωτίστως ότι αυτό είναι το ζητούμενο και όχι κάτι άλλο ,  εύκολα μπορούμε   – όλοι μαζί -
να διαμορφώσουμε και εκείνες τις διαδικασίες που να διασφαλίζουν το ποθούμενο. Γιατί η Ποιότητα τελικά είναι ΟΜΑΔΙΚΟ αθλημα.

Πηγή: http://iiu.teikav.edu.gr/iiw/courses/eksamino_05/tello_ii/ejamina/0910XE/pdf/TP_DELDP_07.pdf