La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

2. INGEGNERIA DI SISTEMA Il software è inutile a meno che non sia combinato con componenti hardware per formare un sistema Introdurremo il concetto di.

Presentazioni simili


Presentazione sul tema: "2. INGEGNERIA DI SISTEMA Il software è inutile a meno che non sia combinato con componenti hardware per formare un sistema Introdurremo il concetto di."— Transcript della presentazione:

1 2. INGEGNERIA DI SISTEMA Il software è inutile a meno che non sia combinato con componenti hardware per formare un sistema Introdurremo il concetto di ingegneria di sistema Descriveremo il processo di acquisizione e di sviluppo di un sistema Vedremo come rappresentare larchitettura di un sistema Introdurremo il concetto di affidabilità di un sistema

2 Ingegneria di sistema Un sistema è un insieme di componenti correlate Software Hardware Risorse umane Dati (Informazione) che insieme realizzano un obiettivo comune Ingegneria di sistema significa: Progettare Implementare Installare sistemi che includono hardware (meccanico, elettrico, elettronico), software e personale

3 Il tutto non è la somma delle parti Le componenti di un sistema possono operare in modo indipendente, ma quando sono integrate in un sistema dipendono da altre componenti Esempi Una penna Un sistema di gestione del traffico aereo Un sistema di allarme

4 Linterdipendenza delle componenti fa sì che gli errori possano essere propagati in tutto il sistema. I fallimenti possono essere dovuti a interrelazioni tra componenti di cui non si è tenuto conto Laffidabilità dipende dallaffidabilità dellhardware, del software e degli operatori Resilience (capacità di recupero) = abilità del sistema di continuare ad operare correttamente in presenza di fallimenti di una o più componenti Affidabilità di un sistema

5 Proprietà emergenti Proprietà del sistema visto globalmente, che non necessariamente possono essere derivate dalle proprietà delle singole componenti del sistema Possono essere conseguenza delle relazioni che intercorrono tra le componenti del sistema Sono proprietà che possono essere valutate e misurate solo in seguito allintegrazione delle componenti del sistema.

6 Esempi di proprietà di un sistema Il peso complessivo del sistema Può essere calcolato a partire dalle proprietà delle componenti del sistema Laffidabilità del sistema Dipende dallaffidabilità delle singole componenti e dalle relazioni che intercorrono tra le componenti Lusabilità di un sistema Non dipende solo dalle componenti hw o sw, ma anche dallambiente e dagli operatori

7 Fattori che influenzano laffidabilità Affidabilità dellhardware Qual è la probabilità che una componente hardware si rompi e quanto temo ci vuole a ripararla? Affidabilità del software Qual è la probabilità che il software produca un output non corretto? Affidabilità degli operatori Qual è la probabilità che un utilizzatore del sistema commetta un errore?

8 I sistemi e il loro ambiente I sistemi non sono indipendenti, ma sono inseriti in un ambiente, la cui conoscenza va inclusa nella specifica Lobiettivo di un sistema più essere di modificare il proprio ambiente (es. sistema di riscaldamento) Lambiente può condizionare il comportamento del sistema (es. blackout) Un sistema può essere visto come un sottosistema del proprio ambiente Sullambiente si devono fare delle assunzioni

9 Sistemi e sottosistemi Città Strada Edificio Sistema di riscaldamento Sistema di allarme Sistema elettrico Sistema idraulico Sistema utenti Sistema edile

10 Acquisizione di un sistema Un sistema può essere costruito o acquisito. Per acquisire un sistema per una azienda per soddisfare una qualche necessità è necessario dare la specifica del sistema e larchitettura di progetto Scegliere tra sistemi o sottosistemi da comprare off the shelf e quelli da sviluppare in modo specifico su contratto. Fornitori e sotto-fornitori

11 Modello contraente/sottofornitori Acquirente del sistema Contraente Principale Sotto-fornitore 1Sotto-fornitore 2Sotto-fornitore 3

12 Acquisizione di un sistema Analisi di mercato Adattare i requisiti Scegliere il sistema Richiedere preventivi Scegliere il fornitore Richiesta di offerte Selezionare le offerte Negoziare il contratto Contrattare lo sviluppo sistemi off the shelf sistemi dedicati Il punto di partenza è in entrambi i casi la specifica del sistema

13 Progettazione di un sistema Coinvolge inevitabilmente tecnici di aree diverse, con problemi di vocabolario e metodologia Usualmente segue un modello di sviluppo a cascata, per poter sviluppare parallelamente le diverse componenti del sistema Cè poco spazio per iterazioni tra le varie fasi, per gli alti costi di modifica Il sottosistema software è quello più flessibile (fa da collante)

14 Multidisciplinarietà Ingegnere del Software Ingegnere Elettronico Ingegnere Meccanico Ingegnere Civile Ingegnere Elettrico Architetto Calcolo Strutture Interfaccia Utenti sistema controllo traffico aereo

15 Architettura di riferimento

16 Il contesto...

17 Sviluppo di un sistema Definizione dei requisiti Progettazione in sotto-sistemi Sviluppo dei sotto-sistemi Integrazione del sistema Installazione del sistema Mantenimento del sistema Decommissioning Non ci sono back-arrows!

18 Definizione dei requisiti Quali sono i requisiti globali del sistema? Requisiti funzionali: cosa il sistema deve fare Requisiti non funzionali: proprietà del sistema, ad es. sicurezza, efficienza... vincoli sul sistema, ad es. vincoli dambiente… caratteristiche che il sistema non deve esibire

19 Esempio Possibili requisiti per un sistema per la sicurezza di un edificio Costruire un sistema di allarme contro incendi e furti per ledificio che segnali allinterno ed allesterno la presenza di un incendio o di unintrusione non autorizzata. Costruire un sistema che assicuri che il normale funzionamento del lavoro svolto nelledificio non sia turbato da eventi come incendi o intrusioni non autorizzate.

20 Progettazione in sottosistemi Organizzare i requisiti, separandoli valutare le alternative possibili Identificare i sottosistemi Assegnare requisiti ai sottosistemi Specificare la funzionalità dei sottosistemi Definire le interfacce dei sottosistemi È il punto critico per la parallelizzazione

21 Sviluppo dei sottosistemi Tipicamente eseguito in parallelo Problemi di comunicazione tra i vari team di sviluppo Può implicare lacquisizione di sistemi off the shelf

22 E il processo di mettere assieme hardware, software e risorse umane Non è possibile un approccio big-bang! Deve essere eseguito incrementalmente i sottosistemi vanno integrati uno alla volta questo riduce i costi di individuazione degli errori E qui che emergono i problemi di interfaccia e di coordinamento tra le diverse componenti Integrazione del sistema

23 Le ipotesi sullambiente possono rivelarsi non corrette Opposizione allintroduzione di un nuovo sistema da parte degli operatori Coesistenza per un certo periodo con sistemi preesistenti Problemi fisici di installazione (cablaggio...) Formazione degli operatori Installazione

24 Mette in luce i requisiti non contemplati Gli utenti possono usare il sistema in modo difforme da quello anticipato dai progettisti Può rivelare problemi nellinterazione con altri sistemi Problemi nelluso di interfacce diverse che possono indurre in errore gli operatori Messa in opera

25 Mantenimento e Smantellamento I grossi sistemi hanno una lunga durata. Devono evolvere per soddisfare requisiti in evoluzione Levoluzione è intrinsecamente costosa Obsolescenza dei sistemi Lo smantellamento del sistema può avere impatti sullambiente esterno Può richiedere la riconversione di dati per luso in altri sistemi

26 Modellare larchitettura di un sistema Il modello architetturale di un sistema mostra in modo astratto la struttura in sottosistemi Dovrebbe rappresentare i flussi di informazione tra i vari sottosistemi Usualmente è presentata in diagrammi a blocchi Dal modello si dovrebbero identificare i diversi tipi delle componenti funzionali di un sistema

27 Esempio

28 Esempio: un sistema di allarme Sensore dambiente Sirena Centralina di allarme Sensori porte e finestre Caller telefonico Sintetizzatore di voce centro di controllo esterno

29 Le componenti funzionali di un sistema Sensori: derivano informazione dallambiente Attuatori: determinano cambiamenti nellambiente Componenti di calcolo: eseguono delle computazioni input -> output Componenti di comunicazione: permettono ad altre componenti del sistema di comunicare Componenti di coordinamento: coordinano le operazioni delle varie componenti Interfacce: trasformano rappresentazioni usate in una componente del sistema in unaltra rappresentazione

30 Esempio Sensore dambiente Sirena Centralina di allarme Sensori porte e finestre Caller telefonico Sintetizzatore di voce centro di controllo esterno sensore attuatore comunicaz. interfaccia coordinam.


Scaricare ppt "2. INGEGNERIA DI SISTEMA Il software è inutile a meno che non sia combinato con componenti hardware per formare un sistema Introdurremo il concetto di."

Presentazioni simili


Annunci Google