Analisi dei Requisiti, Progettazione Preliminare ed Esecutiva di Grandi Sistemi Ingegneristici: Casi di Studio

Transcript

1 Seminario di Analisi dei Requisiti, Progettazione Preliminare ed Esecutiva di Grandi Sistemi Ingegneristici: Casi di Studio Corso di Ingegneria dei Sistemi Software e dei Servizi in Rete Parte 1. L Ingegneria dei Sistemi 5 Novembre 2012

2 Sommario del Seminario Il seminario si articola in sei ore: L'INGEGNERIA DEI SISTEMI (1h) Concetti di Systems Engineering Il V-Model Concezione del Sistema Requisiti Utente/Sistema/Sottosistema/Software Progettazione Preliminare ed Esecutiva Verifica e Validazione CASI DI STUDIO (3h) Sistema di Gestione della Sicurezza di un Porto Industriale Sistema Integrato di Sorveglianza Costiera, Sicurezza e Logistica Portuale Sistema di Monitoraggio degli Ausilii alla Navigazione in Mare EVOLUZIONE DELLE METODOLOGIE E DEGLI STRUMENTI (1h) Dall'UML al SysML Tools di Riferimento Il ruolo dell'incose, riferimenti ed eventi PROCESSO DI DEFINIZIONE DELL ARCHITETTURA DI SISTEMA (1h) Analisi del Contesto (caso di riferimento: sistema di sorveglianza aerea) Analisi degli Stati Operativi del Sistema Analisi Funzionale tramite Use Case e Sequence Diagrams Passaggio dall Analisi Black-Box alla White-Box Definizione dell Architettura di Sistema

3 Concetti di Systems Engineering COS È IL «SYSTEMS ENGINEERING»? Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs. (INCOSE) CHI LA DEFINISCE? Il riferimento principale è lo Standard ISO/IEC 15288:2008 Systems and software engineering - System life cycle processes Molti dei riferimenti citati nel corso sono invece derivati dal Systems Engineering Handbook, v3.2.1, pubblicato dalla INCOSE, che si basa sull ISO/IEC 15288:2008

4 Comunalità e differenze con l Ingegneria del Software IL CAMBIO DI PARADIGMA Il Systems Engineering si fonda su un cambio di paradigma, dal particolare al generale, dalle competenze di dominio a quelle di sistema (reductionist thinking vs. holistic thinking) Un concetto che non è estraneo all ingegneria del software: a partire dallo sviluppo della programmazione Object Oriented il focus si è spostato dal contenuto algoritmico del software ad altri aspetti quali l architettura di classi ed oggetti, le loro interrelazioni, le interfacce ed i servizi forniti. Inoltre, classi ed oggetti possono essere realizzati da sviluppatori diversi, con linguaggi diversi e geograficamente separati L approccio OO ha portato nel mondo software alla definizione del linguaggio UML (Unified Modeling Language), che si è dimostrato un efficace strumento di rappresentazione di software con architettura e comportamento complessi. L UML è stato prontamente fatto proprio dalla Systems Engineering, mediante il profilo chiamato SysML (Systems Modeling Language), che ne conserva i costrutti essenziali, arricchendoli con elementi specifici per i sistemi (requisiti, diagrammi parametrici, blocchi, porte, ) IL SOFTWARE COME SOTTOSISTEMA La differenza principale tra approccio al software ed approccio al sistema, è che nonostante il software si qualifichi sia come prodotto che come sistema, nelle applicazioni per la grande industria non può essere considerato come un sistema a sé stante, ma come parte di un sistema più ampio che include anche sensori, attuatori, hardware di elaborazione, interfacce uomo-macchina ed infrastrutture di supporto.

5 I Processi della Systems Engineering IN COSA IL SYSTEMS ENGINEERING PUO SUPPORTARE LE ATTIVITA DI INGEGNERIA? Uno degli scopi è la definizione formale dei Processi che regolano le fasi di vita di sistemi e prodotti. In particolare, dei Processi Tecnici

6 Definizione di Processo COS E UN PROCESSO? E un insieme di attività intercorrelate che trasformano inputs in outputs DEFINIZIONE DEI TERMINI RILEVANTI Inputs: gli artefatti su cui il processo agisce, che vengono usati o trasformati per generare gli outputs Outputs: dati processati, prodotti e servizi Controlli: elementi che governano lo sviluppo del processo, senza esserne modificati (esempio: normative, guidelines, standards di riferimento) Enablers: gli strumenti tramite I quali si realizza il processo (esempio: tools, apparati HW, infrastrutture) PERCHÉ SI APPLICANO I PROCESSI? Per definire i requisiti di un sistema Per trasformare i requisiti in un prodotto efficiente Per consentire un riuso consistente del prodotto Per usare il prodotto al fine di fornire i servizi richiesti Per supportare la fornitura dei servizi Per smaltire il prodotto quando viene ritirato dal servizio

7 Il V-Model (o Modello Vee) RAPPRESENTAZIONE SCHEMATICA DEL CICLO DI SVILUPPO DI UN SISTEMA/PRODOTTO PROCESSI TECNICI INTERESSATI DAL V-MODEL Definizione dei Requisiti Utente Integrazione Analisi dei Requisiti Verifica Progetto Architetturale Validazione Implementazione

8 I Processi Tecnici come Fasi del V-Model FASI DI SVILUPPO DEL SISTEMA/PRODOTTO I processi si sviluppano iterativamente in tutte le fasi, ma ogni processo concerne in modo specifico una determinata fase (in altri termini, si applica ad una specifica Baseline di riferimento) Fase di Concezione Fase di Validazione/ Omologazione Definizione dei Requisiti Utente Analisi dei Requisiti Validazione Fase di Progettazione Fase di Verifica Progetto Architetturale Verifica Fase di Implementazione Implementazione Integrazione Fase di Integrazione

9 Il Concetto di Baseline UNA BASELINE COSTITUISCE L INSIEME DEGLI ARTEFATTI DI UN PROGETTO CHE È POSSIBILE USARE COME BASE DI CONFRONTO La Baseline identifica una configurazione del sistema fissata in un dato istante di tempo. Essa naturalmente si modifica in modo continuo con il passare del tempo (da sinistra verso destra nel V-Model) ESEMPIO 1 Lato «Design» della V Il processo di Implementazione si applica solo su una Baseline per la quale la Progettazione Architetturale sia stata completata (può anche non coprire l intero sistema) L Implementazione può comportare una revisione dei requisiti e quindi una regressione della Baseline ESEMPIO 2 Lato «IV&V» della V La Validazione si applica solo su una Baseline Verificata L eventuale revisione di requisiti di sistema in fase di Validazione, può comportare una regressione della Baseline, con impatti rilevanti su tempi e costi

10 Fase di Concezione: Definizione dei Requisiti Utente SCOPO Lo scopo del processo di Definizione dei Requisiti Utente è di definire i requisiti per un sistema che possa fornire i servizi richiesti dall utente in un ben definito contesto OUTPUTS Documenti di concetto del sistema Concetto della produzione Concetto del deployment Concetto delle operazioni (ConOps) Concetto del supporto Concetto dello smaltimento Definizione dei Requisiti utente Misure di Efficacia (MOE) Criteri di validazione Matrici di tracciabilità dei requisiti METODI COMUNI DI ACQUISIZIONE DEI REQUISITI UTENTE Site Survey Questionari Seminari, workshop, incontri dedicati

11 Fase di Concezione: Analisi dei Requisiti SCOPO Lo scopo del Processo di Analisi dei Requisiti è di trasformare la vista centrata sui requisiti utente dei servizi desiderati in una vista tecnica di un prodotto che sia in grado di fornire quei servizi OUTPUTS Definizione dei Requisiti di sistema Definizione Misure di Performance (MOP) Definizione funzioni del sistema Definizione interfacce funzionali Definizione criteri di verifica Definizione dell albero dei requisiti Tracciabilità dei requisiti

12 Fase di Progettazione: La Progettazione Preliminare SCOPO Lo scopo del Processo di Progettazione Architetturale è di sintetizzare una soluzione che soddisfi i requisiti di sistema OUTPUTS Misure di performance Architettura del sistema Requisiti di interfaccia Requisiti di sottosistema Descrizione dei sottosistemi Tracciabilità dei requisiti di sottosistema ESEMPI DI SCHEMI DI ARCHITETTURA PRELIMINARE Architettura fisica Architettura logica Sistema A Sistema B Sistema C

13 Fase di Implementazione: La Progettazione Esecutiva SCOPO Lo scopo del Processo di Implementazione è di realizzare uno specifico elemento del sistema ESEMPI DI SCHEMI DI ARCHITETTURA ESECUTIVA Architettura fisica Diagramma delle classi OUTPUTS Strategia di implementazione Requisiti e constraints specifici di implementazione Sottosistemi, verificati e validati Documentazione di sottosistema Progetti esecutivi Codice Specifiche dei materiali Documenti di training e manutenzione Layout di sito

14 Fasi di Integrazione/Verifica/Validazione SCOPO Lo scopo del Processo di Integrazione è di assemblare un sistema che sia consistente con l architettura definita Lo scopo del Processo di Verifica è di confermare che il sistema realizzato soddisfi i requisiti di progetto Lo scopo del Processo di Validazione è di fornire evidenza obiettiva che i servizi forniti dal sistema in uso soddisfino i requisiti utente, ottenendo il suo scopo prefissato nell ambiente operativo richiesto OUTPUTS Strategia di integrazione/verifica/validazione Requisiti e constraints specifici Procedure di integrazione/verifica/validazione Sistema integrato/verificato/validato Documenti di controllo delle interfacce (solo integrazione) Matrice di tracciabilità dei requisiti finale (solo verifica) Rapporto di integrazione/verifica/validazione LA DOMANDA GIUSTA DA PORRE: VERIFICA Are we building the system right? VALIDAZIONE Are we building the right system?

15 SPAZIO DISCUSSIONE DOMANDE, CHIARIMENTI, APPROFONDIMENTI?

16 GRAZIE PER L ATTENZIONE! ASTER S.p.A. Ing. Lucio Tirone Via Tiburtina 1166, Roma Tel: Fax: lucio.tirone@aster-te.it Partner of Assystem Group