Systems analysis in IT — Ανάλυση συστημάτων στην πληροφορική

From Systems analysis wiki
Jump to navigation Jump to search

Συστημική Ανάλυση στην Πληροφορική (Systems Analysis and Design) — προσέγγιση για τον σχεδιασμό και την ανάπτυξη πληροφοριακών συστημάτων από την αρχική ιδέα έως τη λειτουργία, η οποία περιλαμβάνει τον εντοπισμό αναγκών, την τυποποίηση απαιτήσεων, τη μοντελοποίηση του πεδίου εφαρμογής και των διεργασιών, καθώς και την αξιολόγηση εναλλακτικών και κινδύνων. Με άλλα λόγια, η συστημική ανάλυση στην Πληροφορική είναι το στάδιο ανάπτυξης κατά το οποίο οι ειδικοί μελετούν το πρόβλημα, καθορίζουν τι πρέπει να κάνει το σύστημα και αναπτύσσουν λύσεις για τη δημιουργία του.

Η κλασική συστημική ανάλυση καλύπτει ένα ευρύ φάσμα τομέων εφαρμογής, όχι μόνο την ανάπτυξη λογισμικού, αλλά και οργανωτικές αλλαγές, στρατηγικές και άλλες πτυχές.[1] [2]

Αντικείμενο και Στόχοι της Συστημικής Ανάλυσης στην Πληροφορική

Αντικείμενο της συστημικής ανάλυσης στην Πληροφορική είναι το πληροφοριακό σύστημα (το λογισμικό προϊόν ή/και η υπηρεσία) σε ολόκληρο τον κύκλο ζωής του — από τη σύλληψη και την αιτιολόγηση έως την υλοποίηση και τη λειτουργία.

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

Οι στόχοι της συστημικής ανάλυσης περιλαμβάνουν:

  • Εντοπισμός αναγκών και στόχων των stakeholders. Ο αναλυτής συλλέγει και διευκρινίζει τις προσδοκίες των πελατών, των χρηστών και άλλων ενδιαφερόμενων μερών· χρησιμοποιούνται συνεντεύξεις, ερωτηματολόγια, παρατήρηση και ανάλυση τρεχουσών διεργασιών. Στην έξοδο διαμορφώνεται η αρχική προδιαγραφή απαιτήσεων με διαχωρισμό σε λειτουργικές («τι πρέπει να κάνει το σύστημα») και μη λειτουργικές (αξιοπιστία, απόδοση, ασφάλεια κ.λπ.).[1][2]
  • Τυποποίηση και τεκμηρίωση απαιτήσεων. Τα αιτήματα μετατρέπονται σε επαληθεύσιμες απαιτήσεις. Μια καλά διατυπωμένη απαίτηση πρέπει να είναι σαφής και αδιαμφισβήτητη, πλήρης, συνεκτική, επαληθεύσιμη και ανιχνεύσιμη σε υψηλότερου επιπέδου στόχους· το σύνολο απαιτήσεων — συμφωνημένο και ολοκληρωμένο.[3][4] Στην πράξη χρησιμοποιούνται τυποποιημένα έγγραφα: SRS (Software Requirements Specification) σύμφωνα με ISO/IEC/IEEE 29148, καθώς και, σε ορισμένους κλάδους, URS (User Requirements Specification) και λειτουργικές προδιαγραφές.[5][6][7]
  • Ανάλυση και μοντελοποίηση συστήματος. Για την κατανόηση του πώς το σύστημα θα λειτουργεί και θα αλληλεπιδρά με τον εξωτερικό κόσμο, δημιουργούνται μοντέλα: διαγράμματα περιπτώσεων χρήσης (Use Case) για σενάρια χρήσης, DFD για ροές δεδομένων και επιχειρηματικές διεργασίες, διαγράμματα κλάσεων/συστατικών κ.ά. Τα μοντέλα χρησιμεύουν ως βάση για τη σύγκριση εναλλακτικών λύσεων και αρχιτεκτονικών.[8][9][10]
  • Αξιολόγηση σκοπιμότητας και επιλογή λύσης. Διεξάγεται feasibility study (τεχνική, οργανωτική, οικονομική, χρονοδιαγραμματική σκοπιμότητα) και σύγκριση αρχιτεκτονικών εναλλακτικών (trade-off). Για την αξιολόγηση της ποιότητας της αρχιτεκτονικής βάσει χαρακτηριστικών (π.χ., απόδοση, επεκτασιμότητα, τροποποιησιμότητα) εφαρμόζονται μέθοδοι όπως το ATAM (Architecture Tradeoff Analysis Method).[11][12] Η επιλογή μεταξύ, για παράδειγμα, μονολιθικής και μικροϋπηρεσιακής αρχιτεκτονικής [3] βασίζεται σε ρητούς συμβιβασμούς (πολυπλοκότητα λειτουργίας vs. ανεξάρτητη επεκτασιμότητα και ταχύτητα παράδοσης) σύμφωνα με τις συστάσεις βιομηχανικών οδηγών.[13][14]
  • Προετοιμασία αντικειμένων έργου. Από τα αποτελέσματα της ανάλυσης διαμορφώνονται:
    • εγκεκριμένη προδιαγραφή απαιτήσεων (με αναφορά στη σπουδαιότητά τους),
    • εννοιολογικό μοντέλο συστήματος (διαγράμματα/περιγραφές),
    • αρχιτεκτονικές και σχεδιαστικές αποφάσεις (σχήματα δεδομένων, διεπαφές εξωτερικών συστημάτων),
    • σχέδιο υλοποίησης (φάσεις/λειτουργικές μονάδες).
    • Κρίσιμο είναι να διασφαλίζεται η ιχνηλατισιμότητα (bidirectional traceability) των απαιτήσεων στα στοιχεία σχεδιασμού και τα τεστ.[15][4]

Η επιτυχία ενός έργου Πληροφορικής εξαρτάται σε μεγάλο βαθμό από ώριμες πρακτικές διαχείρισης απαιτήσεων και αρχιτεκτονικής. Έρευνα που διεξήγαγαν McKinsey και Oxford έδειξε ότι τα μεγάλα έργα Πληροφορικής συχνά υπερβαίνουν τον προϋπολογισμό και τα χρονοδιαγράμματα. Η έρευνα αυτή ανέδειξε επίσης πόσο σημαντικό είναι να διαχειρίζεται κανείς σωστά τη στρατηγική, να αλληλεπιδρά με τους ενδιαφερόμενους και να συλλέγει απαιτήσεις με σωστό τρόπο. Όλα αυτά μπορούν να επηρεάσουν σε μεγάλο βαθμό την επιτυχία ή την αποτυχία του έργου.[16]

Προσεγγίσεις και Μεθοδολογίες στη Συστημική Ανάλυση Πληροφορικής

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

  • Σκληρή και μαλακή προσέγγιση. Στα έργα Πληροφορικής η σκληρή προσέγγιση (hard systems) προϋποθέτει εκ των προτέρων τυποποιημένους στόχους και απαιτήσεις, αποσύνθεση και σχεδιασμό «από πάνω προς τα κάτω». Η μαλακή προσέγγιση (soft systems) εφαρμόζεται όταν οι στόχοι είναι ασαφείς και υπάρχουν πολλαπλές οπτικές γωνίες: χρησιμοποιούνται στοιχεία Soft Systems Methodology (SSM) (π.χ., rich picture, ριζικοί ορισμοί, CATWOE) για τη συμφωνία κατανόησης του προβλήματος και των επιθυμητών αλλαγών· στη συνέχεια τα αποτελέσματα μεταφράζονται σε επίσημες απαιτήσεις.[17][18]
  • Μεθοδολογία SSM (Soft Systems Methodology). Αρχικά αναπτυγμένη από τον Πίτερ Τσέκλαντ για οργανωτικές αλλαγές, η SSM είναι χρήσιμη στα προ-αναπτυξιακά στάδια στην Πληροφορική: από τη διερεύνηση της προβληματικής κατάστασης και τη διατύπωση ριζικών ορισμών (μεταξύ άλλων μέσω CATWOE) έως τη σύγκριση εννοιολογικών μοντέλων με την πραγματικότητα και την επίτευξη συναίνεσης μεταξύ stakeholders.[19][20]
  • Δομημένες μεθοδολογίες: SADT/IDEF0. Το SADT μοντελοποιεί το σύστημα ως ιεραρχία λειτουργιών· ο τυποποιημένος συμβολισμός IDEF0 (IEEE 1320.1) καταγράφει τις λειτουργίες και τις διεπαφές I-C-O-M (Inputs, Controls, Outputs, Mechanisms). Η μέθοδος είναι κατάλληλη για λειτουργική αποσύνθεση και συμφωνία ορίων συστήματος ανεξάρτητα από αλγορίθμους.[21][22]
  • Αντικειμενοστραφής ανάλυση: UML και SysML (MBSE). Το UML έχει καταστεί η βασική γλώσσα για απαιτήσεις και σχεδιασμό (διαγράμματα περιπτώσεων χρήσης, κλάσεων, ακολουθιών κ.ά.) και διευκολύνει την επικύρωση σεναρίων με τους χρήστες· το SysML επεκτείνει το UML για τη συστημική μηχανική (διαγράμματα απαιτήσεων, παραμετρικά διαγράμματα) και βασίζεται στην προσέγγιση MBSE, όπου το μοντέλο είναι το κεντρικό αντικείμενο σε όλα τα στάδια από τις απαιτήσεις έως τα τεστ.[23][24][25]
  • Μοντελοποίηση επιχειρηματικών διεργασιών: BPMN. Το πρότυπο BPMN χρησιμοποιείται για γραφική περιγραφή διεργασιών (pools, ροές εργασίας, γεγονότα, πύλες), συμπεριλαμβανομένης της σύγκρισης as-is/to-be στις προδιαγραφές απαιτήσεων και ολοκλήρωσης.[26][27]
  • Σύνδεση με τη μηχανική απαιτήσεων. Η διαδικασία περιλαμβάνει τα στάδια elicitation–analysis–specification–validation–change management· τα κριτήρια «καλής απαίτησης» και η δομή SRS ρυθμίζονται από το ISO/IEC/IEEE 29148. Για την ιεράρχηση χρησιμοποιούνται τεχνικές MoSCoW (Must/Should/Could/Won't) και μέθοδοι πολυκριτηριακής επιλογής, όπως το AHP. Σε ευέλικτες διαδικασίες, η δραστηριότητα συστημικής ανάλυσης αντικατοπτρίζεται στο backlog refinement και στην ιχνηλατισιμότητα απαιτήσεων.[28][29][30][31]
  • Σύνδεση με τη συστημική μηχανική. Για σύνθετα (κυβερνοφυσικά) συστήματα εφαρμόζεται το V-μοντέλο: στον «αριστερό» κλάδο — συστημική ανάλυση και αρχιτεκτονική, στον «δεξιό» — ολοκλήρωση, επαλήθευση και επικύρωση με σύνδεση στα αντικείμενα του αριστερού κλάδου. Οι μέθοδοι αξιολόγησης αρχιτεκτονικής βάσει ποιοτικών χαρακτηριστικών περιλαμβάνουν το ATAM (trade-off ανάλυση).[32][33]

Η συστημική ανάλυση στην Πληροφορική συνδυάζει δοκιμασμένες προσεγγίσεις — από μαλακές μεθόδους εναρμόνισης οράματος έως επίσημους συμβολισμούς και πρότυπα. Η επιλογή εργαλείων καθορίζεται από τον βαθμό σαφήνειας της εργασίας: σε υψηλή αβεβαιότητα ενισχύεται ο ρόλος της SSM και της διευκόλυνσης, σε σαφή όρια — τα επίσημα μοντέλα (UML/SysML, IDEF0, BPMN) και οι κανονισμοί.

Σύνδεση με Αρχιτεκτονική Πληροφορικής και Αρχιτεκτονική Επιχείρησης

Η συστημική ανάλυση σε έργα Πληροφορικής συνδέεται στενά με τον αρχιτεκτονικό σχεδιασμό. Οι ρόλοι του αναλυτή και του αρχιτέκτονα επικαλύπτονται: ο αναλυτής διατυπώνει τις απαιτήσεις και το λογικό μοντέλο, ο αρχιτέκτονας καθορίζει την επιθυμητή δομή της λύσης και τις τεχνικές ανταλλαγές· η εργασία διεξάγεται από κοινού.

  • Αρχιτεκτονική συστημάτων Πληροφορικής. Με τη στενή έννοια, η αρχιτεκτονική λογισμικού είναι η οργάνωση συστατικών, οι σχέσεις τους και οι αρχές που διέπουν τον σχεδιασμό της λύσης. Ο αναλυτής πρέπει να λαμβάνει υπόψη τα αρχιτεκτονικά στυλ (στρωματωτή, πελάτη-εξυπηρετητή, μικροϋπηρεσιακή, event-driven και άλλα), καθώς οι μη λειτουργικές απαιτήσεις (αξιοπιστία, επεκτασιμότητα, τροποποιησιμότητα) καθορίζουν συχνά τις αρχιτεκτονικές αποφάσεις και τις ανταλλαγές τους.[34][35] Στο πρώιμο στάδιο ανάλυσης διαμορφώνεται το αρχιτεκτονικό όραμα (high-level vision) και επεξεργάζεται ένα προκαταρκτικό περίγραμμα λύσης για τον έλεγχο της βιωσιμότητας των απαιτήσεων (η διάρκεια επαναλήψεων και η λεπτομέρεια εξαρτώνται από τη μεθοδολογία).[36]
  • Πρότυπα και προκαταρκτικές λύσεις. Για την ικανοποίηση μη λειτουργικών απαιτήσεων εφαρμόζονται αρχιτεκτονικά πρότυπα (architectural patterns). Για παράδειγμα, για ασύγχρονη επικοινωνία και χαλαρή σύζευξη — publish–subscribe μέσω μεσίτη μηνυμάτων σε event-driven αρχιτεκτονική.[37]
  • TOGAF (The Open Group Architecture Framework). Ένα από τα πιο διαδεδομένα πλαίσια εταιρικής αρχιτεκτονικής· περιλαμβάνει τη μέθοδο ADM (Architecture Development Method) και αντικείμενα διαχείρισης αρχιτεκτονικής (αποθετήριο, καταλόγους/πίνακες, αρχές). Στο TOGAF η διαχείριση απαιτήσεων είναι μια διαπερνώσα διαδικασία, ολοκληρωμένη σε όλες τις φάσεις ADM.[36] Για την υποστήριξη απαιτήσεων και ιχνηλατισιμότητας χρησιμοποιούνται κατάλογοι και πίνακες (π.χ., απαιτήσεις ↔ υπηρεσίες, λειτουργίες ↔ συστατικά), και διαχωρίζονται Architecture Building Blocks και Solution Building Blocks.[38][39] Οι αρχές και τα πρότυπα της επιχείρησης καταγράφονται σε αντίστοιχους καταλόγους και λειτουργούν ως εξωτερικές μη λειτουργικές απαιτήσεις για τις ομάδες έργου.[40] Η συμμόρφωση των λύσεων με την επιθυμητή αρχιτεκτονική επιβεβαιώνεται μέσω της διαδικασίας Architecture Compliance Review.[41] Η προσέγγιση TOGAF προβλέπει προκαταρκτικό Architecture Vision και επακόλουθη εξειδίκευση (δεδομένα/εφαρμογές/τεχνολογίες) με σχέδιο μετάβασης και διαχείριση αλλαγών απαιτήσεων.[42][43]
  • Zachman Framework. Μια πρώιμη και επιδραστική οντολογία αντικειμένων αρχιτεκτονικής επιχείρησης, παρουσιασμένη ως πίνακας 6×6 (προοπτικές × πτυχές «τι/πώς/πού/ποιος/πότε/γιατί»). Η σειρά «σχεδιαστής» σχετίζεται με τη συστημική ανάλυση και σχεδιασμό· οι στήλες καθορίζουν την πληρότητα εξέτασης δεδομένων, λειτουργιών/διεργασιών, ρόλων, τοποθεσίας και κινήτρων. Το πλαίσιο λειτουργεί ως ταξινόμηση (και όχι ως μεθοδολογία) και βοηθά να εξασφαλιστεί η πληρότητα της περιγραφής λύσης στο τοπίο της επιχείρησης.[44]
  • Σύνδεση με Αρχιτεκτονική Επιχείρησης (Enterprise Architecture, EA). Ο συστημικός αναλυτής εργάζεται στο πλαίσιο της EA: νέες απαιτήσεις ιχνηλατούνται σε επιχειρηματικές ικανότητες και λειτουργικό μοντέλο· εφαρμόζονται πρότυπα και θεμελιώδεις περιορισμοί της επιχείρησης (ασφάλεια, διαλειτουργικότητα κ.λπ.).[45][36] Στο στάδιο έναρξης διαμορφώνεται το Architecture Vision (στόχοι/περιορισμοί, συγκεντρωτικές απαιτήσεις), στη συνέχεια ο αναλυτής εξειδικεύει, διατηρώντας ιχνηλατισιμότητα στο όραμα και τα εταιρικά πρότυπα· η μη συμμόρφωση με τα πρότυπα εντοπίζεται στις αρχιτεκτονικές αναθεωρήσεις και μπορεί να οδηγήσει σε αναθεωρήσεις της λύσης.[36][46]

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

Διαδικασίες και Πρακτικές

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

  • Κλασικό SDLC (Waterfall). Το στάδιο System Analysis & Requirements Definition προηγείται του σχεδιασμού και της υλοποίησης· οι απαιτήσεις καταγράφονται σε λεπτομερή SRS ως βάση σχεδιασμού και συμβολαίων. Είναι αποτελεσματικό σε σταθερά και ρυθμιζόμενα πεδία· οι κίνδυνοι «παγώματος» απαιτήσεων μειώνονται με SRR/αναθεωρήσεις και διαχείριση αλλαγών μέσω CCB.[47][48][49]
  • Ευέλικτες μεθοδολογίες (Agile). Η ανάλυση είναι συνεχής: αντί για τελική SRS τηρείται product backlog από user stories με κριτήρια αποδοχής, που εξευγενίζεται στο backlog refinement· εφαρμόζεται BDD (Given–When–Then)· ο κίνδυνος απώλειας συνολικής αρχιτεκτονικής αντιμετωπίζεται με πρώιμη αρχιτεκτονική επεξεργασία και διαφανή ιχνηλατισιμότητα απαιτήσεων ↔ υλοποίησης/τεστ.[50][51][52]
  • DevOps και SRE. Οι συχνές κυκλοφορίες απαιτούν λειτουργικές απαιτήσεις «εξ ορισμού»: αυτοματισμό, παρατηρησιμότητα, επαναφορά. Οι μη λειτουργικές απαιτήσεις διατυπώνονται ως SLO/SLI, διαχειρίζεται το error budget· στο backlog προστίθενται εργασίες για logs/μετρικές/traces/ειδοποιήσεις· για κυκλοφορία χωρίς διακοπή — πρότυπα blue/green και άλλα.[53][54][55]
  • Διαχείριση απαιτήσεων και κινδύνων. Οι απαιτήσεις στο ALM έχουν καταστάσεις και συνδέσεις με εργασίες/εκδόσεις/ελαττώματα· απαραίτητα είναι ο version control, η ανάλυση επιπτώσεων αλλαγών και η τακτική αναιεράρχηση.[56][57]
  • Διασφάλιση Ποιότητας (QA). Η ποιότητα θεσπίζεται στο στάδιο των απαιτήσεων: αναθεωρήσεις, «Three Amigos», σχέδιο Acceptance Test Plan, αυτοματοποιημένα τεστ κριτηρίων αποδοχής (BDD/ATDD).[58][59]
  • Παρατηρησιμότητα και αξιοπιστία. Στις απαιτήσεις περιλαμβάνονται SLA/SLO, MTTR και MTBF με μετρήσιμους στόχους και μεθόδους ελέγχου· οι παράμετροι λαμβάνονται από επιχείρηση/λειτουργία και ενσωματώνονται στην αρχιτεκτονική και τα τεστ αξιοπιστίας.[60][61]

Μετρικές και Ποιότητα Αντικειμένων

Για την αξιολόγηση της εργασίας του συστημικού αναλυτή και της ποιότητας των αποτελεσμάτων του εφαρμόζονται γενικά αποδεκτά κριτήρια. Ποιοτικές απαιτήσεις και μοντέλα — η βάση επιτυχημένου έργου, συνεπώς διαχειρίζονται σε ολόκληρο τον κύκλο ζωής (elicitation → specification → verification/validation → change management). Τα βασικά χαρακτηριστικά ποιότητας απαιτήσεων κατοχυρώνονται στα πρότυπα ISO/IEC/IEEE 29148 και (ιστορικά) IEEE 830.[3][62][1]

  • Ορθότητα (Correctness) — η απαίτηση αντικατοπτρίζει την πραγματική ανάγκη και έχει συμφωνηθεί με ειδικούς του πεδίου εφαρμογής· επιβεβαιώνεται με επικύρωση (review/inspection, πρωτότυπα, σενάρια).[1][4]
  • Πληρότητα (Completeness) — καλύπτονται ουσιαστικές πτυχές και συνθήκες.
    • Πληρότητα μεμονωμένης απαίτησης: αναφέρονται οι απαραίτητες λεπτομέρειες (π.χ., «η ένδειξη μεταβαίνει σε κατάσταση κόκκινο σε αποτυχία», και όχι απλώς «γίνεται κόκκινο»).
    • Πληρότητα προδιαγραφής: καλύπτονται σενάρια/ρόλοι, καθορίζονται NFR· επιτυγχάνεται με λίστες ελέγχου και ιχνηλατισιμότητα σε επιχειρηματικούς στόχους· χρήσιμος είναι ο ανεξάρτητος έλεγχος πληρότητας (QA/review).[3][63]
  • Μονοσήμαντο (Unambiguity) — οι διατυπώσεις ερμηνεύονται μοναδικά· βοηθά το γλωσσάριο, τα πρότυπα τύπου «το σύστημα πρέπει να κάνει Α, όταν Β, εφόσον Γ», παραδείγματα· τα διαγράμματα συνοδεύονται από υπόμνημα. Έλεγχος — αρχή «τεσσάρων ματιών».[3][1]
  • Συνέπεια (Consistency) — οι απαιτήσεις δεν αντιφάσκουν μεταξύ τους και σε εξωτερικούς περιορισμούς· εφαρμόζονται δομημένη οργάνωση, συνοπτικοί πίνακες χαρακτηριστικών, ομαδικές αναθεωρήσεις· ελέγχεται κανονιστική/πρότυπα συμμόρφωση.[3][63]
  • Επαληθευσιμότητα/Δυνατότητα δοκιμής (Verifiability) — η επίτευξη επιβεβαιώνεται με τεστ/επίδειξη/ανάλυση· μη επαληθεύσιμες διατυπώσεις αντικαθίστανται με μετρήσιμα κριτήρια· για NFR καθορίζονται μετρικές και εκ των προτέρων καθορίζονται κριτήρια αποδοχής.[3][63]
  • Τροποποιησιμότητα και ιχνηλατισιμότητα (Modifiability & Traceability) — μοναδικά ID, λογική δομή («μία ιδέα — μία παράγραφος»), απουσία διπλότυπων· τηρούνται συνδέσεις «απαίτηση ↔ πηγή/στόχος/σχεδιασμός/τεστ», τηρείται πίνακας ιχνηλατισιμότητας (RTM).[64][3]
  • Κατάταξη και ιεράρχηση — ποιότητα συνόλου απαιτήσεων· χρησιμοποιούνται τεχνικές MoSCoW και MCDM (π.χ., AHP)· η ιεράρχηση από κοινού με την επιχείρηση επηρεάζει τον σχεδιασμό και τους κινδύνους.[65][66]

Μετρικές ποιότητας απαιτήσεων (παραδείγματα):[63][1]

  • πυκνότητα ελαττωμάτων απαιτήσεων (παρατηρήσεις ανά 100 απαιτήσεις)·
  • αριθμός αλλαγών μετά τη βασική τεκμηρίωση·
  • μετρικές κάλυψης: ποσοστό απαιτήσεων με τεστ· ποσοστό απαιτήσεων ιχνηλατημένων σε επιχειρηματικούς στόχους·
  • σταθερότητα απαιτήσεων (αναλογία προστεθεισών/αφαιρεθεισών προς συνολικό αριθμό ανά περίοδο)·
  • μέγεθος/πολυπλοκότητα προδιαγραφής (μέσος αριθμός απαιτήσεων ανά use case, βάθος αποσύνθεσης)·
  • ικανοποίηση stakeholders (έρευνα).

Σε ώριμες διαδικασίες (π.χ., CMMI επίπεδο 3+) υπάρχουν κανονισμοί ποιότητας απαιτήσεων: επίσημες επαληθεύσεις, έλεγχοι συμμόρφωσης με πρότυπα, συλλογή/ανάλυση μετρικών.[67] Σε κρίσιμα πεδία (αεροναυτική, διάστημα κ.ά.) εφαρμόζονται επίσημες μέθοδοι για αύξηση αξιοπιστίας.[68]

Τυπικά Σφάλματα

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

Τυπικά προβλήματα, οι συνέπειές τους και τρόποι αποφυγής.

  • Ελλιπείς και παραλειφθείσες απαιτήσεις. Παραλείπονται ρόλοι με ειδικά δικαιώματα, οριακές περιπτώσεις και NFR. Συνέπειες: αναθεωρήσεις αρχιτεκτονικής και μετάθεση εκκίνησης. Πώς να αποφευχθεί: λίστες ελέγχου, καταιγισμός ιδεών «τι γίνεται αν…», έγκαιρη συμμετοχή δοκιμαστών, ιχνηλατισιμότητα σε επιχειρηματικούς στόχους.[1][69]
  • Ασαφείς, αμφίσημες διατυπώσεις. Συνέπειες: οι προγραμματιστές υλοποιούν «λάθος πράγμα», ο πελάτης δυσαρεστείται. Πώς να αποφευχθεί: μετρήσιμα κριτήρια, γλωσσάριο, πρότυπα «Α, όταν Β, εφόσον Γ», peer‑review.[3][69]
  • Αντιφατικές απαιτήσεις. Συνέπειες: καθυστερήσεις για αποσαφηνίσεις, επαναλειτουργίες στην ολοκλήρωση. Πώς να αποφευχθεί: δομημένη οργάνωση, έλεγχος επιχειρηματικών κανόνων/κανονιστικής, συνεδρίες επίλυσης συγκρούσεων, έλεγχος συνέπειας στις αναθεωρήσεις.[3][1]
  • Σύνδρομο «χρυσής επιμετάλλωσης» (gold‑plating). Συνέπειες: αύξηση εύρους, πολυπλοκότητας, νέα σημεία αποτυχίας. Πώς να αποφευχθεί: σύνδεση κάθε απαίτησης με στόχο/μετρική· στο Agile — να μην συμπεριλαμβάνεται περιττό στο backlog· κατοχύρωση εύρους· βλ. YAGNI.
  • Υπερβολική λεπτομέρεια εκεί που δεν χρειάζεται. Πώς να αποφευχθεί: διαχωρισμός τι/γιατί (απαιτήσεις) από πώς (σχεδιασμός/υλοποίηση)· εφαρμογή design‑free requirements όπου ενδείκνυται.[3]
  • Παράβαση διαχείρισης απαιτήσεων. Συνέπειες: σύγχυση εκδόσεων, υλοποίηση «λάθους πράγματος». Πώς να αποφευχθεί: ενιαία πηγή αλήθειας στο ALM, ιστορικοποίηση και καταστάσεις, RTM και ανάλυση επιπτώσεων αλλαγών· διαχείριση αλλαγών μέσω CCB.[64][1]
  • Απουσία συμμετοχής χρηστών. Πώς να αποφευχθεί: συνεντεύξεις, παρατήρηση, πρωτότυπα, τακτικές επιδείξεις· ρητή επικύρωση με stakeholders.[3][1]
  • Υπερβολικά παρατεταμένη «αναλυτική παράλυση». Πώς να αποφευχθεί: ζώνη επάρκειας, επαναληπτικότητα και timeboxing· εκκίνηση MVP/προσαυξήσεων και διόρθωση βάσει ανατροφοδότησης.[1]
  • Αγνόηση μη λειτουργικών απαιτήσεων. Πώς να αποφευχθεί: εξαγωγή NFR (π.χ., FURPS+), καθορισμός μετρήσιμων κριτηρίων, συμπερίληψή τους στο σχέδιο δοκιμών και τις αρχιτεκτονικές αποφάσεις.[1][3]
  • Επικοινωνιακά σφάλματα και «ανθρώπινος παράγοντας». Πώς να αντιμετωπιστεί: ανάπτυξη δεξιοτήτων συνέντευξης και διευκόλυνσης, διατήρηση ουδετερότητας, καταγραφή αποφάσεων και πηγών απαιτήσεων (ιχνηλατισιμότητα σε στόχους).[1]

Τα περισσότερα προβλήματα ανάγονται στην ποιότητα των διατυπώσεων, την πληρότητα και τη διαχειρισιμότητα απαιτήσεων· η εφαρμογή των προτύπων ISO/IEC/IEEE 29148 και των πρακτικών SWEBOK (επικυρωσιμότητα, ιχνηλατισιμότητα, επαναληπτικότητα) μειώνει σημαντικά τον κίνδυνο καθυστερήσεων και επαναλειτουργιών.[3][1]

Περιορισμοί

Παρά την αποτελεσματικότητά της στη μείωση αβεβαιότητας, η συστημική ανάλυση έχει τους δικούς της περιορισμούς:

  • Η πραγματικότητα είναι μεταβλητή και σύνθετη. Είναι αδύνατο να ληφθούν υπόψη όλοι οι παράγοντες, ειδικά σε μακροπρόθεσμα έργα. Ορισμένες απαιτήσεις θα εμφανιστούν αναπόφευκτα μετά την εκκίνηση του συστήματος. Είναι σημαντικό να επιδιώκεται η ελαχιστοποίηση των απροόπτων, αλλά πρέπει κανείς να είναι προετοιμασμένος για αλλαγές.
  • Οι απαιτήσεις εξαρτώνται από τους ανθρώπους. Οι επιχειρηματικές προτεραιότητες, οι νόμοι και η αγορά μπορούν να αλλάξουν. Η συστημική ανάλυση αποτυπώνει την τρέχουσα κατάσταση και δεν μπορεί να προβλέψει όλες τις εξωτερικές αλλαγές. Για προσαρμογή, είναι απαραίτητο να ενημερώνονται τακτικά οι απαιτήσεις και να εργάζεται κανείς επαναληπτικά.
  • Οι χρήστες δεν γνωρίζουν πάντα τι θέλουν, μέχρι να το δουν. Αυτός είναι ένας γνωστός περιορισμός. Το prototyping και οι ευέλικτες μεθοδολογίες, όπως το Agile, βοηθούν στην υπέρβαση αυτού του προβλήματος. Η ανάλυση στο χαρτί έχει τα όριά της, και για τη λήψη ακριβών δεδομένων χρειάζεται ανατροφοδότηση από υλοποιήσεις.
  • Ισορροπία μεταξύ χρόνου και ποιότητας. Η υπερβολικά λεπτομερής ανάλυση μπορεί να καταστεί παρωχημένη. Σε καινοτόμους τομείς είναι προτιμότερο να δημιουργηθεί γρήγορα ένα ελάχιστα βιώσιμο προϊόν (MVP) και να ληφθούν πραγματικά δεδομένα. Η συστημική ανάλυση είναι αποτελεσματική σε σταθερούς τομείς, αλλά σε ερευνητικά έργα (R&D) ο ρόλος της είναι περιορισμένος.
  • Ανθρώπινος παράγοντας. Ακόμα και οι καλύτερες μεθοδολογίες δεν αντισταθμίζουν την ανεπάρκεια του αναλυτή ή την απουσία του πελάτη. Είναι σημαντικό όλοι οι συμμετέχοντες στη διαδικασία να είναι εμπλεκόμενοι και κινητοποιημένοι.

Επίδραση Σύγχρονων Τεχνολογιών στη Συστημική Ανάλυση στην Πληροφορική

Η συστημική ανάλυση στην Πληροφορική εξελίσσεται συνεχώς υπό την επίδραση τεχνολογικών καινοτομιών. Ο αναλυτής του 21ου αιώνα εργάζεται σε συνθήκες εκρηκτικής αύξησης δεδομένων, καθολικής ενσωμάτωσης AI, ταχύτατου κύκλου ανάπτυξης και αυξημένης προσοχής στην ασφάλεια. Η επιτυχημένη πρακτική συστημικής ανάλυσης απαιτεί απόκτηση νέων γνώσεων (Data Science, κυβερνοασφάλεια, τεχνολογίες cloud) και ευελιξία στην εφαρμογή μεθόδων.

  • Δεδομένα και AI/ML: τι προστίθεται στην ανάλυση. Για συστήματα με AI, ήδη από την έναρξη καθορίζονται οι στόχοι και το πλαίσιο εφαρμογής, οι απαιτήσεις για πηγές και ποιότητα δεδομένων, καθώς και μετρικές εμπιστοσύνης στις αποφάσεις μοντέλου (αξιοπιστία, ασφάλεια, εξηγησιμότητα, εμπιστευτικότητα, δικαιοσύνη). Σχεδιάζονται έλεγχοι TEVV (testing, evaluation, verification, validation), παρακολούθηση κατά τη λειτουργία και ασφαλής απενεργοποίηση/απόσυρση μοντέλου. Αυτά τα βήματα αντιστοιχούν στις λειτουργίες GOVERN–MAP–MEASURE–MANAGE από το πλαίσιο NIST για διαχείριση κινδύνων AI· αντικατοπτρίζονται στις SRS, αρχιτεκτονική και σχέδια επαλήθευσης/λειτουργίας.[70]
  • DevSecOps: ασφάλεια «αριστερά» και εξ ορισμού. Η ενσωμάτωση ασφάλειας σε κάθε στάδιο CI/CD γίνεται κανόνας: αυτοματοποιημένοι έλεγχοι (SAST/DAST), σάρωση εξαρτήσεων και containers, πολιτικές ανάπτυξης, βασική παρατηρησιμότητα. Χρησιμοποιούνται αξιόπιστα μητρώα αντικειμένων και τυποποιημένες «σκληρυμένες» εικόνες· εφαρμόζονται αρχές μηδενικής εμπιστοσύνης. Στη συστημική ανάλυση περιγράφονται εκ των προτέρων σημεία ελέγχου αγωγού (συνθήκες διέλευσης σταδίων), σύνδεση απαιτήσεων με ελέγχους ασφαλείας και κανόνες μετάβασης μεταξύ περιβαλλόντων (dev/test/stage/prod).[71]
  • Τι αλλάζει στα έγγραφα (αντικείμενα). Ποια ενότητα εμφανίζεται ή διευκρινίζεται στα βασικά έγγραφα παρουσία Big Data και AI/ML και κατά την εργασία σε DevSecOps:
    • SRS / Προδιαγραφή απαιτήσεων: στόχοι και πλαίσιο εφαρμογής AI· απαιτήσεις δεδομένων (προέλευση, ποιότητα, ηθικοί και νομικοί περιορισμοί)· μετρικές μοντέλου (ακρίβεια, αξιοπιστία, χρόνος απόκρισης)· σχέδιο TEVV (testing, evaluation, verification, validation)· απαιτήσεις διαφάνειας/εξηγησιμότητας και ιδιωτικότητας· κριτήρια απενεργοποίησης/απόσυρσης μοντέλου από λειτουργία.[70]
    • Αρχιτεκτονική και αποφάσεις (Architecture, ADR): αποτελέσματα μοντελοποίησης απειλών· μέτρα «ασφάλεια εξ ορισμού» (κρυπτογράφηση, έλεγχος πρόσβασης, διαχείριση μυστικών, αρχή ελάχιστων δικαιωμάτων)· περιορισμοί χρήσης δεδομένων/μοντέλων· καταχωρήσεις ADR με αξιολόγηση κινδύνων και ανταλλαγών.[71][70]
    • Σχέδιο επαλήθευσης και επικύρωσης (V&V / TEVV): σενάρια δοκιμής μοντέλων και δεδομένων· κατώτατα όρια αποδοχής για μετρικές ποιότητας· παρακολούθηση data/model drift· διαδικασίες περιοδικής επανεκτίμησης και επανεπικύρωσης.[70]
    • Πολιτικές CI/CD και «πύλες» αγωγού: αυτοματοποιημένοι έλεγχοι SAST/DAST, SCA (εξαρτήσεις), σάρωση containers· υπογραφή και αποθήκευση αντικειμένων σε αξιόπιστα μητρώα· κανόνες προαγωγής μεταξύ περιβαλλόντων (dev/test/stage/prod) και συνθήκες αποκλεισμού build κατά αποτυχία ελέγχων· απαιτήσεις παρατηρησιμότητας εξ ορισμού.[71]
    • Σχέδιο διαχείρισης δεδομένων και μοντέλων: κατάλογος πηγών και lineage· κριτήρια ποιότητας και διαθεσιμότητας δεδομένων· εκδόσεις dataset/μοντέλων· πρόγραμμα (επαν)εκπαίδευσης και έλεγχος bias· πολιτική πρόσβασης και αποθήκευσης· σχέδιο ασφαλούς απενεργοποίησης μοντέλου και διαγραφής δεδομένων, εάν απαιτείται.[70]
    • Λειτουργία και παρατηρησιμότητα (Ops/Runbook): μετρικές εμπιστοσύνης AI και SLO· έλεγχος και καταγραφή· ειδοποιήσεις για υποβάθμιση/ανωμαλίες· σχέδιο αντιμετώπισης συμβάντων· fallback/kill‑switch για AI-συστατικά· απαιτήσεις αναφοράς και μετα-συμβαντικής ανάλυσης.[70][71]
    • Ιχνηλατισιμότητα (end‑to‑end): ρητές συνδέσεις «απαίτηση ↔ έλεγχος/επαλήθευση στον αγωγό» και «απαίτηση ↔ τεστ/παρακολούθηση στη λειτουργία», ώστε να είναι δυνατή η αποδεικτική επαλήθευση ασφάλειας και ποιότητας σε ολόκληρο τον κύκλο ζωής.[71][70]
  • Ρόλος του συστημικού αναλυτή.
    • διαχειρίζεται πλαίσιο και κινδύνους AI (φορείς, σενάρια εφαρμογής, υποθέσεις και περιορισμοί δεδομένων);
    • εξασφαλίζει ιχνηλατισιμότητα «απαίτηση ↔ έλεγχος ασφαλείας στον αγωγό»;
    • διατυπώνει επαληθεύσιμες μη λειτουργικές απαιτήσεις (ασφάλεια, διαφάνεια, παρατηρησιμότητα) σε ολόκληρο τον κύκλο ζωής συστήματος.[70][71]

Διαφορές από την Κλασική Συστημική Ανάλυση

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

Παρακάτω — βασικές διαφορές.

  • Στόχοι και αντικείμενο ανάλυσης. Η κλασική ανάλυση επιλύει ελάχιστα δομημένα, «ασαφή» προβλήματα και βελτιώνει ήδη υπάρχοντα κοινωνικοτεχνικά συστήματα (αστικό δίκτυο μεταφορών, στρατηγική εταιρείας, περιβαλλοντική πολιτική). Αντικείμενο — πραγματικό σύστημα· στόχος — βοήθεια στον Λήπτη Αποφάσεων να επιλέξει πορεία δράσης. Για τη συστημική ανάλυση στην Πληροφορική ο στόχος — να σχεδιαστεί και να δημιουργηθεί ένα νέο πληροφοριακό σύστημα ή λογισμικό προϊόν που πληροί τις απαιτήσεις. Αντικείμενο — το σχεδιαζόμενο σύστημα· εστίαση — συμπεριφορά και χαρακτηριστικά που χρειάζονται οι χρήστες.
  • Μεθοδολογικές βάσεις. Οι κλασικές σχολές βασίζονται στη συστημική σκέψη και συχνά στα μαθηματικά. Η σκληρή προσέγγιση (hard systems) — τυποποίηση προβλήματος, ποσοτικά κριτήρια, βελτιστοποίηση (όπως στο operations research). Οι μαλακές μεθοδολογίες (soft systems) αναγνωρίζουν την πολλαπλότητα οπτικών· παράδειγμα — Soft Systems Methodology (SSM), όπου μέσω συζητήσεων και εννοιολογικών μοντέλων συμφωνούνται επιθυμητές αλλαγές. Στην Πληροφορική, η βάση — μηχανικές πειθαρχίες: μηχανική απαιτήσεων, σχεδιασμός λογισμικού, αρχιτεκτονικά πλαίσια. Εφαρμόζονται τυποποιημένες διαδικασίες (ISO/IEC/IEEE 15288, 12207, 29148), συμβολισμοί UML/SysML και πρακτικές διαχείρισης αλλαγών.
  • Ρόλοι και αντικείμενα. Στην κλασική ανάλυση ο ρόλος «συστημικού αναλυτή» είναι συχνά άτυπος· τα αποτελέσματα — αναλυτική έκθεση, συστάσεις, μαθηματικά μοντέλα, σενάρια «τι‑εάν». Στην Πληροφορική ο ρόλος αναλυτή (ή επιχειρηματικού αναλυτή) είναι τυποποιημένος· εκδίδονται προδιαγραφές απαιτήσεων, μοντέλα συστήματος (UML, ER), προδιαγραφές διεπαφών, user stories και backlog — αντικείμενα που χρησιμοποιούνται άμεσα από προγραμματιστές και δοκιμαστές.
  • Κύκλος ζωής και διαδικασία. Η κλασική ανάλυση δεν έχει ενιαίο πρότυπο: τα βήματα εξαρτώνται από το πρόβλημα (στο SSM — από τη μελέτη κατάστασης έως την εφαρμογή αλλαγών). Στην Πληροφορική εφαρμόζονται τυποποιημένοι κύκλοι SDLC: στο καταρρακτοειδές μοντέλο υπάρχει ξεχωριστή φάση ανάλυσης απαιτήσεων· σε επαναληπτικές και ευέλικτες προσεγγίσεις η ανάλυση είναι συνεχής δραστηριότητα κάθε sprint. Σύγχρονες πρακτικές (DevOps, CI/CD) επεκτείνουν το πλαίσιο ανάλυσης στη λειτουργία: λαμβάνονται υπόψη απαιτήσεις συντηρησιμότητας, παρατηρησιμότητας και δυνατότητας ενημέρωσης. Με άλλα λόγια, η συστημική ανάλυση στην Πληροφορική είναι ενσωματωμένη στον κύκλο ζωής ανάπτυξης, ενώ η κλασική συχνά εκτελείται ως έργο/συμβουλευτική δραστηριότητα.

Συστημικός Αναλυτής

Συστημικός αναλυτής στην Πληροφορική — ειδικός υπεύθυνος για τη συστημική σκέψη στο σχεδιασμό και ανάπτυξη πληροφοριακών συστημάτων: διαμόρφωση και επικύρωση απαιτήσεων, μοντελοποίηση (UML/BPMN), συμφωνία αρχιτεκτονικών αποφάσεων και εξασφάλιση ολοκλήρωσης. Ο ρόλος και οι προϋποθέσεις πιστοποίησης στη Ρωσική Ομοσπονδία κατοχυρώνονται στο επαγγελματικό πρότυπο και το FGOS.

Κύριος στόχος του είδους επαγγελματικής δραστηριότητας: Εξασφάλιση συμμόρφωσης της υπηρεσίας Πληροφορικής, του αυτοματοποιημένου συστήματος, του αυτοματοποιημένου πληροφοριακού συστήματος, του αυτοματοποιημένου συστήματος διαχείρισης, του λογισμικού, του πληροφοριακού προϊόντος ή μέσου (εφεξής - Σύστημα) με το περιβάλλον, τις αρχικές απαιτήσεις και περιορισμούς, τους στόχους αυτοματοποίησης και αυτοματοποιημένης δραστηριότητας μέσω ανάπτυξης και παρόδου ποιοτικών και αλληλένδετων σχεδιαστικών αποφάσεων στα ενδιαφερόμενα μέρη κατά την εκκίνηση και συντονισμό εργασιών επιμέρους εκτελεστών σε ολόκληρο τον κύκλο ζωής του Συστήματος (Επαγγελματικό πρότυπο «Συστημικός αναλυτής» (εντολή Υπουργείου Εργασίας ΡΟ αρ. 367ν της 27.04.2023).[72]

Γλωσσάριο Βασικών Όρων

Βασικές Έννοιες και Συμμετέχοντες

  • Συστημική ανάλυση στην Πληροφορική — πειθαρχία της οποίας το αντικείμενο είναι το πληροφοριακό σύστημα σε ολόκληρο τον κύκλο ζωής του, από τη σύλληψη έως τη λειτουργία.
  • Stakeholders — άτομα ή ομάδες που ενδιαφέρονται ή επηρεάζονται από ένα έργο (πελάτες, χρήστες, διαχειριστές).
  • Αντικείμενα έργου — έγγραφα και αποτελέσματα που δημιουργούνται κατά τη διάρκεια του έργου, όπως προδιαγραφές, μοντέλα, σχέδια και αποφάσεις.

Απαιτήσεις: Είδη και Τεκμηρίωση

  • Λειτουργικές απαιτήσεις — περιγράφουν τι πρέπει να κάνει το σύστημα· τις λειτουργίες και τη συμπεριφορά του.
  • Μη λειτουργικές απαιτήσεις — περιγράφουν χαρακτηριστικά ποιότητας συστήματος (αξιοπιστία, απόδοση, ασφάλεια, ευχρηστία, επεκτασιμότητα κ.λπ.).
  • Προδιαγραφή απαιτήσεων (αρχική) — έγγραφο που περιέχει το αρχικό σύνολο απαιτήσεων, συλλεγμένων στα αρχικά στάδια του έργου.
  • SRS (Software Requirements Specification) — τυποποιημένο έγγραφο που περιγράφει λεπτομερώς τις απαιτήσεις λογισμικού σύμφωνα με διεθνή πρότυπα (π.χ., ISO/IEC/IEEE 29148).
  • URS (User Requirements Specification) — έγγραφο που περιγράφει τις απαιτήσεις χρήστη για το σύστημα από την άποψη επιχειρηματικών διεργασιών και προσδοκιών τελικού χρήστη.
  • Αρχιτεκτονικά σημαντικές απαιτήσεις (ASR) — απαιτήσεις που επηρεάζουν ουσιαστικά αρχιτεκτονικές αποφάσεις και ανταλλαγές.
  • Διαλειτουργικές απαιτήσεις (CFR) — συνώνυμο μη λειτουργικών απαιτήσεων, που υπογραμμίζει τον διαπερνώντα χαρακτήρα τους.
  • Κριτήρια αποδοχής (Acceptance Criteria) — επαληθεύσιμες συνθήκες, κατά την εκπλήρωση των οποίων η εργασία για μια απαίτηση θεωρείται αποδεκτή.
  • Definition of Ready (DoR) — συμφωνία ετοιμότητας στοιχείου backlog για ανάπτυξη (σαφήνεια, εκτίμηση, κριτήρια).
  • Definition of Done (DoD) — συμφωνία «ολοκλήρωσης» εργασίας (κώδικας, τεστ, τεκμηρίωση, ανάπτυξη).
  • Περιορισμός (Constraint) — σκληρή συνθήκη που περιορίζει τις αποφάσεις (προθεσμίες, πλατφόρμες, πρότυπα, άδειες).
  • Υπόθεση (Assumption) — παραδοχή που γίνεται αποδεκτή χωρίς απόδειξη, που απαιτεί επακόλουθη επικύρωση.
  • Ποιότητα απαιτήσεων — χαρακτηριστικά κατά ISO 29148: μονοσήμαντο, πληρότητα, συνέπεια, επαληθευσιμότητα, ατομικότητα.

Τυποποίηση, Ιχνηλατισιμότητα και Ιεράρχηση Απαιτήσεων

  • Τυποποίηση απαιτήσεων — διαδικασία μετατροπής άτυπων αιτημάτων σε σαφείς, επαληθεύσιμες και μονοσήμαντες απαιτήσεις.
  • Ιχνηλατισιμότητα απαιτήσεων — δυνατότητα παρακολούθησης κύκλου ζωής απαίτησης από την πηγή της έως την υλοποίηση, δοκιμή και ανάπτυξη.
  • Bidirectional traceability (αμφίδρομη ιχνηλατισιμότητα) — ικανότητα παρακολούθησης συνδέσεων μεταξύ απαιτήσεων, στοιχείων σχεδιασμού και σεναρίων δοκιμής τόσο σε άμεση όσο και σε αντίστροφη κατεύθυνση.
  • MoSCoW — τεχνική ιεράρχησης απαιτήσεων, που τις ταξινομεί ως Must-have (πρέπει να υπάρχει), Should-have (πρέπει να έχει), Could-have (μπορεί να έχει) και Won't-have (δεν θα έχει).
  • BDD (Behavior-Driven Development) — μεθοδολογία ανάπτυξης, στην οποία τα τεστ γράφονται σε φυσική γλώσσα, προσανατολισμένη στη συμπεριφορά συστήματος από την άποψη χρήστη (μορφή Given–When–Then).

Συμβολισμοί και Μοντελοποίηση

  • UML (Unified Modeling Language) — τυποποιημένη γλώσσα γραφικής μοντελοποίησης για προδιαγραφή, οπτικοποίηση, κατασκευή και τεκμηρίωση συστατικών λογισμικού συστημάτων.
  • SysML (Systems Modeling Language) — επέκταση UML για συστημική μηχανική, που υποστηρίζει μοντελοποίηση διαφόρων πτυχών σύνθετων συστημάτων, συμπεριλαμβανομένων απαιτήσεων, συμπεριφοράς, δομής και παραμέτρων.
  • BPMN (Business Process Model and Notation) — πρότυπο γραφικής σημειογραφίας για περιγραφή επιχειρηματικών διεργασιών, που επιτρέπει την οπτικοποίηση ροών εργασίας, γεγονότων, πυλών και pools.
  • MBSE (Model-Based Systems Engineering) — προσέγγιση συστημικής μηχανικής, όπου το μοντέλο είναι το κεντρικό αντικείμενο σε όλα τα στάδια κύκλου ζωής συστήματος, από τις απαιτήσεις έως τη δοκιμή.
  • ArchiMate — σημειογραφία εταιρικής αρχιτεκτονικής (επιχείρηση, εφαρμογές, τεχνολογίες) και οι σχέσεις τους.
  • DMN (Decision Model and Notation) — μοντελοποίηση επιχειρηματικών αποφάσεων και πινάκων κανόνων.
  • DFD (Data Flow Diagram) — διαγράμματα ροής δεδομένων (πλαίσιο, επίπεδα αποσύνθεσης).
  • ERD (Entity-Relationship Diagram) — μοντέλο πεδίου εφαρμογής με οντότητες, σχέσεις και χαρακτηριστικά.
  • CRUD-πίνακας — αντιστοιχία πράξεων Create/Read/Update/Delete σε οντότητες και ρόλους/λειτουργίες.

Αρχιτεκτονικά Στυλ και Αξιολόγηση Λύσεων

  • Μονολιθική αρχιτεκτονική — αρχιτεκτονική προσέγγιση κατά την οποία ολόκληρο το σύστημα αναπτύσσεται ως ενιαία, αδιαίρετη λειτουργική μονάδα.
  • Μικροϋπηρεσιακή αρχιτεκτονική — αρχιτεκτονική προσέγγιση κατά την οποία το σύστημα δομείται ως σύνολο μικρών, ανεξάρτητα αναπτύξιμων και επεκτάσιμων υπηρεσιών.
  • Trade-off (συμβιβασμός) — επιλογή μεταξύ αμοιβαία αποκλειόμενων ή αντικρουόμενων χαρακτηριστικών ή αποφάσεων, όπου η βελτίωση ενός χαρακτηριστικού γίνεται σε βάρος άλλου.
  • ATAM (Architecture Tradeoff Analysis Method) — μέθοδος αξιολόγησης αρχιτεκτονικής λογισμικού, που χρησιμοποιείται για ανάλυση ανταλλαγών μεταξύ ποιοτικών χαρακτηριστικών (π.χ., απόδοση, επεκτασιμότητα).

Εταιρική Αρχιτεκτονική και Πλαίσια

  • TOGAF (The Open Group Architecture Framework) — ένα από τα πιο διαδεδομένα πλαίσια εταιρικής αρχιτεκτονικής, που περιλαμβάνει τη μέθοδο ADM (Architecture Development Method) για ανάπτυξη και διαχείριση αρχιτεκτονικής.
  • Zachman Framework — οντολογία αντικειμένων αρχιτεκτονικής επιχείρησης, παρουσιασμένη ως πίνακας 6×6, που ταξινομεί διάφορες πτυχές αρχιτεκτονικής από διαφορετικές προοπτικές.

Προσεγγίσεις Ανάλυσης και Διαδικασίες Ανάπτυξης

  • Σκληρή προσέγγιση (Hard Systems) — μεθοδολογία συστημικής ανάλυσης που προϋποθέτει εκ των προτέρων τυποποιημένους στόχους και απαιτήσεις, αποσύνθεση και σχεδιασμό «από πάνω προς τα κάτω», αποτελεσματική για σαφώς ορισμένα ζητήματα.
  • Μαλακή προσέγγιση (Soft Systems) — μεθοδολογία συστημικής ανάλυσης, εφαρμοζόμενη όταν οι στόχοι είναι ασαφείς και υπάρχουν πολλαπλές οπτικές γωνίες stakeholders, κατευθυνόμενη στη συμφωνία κατανόησης του προβλήματος και επιθυμητών αλλαγών.
  • SSM (Soft Systems Methodology) — συγκεκριμένη μεθοδολογία μαλακής συστημικής προσέγγισης, αναπτυγμένη από τον Πίτερ Τσέκλαντ, που χρησιμοποιεί εργαλεία όπως rich picture, ριζικοί ορισμοί και CATWOE.
  • Waterfall (καταρρακτοειδές μοντέλο) — κλασική μεθοδολογία ανάπτυξης λογισμικού, όπου τα στάδια (ανάλυση, σχεδιασμός, υλοποίηση, δοκιμή, εφαρμογή) εκτελούνται διαδοχικά, με πλήρη ολοκλήρωση του προηγούμενου σταδίου πριν την έναρξη του επόμενου.
  • Agile — ομάδα ευέλικτων μεθοδολογιών ανάπτυξης λογισμικού, προσανατολισμένων στην επαναληπτική ανάπτυξη, προσαρμογή στις αλλαγές, αλληλεπίδραση με τον πελάτη και συνεχή παροχή αξίας.

Μέθοδοι Επιλογής και Τυπικά Σφάλματα

  • AHP (Analytic Hierarchy Process) — μέθοδος πολυκριτηριακής επιλογής, που επιτρέπει τη δομημένη οργάνωση σύνθετων προβλημάτων και αξιολόγηση εναλλακτικών βάσει ιεραρχίας κριτηρίων.
  • Gold-plating (σύνδρομο «χρυσής επιμετάλλωσης») — σφάλμα στη συστημική ανάλυση, που συνίσταται στην προσθήκη λειτουργικότητας που δεν απαιτείται από τους stakeholders, οδηγώντας σε αύξηση εύρους και πολυπλοκότητας έργου.

Σύνδεσμοι

  • ISO/IEC/IEEE 15288:2023 — System life cycle processes
  • ISO/IEC/IEEE 12207:2017 — Software life cycle processes
  • ISO/IEC/IEEE 29148:2018 — Requirements engineering
  • ISO/IEC/IEEE 42010:2022 — Architecture description
  • ISO/IEC 25010:2023 — Product quality model (SQuaRE)
  • ISO/IEC/IEEE 24748-2:2024 — Life cycle management — Guidelines for applying ISO/IEC/IEEE 15288
  • ISO/IEC/IEEE 15289:2019 — Content of life-cycle information items (documentation)
  • ISO/IEC/IEEE 42020:2019 — Architecture processes
  • ISO/IEC/IEEE 29119-1:2022 — Software testing — Part 1: General concepts
  • IEEE Std 1012-2024 — System, Software, and Hardware Verification and Validation
  • UML 2.5.1 — OMG Specification
  • BPMN 2.0.2 — OMG Specification
  • SysML v1.7 — OMG Specification
  • TOGAF Standard, 10th Edition — The Open Group
  • ArchiMate 3.2 — The Open Group
  • SEI ATAM — Architecture Tradeoff Analysis Method
  • NASA Systems Engineering Handbook, SP-2016-6105 Rev2 (PDF)
  • SWEBOK Guide v4.0a — IEEE Computer Society (PDF)
  • Guide to the Systems Engineering Body of Knowledge (SEBoK)
  • BABOK Guide v3 — IIBA
  • Google SRE Books — Official site
  • Microsoft Azure Well-Architected Framework — Official docs
  • Συστημική ανάλυση με απλά λόγια. YouTube
  • Συστημική ανάλυση στην Πληροφορική με απλά λόγια. YouTube

Βιβλιογραφία

  • ISO/IEC/IEEE (2023). 15288: System Life Cycle Processes.
  • INCOSE (2023). INCOSE Systems Engineering Handbook, 5η έκδ.
  • ISO/IEC/IEEE (2018). 29148: Systems and Software Engineering — Life Cycle Processes — Requirements Engineering.
  • IIBA (2015). A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), v3.
  • The Open Group (2022). The TOGAF® Standard, 10th Edition. Επίσημη δωρεάν έκδοση.
  • OMG (2017). Unified Modeling Language (UML®) 2.5.1 Specification. PDF.
  • OMG (2014). Business Process Model and Notation (BPMN™) 2.0.2 Specification. PDF.
  • OMG (2024). Systems Modeling Language (SysML®) 1.7 Specification. PDF.
  • The Open Group (2022). ArchiMate® 3.2 Specification. Επίσημη δωρεάν λήψη (υπό άδεια).
  • Bass, L.; Clements, P.; Kazman, R. (2021). Software Architecture in Practice, 4η έκδ.
  • Wiegers, K.; Beatty, J. (2013). Software Requirements, 3η έκδ.
  • Rozanski, N.; Woods, E. (2012). Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives, 2η έκδ.
  • Meadows, D. (2008). Thinking in Systems: A Primer.
  • Senge, P. M. (2006). The Fifth Discipline: The Art & Practice of the Learning Organization (αναθ. έκδ.).
  • Blanchard, B. S.; Fabrycky, W. J. (2010). Systems Engineering and Analysis, 5η έκδ.
  • Robertson, J.; Robertson, S. (2012). Mastering the Requirements Process: Getting Requirements Right, 3η έκδ.
  • van Lamsweerde, A. (2009). Requirements Engineering: From System Goals to UML Models to Software Specifications.
  • Hull, E.; Jackson, K.; Dick, J. (2017). Requirements Engineering, 4η έκδ.
  • Kendall, K. E.; Kendall, J. E. (2023). Systems Analysis and Design, 11η έκδ.
  • Dennis, A.; Wixom, B. H.; Tegarden, D. (2021). Systems Analysis and Design: An Object-Oriented Approach with UML, 8η έκδ.
  • Satzinger, J. W.; Jackson, R. B.; Burd, S. D. (2015). Systems Analysis and Design in a Changing World, 7η έκδ.
  • Fowler, M. (2003). UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3η έκδ.
  • Delligatti, L. (2013). SysML Distilled: A Brief Guide to the Systems Modeling Language.
  • Silver, B. (2011). BPMN Method and Style, 2η έκδ.
  • Lankhorst, M. et al. (2017). Enterprise Architecture at Work: Modelling, Communication and Analysis, 4η έκδ.
  • Richards, M.; Ford, N. (2020). Fundamentals of Software Architecture.
  • Fairbanks, G. (2010). Just Enough Software Architecture: A Risk-Driven Approach.
  • Keeling, M. (2017). Design It!: From Programmer to Software Architect.
  • Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software.
  • Vernon, V. (2013). Implementing Domain-Driven Design.
  • Brandolini, A. (2018). Introducing EventStorming: An Act of Deliberate Collective Learning.
  • Simsion, G.; Witt, G. (2015). Data Modeling Essentials, 4η έκδ.
  • Silverston, L. (2008–2009). The Data Model Resource Book, Vols. 1–3 (αναθ. εκδ.).
  • Keeney, R. L.; Raiffa, H. (1993). Decisions with Multiple Objectives: Preferences and Value Trade-Offs, 2η έκδ.
  • Saaty, T. L. (1980). The Analytic Hierarchy Process· (1990) Decision Making for Leaders.

Σημειώσεις

  1. ↑ 1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 1.12 IEEE Computer Society (2025). Guide to the Software Engineering Body of Knowledge (SWEBOK), v4.0a. Requirements Engineering: elicitation techniques. https://ieeecs-media.computer.org/media/education/swebok/swebok-v4.pdf
  2. ↑ Zowghi, D.; Coulin, C. (2005/2014). Requirements Elicitation: A Survey of Techniques, Approaches, and Tools. https://eecs481.org/readings/requirements.pdf
  3. ↑ 3.00 3.01 3.02 3.03 3.04 3.05 3.06 3.07 3.08 3.09 3.10 3.11 3.12 ISO/IEC/IEEE 29148 (2011/2018). Systems and software engineering — Requirements engineering. ISO overview page: «Defines the construct of a good requirement…». https://www.iso.org/standard/45171.html
  4. ↑ 4.0 4.1 4.2 NASA (2020). NPR 7123.1C — Systems Engineering Processes and Requirements. Определение «well-formed (clear and unambiguous), complete, consistent, individually verifiable and traceable». https://nodis3.gsfc.nasa.gov/displayAll.cfm?Internal_ID=N_PR_7123_001C_&page_name=all
  5. ↑ GMU (George Mason University). IEEE Software Requirements Specification Template (SRS). https://cs.gmu.edu/~rpettit/files/project/SRS-template.doc
  6. ↑ Westfall, L. (Cal Poly, .edu). The What, Why, Who, When and How of Software Requirements (упоминает URS). https://users.csc.calpoly.edu/~csturner/courses/300f06/readings/%5B3%5D_%20The_Why_What_Who_When_and_How_of_Software_Requirements.pdf
  7. ↑ Stanford University IT (.edu). Functional Specification Document Template. https://uit.stanford.edu/sites/default/files/2017/08/30/Functional%20Specification%20Document%20Template.docx
  8. ↑ Penn State (.edu). Elements of a Use Case Diagram. https://www.e-education.psu.edu/geog468/l8_p4.html
  9. ↑ UC Irvine (.edu). Data Flow Diagram. https://www.security.uci.edu/program/risk-assessment/data-flow-diagram/
  10. ↑ ISO/IEC/IEEE 42010 (2011/2022). Architecture description — требования к описанию архитектуры и точкам зрения. https://standards.ieee.org/ieee/42010/5334/
  11. ↑ Cornell University (.edu). CS 5150 — Feasibility Studies. https://www.cs.cornell.edu/courses/cs5150/2015fa/slides/C1-feasibility.pdf
  12. ↑ Carnegie Mellon SEI. Architecture Tradeoff Analysis Method (ATAM) — overview. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/
  13. ↑ Microsoft Azure Architecture Center. Architecture styles: microservices — benefits & complexity. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/
  14. ↑ Google Cloud. What Is Microservices Architecture? — Monolithic vs. microservices (обзор). https://cloud.google.com/learn/what-is-microservices-architecture
  15. ↑ NASA (2023). Requirements Management — Traceability, Bidirectional traceability (definitions). https://www.nasa.gov/reference/6-2-requirements-management/
  16. ↑ McKinsey (2012). Delivering large-scale IT projects on time, on budget, and on value. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value
  17. ↑ University of Cambridge, IfM. Soft Systems Methodology (SSM) — CATWOE, 3Es. https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/
  18. ↑ Lancaster University (ePrints). Soft Systems Methodology and root definitions. https://eprints.lancs.ac.uk/id/eprint/48770/1/Document.pdf
  19. ↑ University of Cambridge, IfM. Soft Systems Methodology (SSM). https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/
  20. ↑ UCL Discovery (.ac.uk). M. Haklay. Soft System Methodology (SSM). https://discovery.ucl.ac.uk/1296/1/paper13.pdf
  21. ↑ IEEE Std 1320.1-1998 (R2004). Functional Modeling Language — Syntax and Semantics for IDEF0. https://standards.ieee.org/ieee/1320.1/2003/
  22. ↑ ISO/IEC/IEEE 31320-1:2012. IDEF0: Function Modeling. https://cdn.standards.iteh.ai/samples/60615/9c848e7a1bc54042b774b3cb050872e7/ISO-IEC-IEEE-31320-1-2012.pdf
  23. ↑ University of Washington (.edu). UML Class Diagrams / UML overview (course material). https://courses.cs.washington.edu/courses/cse403/16au/lectures/L07.pdf
  24. ↑ JHU/APL (.edu). Modeling with SysML — tutorial. https://www.jhuapl.edu/sites/default/files/2023-03/ModelingwithSysMLTutorial.pdf
  25. ↑ MIT OCW (.edu). O. de Weck. Introduction to Systems Modeling Languages (incl. SysML, MBSE). https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/23fea897f48d11f45593fa4be698d749_MIT16_842F15_Ses3_sysmodlg.pdf
  26. ↑ IBM. What is Business Process Modeling and Notation (BPMN)?. https://www.ibm.com/think/topics/bpmn
  27. ↑ IBM Docs. Business Process Modeling Notation (BPMN) model. https://www.ibm.com/docs/en/iis/11.5.0?topic=types-business-process-modeling-notation-bpmn-model
  28. ↑ IEEE/ISO/IEC 29148:2018. Systems and software engineering — Requirements engineering (overview). https://standards.ieee.org/ieee/29148/6937/
  29. ↑ King’s College London (.ac.uk). What is MoSCoW prioritization?. https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/
  30. ↑ T. L. Saaty. How to Make a Decision: The Analytic Hierarchy Process. Interfaces 24(6), 1994. https://pubsonline.informs.org/doi/10.1287/inte.24.6.19
  31. ↑ Microsoft Learn (Azure Boards). Best practices for Agile project management — Refine each backlog. https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management
  32. ↑ MIT OCW (.edu). V-Model — Fundamentals of Systems Engineering. https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/resources/v-model/
  33. ↑ Carnegie Mellon SEI (.edu). Architecture Tradeoff Analysis Method (ATAM) — overview. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/
  34. ↑ Microsoft Azure Architecture Center. Architecture styles. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/
  35. ↑ Kazman, R.; Klein, M.; Clements, P. ATAM: Method for Architecture Evaluation. CMU/SEI Technical Report, 2000. https://www.sei.cmu.edu/documents/629/2000_005_001_13706.pdf
  36. ↑ 36.0 36.1 36.2 36.3 The Open Group. Introduction — The TOGAF® Standard. https://www.togaf.org/chap01.html
  37. ↑ Microsoft Azure Architecture Center. Event-Driven Architecture style. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven
  38. ↑ Jonkers, H. et al. ArchiMate® and the TOGAF® Framework. The Open Group (white paper). https://pubs.opengroup.org/onlinepubs/7698909899/toc.pdf
  39. ↑ Estrem, W. Building Blocks Revisited. The Open Group (presentation). https://archive.opengroup.org/public/member/proceedings/q411b/presentations/Estrem%20-%20Building%20Blocks%20Revisted.pdf
  40. ↑ The Open Group. Architecture Principles. https://pubs.opengroup.org/onlinepubs/7499919799/toc.pdf
  41. ↑ The Open Group. IT Architecture Compliance. https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm
  42. ↑ The TOGAF® Standard, Version 9.2 (спецификация). The Open Group. https://university.sk/wp-content/uploads/2020/01/TOGAF_v9_2_specifikacia.pdf
  43. ↑ Engelsman, W.; van Sinderen, M. Supporting Requirements Management in TOGAF and ArchiMate. The Open Group (white paper). https://pubs.opengroup.org/onlinepubs/7698999899/toc.pdf
  44. ↑ Zachman, J. A. A Framework for Information Systems Architecture. IBM Systems Journal, 26(3), 276–292, 1987. https://doi.org/10.1147/sj.263.0276
  45. ↑ MIT CISR. Classic Topics — Enterprise Architecture (определение EA как «organizing logic for business process and IT capabilities…»). https://cisr.mit.edu/content/classic-topics-enterprise-architecture
  46. ↑ The Open Group. IT Architecture Compliance. https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm
  47. ↑ Royce, W. W. (1970). Managing the Development of Large Software Systems. IEEE WESCON. Репринт (PDF): https://www.praxisframework.org/files/royce1970.pdf
  48. ↑ Defense Acquisition University. System Requirements Review (SRR) — Acquipedia. https://aaf.dau.edu/acquipedia/article/system-requirements-review-srr/
  49. ↑ NASA (2023). Requirements Management — baseline, change control (CCB). https://www.nasa.gov/reference/6-2-requirements-management/
  50. ↑ Microsoft Learn (Azure Boards). Best practices for Agile project management — Refine each backlog. https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management
  51. ↑ MSDN Magazine (Microsoft). BDD Primer: Behavior‑Driven Development with SpecFlow. https://learn.microsoft.com/en-us/archive/msdn-magazine/2010/december/msdn-magazine-bdd-primer-behavior-driven-development-with-specflow-and-watin
  52. ↑ Microsoft Learn. End‑to‑end traceability in Azure DevOps. https://learn.microsoft.com/en-us/azure/devops/cross-service/end-to-end-traceability
  53. ↑ Google SRE. Service Level Objectives; Error Budget Policy. https://sre.google/sre-book/service-level-objectives/ ; https://sre.google/workbook/error-budget-policy/
  54. ↑ Microsoft Learn. Azure Monitor — Overview. https://learn.microsoft.com/en-us/azure/azure-monitor/fundamentals/overview
  55. ↑ AWS Whitepaper. Blue/Green Deployments on AWS. https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html
  56. ↑ Microsoft Learn. Manage change — track, triage, and implement change requests. https://learn.microsoft.com/en-us/azure/devops/cross-service/manage-change
  57. ↑ Microsoft Learn (Azure Boards). Backlogs overview — create and manage your product backlog. https://learn.microsoft.com/en-us/azure/devops/boards/backlogs/backlogs-overview
  58. ↑ Microsoft Learn (Azure Test Plans). What is Azure Test Plans?. https://learn.microsoft.com/en-us/azure/devops/test/overview
  59. ↑ MSDN Magazine. Behavior‑Driven Design with SpecFlow. https://learn.microsoft.com/en-us/archive/msdn-magazine/2013/july/data-points-behavior-driven-design-with-specflow
  60. ↑ IBM. MTTR vs. MTBF: What’s the difference?. https://www.ibm.com/think/topics/mttr-vs-mtbf
  61. ↑ Google Cloud. Google Cloud Observability. https://cloud.google.com/products/observability
  62. ↑ IEEE Std 830‑1998. IEEE Recommended Practice for Software Requirements Specifications (исторический стандарт). Учебная копия (PDF): https://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf
  63. ↑ 63.0 63.1 63.2 63.3 NASA. Systems Engineering Handbook (NASA/SP‑2016‑6105 Rev2). https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf
  64. ↑ 64.0 64.1 NASA (2023). Requirements Management — traceability, baseline, CCB. https://www.nasa.gov/reference/6-2-requirements-management/
  65. ↑ King’s College London (.ac.uk). What is MoSCoW prioritization?. https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/
  66. ↑ Saaty, T. L. (1994). How to Make a Decision: The Analytic Hierarchy Process. Interfaces 24(6), 19–43. https://doi.org/10.1287/inte.24.6.19
  67. ↑ SEI / CMMI Institute. Capability Maturity Model Integration (CMMI) — Overview. https://www.sei.cmu.edu/cmmi/
  68. ↑ NASA Langley. What is Formal Methods?; NASA‑GB‑002‑95 Guidebook. https://shemesh.larc.nasa.gov/fm/fm-what.html ; https://ntrs.nasa.gov/api/citations/19980228002/downloads/19980228002.pdf
  69. ↑ 69.0 69.1 SEI (CMU). Common Testing Problems: Pitfalls to Prevent and Mitigate (о типичных проблемах требований/трассируемости). https://www.sei.cmu.edu/blog/common-testing-problems-pitfalls-to-prevent-and-mitigate/
  70. ↑ 70.0 70.1 70.2 70.3 70.4 70.5 70.6 70.7 NIST (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100‑1. https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf
  71. ↑ 71.0 71.1 71.2 71.3 71.4 71.5 U.S. DoD CIO (2021). DoD Enterprise DevSecOps Reference Design. https://dodcio.defense.gov/Portals/0/Documents/Library/DevSecOpsReferenceDesign.pdf
  72. ↑ Профессиональный стандарт «Системный аналитик» (приказ Минтруда РФ от 27.04.2023 № 367н).
Retrieved from "https://systems-analysis.ru/int/index.php?title=Systems_analysis_in_IT_—_Ανάλυση_συστημάτων_στην_πληροφορική&oldid=23571"