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

Slides:



Advertisements
Presentazioni simili
USABILITÁ Sembra banale, ma….
Advertisements

L’Informatica dal Problema alla Soluzione
1 La natura della contabilità direzionale
Processo software il processo.
4 – Progettazione – Introduzione e Modello E-R
Funzionalismo.
Evolvere robot stigmergici in Evorobot*
DIAGRAMMI DI FLUSSO DEI DATI
1 12. Progettare Sistemi Real-Time Progettare sistemi software il cui comportamento è condizionato da vincoli di tempo Mostreremo perché i sistemi real-time.
1 9: Progettazione Architetturale Obiettivo: stabilire la struttura globale di un sistema software Descriveremo diversi tipi di modello di architettura,
1 14. Verifica e Validazione Come assicurarsi che il software corrisponda alle necessità dellutente? Introdurremo i concetti di verifica e validazione.
Il Software: Obiettivi Programmare direttamente la macchina hardware è molto difficile: lutente dovrebbe conoscere lorganizzazione fisica del computer.
Gestione dei dati e della conoscenza (agenti intelligenti) M.T. PAZIENZA a.a
Sistemi basati su conoscenza (agenti intelligenti) Prof. M.T. PAZIENZA a.a
Ingegneria del Software Dott. Ing. Leonardo Rigutini Dipartimento Ingegneria dellInformazione Università di Siena Via Roma 56 – – SIENA Uff
Identificazione delle attività
GESTIONE DEI SISTEMI INFORMATIVI IN AZIENDA
IL PATRIMONIO DI DATI - LE BASI DI DATI. Il patrimonio dei dati Il valore del patrimonio di dati: –Capacità di rispondere alle esigenze informative di.
MODALITÀ DI ACQUISIZIONE DEL SOFTWARE APPLICATIVO Paolo Atzeni Dipartimento di Informatica e Automazione Università Roma Tre 03/12/2008 (materiale da:
Introduzione a Scrum
Jidoka.
Struttura dei sistemi operativi (panoramica)
L'alternanza scuola - lavoro.
I ventilatori.
A.Natali DL Maggio1999 Oggetti Concetti fondamentali.
Metodologia sviluppo KBS Fabio Sartori 12 ottobre 2005.
Elaborato F.S. Di Somma V. PROGETTO QUALITA VERSO IL…. MANUALE DELLA QUALITA A.S. 2006/2007 F. S. QUALITA DI SOMMA V.
Il Gruppo di Lavoro. Le 7 variabili del modello OBIETTIVO METODO RUOLI LEADERSHIP COMUNICAZIONE CLIMA SVILUPPO.
INTRODUZIONE l sistema operativo è il primo software che lutente utilizza quando accende il computer; 1)Viene caricato nella memoria RAM con loperazione.
La progettazione di un sistema informatico
Manutenzione degli assets produttivi
INFORMATICA MATTEO CRISTANI.
L’importanza del Piano Formativo.
Il processo di sviluppo del Sw: strategia make
Lo sviluppo del progetto informatico
I sistemi di pianificazione e controllo.
1Ingegneria Del Software L-A Progetto realizzato da: Luca Iannario, Enrico Baioni, Sara Sabioni. A.A. 2008/2009.
1 AUTOMATIZZAIAUTOMATIZZAIAUTOMATIZZAIAUTOMATIZZAI S.I. SISTEMASISTEMA INFORMATIVO INFORMATIVO PROCESSOPROCESSO DECISIONALE DECISIONALE DECISIONEDECISIONE.
Ingegneria del software Modulo 2 -Il software come prodotto Unità didattica 2 -I costi del software Ernesto Damiani Università degli Studi di Milano Lezione.
Analisi dei Requisiti (Requirements Engineering) Seminario RE Università degli Studi di Padova, 12 Gennaio 2004.
Dati e DBMS DBMS relazionali SQL Progettazione di una base di dati Programma del Corso.
Scelta di un modello di processo: esempio
Commenti alle Attività Generiche. Attività Generiche (Pressman) Principali: Comunicazioni; Pianificazione; Modellazione; Costruzione, Dispiegamento Collaterali:
Esercitazioni di Ingegneria del Software con UML
La modellazione degli oggetti
1 Progettazione Architetturale. 2 Obiettivo: stabilire la struttura globale di un sistema software Descriveremo diversi tipi di modello di architettura,
La sicurezza dei sistemi informatici. Il sistema deve soddisfare i seguenti requisiti di sicurezza (CIANA)  Confidenzialità (Riservatezza)  Integrità.
10 azioni per lo scheduling su Grid Uno scheduler per Grid deve selezionare le risorse in un ambiente dove non ha il controllo diretto delle risorse locali,
Commenti all’esempio del treno Nell’esempio del treno si è iniziato dalle attività generiche e/o attività operative che tipicamente costituiscono i passi.
Come impostare il curricolo
Analisi dei requisiti Il primo passo di “qualsiasi” processo di sviluppo è la definizione dei requisiti  Definizione del Business Model  Solitamente.
1 Torino - Settembre 2005 Definizione dei contratti di fornitura ICT Aurora Girolamo Partecipante al gruppo di lavoro Convegno Confindustria - CNIPA La.
Sistemi basati su conoscenza (agenti intelligenti) Prof. M.T. PAZIENZA a.a
Master MATITCiclo di vita del Sistema Informativo1 CICLO DI VITA DEL SISTEMA INFORMATIVO.
TECNOLOGIE DELL’INFORMAZIONE E DELLA COMUNICAZIONE PER LE AZIENDE Materiale di supporto alla didattica.
Intelligenza Artificiale 1 Gestione della conoscenza lezione 14 Prof. M.T. PAZIENZA a.a
Che cosa è e a cosa serve un GIS?
Progettazione di basi di dati: metodologie e modelli
Ingegneria del software Modulo 2 -Il software come prodotto Unità didattica 2 - I costi del software Ernesto Damiani Università degli Studi di Milano Lezione.
Qualità Definizione: grado in cui un insieme di caratteristiche intrinseche soddisfa i requisiti.
UNIVERSITÀ DEGLI STUDI DI PERUGIA Dipartimento di Ingegneria Industriale Prof. Francesco Castellani Corso di “Meccanica Applicata B”
Economia e Organizzazione Aziendale
Riunione CCR 21/12/2005 Gruppo Storage Relazione sulla analisi di infrastrutture Fibre Channel e presentazione attivita’ per il 2006 Alessandro Brunengo.
Politecnico di Milano © 2001 William Fornaciari La tolleranza ai guasti Concetti generali Docente: William Fornaciari Politecnico di Milano
Standard e strumenti per lo sviluppo del software Marco Carezzano Andrea Andrenacci (ZEROPIU, Business Partner di Telecom Italia) Milano, 2 febbraio 2005.
Le basi di dati.
Implementazioni di un analizzatore di protocollo Esistono quattro fondamentali tradeoff per la realizzazione di un analizzatore di protocollo:  Analisi.
Dispositivi di comando e controllo Dispositivi a logica programmabile.
L’analisi dell’esperienza: alcuni concetti chiave Competenze emergenti e occupazione nel turismo A.A
VERSO IL PIANO DI AZIONE AMBIENTALE FORUM AGENDA 21 V MUNICIPIO - IV INCONTRO Prof. Silvia Macchi Ing. Liana Ricci DICEA - Dip. di Ingegneria Civile, Edile.
Transcript della presentazione:

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 l’architettura di un sistema Introdurremo il concetto di affidabilità di un sistema

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

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

Affidabilità di un sistema L’interdipendenza 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 L’affidabilità dipende dall’affidabilità dell’hardware, 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

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 all’integrazione delle componenti del sistema.

Esempi di proprietà di un sistema Il peso complessivo del sistema Può essere calcolato a partire dalle proprietà delle componenti del sistema L’affidabilità del sistema Dipende dall’affidabilità delle singole componenti e dalle relazioni che intercorrono tra le componenti L’usabilità di un sistema Non dipende solo dalle componenti hw o sw, ma anche dall’ambiente e dagli operatori

Fattori che influenzano l’affidabilità Affidabilità dell’hardware 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?

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

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

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 l’architettura 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

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

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

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)

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

Architettura di riferimento

Il contesto...

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

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 d’ambiente… caratteristiche che il sistema non deve esibire

Esempio Possibili requisiti per un sistema per la sicurezza di un edificio Costruire un sistema di allarme contro incendi e furti per l’edificio che segnali all’interno ed all’esterno la presenza di un incendio o di un’intrusione non autorizzata. Costruire un sistema che assicuri che il normale funzionamento del lavoro svolto nell’edificio non sia turbato da eventi come incendi o intrusioni non autorizzate.

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

Sviluppo dei sottosistemi Tipicamente eseguito in parallelo Problemi di comunicazione tra i vari team di sviluppo Può implicare l’acquisizione di sistemi “off the shelf”

Integrazione del sistema 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

Installazione Le ipotesi sull’ambiente possono rivelarsi non corrette Opposizione all’introduzione di un nuovo sistema da parte degli operatori Coesistenza per un certo periodo con sistemi preesistenti Problemi fisici di installazione (cablaggio...) Formazione degli operatori

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

Mantenimento e Smantellamento I grossi sistemi hanno una lunga durata. Devono evolvere per soddisfare requisiti in evoluzione L’evoluzione è intrinsecamente costosa Obsolescenza dei sistemi Lo smantellamento del sistema può avere impatti sull’ambiente esterno Può richiedere la riconversione di dati per l’uso in altri sistemi

Modellare l’architettura 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

Esempio

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

Le componenti funzionali di un sistema Sensori: derivano informazione dall’ambiente Attuatori: determinano cambiamenti nell’ambiente 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 un’altra rappresentazione

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