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

Presentazione sul tema: "Ingegneria dei Requisiti - e dei Sistemi - Giuseppe Berio DI-Unito 2007."— Transcript della presentazione:

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

2 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

3 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

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

5 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

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

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

8 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

9 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)

10 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

11 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

12 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

13 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).