Analisi dei sistemi in IT

From Systems analysis Wiki
Jump to navigation Jump to search

Analisi dei Sistemi in IT (Systems Analysis and Design) — approccio alla progettazione e allo sviluppo di sistemi informativi dall'ideazione all'esercizio, che include l'identificazione dei bisogni, la formalizzazione dei requisiti, la modellazione del dominio applicativo e dei processi, nonché la valutazione delle alternative e dei rischi. In altre parole, l'analisi dei sistemi in IT è la fase di sviluppo in cui gli specialisti studiano il problema, definiscono cosa deve fare il sistema e sviluppano soluzioni per la sua creazione.

L'analisi dei sistemi classica abbraccia un'ampia gamma di ambiti applicativi, non solo lo sviluppo di software, ma anche i cambiamenti organizzativi, le strategie e altri aspetti.[1] [2]

Oggetto e compiti dell'analisi dei sistemi in IT

L'oggetto dell'analisi dei sistemi in IT è il sistema informativo (prodotto software e/o servizio) nell'intero ciclo di vita — dall'ideazione e giustificazione fino alla realizzazione e all'esercizio.

Il compito dell'analisi dei sistemi è trasformare le esigenze di business in un insieme coerente e verificabile di requisiti e decisioni architetturali: identificare e documentare gli obiettivi e i vincoli degli stakeholder, formalizzare i requisiti, modellare il dominio applicativo e i processi, valutare la fattibilità e i rischi delle alternative e giustificare l'architettura scelta. Il risultato è la creazione di documenti concordati e l'istituzione di collegamenti tracciabili tra requisiti, decisioni progettuali e test. Ciò garantisce la gestibilità e il controllo del processo di sviluppo.

I compiti dell'analisi dei sistemi includono:

  • Identificazione dei bisogni e degli obiettivi degli stakeholder. L'analista raccoglie e affina le aspettative di committenti, utenti e altre parti interessate; si utilizzano interviste, sondaggi, osservazione e analisi dei processi correnti. Il risultato è una specifica dei requisiti primaria con distinzione tra requisiti funzionali («cosa deve fare il sistema») e non funzionali (affidabilità, prestazioni, sicurezza, ecc.).[1][2]
  • Formalizzazione e documentazione dei requisiti. Le richieste vengono trasformate in requisiti verificabili. Un requisito ben formulato deve essere chiaro e non ambiguo, completo, non contraddittorio, verificabile e tracciabile rispetto agli obiettivi di livello superiore; l'insieme dei requisiti deve essere coerente e integro.[3][4] Nella pratica si utilizzano documenti standardizzati: SRS (Software Requirements Specification) secondo ISO/IEC/IEEE 29148, nonché, in alcuni settori, URS (User Requirements Specification) e specifiche funzionali.[5][6][7]
  • Analisi e modellazione del sistema. Per comprendere come il sistema funzionerà e interagirà con il mondo esterno, vengono costruiti modelli: diagrammi dei casi d'uso (Use Case) per gli scenari di utilizzo, DFD per i flussi di dati e i processi di business, diagrammi di classi/componenti e altri. I modelli servono come base per il confronto di soluzioni e architetture alternative.[8][9][10]
  • Valutazione della fattibilità e scelta della soluzione. Viene condotto uno feasibility study (fattibilità tecnica, organizzativa, economica, temporale) e un confronto tra alternative architetturali (trade-off). Per la valutazione della qualità dell'architettura secondo gli attributi (es. prestazioni, scalabilità, modificabilità) si applicano metodi come ATAM (Architecture Tradeoff Analysis Method).[11][12] La scelta tra, ad esempio, architettura monolitica e a microservizi [3] si basa su compromessi espliciti (complessità operativa vs. scalabilità indipendente e velocità di rilascio) secondo le raccomandazioni delle guide di settore.[13][14]
  • Preparazione degli artefatti progettuali. Al termine dell'analisi vengono prodotti:
    • la specifica dei requisiti approvata (con indicazione della loro importanza),
    • il modello concettuale del sistema (diagrammi/descrizioni),
    • le decisioni architetturali e progettuali (schemi dei dati, interfacce dei sistemi esterni),
    • il piano di realizzazione (fasi/moduli).
    • È fondamentale garantire la tracciabilità (bidirectional traceability) dei requisiti rispetto agli elementi di design e ai test.[15][4]

Il successo di un progetto IT dipende in larga misura dalla maturità delle pratiche di gestione dei requisiti e dell'architettura. Una ricerca condotta da McKinsey e Oxford ha dimostrato che i grandi progetti IT spesso superano il budget e i tempi. Questa ricerca ha anche evidenziato quanto sia importante gestire correttamente la strategia, interagire con le parti interessate e raccogliere i requisiti in modo appropriato. Tutto ciò può influire fortemente sul successo o sul fallimento del progetto.[16]

Approcci e metodologie nell'analisi dei sistemi IT

L'analisi dei sistemi in IT si basa sui principi del pensiero sistemico e sulle metodologie adattate allo sviluppo software. Nella pratica si combinano approcci «rigidi» e «morbidi», metodologie strutturate, notazioni orientate agli oggetti, nonché linguaggi di modellazione dei processi e dei requisiti.

  • Approcci rigido e morbido. Nei progetti IT, l'approccio rigido (hard systems) prevede obiettivi e requisiti formalizzabili in anticipo, decomposizione e progettazione «top-down». L'approccio morbido (soft systems) si applica quando gli obiettivi non sono chiari e i punti di vista sono molteplici: si utilizzano elementi della Soft Systems Methodology (SSM) (es. rich picture, definizioni radice, CATWOE) per armonizzare la comprensione del problema e i cambiamenti desiderati; successivamente i risultati vengono tradotti in requisiti formali.[17][18]
  • Metodologia SSM (Soft Systems Methodology). Originariamente sviluppata da Peter Checkland per i cambiamenti organizzativi, la SSM è utile nelle fasi pre-progettuali dell'IT: dall'esplorazione della situazione problematica e dalla formulazione delle definizioni radice (anche attraverso CATWOE) fino al confronto dei modelli concettuali con la realtà e al raggiungimento di un'accomodazione tra gli stakeholder.[19][20]
  • Metodologie strutturate: SADT/IDEF0. SADT modella il sistema come una gerarchia di funzioni; la notazione standard IDEF0 (IEEE 1320.1) fissa le funzioni e le loro interfacce I-C-O-M (Inputs, Controls, Outputs, Mechanisms). Il metodo è utile per la decomposizione funzionale e la definizione dei confini del sistema indipendentemente dagli algoritmi.[21][22]
  • Analisi orientata agli oggetti: UML e SysML (MBSE). UML è diventato il linguaggio base per i requisiti e il design (diagrammi dei casi d'uso, di classi, di sequenza, ecc.) e facilita la validazione degli scenari con gli utenti; SysML estende UML per l'ingegneria di sistema (diagrammi dei requisiti, diagrammi parametrici) e si basa sull'approccio MBSE, dove il modello è l'artefatto centrale attraverso le fasi dai requisiti ai test.[23][24][25]
  • Modellazione dei processi di business: BPMN. Lo standard BPMN viene utilizzato per la descrizione grafica dei processi (pool, flussi di lavoro, eventi, gateway), incluso il confronto as-is/to-be nelle specifiche dei requisiti e nell'integrazione.[26][27]
  • Collegamento con l'ingegneria dei requisiti. Il processo include le fasi elicitation–analysis–specification–validation–change management; i criteri del «buon requisito» e la struttura dell'SRS sono regolamentati da ISO/IEC/IEEE 29148. Per la prioritizzazione si applicano le tecniche MoSCoW (Must/Should/Could/Won't) e i metodi di scelta multicriteria, come AHP. Nei processi agili, l'attività di analisi dei sistemi si riflette nel backlog refinement e nella tracciabilità dei requisiti.[28][29][30][31]
  • Collegamento con l'ingegneria di sistema. Per i sistemi complessi (cyber-fisici) si applica il modello a V: sul «ramo sinistro» — analisi dei sistemi e architettura, sul «ramo destro» — integrazione, verifica e validazione con riferimento agli artefatti del ramo sinistro. I metodi di valutazione dell'architettura secondo gli attributi di qualità includono ATAM (analisi dei trade-off).[32][33]

L'analisi dei sistemi in IT combina approcci collaudati — dalle metodologie morbide di allineamento della visione alle notazioni formali e agli standard. La scelta degli strumenti è determinata dal grado di definizione del problema: in caso di elevata incertezza si rafforza il ruolo di SSM e della facilitazione, in presenza di confini chiari — i modelli formali (UML/SysML, IDEF0, BPMN) e le normative.

Collegamento con l'architettura IT e l'architettura d'impresa

L'analisi dei sistemi nei progetti IT è strettamente collegata alla progettazione architettonica. I ruoli di analista e architetto si sovrappongono: l'analista formula i requisiti e il modello logico, l'architetto definisce la struttura target della soluzione e i compromessi tecnici; il lavoro viene svolto congiuntamente.

  • Architettura dei sistemi IT. In senso stretto, l'architettura software è l'organizzazione dei componenti, le loro relazioni e i principi che guidano la progettazione della soluzione. Per l'analista è importante tenere conto degli stili architetturali (a strati, client–server, a microservizi, event-driven e altri), poiché i requisiti non funzionali (affidabilità, scalabilità, modificabilità) spesso determinano le decisioni architetturali e i loro compromessi.[34][35] Nella fase iniziale dell'analisi si forma la visione architetturale (high-level vision) e si elabora una bozza della soluzione per verificare la fattibilità dei requisiti (la durata delle iterazioni e il livello di dettaglio dipendono dalla metodologia).[36]
  • Template e soluzioni preliminari. Per soddisfare i requisiti non funzionali si utilizzano i pattern architetturali (architectural patterns). Ad esempio, per l'interazione asincrona e il basso accoppiamento — publish–subscribe tramite message broker nell'architettura event-driven.[37]
  • TOGAF (The Open Group Architecture Framework). Uno dei framework di architettura aziendale più diffusi; include il metodo ADM (Architecture Development Method) e gli artefatti di gestione dell'architettura (repository, cataloghi/matrici, principi). In TOGAF la gestione dei requisiti è un processo trasversale, integrato in tutte le fasi dell'ADM.[36] Per il supporto dei requisiti e la tracciabilità si utilizzano cataloghi e matrici (es. requisiti ↔ servizi, funzioni ↔ componenti) e si distinguono Architecture Building Blocks e Solution Building Blocks.[38][39] I principi e gli standard aziendali sono registrati nei cataloghi corrispondenti e fungono da requisiti non funzionali esterni per i team di progetto.[40] La conformità delle soluzioni all'architettura target è confermata dalla procedura di Architecture Compliance Review.[41] L'approccio TOGAF prevede una Architecture Vision preliminare e una successiva dettagliazione (dati/applicazioni/tecnologie) con piano di migrazione e gestione delle modifiche ai requisiti.[42][43]
  • Zachman Framework. Ontologia precoce e influente degli artefatti dell'architettura aziendale, presentata come una matrice 6×6 (prospettive × aspetti «cosa/come/dove/chi/quando/perché»). La riga «progettista» corrisponde all'analisi e alla progettazione dei sistemi; le colonne definiscono la completezza dell'analisi di dati, funzioni/processi, ruoli, ubicazione e motivazione. Il framework serve come classificazione (non come metodologia) e aiuta a garantire la completezza della descrizione della soluzione nel panorama aziendale.[44]
  • Collegamento con l'architettura d'impresa (Enterprise Architecture, EA). L'analista di sistema lavora nel contesto dell'EA: i nuovi requisiti vengono tracciati verso le capacità di business e il modello operativo; si applicano standard e vincoli principali dell'impresa (sicurezza, interoperabilità, ecc.).[45][36] Nella fase di avvio si forma la Architecture Vision (obiettivi/vincoli, requisiti di alto livello), poi l'analista dettaglia, mantenendo la tracciabilità verso la visione e gli standard aziendali; la mancata osservanza degli standard viene rilevata nelle revisioni architetturali e può portare a rielaborazioni della soluzione.[36][46]

In sintesi: l'analisi dei sistemi e la progettazione architettonica formano il binomio «requisiti → decisioni architetturali → compromessi sugli attributi di qualità». La scelta dei metodi (stili/pattern, artefatti TOGAF, classificazione Zachman) è determinata dalla natura del progetto e dal framework dell'architettura aziendale.

Processi e pratiche

L'analisi dei sistemi è integrata nell'intero ciclo di vita dello sviluppo e dell'esercizio del software, collegando gli obiettivi di business, l'architettura e la consegna. Include la ricerca pre-progettuale, la scelta dell'approccio, la formazione di artefatti verificabili e i requisiti di affidabilità, prestazioni, sicurezza e manutenibilità. Nel modello a cascata l'analisi viene eseguita prima della progettazione e della realizzazione, nei metodi agili — in modo continuo attraverso le iterazioni, e in DevOps — con enfasi sugli obiettivi operativi. Indipendentemente dall'approccio, l'analisi garantisce la tracciabilità, la gestione delle modifiche e dei rischi, la documentazione dei compromessi architetturali e il rispetto dei vincoli normativi, rendendo lo sviluppo prevedibile e gestibile.

  • SDLC classico (Waterfall). La fase di System Analysis & Requirements Definition precede la progettazione e la realizzazione; i requisiti sono fissati in una dettagliata SRS come base di pianificazione e contrattuale. È efficace in domini stabili e regolamentati; i rischi del «congelamento» dei requisiti vengono ridotti tramite SRR/revisioni e gestione delle modifiche attraverso il CCB.[47][48][49]
  • Metodologie agili (Agile). L'analisi è continua: invece di una SRS finale si gestisce un product backlog di user story con criteri di accettazione, affinato nel backlog refinement; si applica BDD (Given–When–Then); il rischio di perdere la coerenza architettonica viene compensato da una progettazione architettonica anticipata e da una tracciabilità trasparente requisiti ↔ realizzazione/test.[50][51][52]
  • DevOps e SRE. I rilasci frequenti richiedono requisiti operativi «di default»: automazione, osservabilità, rollback. I requisiti non funzionali vengono formulati come SLO/SLI, si gestisce l'error budget; al backlog vengono aggiunti task per log/metriche/trace/alert; per il rilascio senza downtime — pattern blue/green e altri.[53][54][55]
  • Gestione dei requisiti e dei rischi. I requisiti nell'ALM hanno stati e collegamenti con task/rilasci/difetti; sono obbligatori il version control, l'analisi dell'impatto delle modifiche e la riprioritizzazione regolare.[56][57]
  • Garanzia della qualità (QA). La qualità viene pianificata nella fase dei requisiti: revisioni, «Three Amigos», piano di Acceptance Test Plan, test automatici dei criteri di accettazione (BDD/ATDD).[58][59]
  • Osservabilità e affidabilità. Nei requisiti vengono inclusi SLA/SLO, MTTR e MTBF con obiettivi misurabili e metodi di controllo; i parametri provengono dal business/esercizio e vengono incorporati nell'architettura e nei test di affidabilità.[60][61]

Metriche e qualità degli artefatti

Per valutare il lavoro dell'analista di sistema e la qualità dei suoi risultati si applicano criteri consolidati. Requisiti e modelli di qualità sono la base del successo del progetto, pertanto vengono gestiti nell'intero ciclo di vita (elicitation → specification → verification/validation → change management). Gli attributi di qualità di base dei requisiti sono sanciti negli standard ISO/IEC/IEEE 29148 e (storicamente) IEEE 830.[3][62][1]

  • Correttezza (Correctness) — il requisito riflette il bisogno autentico ed è concordato con gli esperti del dominio; viene confermato dalla validazione (revisione/ispezione, prototipi, scenari).[1][4]
  • Completezza (Completeness) — gli aspetti e le condizioni sostanziali sono presi in considerazione.
    • Completezza del singolo requisito: sono indicati i dettagli necessari (es. «l'indicatore passa allo stato rosso in caso di guasto», e non semplicemente «diventa rosso»).
    • Completezza della specifica: scenari/ruoli sono coperti, gli NFR sono definiti; si raggiunge tramite checklist e tracciabilità verso gli obiettivi di business; è utile un audit indipendente di completezza (QA/revisione).[3][63]
  • Non ambiguità (Unambiguity) — le formulazioni sono interpretate in un unico modo; aiutano il glossario, i template del tipo «il sistema deve fare A, quando B, se C», gli esempi; i diagrammi sono accompagnati da legenda. Verifica — principio dei «quattro occhi».[3][1]
  • Coerenza (Consistency) — i requisiti non si contraddicono tra loro e con i vincoli esterni; si applicano strutturazione, tabelle riassuntive degli attributi, revisioni di gruppo; si verifica la conformità normativa/agli standard.[3][63]
  • Verificabilità/testabilità (Verifiability) — il raggiungimento è confermato da un test/dimostrazione/analisi; le formulazioni non verificabili vengono sostituite con criteri misurabili; per gli NFR si definiscono metriche e si fissano in anticipo i criteri di accettazione.[3][63]
  • Modificabilità e tracciabilità (Modifiability & Traceability) — ID univoci, struttura logica («un'idea — un paragrafo»), assenza di duplicati; si mantengono i collegamenti «requisito ↔ fonte/obiettivo/design/test», si gestisce la matrice di tracciabilità (RTM).[64][3]
  • Classificazione e prioritizzazione — qualità dell'insieme dei requisiti; si utilizzano le tecniche MoSCoW e MCDM (es. AHP); la prioritizzazione con il business influisce sulla pianificazione e sui rischi.[65][66]

Metriche di qualità dei requisiti (esempi):[63][1]

  • densità dei difetti dei requisiti (osservazioni per 100 requisiti);
  • numero di modifiche dopo la baseline;
  • metriche di copertura: percentuale di requisiti con test; percentuale di requisiti tracciabili verso obiettivi di business;
  • stabilità dei requisiti (rapporto tra aggiunti/rimossi e totale nel periodo);
  • dimensione/complessità della specifica (numero medio di requisiti per use case, profondità della decomposizione);
  • soddisfazione degli stakeholder (sondaggio).

Nei processi maturi (es. CMMI livello 3+) sono in vigore regolamenti di qualità dei requisiti: verifiche formali, audit di conformità ai template, raccolta/analisi delle metriche.[67] Nei domini critici (avionica, spazio, ecc.) si applicano metodi formali per aumentare l'affidabilità.[68]

Errori tipici

Nei progetti IT si riscontrano frequentemente errori di analisi dei sistemi: incompletezza e ambiguità dei requisiti, contraddizioni, confini sfumati, ignoranza degli aspetti non funzionali, integrazione mancata e sicurezza in ritardo. Ciò porta a rielaborazioni, ritardi, aumento dei costi e difetti.

Problemi tipici, le loro conseguenze e le modalità di prevenzione.

  • Incompletezza e requisiti mancanti. Si trascurano ruoli con privilegi speciali, casi limite e NFR. Conseguenze: rielaborazioni dell'architettura e posticipo del lancio. Come evitare: checklist, brainstorming «e se…», coinvolgimento precoce dei tester, tracciabilità verso gli obiettivi di business.[1][69]
  • Formulazioni poco chiare e ambigue. Conseguenze: gli sviluppatori realizzano «la cosa sbagliata», il committente è insoddisfatto. Come evitare: criteri misurabili, glossario, template «A, quando B, se C», peer‑review.[3][69]
  • Requisiti contraddittori. Conseguenze: ritardi per i chiarimenti, rielaborazioni in fase di integrazione. Come evitare: strutturazione, verifica delle regole di business/normativa, sessioni di risoluzione dei conflitti, controllo della coerenza in fase di revisione.[3][1]
  • Sindrome del «gold‑plating». Conseguenze: aumento del volume, complessità, nuovi punti di guasto. Come evitare: collegare ogni requisito a un obiettivo/metrica; in Agile — non includere elementi non necessari nel backlog; bloccare lo scope; cfr. YAGNI.
  • Eccessiva dettagliazione dove non necessaria. Come evitare: separare il cosa/perché (requisiti) dal come (design/realizzazione); applicare i design‑free requirements dove appropriato.[3]
  • Violazione della gestibilità dei requisiti. Conseguenze: confusione delle versioni, realizzazione della «cosa sbagliata». Come evitare: unica fonte di verità nell'ALM, storicizzazione e stati, RTM e analisi dell'impatto delle modifiche; gestione delle modifiche tramite CCB.[64][1]
  • Assenza di partecipazione degli utenti. Come evitare: interviste, osservazione, prototipi, dimostrazioni regolari; validazione esplicita con gli stakeholder.[3][1]
  • Eccessiva «paralisi analitica». Come evitare: zona di sufficienza, iteratività e timeboxing; lancio di MVP/incrementi e correzione in base al feedback.[1]
  • Ignoranza dei requisiti non funzionali. Come evitare: individuare gli NFR (es. FURPS+), definire criteri misurabili, includerli nel piano di test e nelle decisioni architetturali.[1][3]
  • Errori di comunicazione e «fattore umano». Come risolvere: sviluppare le competenze di intervista e facilitazione, mantenere la neutralità, documentare le decisioni e le fonti dei requisiti (tracciabilità verso gli obiettivi).[1]

La maggior parte dei problemi si riconduce alla qualità delle formulazioni, alla completezza e alla gestibilità dei requisiti; l'applicazione degli standard ISO/IEC/IEEE 29148 e delle pratiche SWEBOK (validabilità, tracciabilità, iteratività) riduce significativamente il rischio di ritardi e rielaborazioni.[3][1]

Limitazioni

Nonostante la sua efficacia nel ridurre l'incertezza, l'analisi dei sistemi ha le sue limitazioni:

  • La realtà è mutevole e complessa. È impossibile tenere conto di tutti i fattori, specialmente nei progetti a lungo termine. Alcuni requisiti emergeranno inevitabilmente solo dopo il lancio del sistema. È importante cercare di minimizzare le sorprese, ma bisogna essere pronti ai cambiamenti.
  • I requisiti dipendono dalle persone. Le priorità del business, le leggi e il mercato possono cambiare. L'analisi dei sistemi fotografa lo stato attuale e non può prevedere tutti i cambiamenti esterni. Per adattarsi è necessario aggiornare regolarmente i requisiti e lavorare in modo iterativo.
  • Gli utenti non sanno sempre cosa vogliono finché non lo vedono. Questo è un limite noto. La prototipazione e le metodologie agili come Agile aiutano a superare questo problema. L'analisi su carta ha i suoi limiti e per ottenere dati accurati è necessario il feedback sulle realizzazioni.
  • Equilibrio tra tempo e qualità. Un'analisi eccessivamente dettagliata può diventare obsoleta. Nei settori innovativi è meglio creare rapidamente un prodotto minimo vitale (MVP) e ottenere dati reali. L'analisi dei sistemi è efficace in domini stabili, ma nei progetti esplorativi (R&D) il suo ruolo è limitato.
  • Il fattore umano. Anche le migliori metodologie non compensano l'incompetenza dell'analista o la non disponibilità del committente. È importante che tutti i partecipanti al processo siano coinvolti e motivati.

Influenza delle tecnologie moderne sull'analisi dei sistemi in IT

L'analisi dei sistemi in IT è in continua evoluzione sotto l'influenza delle innovazioni tecnologiche. L'analista del XXI secolo opera in un contesto di crescita esplosiva dei dati, diffusione pervasiva dell'IA, ciclo di sviluppo rapido e maggiore attenzione alla sicurezza. Una pratica efficace di analisi dei sistemi richiede l'acquisizione di nuove conoscenze (Data Science, cybersicurezza, tecnologie cloud) e flessibilità nell'applicazione dei metodi.

  • Dati e AI/ML: cosa si aggiunge nell'analisi. Per i sistemi con IA, già all'avvio si fissano gli obiettivi e il contesto di applicazione, i requisiti sulle fonti e la qualità dei dati, nonché le metriche di fiducia nelle decisioni del modello (affidabilità, sicurezza, spiegabilità, riservatezza, equità). Vengono pianificate le verifiche TEVV (testing, evaluation, verification, validation), il monitoraggio in esercizio e la disattivazione/ritiro sicuro del modello. Questi passaggi corrispondono alle funzioni GOVERN–MAP–MEASURE–MANAGE del framework NIST per la gestione dei rischi dell'IA; vengono riflessi nell'SRS, nell'architettura e nei piani di verifica/esercizio.[70]
  • DevSecOps: sicurezza «a sinistra» e di default. L'integrazione della sicurezza in ogni fase del CI/CD diventa la norma: verifiche automatiche (SAST/DAST), scansione delle dipendenze e dei container, policy di deployment, osservabilità di base. Si utilizzano registry di artefatti attendibili e immagini «hardened» standardizzate; si applicano i principi di zero trust. Nell'analisi dei sistemi vengono descritti in anticipo i punti di controllo della pipeline (condizioni di passaggio tra le fasi), il collegamento dei requisiti con i controlli di sicurezza e le regole di transizione tra gli ambienti (dev/test/stage/prod).[71]
  • Cosa cambia nei documenti (artefatti). Quale sezione appare o viene precisata nei documenti chiave in presenza di Big Data e AI/ML e nel lavoro con DevSecOps:
    • SRS / Specifica dei requisiti: obiettivi e contesto di applicazione dell'IA; requisiti sui dati (provenienza, qualità, vincoli etici e legali); metriche del modello (accuratezza, affidabilità, tempo di risposta); piano TEVV (testing, evaluation, verification, validation); requisiti di trasparenza/spiegabilità e privacy; criteri di disattivazione/ritiro del modello dall'esercizio.[70]
    • Architettura e decisioni (Architecture, ADR): risultati della modellazione delle minacce; misure «sicurezza di default» (cifratura, controllo degli accessi, secret management, principio del minimo privilegio); restrizioni sull'utilizzo di dati/modelli; record ADR con valutazione dei rischi e dei compromessi.[71][70]
    • Piano di verifica e validazione (V&V / TEVV): scenari di test per modelli e dati; soglie di accettazione per le metriche di qualità; monitoraggio del drift dei dati/del modello; procedure di rivalutazione periodica e rivalidazione.[70]
    • Policy CI/CD e «gate» della pipeline: verifiche automatiche SAST/DAST, SCA (dipendenze), scansione dei container; firma e archiviazione degli artefatti in registry attendibili; regole di promozione tra ambienti (dev/test/stage/prod) e condizioni di blocco della build in caso di fallimento delle verifiche; requisiti di osservabilità di default.[71]
    • Piano di gestione dei dati e dei modelli: catalogo delle fonti e lineage; criteri di qualità e disponibilità dei dati; versioni dei dataset/modelli; pianificazione del (ri)addestramento e controllo del bias; policy di accesso e conservazione; piano di disattivazione sicura del modello e cancellazione dei dati, se richiesto.[70]
    • Esercizio e osservabilità (Ops/Runbook): metriche di fiducia nell'IA e SLO; audit e journaling; alert su degrado/anomalie; piano di risposta agli incidenti; fallback/kill‑switch per le componenti IA; requisiti di reportistica e analisi post-incidente.[70][71]
    • Tracciabilità (end‑to‑end): collegamenti espliciti «requisito ↔ controllo/verifica nella pipeline» e «requisito ↔ test/monitoraggio in esercizio», affinché sia possibile verificare in modo dimostrabile la sicurezza e la qualità nell'intero ciclo di vita.[71][70]
  • Ruolo dell'analista di sistema.
    • gestisce il contesto e i rischi dell'IA (attori, scenari di applicazione, assunzioni e vincoli sui dati);
    • garantisce la tracciabilità «requisito ↔ controllo di sicurezza nella pipeline»;
    • formula requisiti non funzionali verificabili (sicurezza, trasparenza, osservabilità) nell'intero ciclo di vita del sistema.[70][71]

Differenze rispetto all'analisi dei sistemi classica

Il termine «analisi dei sistemi» è storicamente più ampio dello sviluppo software. L'analisi dei sistemi classica è un approccio alla risoluzione di problemi complessi e interdisciplinari (sociali, economici, gestionali), basato sul pensiero sistemico e sui metodi quantitativi, di solito per supportare le decisioni manageriali. Nell'IT, per analisi dei sistemi si intende una disciplina applicata nell'ambito dell'ingegneria del software, orientata alla creazione di sistemi informativi.

Di seguito le principali differenze.

  • Obiettivi e oggetto dell'analisi. L'analisi classica risolve problemi scarsamente strutturati, «sfumati», e migliora i sistemi sociotecnici già esistenti (rete di trasporto urbana, strategia aziendale, politica ambientale). L'oggetto è il sistema reale; il compito è aiutare il decisore a scegliere un corso d'azione. Per l'analisi dei sistemi in IT, l'obiettivo è progettare e creare un nuovo sistema informativo o prodotto software che soddisfi i requisiti. L'oggetto è il sistema da progettare; il focus è sul comportamento e sulle caratteristiche necessarie agli utenti.
  • Fondamenti metodologici. Le scuole classiche si basano sul pensiero sistemico e spesso sulla matematica. L'approccio rigido (hard systems) — formalizzazione del problema, criteri quantitativi, ottimizzazione (come nella operations research). Le metodologie morbide (soft systems) riconoscono la molteplicità dei punti di vista; un esempio è la Soft Systems Methodology (SSM), dove attraverso discussioni e modelli concettuali si concordano i cambiamenti desiderati. Nell'IT la base sono le discipline ingegneristiche: ingegneria dei requisiti, progettazione software, framework architetturali. Si applicano processi standardizzati (ISO/IEC/IEEE 15288, 12207, 29148), notazioni UML/SysML e pratiche di gestione delle modifiche.
  • Ruoli e artefatti. Nell'analisi classica il ruolo dell'«analista di sistema» è spesso informale; i risultati sono rapporti analitici, raccomandazioni, modelli matematici, scenari «what-if». Nell'IT il ruolo dell'analista (o business analyst) è formalizzato; vengono prodotte specifiche dei requisiti, modelli del sistema (UML, ER), specifiche delle interfacce, user story e backlog — artefatti direttamente utilizzati da sviluppatori e tester.
  • Ciclo di vita e processo. L'analisi classica non ha un template unico: i passi dipendono dal problema (nella SSM — dall'esplorazione della situazione all'implementazione dei cambiamenti). Nell'IT sono adottati cicli SDLC standard: nel modello a cascata esiste una fase separata di analisi dei requisiti; negli approcci iterativi e agili l'analisi è un'attività continua di ogni sprint. Le pratiche moderne (DevOps, CI/CD) estendono i confini dell'analisi all'esercizio: vengono considerati i requisiti di manutenibilità, osservabilità e aggiornabilità. In altre parole, l'analisi dei sistemi in IT è integrata nel ciclo di vita dello sviluppo, mentre quella classica viene eseguita più spesso come attività progettuale/consulenziale.

Analista di sistema

L'analista di sistema in IT è uno specialista responsabile del pensiero sistemico nella progettazione e nello sviluppo dei sistemi informativi: formazione e validazione dei requisiti, modellazione (UML/BPMN), accordo sulle decisioni architetturali e garanzia dell'integrazione. Il ruolo e i requisiti di qualificazione nella Federazione Russa sono sanciti nello standard professionale e nel FGOS.

Obiettivo principale del tipo di attività professionale: Garantire la conformità del servizio IT, del sistema automatizzato, del sistema informativo automatizzato, del sistema di controllo automatizzato, del prodotto o strumento software e informativo (di seguito — Sistema) all'ambiente, ai requisiti e vincoli iniziali, agli obiettivi di automazione e dell'attività automatizzata, mediante lo sviluppo e la trasmissione di soluzioni progettuali di qualità e interconnesse alle parti interessate durante il lancio e il coordinamento del lavoro dei singoli esecutori nell'intero ciclo di vita del Sistema (Standard professionale «Analista di sistema» (ordinanza del Ministero del Lavoro della Federazione Russa del 27.04.2023 n. 367н).[72]

Glossario dei termini chiave

Concetti di base e partecipanti

  • Analisi dei sistemi in IT — disciplina il cui oggetto è il sistema informativo nell'intero suo ciclo di vita, dall'ideazione all'esercizio.
  • Stakeholder — persone o gruppi interessati al progetto o coinvolti da esso (committenti, utenti, manager).
  • Artefatti progettuali — documenti e risultati creati nel corso del progetto, come specifiche, modelli, piani e decisioni.

Requisiti: tipi e documentazione

  • Requisiti funzionali — descrivono cosa deve fare il sistema; le sue funzioni e il suo comportamento.
  • Requisiti non funzionali — descrivono gli attributi di qualità del sistema (affidabilità, prestazioni, sicurezza, usabilità, scalabilità, ecc.).
  • Specifica dei requisiti (primaria) — documento contenente l'insieme iniziale di requisiti raccolti nelle fasi iniziali del progetto.
  • SRS (Software Requirements Specification) — documento standardizzato che descrive in dettaglio i requisiti software secondo gli standard internazionali (es. ISO/IEC/IEEE 29148).
  • URS (User Requirements Specification) — documento che descrive i requisiti dell'utente verso il sistema dal punto di vista dei processi di business e delle aspettative dell'utente finale.
  • Requisiti architetturalmente significativi (ASR) — requisiti che influenzano significativamente le decisioni architetturali e i compromessi.
  • Requisiti cross-funzionali (CFR) — sinonimo di requisiti non funzionali, che ne sottolinea il carattere trasversale.
  • Criteri di accettazione (Acceptance Criteria) — condizioni verificabili al cui soddisfacimento il lavoro su un requisito è considerato accettato.
  • Definition of Ready (DoR) — accordo sulla disponibilità di un elemento del backlog allo sviluppo (chiarezza, stima, criteri).
  • Definition of Done (DoD) — accordo sulla «completezza» del lavoro (codice, test, documentazione, deployment).
  • Vincolo (Constraint) — condizione rigida che limita le soluzioni (scadenze, piattaforme, standard, licenze).
  • Assunzione (Assumption) — ipotesi accettata senza dimostrazione, che richiede una successiva validazione.
  • Qualità dei requisiti — proprietà secondo ISO 29148: non ambiguità, completezza, coerenza, verificabilità, atomicità.

Formalizzazione, tracciabilità e prioritizzazione dei requisiti

  • Formalizzazione dei requisiti — processo di trasformazione delle richieste informali in requisiti chiari, verificabili e non ambigui.
  • Tracciabilità dei requisiti — possibilità di seguire il ciclo di vita di un requisito dalla sua fonte fino alla realizzazione, al testing e al deployment.
  • Bidirectional traceability (tracciabilità bidirezionale) — capacità di seguire i collegamenti tra requisiti, elementi di design e scenari di test sia in avanti che all'indietro.
  • MoSCoW — tecnica di prioritizzazione dei requisiti che li classifica come Must-have (deve esserci), Should-have (dovrebbe esserci), Could-have (potrebbe esserci) e Won't-have (non ci sarà).
  • BDD (Behavior-Driven Development) — metodologia di sviluppo in cui i test vengono scritti in linguaggio naturale orientato al comportamento del sistema dal punto di vista dell'utente (formato Given–When–Then).

Notazioni e modellazione

  • UML (Unified Modeling Language) — linguaggio standardizzato di modellazione grafica per la specifica, la visualizzazione, la costruzione e la documentazione dei componenti dei sistemi software.
  • SysML (Systems Modeling Language) — estensione di UML per l'ingegneria di sistema, che supporta la modellazione di vari aspetti di sistemi complessi, inclusi requisiti, comportamento, struttura e parametri.
  • BPMN (Business Process Model and Notation) — standard di notazione grafica per la descrizione dei processi di business, che consente di visualizzare flussi di lavoro, eventi, gateway e pool.
  • MBSE (Model-Based Systems Engineering) — approccio all'ingegneria di sistema in cui il modello è l'artefatto centrale in tutte le fasi del ciclo di vita del sistema, dai requisiti al testing.
  • ArchiMate — notazione per l'architettura aziendale (business, applicazioni, tecnologie) e le loro relazioni.
  • DMN (Decision Model and Notation) — modellazione delle decisioni di business e delle tabelle di regole.
  • DFD (Data Flow Diagram) — diagrammi dei flussi di dati (contesto, livelli di decomposizione).
  • ERD (Entity-Relationship Diagram) — modello del dominio applicativo con entità, relazioni e attributi.
  • Matrice CRUD — corrispondenza delle operazioni Create/Read/Update/Delete con entità e ruoli/funzioni.

Stili architetturali e valutazione delle soluzioni

  • Architettura monolitica — approccio architetturale in cui l'intero sistema è sviluppato come un unico modulo indivisibile.
  • Architettura a microservizi — approccio architetturale in cui il sistema è costruito come un insieme di servizi piccoli, deployabili e scalabili in modo indipendente.
  • Trade-off (compromesso) — scelta tra caratteristiche o soluzioni mutuamente esclusive o in conflitto, dove il miglioramento di una caratteristica avviene a scapito di un'altra.
  • ATAM (Architecture Tradeoff Analysis Method) — metodo di valutazione dell'architettura software utilizzato per analizzare i compromessi tra attributi di qualità (es. prestazioni, scalabilità).

Architettura aziendale e framework

  • TOGAF (The Open Group Architecture Framework) — uno dei framework di architettura aziendale più diffusi, che include il metodo ADM (Architecture Development Method) per lo sviluppo e la gestione dell'architettura.
  • Zachman Framework — ontologia degli artefatti dell'architettura aziendale, presentata come una matrice 6×6, che classifica i vari aspetti dell'architettura da diverse prospettive.

Approcci all'analisi e ai processi di sviluppo

  • Approccio rigido (Hard Systems) — metodologia di analisi dei sistemi che prevede obiettivi e requisiti formalizzabili in anticipo, decomposizione e progettazione «top-down», efficace per problemi chiaramente definiti.
  • Approccio morbido (Soft Systems) — metodologia di analisi dei sistemi applicata in presenza di obiettivi poco chiari e molteplici punti di vista degli stakeholder, orientata all'armonizzazione della comprensione del problema e dei cambiamenti desiderati.
  • SSM (Soft Systems Methodology) — metodologia specifica dell'approccio sistemico morbido, sviluppata da Peter Checkland, che utilizza strumenti come rich picture, definizioni radice e CATWOE.
  • Waterfall (modello a cascata) — metodologia classica di sviluppo software in cui le fasi (analisi, progettazione, realizzazione, testing, implementazione) vengono eseguite in sequenza, con il completamento totale della fase precedente prima di iniziare la successiva.
  • Agile — gruppo di metodologie agili di sviluppo software, orientate allo sviluppo iterativo, all'adattamento ai cambiamenti, all'interazione con il committente e alla consegna continua di valore.

Metodi di scelta ed errori tipici

  • AHP (Analytic Hierarchy Process) — metodo di scelta multicriteria che consente di strutturare problemi complessi e valutare le alternative sulla base di una gerarchia di criteri.
  • Gold-plating (sindrome della «piastra d'oro») — errore nell'analisi dei sistemi che consiste nell'aggiunta di funzionalità non richieste dagli stakeholder, con conseguente aumento del volume e della complessità del progetto.

Riferimenti

  • 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
  • Analisi dei sistemi in parole semplici. YouTube
  • Analisi dei sistemi in IT in parole semplici. YouTube

Bibliografia

  • ISO/IEC/IEEE (2023). 15288: System Life Cycle Processes.
  • INCOSE (2023). INCOSE Systems Engineering Handbook, 5ª ed.
  • 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. Versione ufficiale gratuita.
  • 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. Download ufficiale gratuito (su licenza).
  • Bass, L.; Clements, P.; Kazman, R. (2021). Software Architecture in Practice, 4ª ed.
  • Wiegers, K.; Beatty, J. (2013). Software Requirements, 3ª ed.
  • Rozanski, N.; Woods, E. (2012). Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives, 2ª ed.
  • Meadows, D. (2008). Thinking in Systems: A Primer.
  • Senge, P. M. (2006). The Fifth Discipline: The Art & Practice of the Learning Organization (rev. ed.).
  • Blanchard, B. S.; Fabrycky, W. J. (2010). Systems Engineering and Analysis, 5ª ed.
  • Robertson, J.; Robertson, S. (2012). Mastering the Requirements Process: Getting Requirements Right, 3ª ed.
  • 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ª ed.
  • Kendall, K. E.; Kendall, J. E. (2023). Systems Analysis and Design, 11ª ed.
  • Dennis, A.; Wixom, B. H.; Tegarden, D. (2021). Systems Analysis and Design: An Object-Oriented Approach with UML, 8ª ed.
  • Satzinger, J. W.; Jackson, R. B.; Burd, S. D. (2015). Systems Analysis and Design in a Changing World, 7ª ed.
  • Fowler, M. (2003). UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3ª ed.
  • Delligatti, L. (2013). SysML Distilled: A Brief Guide to the Systems Modeling Language.
  • Silver, B. (2011). BPMN Method and Style, 2ª ed.
  • Lankhorst, M. et al. (2017). Enterprise Architecture at Work: Modelling, Communication and Analysis, 4ª ed.
  • 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ª ed.
  • Silverston, L. (2008–2009). The Data Model Resource Book, Vols. 1–3 (rev. eds.).
  • Keeney, R. L.; Raiffa, H. (1993). Decisions with Multiple Objectives: Preferences and Value Trade-Offs, 2ª ed.
  • Saaty, T. L. (1980). The Analytic Hierarchy Process; (1990) Decision Making for Leaders.

Note

  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.info/int/index.php?title=Analisi_dei_sistemi_in_IT&oldid=310"