Analisi e specifica dei requisiti

Documenti analoghi
Progettazione di basi di dati

Le basi di dati. Definizione 1. Lezione 2. Bisogna garantire. Definizione 2 DBMS. Differenza

interoperabilità fra dispositivi forniti da diversi produttori; superare i problemi legati alla limitazione del numero di risorse.

Metodologie e modelli di progetto

TECNOLOGIE DELL INFORMAZIONE E DELLA COMUNICAZIONE PER LE AZIENDE

PROCESSI NON SEQUENZIALI E TIPI DI INTERAZIONE

Modelli di interazione tra processi

CLASSIFICAZIONE DEI SISTEMI OPERATIVI (in ordine cronologico)

Università di Bergamo Facoltà di Ingegneria INGEGNERIA DEL SOFTWARE. Paolo Salvaneschi A4_3 V2.1. Progettazione. Metodi e Linguaggi

La Raccolta dei Requisiti. Corso di Ingegneria del Software Anno Accademico 2012/2013

Modelli di interazione tra processi

Basi di Dati. Progettazione di una Base di Dati. Progettazione di una Base di Dati

I SISTEMI OPERATIVI. Insieme di programmi che implementano funzioni essenziali per l uso di un sistema elaboratore.

UML. Il linguaggio UML e ArgoUML. Ingegneria dei sistemi software 2009/ /09/2009

Modelli di interazione tra processi

INTRODUZIONE AL TESTO FILOSOFICO

Capitolo I1: Laboratorio con DevC++

Prof. Rossella Cancelliere

CONCETTI E ARCHITETTURA DI UN SISTEMA DI BASI DI DATI

IL RUOLO DELLA TECNOLOGIA NEL PROGETTO DI ARCHITETTURA. Progettazione dei Sistemi Costruttivi

Introduzione alla programmazione. Walter Didimo

Sequential Functional Chart

PROGETTARE SISTEMI INFORMATIVI. Fasi e relativi approcci

Modello a scambio di messaggi

Materiale didattico. Sommario

Il Sistema Operativo

REGISTRI D'ESAME CODICE ESAME CORSO DI LAUREA NOME DEL CORSO LAUREA CFU

Programmazione Orientata agli Oggetti. Emilio Di Giacomo e Walter Didimo

Indice PARTE A. Prefazione Gli Autori Ringraziamenti dell Editore La storia del C. Capitolo 1 Computer 1. Capitolo 2 Sistemi operativi 21 XVII XXIX

Cap. 1-I 1 I sistemi informatici

MODELLISTICA DI IMPIANTI E SISTEMI Syllabus e Testi di Riferimento Prof. Giuseppe Iazeolla

ALLEGATO 2A MODELLO DI OFFERTA TECNICA LOTTO 1

LA REVISIONE LEGALE DEI CONTI La Pianificazione Ottobre 2013

(1) (2) (3) (4) 11 nessuno/a (1) (2) (3) (4) X è il minore tra A e B nessuno/a X è sempre uguale ad A X è il maggiore tra A e B

Il linguaggio di programmazione Python

I Diagrammi di Flusso OO

Il Sistema Operativo

AXO - Architettura dei Calcolatori e Sistema Operativo. organizzazione strutturata dei calcolatori

QUESTIONARIO 2: PIANIFICAZIONE DEL MIGLIORAMENTO

Seminario regionale Senigallia 15 aprile 2015

Introduzione alla programmazione Algoritmi e diagrammi di flusso. Sviluppo del software

Analisi dei Requisiti e Definizione delle Specifiche

Ingegneria del Software 4. Introduzione a UML. Dipartimento di Informatica Università di Pisa A.A. 2014/15

Corso di Ingegneria del Software. Activity Diagram

Contenuto del documento: Premessa...3 Principi Generali...3 Approccio Metodologico...3 Applicazione del Modello...5 Struttura del Modello...5 Definizi

Sistemi Operativi. Lez. 6: Problemi classici della programmazione concorrente

Sviluppo di programmi

Lez. 5 La Programmazione. Prof. Salvatore CUOMO

Le aree dell informatica

Introduzione alla OOP Object Oriented Programming

Linee di programmazione

LINGUAGGI DI ALTO LIVELLO. Si basano su una macchina virtuale le cui mosse non sono quelle della macchina hardware

SISTEMA INFORMATIVO E SISTEMA INFORMATICO. Sistema informativo e sistema informatico

MODELLO e RAPPRESENTAZIONE

L hardware da solo non è sufficiente per il funzionamento dell elaboratore È necessario introdurre il software:

Modelli di Ciclo di Vita del Software (CVS)

Lezione 2 Chiamate di procedura e risposta alle interruzioni

Linguaggi di programmazione e astrazione

Il Modello a scambio di messaggi

Elena Baralis 2007 Politecnico di Torino 1

Progetto sito web Gigli Elisa

DBMS. Alice Pavarani

Considerazioni di Federesco sulla Strategia Energetica Nazionale. Claudio G. Ferrari Presidente Federesco

Lo sviluppo del progetto informatico

Programmazione Disciplinare: Tecnologie e tecniche di rappresentazione grafica Classe: Seconda

Le sue caratteristiche:

Classi. Oggetti e classi. Creazione e inizializzazione di oggetti in C++ Distruzione di oggetti in C++

EUROPEAN PROJECT MANAGEMENT QUALIFICATION - epmq. Fundamentals. Syllabus 1.5

Metodologia di lavoro: PCM & GOPP

I fattori di qualità della progettazione

Introduzione a Java. Prof. Francesco Accarino IIS Altiero Spinelli Via Leopardi132 Sesto San Giovanni

REPERTORIO DELLE QUALIFICAZIONI PROFESSIONALI DELLA REGIONE CAMPANIA

Modelli e Metodi per la Simulazione (MMS)

Transcript:

Analisi e specifica dei requisiti Processo che stabilisce i servizi che il committente richiede al sistema da sviluppare ed i vincoli con cui lo si utilizzera` e sviluppera` Requisiti funzionali o non funzionali Funzionali Descrivono le funzioni e i servizi del sistema Non funzionali Vincoli sul sistema o sul suo processo di sviluppo Fase piu` critica del processo di sviluppo di un applicazione Attivita` di tipo esplorativo: progressiva comprensione della realta`; il livello di precisione dell analisi cresce Coinvolge l'ingegnere del software (piu` attento ad aspetti tecnologici) e il committente (piu` attento ad aspetti organizzativi o applicativi) Analisi e Specifica dei requisiti 1

Definizione/Specifica dei requisiti Definizione dei requisiti Documento in linguaggio naturale corredato di diagrammi per i servizi del sistema e vincoli operazionali sul sistema (scritto per il committente) Specifica dei requisiti Documento strutturato che contiene descrizioni dettagliate dei servizi del sistema (specifica funzionale). Puo` servire come contratto tra committente e sviluppatore Specifica del software Descrizione astratta del software che e` la base per il progetto e la realizzazione (scritta per gli sviluppatori). Aggiunge ulteriori dettagli alla specifica dei requisiti Analisi e Specifica dei requisiti 2

Esempio (Sommerville 95) Analisi e Specifica dei requisiti 3

A chi interessa? (Sommerville 95) Analisi e Specifica dei requisiti 4

Problemi Per sistemi software di grandi dimensioni spesso i requisiti sono incompleti ed inconsistenti Utenti diversi hanno requisiti diversi con priorita` diverse Gli utenti finali ed il committente hanno requisiti diversi Spesso e` conveniente una fase di prototipazione per chiarire quali siano i requisiti Requirement Engineering (RE) Studio di fattibilita` Analisi dei requisiti Definizione dei requisiti Specifica dei requisiti Analisi e Specifica dei requisiti 5

Il processo di Requirement Engineering (Sommerville 95) Analisi e Specifica dei requisiti 6

Documenti dei requisiti E` il documento ufficiale che stabilisce cosa e` righiesto agli sviluppatori del sistema Include sia una definizione che una specifica dei requisiti Non e` un documento di progetto (cosa il sistema dovrebbe fare piuttosto che come) Dovrebbe: Specificare il comportamento esterno del sistema; Specificare vincoli realizzativi; Essere facile cambiarlo; Servire come riferimento nella fase di manutenzione; Annotare possibili cambiamenti durante il ciclo di vita del sistema; Definire il comportamento al verificarsi di eventi inattesi. Analisi e Specifica dei requisiti 7

Struttura del documento Introduzione Descrive perche` e` necessario il sistema e come si adatta agli obiettivi commerciali Glossario Definisce i termini tecnici utilizzati Modelli del sistema Definisce i modelli mostrando i componenti del sistema e le loro relazioni Definizione dei requisiti funzionali Descrive i servizi forniti Definizione requisiti non funzionali Definisce i vincoli sul sistema ed il processo di sviluppo Analisi e Specifica dei requisiti 8

Struttura del documento (cont.) Evoluzione del sistema Definisce le assunzioni principali su cui si basa il sistema e le modifiche future Specifica dei requisiti Specifica dettagliata dei requisiti funzionali Appendici Descrizione della piattaforma hardware Requisiti per la base dei dati (ad esempio, modello Entita`-Relazione) Indice Analisi e Specifica dei requisiti 9

Validazione dei requisiti Dimostrazione che i requisiti descrivono il sistema che vuole l'utente Costi alti dovuti a requisiti sbagliati Per validare i requisiti si puo` costruire un prototipo Aspetti da verificare: Validita`: Le funzioni fornite sono quelle richieste? Consistenza: Ci sono incongruenze tra i requisiti? Completezza: La descrizione comprende tutte le funzioni ed i vincoli indicati dall'utente? Realizzabilita`: Tutti i requisiti sono realizzabili con l'hardware ed i finanziamenti disponibili? Analisi e Specifica dei requisiti 10

Se i requisiti sono espressi in un linguaggio formale, si puo` verificarne la consistenza in modo automatico La comprensione dei requisiti migliora nel tempo Analisi e Specifica dei requisiti 11

Specifica dei requisiti e modelli Specifica, di per se`, significa definizione Siamo interessati a come si possano definire le proprieta` che l applicazione dovra` avere, evitando il piu` possibile di descrivere tali proprieta` tramite una loro possibile realizzazione Vari modelli descrittivi possibili, per problemi o classi di applicazioni diverse I modelli sono, obbligatoriamente, astratti poiche` non possono descrivere tutti i dettagli sul sistema Analisi e Specifica dei requisiti 12

Tipologia di modelli Modelli orientati all'elaborazione dati (data-flow) Modelli basati su composizione (modelli semantici dei dati) Modelli basati su classificazione (modelli ad oggetti) Modelli basati su risposte a stimoli (real-time) Modelli orientati a processi (reti di Petri) Analisi e Specifica dei requisiti 13

Tipologia di applicazioni Sequenziali Caratterizzate da un unico flusso di controllo attraverso cui passa l evoluzione dell applicazione Concorrenti Consistono di diverse attivita` che operano contemporaneamente e dunque sono costituite da piu` flussi paralleli di controllo In caso di sistemi a multiprocessore e sistemi distribuiti, parallelismo reale tra le attivita` Necessitano di sincronizzare le attivita` (parallele o concorrenti) Ad esempio, acquisizione di una risorsa in modo esclusivo: occorre impedire che le altre attivita` possano accedere alla stessa risorsa Per entrambe queste categorie, il fattore tempo di esecuzione va a influenzare le prestazioni del sistema, non la correttezza Analisi e Specifica dei requisiti 14

Real-time Per queste, il fattore tempo influenza la correttezza del sistema Ad esempio, due attivita` concorrenti PROD e CONS, che scrivono e leggono messaggi in un buffer BUF limitato, dove PROD non puo` essere bloccato Se la specifica dei requisiti prescrive che tutti i messaggi depositati da PROD vengano effettivamente acquisiti da CONS, questo sistema e` "real-time" Sistemi che interagiscono con un ambiente esterno contenente i processi controllati che non possono essere ritardati attraverso opportuni meccanismi di sincronizzazione (ad esempio, impianti, etc.) E` importante assicurare che la risposta arrivi entro un certo intervallo di ammissibilita` Analisi e Specifica dei requisiti 15

Un'altra classificazione delle applicazioni Orientate ai dati L aspetto prevalente e` costituito dai dati che vengono memorizzati, ricercati, modificati (ad esempio, sistemi informativi) Orientate alle funzioni La complessita` fondamentale sta nel tipo di operazioni fornite (ad esempio, ambiente di programmazione) Orientate al controllo La complessita` fondamentale sta nel modo in cui il controllo fluisce tra le diverse attivita` che si sincronizzano e cooperano all interno del sistema Analisi e Specifica dei requisiti 16