Ανασχεδιασμός παλαιάς βιομηχανικής εφαρμογής – πότε έχει νόημα και πώς μπορεί να γίνει χωρίς κίνδυνο για την παραγωγή;

Γιατί αυτό το θέμα έχει σήμερα σημασία

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

Η σημασία του θέματος προκύπτει από το γεγονός ότι στα βιομηχανικά συστήματα το τεχνολογικό χρέος μετατρέπεται πολύ γρήγορα σε λειτουργικό χρέος. Αν η εφαρμογή είναι δύσκολο να αναπαραχθεί, εξαρτάται από μεμονωμένα πρόσωπα, δεν διαθέτει αξιόπιστες δοκιμές αναπαραγωγής ή η λογική της αναμειγνύει λειτουργίες παραγωγής με λειτουργίες ασφάλειας και διάγνωσης, τότε κάθε περιστατικό θα είναι ακριβότερο από ένα αντίστοιχο πρόβλημα σε ένα σύστημα γραφείου. Η συνέπεια δεν είναι μόνο η διακοπή λειτουργίας. Προστίθεται το κόστος εργασίας της συντήρησης, ο κίνδυνος λανθασμένων προσωρινών παρακάμψεων υπό πίεση χρόνου, η δυσκολία να αποδειχθεί η δέουσα επιμέλεια μετά την αλλαγή, καθώς και το πρόβλημα να διαχωριστεί τι ήταν προϋπάρχουσα βλάβη και τι αποτέλεσμα της επέμβασης της ομάδας έργου. Για τον manager και τον ιδιοκτήτη προϊόντος, το πρακτικό κριτήριο είναι απλό: αν ο χρόνος και η αβεβαιότητα υλοποίησης διαδοχικών μικρών αλλαγών αυξάνονται ταχύτερα από την επιχειρηματική τους αξία, η εφαρμογή έχει εισέλθει σε κατάσταση όπου η απόφαση για αναδόμηση πρέπει να ληφθεί συνειδητά και όχι να αναβάλλεται μέχρι την πρώτη κρίσιμη αστοχία.

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

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

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

Πού αυξάνονται συχνότερα το κόστος ή ο κίνδυνος

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

Η δεύτερη τυπική περιοχή όπου αυξάνεται το κόστος είναι μια σχεδιαστική απόφαση που λαμβάνεται χωρίς πλήρη εικόνα των αλληλεξαρτήσεων. Οι παλιές βιομηχανικές εφαρμογές είναι συχνά άρρηκτα συνδεδεμένες με τη διαμόρφωση του ελεγκτή, τα εκτελεστικά στοιχεία, την οπτικοποίηση, την αρχειοθέτηση δεδομένων και τις διαδικασίες του χειριστή. Στην τεκμηρίωση αυτό φαίνεται ως ένα ενιαίο σύστημα, στην πράξη όμως πρόκειται για επίπεδα που έχουν εξελιχθεί επί χρόνια από διαφορετικές ομάδες. Μια αναδόμηση που αποσκοπεί στη βελτίωση της αναγνωσιμότητας του κώδικα ή στη διευκόλυνση της μελλοντικής συντήρησης μπορεί ανεπαίσθητα να αλλάξει τη σημασία των καθυστερήσεων, των συνθηκών αλληλοασφάλισης, των προεπιλεγμένων τιμών μετά από επανεκκίνηση ή του τρόπου χειρισμού σφάλματος επικοινωνίας. Η συνέπεια δεν είναι μόνο μια τεχνική διόρθωση, αλλά και το κόστος διακοπών λειτουργίας, πρόσθετων δοκιμών στην εγκατάσταση και διαφωνιών για το αν η αστοχία προϋπήρχε ή εισήχθη με την αλλαγή. Γι’ αυτό, πριν ληφθεί απόφαση, αξίζει να αξιολογηθεί όχι μόνο το μέγεθος της τροποποίησης, αλλά και ο αριθμός και η κρισιμότητα των σημείων διεπαφής: πόσα σήματα, συνταγές, τρόποι λειτουργίας και λειτουργικές παρακάμψεις εξαρτώνται από το τμήμα του κώδικα που πρόκειται να ανασχεδιαστεί. Όσο περισσότερα είναι αυτά τα σημεία, τόσο λιγότερο νόημα έχει μια αναδόμηση «με την ευκαιρία» κάποιας άλλης εργασίας.

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

Αυτό το ζήτημα οδηγεί άμεσα στην πρακτική αξιολόγηση του κινδύνου των αλλαγών όταν η τροποποίηση επηρεάζει λειτουργίες προστασίας, ακολουθίες ασφαλούς πρόσβασης, τον έλεγχο κίνησης των εκτελεστικών στοιχείων ή τη συμπεριφορά της εγκατάστασης μετά από απώλεια και επαναφορά τροφοδοσίας. Σε τέτοιο πεδίο, το κόστος ενός σφάλματος δεν περιορίζεται στις διορθώσεις προγραμματισμού, γιατί ανακύπτει και το θέμα της ευθύνης για την έγκριση της αλλαγής σε λειτουργία. Αν η εφαρμογή συνεργάζεται με υδραυλικά, πνευματικά συστήματα ή λύσεις όπως ο χειρισμός με δύο χέρια, τότε το όριο ανάμεσα στην αναδόμηση και την τεχνική αλλαγή γίνεται ακόμη πιο στενό και απαιτεί έλεγχο για το αν έχουν παραβιαστεί οι σχεδιαστικές παραδοχές των μέσων προστασίας. Μόνο σε αυτό το σημείο είναι εύλογη η αναφορά σε συστηματικές μεθόδους αξιολόγησης κινδύνου, συμπεριλαμβανομένης της προσέγγισης που εφαρμόζεται στην πράξη με βάση το ISO/TR 14121-2, και, για τα υδραυλικά συστήματα, και στις σχεδιαστικές απαιτήσεις που οργανώνονται από το ΕΛΟΤ EN ISO 4413. Δεν πρόκειται για τυπολατρία για χάρη της τυπολατρίας, αλλά για μια απλή αρχή λήψης αποφάσεων: αν η αλλαγή μπορεί να επηρεάσει την ασφάλεια της διεργασίας ή του χειρισμού, τότε το κόστος της πρέπει να υπολογίζεται μαζί με την επικύρωση, τις δοκιμές στην εγκατάσταση και το καθεστώς ευθύνης, και όχι αποκλειστικά με τον χρόνο εργασίας του προγραμματιστή.

Πώς να προσεγγίσετε το θέμα στην πράξη

Στην πράξη, το αν έχει νόημα η αναδόμηση μιας παλιάς βιομηχανικής εφαρμογής δεν κρίνεται από την τεχνολογική ελκυστικότητα της αλλαγής, αλλά από το αν μπορεί ταυτόχρονα να μειωθεί ο λειτουργικός κίνδυνος και να διατηρηθεί ο έλεγχος της υλοποίησης. Για τον manager και τον ιδιοκτήτη προϊόντος αυτό σημαίνει μια απλή αλλαγή οπτικής: το ερώτημα δεν είναι αν «αξίζει να τακτοποιηθεί» ο κώδικας, αλλά αν η σημερινή κατάσταση της εφαρμογής δυσκολεύει ουσιαστικά τη συντήρηση, τις δοκιμές, την αποκατάσταση σφαλμάτων ή την εισαγωγή επόμενων τροποποιήσεων με τρόπο σύμφωνο με τις απαιτήσεις. Αν η απάντηση είναι θετική, η αναδόμηση έχει νόημα, αλλά μόνο σε τέτοια έκταση ώστε να μπορεί να απομονωθεί από τη λειτουργία της παραγωγής και να αξιολογηθεί με βάση μετρήσιμα αποτελέσματα. Ένα καλό κριτήριο για τη λήψη απόφασης είναι η σύγκριση δύο κόστους: του κόστους διατήρησης της εφαρμογής στην παρούσα κατάσταση, που περιλαμβάνει διακοπές λειτουργίας, χρόνο διάγνωσης, εξάρτηση από μεμονωμένα άτομα και κίνδυνο λανθασμένης αλλαγής, και του κόστους μιας ελεγχόμενης ανακατασκευής μαζί με δοκιμές, επικύρωση και θέση σε λειτουργία. Χωρίς αυτή τη σύγκριση, το έργο συνήθως ξεφεύγει από τον έλεγχο, επειδή η ομάδα χρηματοδοτεί την τακτοποίηση του κώδικα από προϋπολογισμό που προορίζεται για λειτουργικότητα, ενώ η ευθύνη για τις συνέπειες στην εγκατάσταση παραμένει ακαθόριστη.

Γι’ αυτό, η πρώτη απόφαση δεν θα πρέπει να είναι «ξαναγράφουμε» ή «αφήνουμε ως έχει», αλλά ο καθορισμός του ορίου της αλλαγής. Σε μια ώριμη προσέγγιση, διαχωρίζεται το μέρος που αφορά αποκλειστικά τη δομή του λογισμικού από το μέρος που επηρεάζει τη λογική της διεργασίας, τις ακολουθίες εκκίνησης, παύσης, τους τρόπους λειτουργίας, την επικοινωνία με τις κινήσεις και τη συμπεριφορά μετά από διαταραχή της τροφοδοσίας. Αυτή η διάκριση έχει άμεσο αντίκτυπο στο κόστος και στην οργάνωση. Μια αλλαγή που περιορίζεται στο επίπεδο αναδιοργάνωσης του κώδικα μπορεί να υλοποιηθεί σε συντομότερο κύκλο και με μικρότερη συμμετοχή των υπηρεσιών συντήρησης. Μια αλλαγή που επηρεάζει τη συμπεριφορά της μηχανής ή της γραμμής απαιτεί ήδη σχέδιο δοκιμών στην εγκατάσταση, παράθυρο συντήρησης, διαδικασία επαναφοράς και σαφή ορισμό του ποιος εγκρίνει την επαναφορά σε λειτουργία. Παράλληλα, αξίζει να μετριέται όχι μόνο ο χρόνος εκτέλεσης των εργασιών προγραμματισμού, αλλά και ο χρόνος αποκατάστασης του συστήματος μετά από αποτυχημένη προσπάθεια, ο αριθμός των περιοχών που καλύπτονται από δοκιμές παλινδρόμησης και ο χρόνος που απαιτείται για τη διάγνωση μιας απόκλισης μετά την εκκίνηση. Αυτοί είναι δείκτες που δείχνουν αν η αναδόμηση μειώνει πράγματι τον κίνδυνο του έργου και δεν βελτιώνει απλώς την άνεση εργασίας της ομάδας ανάπτυξης.

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

Μόνο σε αυτό το στάδιο χρειάζεται η κανονιστική αναφορά, γιατί τα πρότυπα δεν υποκαθιστούν την τεχνική απόφαση, αλλά οργανώνουν τη στιγμή κατά την οποία η αλλαγή παύει να είναι αποκλειστικά εργασία προγραμματισμού. Αν η αναδόμηση επηρεάζει τα προστατευτικά μέτρα, τις συνθήκες ασφαλούς πρόσβασης, την απομόνωση ενέργειας ή τη συμπεριφορά των συστημάτων μετά από παύση και επανεκκίνηση, τότε εντάσσεται φυσικά στο πεδίο της πρακτικής αξιολόγησης του κινδύνου αλλαγών, η οποία διενεργείται με συστηματικό τρόπο και με αξιοποίηση της προσέγγισης που είναι γνωστή από το ISO/TR 14121-2. Όταν εμφανίζεται κίνδυνος απρόβλεπτης εκκίνησης, πρέπει πλέον να ελεγχθεί όχι μόνο ο ίδιος ο κώδικας, αλλά και η λογική απομόνωσης και επαναφοράς της ενέργειας, κάτι που οδηγεί άμεσα σε ζητήματα που συνδέονται με το ISO 14118. Αν, πάλι, η εφαρμογή συνδέεται με υδραυλικά ή πνευματικά συστήματα, η αξιολόγηση δεν μπορεί να παραβλέπει τις παραδοχές σχεδιασμού αυτών των συστημάτων, επειδή μια εσφαλμένη ακολουθία ελέγχου μπορεί να διαταράξει την ασφαλή λειτουργία τους ανεξάρτητα από την ορθότητα του ίδιου του προγράμματος· τότε καθίσταται επίσης δικαιολογημένη η αναφορά στις απαιτήσεις που οργανώνουν τον σχεδιασμό υδραυλικών συστημάτων. Στην πράξη αυτό σημαίνει ένα πράγμα: για την έκταση της αναδόμησης δεν αποφασίζει η κομψότητα της λύσης, αλλά το όριο της ευθύνης για την ασφαλή συμπεριφορά της εγκατάστασης μετά την αλλαγή.

Τι να προσέξετε κατά την υλοποίηση

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

Στο στάδιο λήψης της απόφασης για την υλοποίηση, πρέπει να διαχωρίζεται η τεχνικά αναστρέψιμη αλλαγή από εκείνη που, μετά την έναρξη λειτουργίας, δημιουργεί νέα γραμμή βάσης και δυσκολεύει την επιστροφή στην προηγούμενη κατάσταση. Αυτό έχει άμεσες συνέπειες στο κόστος και στο χρονοδιάγραμμα. Μια αναδόμηση κώδικα που απαιτεί ταυτόχρονη ενημέρωση ελεγκτών, οπτικοποίησης, διακομιστή δεδομένων και διεπαφών προς ανώτερα συστήματα παύει να είναι ένα μεμονωμένο προγραμματιστικό έργο· μετατρέπεται σε συντονισμένη αλλαγή στην παραγωγή με πολλά πιθανά σημεία αστοχίας. Γι’ αυτό, πριν από την υλοποίηση, αξίζει να υιοθετηθεί ένα κριτήριο αποδοχής που να μην βασίζεται στη δήλωση «οι δοκιμές ολοκληρώθηκαν επιτυχώς», αλλά στην ικανότητα ελεγχόμενης ανάκλησης της αλλαγής μέσα σε χρόνο αποδεκτό για τη διεργασία. Αν δεν υπάρχει αξιόπιστη διαδικασία επαναφοράς, δεν υπάρχει και βάση για να υποστηριχθεί ότι ο κίνδυνος έχει τεθεί υπό έλεγχο. Στην πράξη, είναι προτιμότερο να μετρώνται όχι αφηρημένες έννοιες όπως η «ποιότητα της υλοποίησης», αλλά δείκτες όπως ο χρόνος επαναφοράς της προηγούμενης έκδοσης, ο αριθμός των διεπαφών που εξαρτώνται από την αλλαγή και ο αριθμός των λειτουργιών των οποίων η ορθότητα μπορεί να επιβεβαιωθεί στην εγκατάσταση χωρίς παρέμβαση στην παραγωγή.

Χαρακτηριστικό παράδειγμα είναι η περίπτωση όπου η αναδόμηση κώδικα βελτιώνει τη διαχείριση εξαιρέσεων και μηνυμάτων σφάλματος, αλλά ταυτόχρονα αλλάζει τη σειρά αρχικοποίησης μετά από επανεκκίνηση του συστήματος. Στον δοκιμαστικό σταθμό όλα φαίνονται σωστά, επειδή οι συσκευές είναι άμεσα διαθέσιμες και η διεργασία δεν λειτουργεί υπό φορτίο. Στη μονάδα, όμως, ο ίδιος κώδικας μπορεί να εκκινήσει την ακολουθία σε διαφορετική χρονική στιγμή από πριν, οδηγώντας σε απώλεια συγχρονισμού με τις κινήσεις, σε εσφαλμένη ερμηνεία σημάτων ετοιμότητας ή σε ακινητοποίηση παρτίδας υλικού σε ενδιάμεση κατάσταση. Ένα τέτοιο συμβάν δεν σημαίνει κατ’ ανάγκη τεχνική βλάβη, αλλά δημιουργεί κόστος από διακοπή λειτουργίας, απορρίψεις, νέα εκκίνηση και πρόσθετη ευθύνη για την απόφαση επανέναρξης της λειτουργίας. Ακριβώς εδώ το ζήτημα της αναδόμησης κώδικα περνά στην πρακτική αξιολόγηση του κινδύνου των αλλαγών: όχι όταν η αλλαγή είναι μεγάλη, αλλά όταν οι συνέπειές της δεν μπορούν πλέον να περιοριστούν στο επίπεδο του λογισμικού.

Το όριο της ευθύνης γίνεται ακόμη σαφέστερο εκεί όπου η εφαρμογή επηρεάζει προστατευτικές λειτουργίες, τη λογική έγκρισης κίνησης, τις ακολουθίες αποφόρτισης, τη διακοπή και την επανεκκίνηση μετά από διαταραχή. Σε μια τέτοια περίπτωση, δεν αρκεί πλέον η σύγκριση εκδόσεων κώδικα ούτε μια λειτουργική δοκιμή που εκτελείται από τον integrator. Απαιτείται μια συστηματική αξιολόγηση για το αν η αλλαγή τροποποιεί το επίπεδο κινδύνου και αν δεν παραβιάζει τις παραδοχές ασφαλούς λειτουργίας της μηχανής ή της εγκατάστασης. Αυτό είναι το φυσικό σημείο εισόδου στο πεδίο της αξιολόγησης κινδύνου σύμφωνα με το ISO 12100 και των πρακτικών που εφαρμόζονται στην αξιολόγηση κινδύνου αλλαγών, ενώ σε πιο σύνθετες περιπτώσεις είναι χρήσιμη η μεθοδολογική προσέγγιση που είναι γνωστή από το ISO/TR 14121-2. Αν η εφαρμογή ελέγχει υδραυλικά ή πνευματικά συστήματα, πρέπει επιπλέον να ελεγχθεί αν η νέα λογική μεταβάλλει τις συνθήκες ασφαλούς ελέγχου της ενέργειας και τη σειρά των κινήσεων· τότε έχουν σημασία και οι απαιτήσεις σχεδιασμού που ισχύουν για αυτά τα συστήματα, και όχι μόνο η ορθότητα του ίδιου του προγράμματος. Για την ομάδα έργου αυτό σημαίνει ένα πράγμα: η υλοποίηση μπορεί να θεωρηθεί προετοιμασμένη μόνο όταν το εύρος της τεχνικής, λειτουργικής και κανονιστικής ευθύνης έχει προσδιοριστεί πριν από την έναρξη λειτουργίας και όχι μόνο μετά το πρώτο συμβάν.