Συστήματα Κληρονομιάς Legacy Systems

1. Συστήματα ΚληρονομιάςLegacy Systems Ορισμός : “ Γερασμένα ” συστήματα λογισμικού που ωστόσο παραμένουν ζωτικά για τη λειτουργία ενός οργανισμού

2. Συστήματα Κληρονομιάς (χαρακτηριστικά) • Συστήματα λογισμικού που παράγονται ειδικά για τις ανάγκες ενός οργανισμού έχουν συνήθως μεγάλη διάρκεια ζωής (10-15 χρόνια) • Πολλά συστήματα λογισμικού που χρησιμοποιούνται ακόμη υλοποιήθηκαν πολλά χρόνια πριν χρησιμοποιώντας τεχνολογίες που σήμερα θεωρούνται απαρχαιωμένες • Αυτά τα συστήματα είναι ακόμη επιχειρησιακά κρίσιμα, δηλαδή είναι ουσιώδη για την ομαλή λειτουργία της επιχείρησης • Τα συστήματα αυτά ονομάστηκαν “Συστήματα Κληρονομιάς” (ΣΚλ)

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

4. Τροποποίηση ΣΚλ • Τα συστήματα πρέπει να αλλάζουν για να παραμένουν χρήσιμα. • Οι αλλαγές, όμως, στα ΣΚλ είναι συχνά πολυέξοδες: • Διαφορετικά τμήματα υλοποιήθηκαν από διαφορετικές ομάδες  Υπάρχει ασυνέπεια προγραμματιστικών στύλ. • Μπορεί να χρησιμοποιήθηκε απαρχαιωμένη γλώσσα προγραμματισμού. • Η τεκμηρίωση του συστήματος είναι συχνά πεπαλαιωμένη. • Η δομή του συστήματος μπορεί να έχει φθαρεί/αλλοιωθεί μετά από τόσα χρόνια συντήρησης. • Χρησιμοποιούνται συχνά τεχνικές εξοικονόμησης χώρου ή αύξησης της ταχύτητας σε βάρος της κατανόησης. • Οι δομές των διαφόρων αρχείων μπορεί να είναι ασύμβατες.

5. Το δίλημμα των ΣΚλ • Η αντικατάσταση ενός ΣΚλ κοστίζει και εμπεριέχει σημαντικό ρίσκο • Η συντήρηση ενός ΣΚλ επίσης κοστίζει • Η επιχείρηση πρέπει να ζυγίσει το κόστος και το ρίσκο, και μπορεί να επιλέξει να διατηρήσει το ΣΚλ σε λειτουργία με τεχνικές όπως η επανατεχνολόγηση (re-engineering)

6. Δομές ΣΚλ • Τα ΣΚλ μπορούν να θεωρηθούν ως κοινωνικο-τεχνικά συστήματα, όχι μόνο συστήματα λογισμικού • System hardware – μπορεί να είναι mainframe hardware • Support software – Λ.Σ. και utilities • Application software – διάφορα προγράμματα • Application data – δεδομένα που χρησιμοποιούν τα προγράμματα και είναι συχνά ζωτικής σημασίας επιχειρησιακή πληροφορία • Business processes – διαδικασίες που υποστηρίζουν ένα επιχειρησιακό στόχο και οι οποίες βασίζονται πάνω στο ΣΚλ(software και hardware) • Business policies and rules – περιορισμοί πάνω στις επιχειρησιακές λειτουργίες

7. Τα μέρη ενός ΣΚλ

8. Μοντέλο επιπέδων Κοινωνικο-τεχνικό σύστημα B u s i n e s s p r o c e s s e s A p p l i c a t i o n s o f t w a r e S u p p o r t s o f t w a r e H a r d w a r e

9. Τροποποίηση συστήματος • Κατά κανόνα, θα πρέπει να μπορεί να αντικατασταθεί ένα επίπεδο αφήνοντας τα άλλα επίπεδα απείραχτα • Στην πράξη αυτό είναι συνήθως αδύνατο • Η τροποποίηση ενός επιπέδου εισάγει νέες δυνατότητες κι έτσι τα υψηλότερα επίπεδα πρέπει να αλλάξουν για να τις εκμεταλλευθούν • Αλλαγές στο λογισμικό μπορεί να το κάνουν πιο αργό, άρα μπορεί να χρειαστούν και αλλαγές στο hardware • Είναι συχνά αδύνατο να συντηρηθούν τα hardware interfaces εξαιτίας του χάσματος μεταξύ mainframes και client-server συστημάτων

10. ΣΚλ – Σύστημα Εφαρμογής

11. Database-centred σύστημα

12. Transaction processing

13. Τα δεδομένα σε ένα ΣΚλ • Το σύστημα μπορεί να είναι file-based με ασύμβατα files. Η απαιτούμενη τροποποίηση μπορεί να είναι η μετάβαση σε database-management σύστημα • Στα ΣΚλ που χρησιμοποιούν DBMS η διαχείριση της Βάσης Δεδομένων από το σύστημα μπορεί να είναι αχρείαστη και ασύμβατη με άλλα DBMSs που χρησιμοποιεί η επιχείρηση • Ένα teleprocessing monitor μπορεί να είναι σχεδιασμένο για συγκεκριμένη ΒΔ και mainframe. Μεταβαίνοντας σε νέα ΒΔ μπορεί να απαιτεί και νέο TP monitor

14. Σχεδιασμός ΣΚλ • Τα περισσότερα ΣΚλ σχεδιάστηκαν πριν την εδραίωση της αντικειμενοστραφούς προσέγγισης • Αντίθετα προς τη φιλοσοφία των objects που αλληλεπιδρούν, τα ΣΚλ σχεδιάστηκαν χρησιμοποιώντας στρατηγική προσανατολισμένη στις λειτουργίες (function-oriented design strategy) • Υπάρχουν πολλές μέθοδοι και CASE εργαλεία διαθέσιμα που υποστηρίζουν function-oriented σχεδίαση και η προσέγγιση αυτή χρησιμοποιείται ακόμη σε πληθώρα επιχειρησιακών εφαρμογών

15. Function-oriented σχεδιασμός

16. Η διαδικασία λειτουργικού σχεδιασμού • Σχεδιασμός ροής δεδομένων • Μοντελοποίηση της επεξεργασίας δεδομένων χρησιμοποιώντας ΔΡΔ • Δομική αποσύνθεση • Μοντελοποίηση της αποσύνθεσης λειτουργιών σε υπο-λειτουργίες μέσω γραφικών απεικονίσεων της δομής του συστήματος • Αναλυτικός σχεδιασμός • Οι οντότητες του σχεδιασμού και τα interfaces τους περιγράφονται με λεπτομέρεια (πιθανή χρήση data dictionary)

17. Κλάσεις ΣΚλ • Batch processing systems Δεδομένα επεξεργάζονται με batch διαδικασία από files • Transaction processing systems Τα δεδομένα παράγονται μέσω συναλλαγών

18. Μοντέλο input-process-output Συνηθισμένο μοντέλο για batch ή/και transaction processing

19. Μοντέλο input-process-output • Τα τμήματα εισόδου (input components) διαβάζουν και επικυρώνουν (validate) δεδομένα από τερματικά ή αρχεία • Τα τμήματα επεξεργασίας (processing components) εκτελούν κάποιους μετασχηματισμούς σε αυτά τα δεδομένα • Τα τμήματα εξόδου (output components) μορφοποιούν και εκτυπώνουν τα αποτελέσματα του υπολογισμού • Είσοδος-επεξεργασία-έξοδος  μπορούν να αναπαρασταθούν σαν λειτουργίες (functions) με ροή δεδομένων μεταξύ τους

20. Η διαδικασία λειτουργικού σχεδιασμού • Σχεδιασμός ροής δεδομένων - Data-flow design • Μοντελοποίηση της επεξεργασίας των δεδομένων μέσα στο σύστημα χρησιμοποιώντας ΔΡΔ • Δομική αποσύνθεση - Structural decomposition • Μοντελοποίηση της αποσύνθεσης λειτουργιών σε υπο-λειτουργίες χρησιμοποιώντας γραφήματα δομής που αντανακλούν τη δομή input/process/output • Λεπτομερής σχεδιασμός - Detailed design • Οι λειτουργίες και τα interfaces τους περιγράφονται με λεπτομέρεια

21. Διαγράμματα Ροής Δεδομένων • Δείξε πώς ένα αντικείμενο εισόδου μετασχηματίζεται λειτουργικά σε αντικείμενο εξόδου • Τα ΔΡΔ είναι αναπόσπαστο μέρος πολλών σχεδιαστικών μεθόδων και υποστηρίζονται από CASE εργαλεία • Μπορεί να μεταφραστεί είτε σε ακολουθιακή, είτε σε παράλληλη σχεδίαση: Ακολουθιακή:Τα στοιχεία επεξεργασίας είναι functions ή procedures Παράλληλη: Τα στοιχεία επεξεργασίας είναι tasks ή processes

22. ΔΡΔ συστήματος μισθοδοσίας

23. Μισθοδοσία – Μαζική επεξεργασία(batch processing) • Οι λειτουργίες στα αριστερά του ΔΡΔ είναι λειτουργίες εισόδου • Read employee record, Read monthly pay data, Validate employee data • Η κεντρική λειτουργία - Compute salary – εκτελεί την επεξεργασία • Οι λειτουργίες στα δεξιά του ΔΡΔ είναι λειτουργίες εξόδου • Write tax transaction, Write pension data, Print payslip, Write bank transaction, Write social security data

24. Επεξεργασία συναλλαγών -Transaction processing • Μια ATM μιας τράπεζας είναι ένα παράδειγμα συστήματος επεξεργασίας συναλλαγών • Οι συναλλαγές δεν έχουν κατάσταση προϊστορίας, δηλαδή δεν εξαρτώνται από το αποτέλεσμα παλαιότερων συναλλαγών. Άρα, η λειτουργική προσέγγιση είναι ο καταλληλότερος τρόπος υλοποίησης ενός τέτοιου συστήματος

25. Σχεδιαστικήπεριγραφή ενός ATM

26. Χρησιμοποιώντας function-oriented σχεδιασμό • Για μερικές κατηγορίες συστημάτων, όπως τα transaction processing systems, η function-oriented προσέγγιση μπορεί να είναι καλύτερη σχεδιαστική μέθοδος από την object-oriented προσέγγιση • Εταιρείες και οργανισμοί μπορεί να έχουν ήδη επενδύσει σε CASE εργαλεία και μεθόδους για function-oriented σχεδιασμό και μπορεί να μην επιθυμούν να υποστούν το κόστος και τα ρίσκατης αλλαγής σε object-oriented προσέγγιση

27. Αποτίμηση ΣΚλ • Οι οργανισμοί που στηρίζονται σε ΣΚλ πρέπει να επιλέξουν μια στρατηγική για την εξέλιξη των συστημάτων αυτών: • Ξεφόρτωμα, πέταμα ολόκληρουτου συστήματος και τροποποίηση των επιχειρησιακών διαδικασιών ώστε το σύστημα να μην είναι πλέον απαραίτητο • Συνέχιση της συντήρησης του συστήματος • Μετασχηματισμός του συστήματος μέσω re-engineering για βελτίωση της συντηρησιμότητάς του • Αντικατάσταση του συστήματος με νέο • Η επιλογή της στρατηγικής θα πρέπει να στηριχθεί στην ποιότητα του συστήματος και την επιχειρησιακή του αξία

28. Ποιότητα και επιχειρησιακή αξία

29. Κατηγορίες ΣΚλ • Low quality, low business value • Αυτά τα συστήματα πρέπει να πεταχτούν • Low-quality, high-business value • Έχουν σημαντική επιχειρησιακή συνεισφορά αλλά η συντήρησή τους είναι πολυέξοδη. Πρέπει να τροποποιηθούν μέσω re-engineering ή να αντικατασταθούν αν υπάρχει κατάλληλο σύστημα διαθέσιμο στην αγορά • High-quality, low-business value • Αντικατάσταση με COTS, πέταμα ή συντήρηση (όλα υποψήφια) • High-quality, high business value • Συνέχιση της λειτουργίας με συνηθισμένη συντήρηση

30. Αποτίμηση επιχειρησιακής αξίας • Η αποτίμηση πρέπει να λάβει υπόψιν διάφορες οπτικές γωνίες • System end-users • Business customers • Line managers • IT managers • Senior managers • Συνεντεύξεις με διάφορους εμπλεκόμενους και αντιπαραβολή των αποτελεσμάτων τους

31. Αποτίμηση ποιότητας συστήματος • Αποτίμηση επιχειρησιακής διαδικασίας • Πόσο καλά υποστηρίζει η επιχειρησιακή διαδικασία τους τρέχοντες στόχους της επιχείρησης; • Αποτίμηση περιβάλλοντος • Πόσο αποτελεσματικό είναι το περιβάλλον του συστήματος και πόσο κοστίζει η συντήρησή του; • Αποτίμηση εφαρμογής • Ποιά είναι η ποιότητα της εφαρμογής λογισμικού του συστήματος;

32. Αποτίμηση επιχειρησιακής διαδικασίας • Χρήση viewpoint-oriented προσέγγισης και αναζήτηση απαντήσεων από τους εμπλεκόμενους στο σύστημα(stakeholders) • Υπάρχει καθορισμένο κάποιο μοντέλο διαδικασίας; Αν ναι, αυτό ακολουθείται; • Υπάρχουν τμήματα του οργανισμού που χρησιμοποιούν διαφορετικές διαδικασίες για την ίδια λειτουργία; • Πώς υιοθετήθηκε η συγκεκριμένη διαδικασία; • Ποιά η σχέση με άλλες επιχειρησιακές διαδικασίες και είναι αυτές απαραίτητες; • Η διαδικασία υποσηρίζεται αποδοτικά από την εφαρμογή λογισμικού του ΣΚλ;

33. Αποτίμηση περιβάλλοντος

34. Αποτίμηση εφαρμογής

35. Μετρικές συστήματος • Η συλλογή ποσοτικών δεδομένωνεπίσης βοηθά στην αποτίμηση της ποιότητας του συστήματος, π.χ. : • Ο αριθμός των αιτημάτων για αλλαγές • Ο αριθμός των διαφορετικών user interfaces που χρησιμοποιεί το σύστημα • Ο όγκος των δεδομένων που διαχειρίζεται το σύστημα