Definizioni – 1 - Dal glossario IEEE - Una condizione o una capacità necessaria a un utente per risolvere un problema [..] - Una condizione (capacità) che deve essere soddisfatta (posseduta) [..] da un sistema [..] per soddisfare un contratto [..] - La descrizione di una condizione o una capacità come in 1 o 2 Definizioni – 2 - Verifica - Intende accertare che l’esecuzione di un dato processo non abbia introdotto errori - Did I build the system right? - Principalmente rivolta al processo, ma applica anche ai prodotti di processi intermedi - Validazione - Intende accertare che l’uscita dell’insieme di processi eseguiti sia il prodotto atteso - Did I build the right system? Ingegneria dei requisiti – 1 - Termine che denota l’insieme delle attività necessarie per il trattamento sistematico dei requisiti - I requisiti software sono uno dei prodotti del relativo processo - Le attività del processo riguardano prima di tutto il sistema, del quale il software è parte Ingegneria dei requisiti – 2 - L’ingegneria dei requisiti deve essere vista come un processo a ciclo PDCA - Da formalizzare e pianificare - Modello di processo, piano delle attività - Da eseguire e gestire - Responsabilità primarie, organizzative, di supporto - Da verificare e migliorare - A livello di efficienza di processo e di qualità di prodotto - Ciò richiede responsabilità con competenze di ingegneria di processo Ingegneria dei requisiti – 3 - Altre attività e competenze richieste dal processo - Analisi dei requisiti - Analisi delle fonti, classificazione, modellazione concettuale, decomposizione del sistema, allocazione, negoziazione - Verifica e validazione - Tramite revisione interna e/o esterna, prototipazione, analisi del modello concettuale - Produzione (dei documenti di specifica) - Studio di Fattibilità, Analisi dei Requisiti, Specifica Tecnica - Gestione e manutenzione dei prodotti - Tracciamento delle attribuzioni, gestione dei cambiamenti Attività primarie necessarie - Analisi dei bisogni - Analisi e specifica dei requisiti - Partizionamento del sistema in componenti - Progettazione architetturale ad alto livello - Attribuzione dei requisiti ai componenti Prodotti primari - Analisi dei bisogni - Definizione dei requisiti a livello sistema - Capitolato d’appalto (responsabilità del cliente) - Specifica dei requisiti software - Studio di Fattibilità - Analisi dei Requisiti - Partizionamento ed attribuzione - Architettura logica del sistema software con componenti caratterizzati - Specifica Tecnica Attività di analisi - Studiare e definire il problema da risolvere - Per identificare il prodotto da commissionare - Per capire cosa deve essere realizzato - Per definire completamente gli accordi committente/fornitore - Verificare le implicazioni economiche e sulla qualità del prodotto - La soddisfazione del committente è relativa ai requisiti - I requisiti possono essere sia espliciti che impliciti Implicazioni economiche e di qualità - Cause di abbandono (Standish Group, 1995) - Requisiti incompleti - Scarso coinvolgimento degli utenti - Mancanza di risorse - Attese irrealistiche - Fluttuazione di specifiche e requisiti - [...] - Ignoranza tecnologica Classificazione dei requisiti – 1 - Distinguere tra attributi di prodotto ed attributi di processo - Gli attributi di prodotto definiscono le caratteristiche richieste al sistema da sviluppare - Esempio: specifica di una funzione da calcolare - Rispondono alla domanda: cosa? - Gli attributi di processo pongono vincoli sulla conduzione e sulle uscite delle attività previste dal processo - Esempio: imposizione di una particolare tecnologia di sviluppo (un linguaggio, uno strumento); adozione di uno standard di programmazione - Rispondono alla domanda: come? Classificazione dei requisiti – 2 - Gli attributi di prodotto esprimono - Requisiti funzionali - Determinano le capacità di calcolo richieste al sistema (capabilities) - Gli attributi di processo esprimono - Requisiti non funzionali - Riducono i gradi di libertà disponibili nella definizione della soluzione * Per esempio le caratteristiche di qualità richieste al prodotto Classificazione dei requisiti – 3 - I requisiti devono essere verificabili - Chi impone un requisito deve sapere come accertarne il soddisfacimento - Chi è chiamato a soddisfare un requisito deve poterne stimare il costo di verifica - Alcuni requisiti derivano implicitamente da attributi di prodotto e/o di processo assegnati dal cliente o decisi dal fornitore Classificazione dei requisiti – 4 Analisi tradizionale - Studio di fattibilità - Analisi dei requisiti - Dominio, glossario, requisiti - Uso prevalente di linguaggio naturale - Limitato uso di linguaggi formali o semi-formali - Specifica - Uso di linguaggi formali o semi-formali - Definizione di funzioni e profilo operazionale - Progettazione top-down e realizzazione Analisi moderna - Studio di fattibilità - Analisi orientata agli oggetti (OO) - Dominio, glossario, requisiti - Uso prevalente di formalismi grafici (diagrammi “use case”) - Continuità logica con la fase di progettazione - Identificazione delle classi - Progettazione OO - Uso di componenti prefabbricati - Realizzazione di componenti riusabili - Programmazione OO - Realizzazione parzialmente automatizzabile Studio di fattibilità – 1 - Valutare rischi, costi e benefici - Prospettiva del committente e del fornitore - Studio basato su dati vari e spesso incerti - Definizione e valutazione di possibili scenari - Decidere se procedere - Entro un costo massimo fissato - Basato su conoscenze disponibili - Senza richiedere ricerche impegnative Studio di fattibilità – 2 - Fattibilità tecnico-organizzativa - Strumenti per la realizzazione - Soluzioni algoritmiche ed architetturali - Hardware idoneo per il supporto dell’esecuzione - Rapporto costi/benefici - Confronto tra il mercato attuale e quello futuro - Costo della produzione, redditività dell’investimento - Individuazione dei rischi - Area di complessità e di incertezza Studio di fattibilità – 3 - Scadenze temporali - Esame delle alternative - Alternative architetturali - Esempio: sistema centralizzato o distribuito; modello client-server od altro - Modalità alternative di realizzazione - “Make or buy” * Riuso di componenti esistenti - Avvio, esercizio e manutenzione del sistema - Formazione ed assistenza utenti Dominio e glossario - Dominio - Campo di applicazione del prodotto - A quali bisogni risponde - Quali problematiche coinvolge - Acquisizione delle competenze - Documentazione preesistente - Interviste agli utenti potenziali - Studio delle soluzioni esistenti - Glossario - Definisce i termini chiave del dominio - Chiusura: tutti - Sinteticità: e soli - Da sottoporre alla verifica ed approvazione del committente - Consolidato mediante uso nelle interviste Analisi dei requisiti – 1 - Taluni requisiti di I livello (di sistema) possono non essere soddisfacibili - Tecnicamente impossibili Esempio: integrare componenti software scritti in linguaggi incompatibili tra loro - Possibili, ma di realizzazione troppo costosa Esempio: qualificare un componente software di cui non si possieda il sorgente - Possibili, ma mutuamente esclusivi tra loro Esempio: usare componenti standard (e.g. Windows, JVM) e contenere la dimensione totale del sistema entro i 40 kB Analisi dei requisiti – 2 - L’analisi dei requisiti deve accertare la soddisfacibilità dei requisiti rispetto ai vincoli esistenti sui processi del progetto - Al termine dell’analisi i requisiti confermati devono essere tutti necessari e sufficienti - Nessun bisogno trascurato - Nessuna caratteristica superflua - Una priorità relativa può essere assegnata ai requisiti confermati - Un negoziato con il cliente determina la politica di assegnazione e la definizione degli obiettivi minimi Analisi dei requisiti – 3 - I prodotti di questa attività sono spesso documenti scritti in linguaggio naturale - Rischio di ambiguità interpretativa - Certe linee guida aiutano ed evitare espressioni ambigue (p.es. terminologia consistente) - L’uso di metodi formali o semi-formali di specifica è utile per ridurre tali rischi Tecniche di analisi delle fonti - L’analisi delle fonti generalmente richiede - Interviste con il cliente - Generazione ed analisi di scenari - Prototipazione - Interna (per il fornitore) - Esterna (per il cliente) - Discussioni creative - ‘Brainstorming’ (approccio maieutico) - Osservazione dei comportamenti e dei bisogni Documento AR – 1 - Completo - Ben organizzato - Privo di inconsistenze - Privo di ambiguità - Privo di ridondanze - Privo di imprecisioni terminologiche - Privo di dettagli tecnici Documento AR – 2 - Ad uso prevalente del progettista - Uso di linguaggi semi-formali (grafici) - Operazionali: diagrammi di flusso dei dati - Dichiarativi: diagrammi entità/relazioni - Misti: UML (vari diagrammi) - Uso di linguaggi formali - Operazionali: Automi a stati finiti, Reti di Petri, Algebre di processo - Dichiarativi: logiche - Misti: Z, VDM, B, ASM Verifica dei requisiti – 1 - Eseguita su un documento già organizzato - Walkthrough - Ispezione - Lettura “strutturata” dei documenti - Esempio: tecnica del lemmario - Efficacia provata sperimentalmente (rileva ~60% dei problemi) - Matrice delle dipendenze Verifica dei requisiti – 1 - Chiarezza espressiva - L’uso del linguaggio naturale rende difficile coniugare chiarezza con facilità di lettura - Chiarezza strutturale - Separazione tra requisiti funzionali e non-funzionali - Classificazione precisa, uniforme ed accurata - Atomicità ed aggregazione - Requisiti elementari - Correlazioni chiare ed esplicite Spazio di negoziato - Requisiti suddivisi in classi - Obbligatori - Irrinunciabili per il cliente - Desiderabili - Non strettamente necessari, ma a tangibile valore aggiunto - Opzionali - Relativamente utili, oppure contrattabili in seguito Gestione dei requisiti - Identificazione, classificazione - Identificatore unico (p.es. garantito da DBMS) - Numerazione sequenziale basata sulla struttura del documento (p.es. 2.4.7) - Coppie - Gestione di cambiamenti - Valutazione di fattibilità tecnica ed impatto sul progetto - Tracciabilità - Requisiti <--> elementi specifica <--> componenti del sistema - Strumenti CASE Allocazione dei requisiti - L’inizio della progettazione architetturale - Può essere influenzata da esigenze od opportunità di riuso (meglio se sistematico) - Componenti aziendali preesistenti - Componenti commerciali - Componenti imposti dal cliente - Componenti riusabili possono includere - Codice sorgente od eseguibile - Specifiche di interfaccia (p.es. API) - Modelli architetturali (design patterns)