Ingegneria dei Requisiti - e dei Sistemi - Giuseppe Berio DI-Unito 2007.

Slides:



Advertisements
Presentazioni simili
DFD (Data Flow Diagram)
Advertisements

Ingegneria dei Requisiti - e dei Sistemi -
La progettazione secondo la norma internazionale ISO 9001
Analisi e progettazione
Sistemi informativi e Sistemi informatici
COME COSTRUIRE LIDEA PROGETTUALE Unità formativa 2.1 Realizzazione dellanalisi dei bisogni.
Le nuove funzioni della piattaforma Puntoedu lingue.
La costruzione e lo sviluppo delle competenze a scuola Prof. Losito
La sperimentazione clinica
L’Informatica dal Problema alla Soluzione
I contenuti di questa presentazione sono stati realizzati a cura di M
4 – Progettazione – Introduzione e Modello E-R
Per crittografia si intende la protezione
Il ciclo di vita della progettazione di un sistema informativo
A.A GESTIONE E ORGANIZZAZIONE PER LA COMUNICAZIONE DIMPRESA 19 marzo 2010 Modulo: Prof. Lucio Fumagalli (canale M-Z)
La valutazione di impatto netto: alcune riflessioni a margine Gruppo Nazionale Placement Roma, 27 Febbraio 2013.
Ciclo di vita del software
Progettare interventi di orientamento Linee guida e suggerimenti operativi.
Progettazione di una base di dati
Metodologia sviluppo KBS Fabio Sartori 12 ottobre 2005.
Corso di Laurea Magistrale in Informatica
1 – Costruzione dell’alberatura
INTEGRAZIONE, RILASCIO
L’ingegneria del software
Strumento per l'innovazione di prodotto eco-compatibile per le PMI
Creare pagine web Xhtlm. Struttura di una pagina.
Basi di Dati e Sistemi Informativi
User stories Claudio Maccari Mail:
Design Goals Definiamo le fondamenta dello sviluppo del sistema.
Analisi dei Requisiti (Requirements Engineering) Seminario RE Università degli Studi di Padova, 12 Gennaio 2004.
OBIETTIVO DEL CORSO Elaborare un programma educativo per la prevenzione delle Malattie a Trasmissione Sessuale (MTS) rivolto agli studenti delle scuole.
Scelta di un modello di processo: esempio
Ingegneria del Software Giuseppe Berio DI-Unito 2006.
Commenti alle Attività Generiche. Attività Generiche (Pressman) Principali: Comunicazioni; Pianificazione; Modellazione; Costruzione, Dispiegamento Collaterali:
Scenari e Casi d’Uso (UML)
Commenti all’esempio del treno Nell’esempio del treno si è iniziato dalle attività generiche che tipicamente servono per portare a termine i compiti iniziali.
Commenti all’esempio del treno Nell’esempio del treno si è iniziato dalle attività generiche e/o attività operative che tipicamente costituiscono i passi.
Esercitazioni di Ingegneria del Software con UML
(Una) Definizione di Ingegneria del Software (IEEE) Strategie sistematiche, a partire da richieste formulate del committente, per lo sviluppo, esercizio.
Ingegnerie dei Requisiti e dei Sistemi
Typical steps in project planning and scheduling To identify the tasks and their durations To evaluate consistency of the task net To evaluate the critical.
Typical steps in project planning and scheduling To identify the tasks, their durations and their relations (pre-requisite, causal, etc.) To evaluate consistency.
Ogni cosa che facciamo influisce sull’ambiente
Progettazione concettuale di SI basati su Web
MODELLI DI PROCESSO DI PRODUZIONE SOFTWARE
SPIRITO DI INIZIATIVA E IMPRENDITORIALITÀ
Definizione(i) di Ingegneria del Software (IEEE) Strategie sistematiche, a partire da richieste formulate del committente, per lo sviluppo, esercizio e.
Business Plan.
I requisiti essenziali 1 – avere una visione strategica dell’apprendimento; 2 – avere un adeguato supporto istituzionale; 3 – lavorare su nuove professionalità.
Commenti all’esempio del treno Nell’esempio del treno si è iniziato dalle attività generiche e/o attività operative che tipicamente costituiscono i passi.
Controllo di qualità dei processi e collaudo
LABORATORIO DI INFORMATICA Ingegneria Informatica a. a
Progettazione di una base di dati Ciclo di vita di un sistema informativo Studio di fattibilità definisce le varie alternative possibili, i relativi costi.
Ingegneria del software Modulo 1 -Introduzione al processo software Unità didattica 4 -Progettazione del software Ernesto Damiani Università degli Studi.
Master MATITCiclo di vita del Sistema Informativo1 CICLO DI VITA DEL SISTEMA INFORMATIVO.
Ingegneria del software Modulo 1 -Introduzione al processo software Unità didattica 1 -Cicli di vita Ernesto Damiani Università degli Studi di Milano Lezione.
Strategie di progetto Si possono utilizzare le strategie tipiche dello sviluppo di un processo di ingegnerizzazione (es. ingegneria del software). Strategie.
Ingegneria del software Modulo 4 -Processi software Unità didattica 2 – eXtreme Programming Ernesto Damiani Università degli Studi di Milano Lezione 1.
Ingegneria del software Modulo 1 -Introduzione al processo software Unità didattica 2 -Gestione requisiti Ernesto Damiani Università degli Studi di Milano.
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.
Problemi, algoritmi e programmazione
Fasi di sviluppo di un software
INDICATORI SOCIALI E VALUTATIVI
DFD (Data Flow Diagram) Riferimenti: –Pressman, Cap. 8.
Progettazione concettuale di SI basati su Web B. Pernici.
DIT Department of Information and Communication Technology Information System Ingegneria del Software: un caso di studio.
Progettazione di un sito web. Aggiornare i siti web Gli utenti navigano per: 1.Trovare informazioni. 2.Comprare beni e servizi. 3.Leggere news. 4.Giocare.
I DONEITÀ DI C ONOSCENZE E C OMPETENZE I NFORMATICHE ( A – D ) Un database è un insieme di record (registrazioni) e di file (archivi) organizzati per uno.
Corso di Laurea Magistrale in Informatica A.A Laboratorio di Progettazione Introduzione Obiettivi del corso Metodo Articolazione Scelta dei progetti.
Transcript della presentazione:

Ingegneria dei Requisiti - e dei Sistemi - Giuseppe Berio DI-Unito 2007

Communication (Comunicazioni) Planning (Pianificazione) Modeling (Modellazione) –Analysis of requirements (Analisi dei requisiti) –Design (Progettazione) Construction (Costruzione) –Code generation (Generazione del codice) –Testing (Collaudo) Deployment (Dispiegamento) Fattibilità Determinazione (Raccolta) dei requisiti (può comprendere la deduzione e la negoziazione dei requisiti) Specifica dei requisiti Progettazione del software Codifica Test Installazione Manutenzione ….. Ingegneria dei Sistemi + Ingegneria dei Requisiti + Ingegneria della Progettazione + Codifica + Test +… Principi & Pratiche COMPITI METODOLOGIE

Ingegnerie dei Requisiti - e dei Sistemi -: Punti chiave Determinazione e specifica dei requisiti del software (senza distinguere lo studio di fattibilità, senza distinguere le due attività che possono essere svolte al contempo) Uso di notazioni (o linguaggi) nella Ingegneria dei Requisiti – e dei Sistemi - Formalizzazione della relazione tra Ingegneria dei Sistemi ed Ingegneria dei Requisiti

Determinazione e specifica dei requisiti (senza introdurre una distinzione esplicita con lo studio di fattibilità)

Sistema(i), requisiti del software: una visione d’insieme Ridurre le code Cercare, Prenotare, Pagare etc. Ricerca Prenotazione Con quale sistema? Con quale software? Requisiti del software sistema = software + ambiente del software Rif. Esempio Treno

Una tipica matrice usata nei compiti iniziali per la determinazione dei requisiti Nome assegnato idtipoprioritàrischiodescrizionefonteriftempocosto

Priorità e Tracciabilità Ridurre CodeFar usare il software ai clienti Pagare CC+++-

Conflitti Nella moderna ingegneria del software è necessario puntare sui conflitti (di varia natura) e sulla loro gestione: maggiori sono i conflitti già nei compiti iniziali e maggiori sono le speranze di determinare i requisiti attesi La determinazione dei requisiti è un’attività in cui tipicamente si devono eliminare i conflitti che possono essere di natura organizzativa (punti di vista diversi, anche del committente, tempi e costi apparentemente non compatibili con i requisiti) e di natura tecnica (esistono requisiti in contraddizione) La negoziazione è un modo di eliminare i conflitti

Determinazione dei Requisiti : una definizione Obiettivo: arrivare ad una collezione, sufficientemente dettagliata, completa e condivisa (cioè priva di conflitti) tra tutti i partecipanti (stakeholder) dei requisiti che il prodotto software dovrà possedere, una volta prodotto La determinazione dei requisiti inizia da una richiesta del committente che, in generale, evidentemente, non indica necessariamente i requisiti del software da sviluppare; in particolare, spesso non indica una chiara distinzione tra ciò che è software da sviluppare e ciò che è l’ambiente circostante al software; i requisiti si devono perciò dedurre, estrarre, identificare, elaborare, negoziare, convalidare e forse anche analizzare La collezione raccoglie e, talvolta, permette di visualizzare, in varie forme, i requisiti di cui è composta, e le relazioni tra tali requisiti Spesso tale collezione coincide con un documento dei requisiti (che introdurremo meglio in seguito)

Determinazione dei requisiti : l’essenziale Per una richiesta significativa del committente, non è possibile determinare i requisiti usando esclusivamente il linguaggio comune; modellazione, con linguaggio adatto, sempre, presentazione adatta Focalizzarsi solo ed esclusivamente su cosa ci si attende dal software, dimenticando come il software opererà; dal cosa al come si deve passare gradualmente e sistematicamente Dovrebbe essere sempre possibile sapere quali sono tutte le ragioni d’esistenza di un requisito, una volta determinato; tracciabilità sempre

Al fine di determinare i requisiti possono essere usati modelli (diagrammi) in qualche linguaggio di modellazione (DFD, Casi d’Uso etc.) o testo Tali modelli (diagrammi)/testo che potremmo qualificare come intermedi, non sono i requisiti ma servono per la determinazione di tali requisiti Spesso, tuttavia, sono indicati con il termine requisiti poiché la nozione di requisito è relativa (anche se questa relatività non è correttamente percepita e usata) Per distinguere tali modelli (diagrammi)/testo intermedi, possiamo introdurre il termine di desiderata del software Determinazione dei Requisiti: desiderata del software

Determinazione dei Requisiti: le fonti Greenfield Engineering (GE) –Sviluppo del sistema dal nulla; i requisiti sono estratti dagli utenti e dal committente –Richiesta del committente Re-engineering (RE) –Riprogettare e reimplementare un sistema esistente con una nuova tecnologia –Richiesta del committente focalizzata sulla nuova tecnologia e che permette di identificare il sistema esistente Interface Engineering (IE) –Interagire con un sistema esistente a partire da un diverso (e nuovo) ambiente software –Richiesta del committente focalizzata sulla nuova tecnologia e che permette di identificare il sistema esistente Un misto dei tre casi precedenti

Determinazione dei Requisiti: le fonti Nelle tre precedenti situazioni (GE, RE, IE) la determinazione parte da quantità diverse d’informazione, che possiamo chiamare fonti dei requisiti e precisamente: –Nulla oppure da esperienze pregresse (non del committente) –Analisi dei sistemi esistenti attraverso la documentazione e la diretta osservazione Ma spesso si tratta di una situazione in cui è necessario –rappresentare i sistemi esistenti (reverse-engineering) e –analizzare i sistemi esistenti rappresentati onde identificare le aree ove tali sistemi non sono soddisfacenti e, quindi, –dove e come dovrebbero essere modificati (requisiti).