Ingegneria del Software

Transcript

1 Ingegneria del Software Ingegneria dei Requisiti Requisiti di un Sistema Software Insieme delle esigenze (funzionalità) che un sistema software deve coprire Cosa desidera il committente? Cosa ci si aspetta dal sistema? Quali funzionalità? Quali operazioni automatiche? Chi si avvantaggerà dall utilizzo del sistema?

2 Prima Classificazione dei Requisiti Funzionali Requisiti espliciti Insieme delle funzionalità esplicitamente richieste dal cliente Requisiti impliciti Insieme di requisiti derivanti dalla natura del sistema Affidabilità, disponibilità, sicurezza,, non sempre sono requisiti esplicitamente richiesti dal cliente ma possono essere necessari per alcune tipologie di sistemi Raccolta dei requisiti Attraverso interviste al cliente ed agli utenti Cliente (committente) ed utilizzatori offrono viste differenti e mettono in luce necessità diverse Analisi del dominio applicativo Quali sono i processi di business del cliente? In che ambito il sistema dovrà operare? Con quali altri sistemi dovrà interoperare?

3 Deduzione dei Requisiti Problemi di ampiezza I limiti del sistema sono mal definiti I clienti specificano dettagli non necessari o omettono dettagli importanti Problemi di comprensione I clienti non sono sicuri di ciò che vogliono o non conoscono bene il dominio applicativo Danno per ovvi dettagli che non lo sono Hanno difficoltà ad esprimere tutte le loro necessità Specificano requisiti in conflitto con altri requisiti Problemi di volatilità I requisiti non sono stabili nel tempo Gestione dei Requisiti Problema della tracciabilità dei requisiti Che fine fanno i requisiti una volta realizzato il sistema? Come facciamo a dimostrare che sono stati implementati? Come li ritroviamo all interno del sistema?

4 Gestione dei Requisiti (2) Strumenti per la tracciabilità dei requisiti Tabella di tracciabilità delle funzioni Mostra le relazioni fra i requisiti e le funzioni del sistema Tabella di tracciabilità dell origine Identifica l origine di ciascun requisito Tabella di tracciabilità delle dipendenze Indica le relazioni esistenti tra i requisiti Tabella di tracciabilità dei sottosistemi Mette in relazione i requisiti ed i sottosistemi che li implementano Tabella di tracciabilità dell interfaccia Relaziona i requisiti e le interfaccie del sistema Gestione dei Requisiti (3) Esempio di tabella di tracciabilità dei sottosistemi Requisiti R01 R02 R03 R04 Sottosistemi S1 S2 S3

5 Quality Function Deployment Una tecnica per la traduzione delle necessità del cliente in requisiti per il sistema Obiettivo è la massimizzazione della soddisfazione del cliente per la quale si classificano i requisiti in: Requisiti Normali Sono requisiti esplicitamente richiesti dal cliente Requisiti Attesi Sono requisiti impliciti che il cliente da per scontato Requisiti Interessanti Sono funzionalità aggiuntive che possono accrescere la soddisfazione del cliente Ingegneria del Software Analisi e Specifica dei Requisisti

6 Analisi e Specifica dei Requisisti Scopi dell Attività: Definizione di funzioni, vincoli, prestazioni, interfacce e qualsiasi altra caratteristica che il sistema dovrà possedere per soddisfare le necessità del cliente Redazione di un Documento di Specifica dei Requisiti Software (SRS), che sia completo, preciso, consistente, non ambiguo, comprensibile sia al committente che allo sviluppatore Predisposizione di un piano di test e della versione 0 del manuale utente N.B. Definizione di COSA il sistema dovrà fare senza descrivere COME Necessità di un SRS Un SRS costituisce il punto di convergenza di tre diversi punti di vista: cliente, utente, sviluppatore Un SRS fornisce un punto di riferimento per la validazione del prodotto finale Un SRS di qualità è il pre-requisito per un software di alta qualità un errore nell SRS produrrà errori nel sistema finale Un SRS di qualità riduce i costi di sviluppo correggere un errore dell SRS dopo lo sviluppo costa 100 volte più che correggerlo durante la fase di Analisi

7 Il Processo di Specifica dei Requisiti Analisi del problema: Partendo da una generale definizione delle necessità dei potenziali utenti, comprendere: il problema, le condizioni di risoluzione ed i vincoli. Lo scopo è di comprendere cosa deve fare il sistema software che si vuole costruire. Specifica dei requisiti trasformazione dei requisiti in un documento di specifiche tecniche e funzionali caratterizzanti il sistema Validazione delle specifiche le specifiche, formalizzate, vengono riviste con l utente/ committente per validarle Il Processo di Specifica dei Requisiti (2) Bisogni utente Analisi del Problema Definizione Specifiche Processo con feedback fra le attività Durante l analisi: decomporre il problema in più parti e relative relazioni uso di modelli per rappresentare le informazioni raccolte (DFD, Object,) Validazione Transizione da analisi a specifica: non immediata, giacchè l analisi fissa la struttura del problema, mentre la specifica definisce il comportamento esterno del sistema

8 Analisi del Problema Comprensione del dominio applicativo (dal punto di vista del committente/utente) all interno del quale si dovrà calare il sistema da realizzare Descrizione dei processi di business Individuazione dei concetti attivi nel dominio Individuazione dei vincoli esistenti Individuazione degli altri sistemi attivi nel dominio Approcci e Strumenti per l Analisi del Problema La tecnica dell Analisi Strutturata Uso di Data Flow Diagrams e Dizionario dei Dati l analisi del problema viene eseguita usando l approccio della decomposizione delle funzioni Modello Entità- Relazioni per modellare i dati (concetti) e le relative relazioni usato per progettare database Analisi Object-Oriented l analisi del problema viene eseguita usando l approccio della decomposizione in oggetti (entità/ concetti del dominio del problema)

9 Specifica dei Requisiti La fase di analisi non definisce tutti gli aspetti del software quali: interfacce utente, gestione dei casi di errorre, vincoli di prestazioni, di progettazione, aderenza agli standard, pertanto La conoscenza acquisita nella fase di analisi dovrà essere tradotta nella Specifica dei requisiti la traduzione non è immediata Qualità di un documento SRS Corretto se ogni requisito presente nell SRS è realmente richiesto al sistema finale Completo se ogni funzione richiesta al software ed il suo comportamento rispetto ad ogni possibile input è specificato Non Ambiguo ogni requisito ha una sola interpretazione (formale vs. informale) Verificabile se è possibile verificare che il sistema realizzi ogni requisito (richiede la non ambiguità dei requisiti)

10 Qualità di un Documento SRS (2) Consistente se nessun requisito è in contraddizione con gli altri Modificabile se la struttura e lo stile dell SRS sono tali da consentire facili modifiche, preservando consistenza e completezza (un SRS con ridondanze non si modifica facilmente) Tracciabile se l origine di ciascun requisito è chiara e può essere referenziata nello sviluppo futuro (def. IEEE) forward traceability: requisito collegabile a qualche elemento del progetto e del codice backward traceability: dal progetto e dal codice è possibile risalire al requisito corrispondente Parti Fondamentali di un SRS Requisiti Funzionali la specifica di quali output sono prodotti dal sistema rispetto a dati input e la logica (non l algoritmo) con cui gli output sono ottenuti. Inoltre il range di input validi, il comportamento rispetto ad input/output non validi Requisiti sulle Prestazioni statiche:# terminali, #utenti simultanei, # file da processare dinamiche: tempi di risposta, throughput Vincoli di progettazione standard da seguire, limiti nelle risorse hardware/ software impiegate, ambiente operativo, affidabilità, sicurezza Requisiti sulle Interfacce esterne la specifica delle modalità con cui il software interagisce con l utente, hardware ed altro software

11 Linguaggi per la Specifica dei Requisiti Informali Le specifiche del sistema sono descritte in linguaggio naturale Formali La specifica è un oggetto formale rappresentata in una notazione definita in modo rigoroso sul piano sintattico e semantico Semiformali Si collocano in una posizione intermedia fra i due estremi; utilizzano, in genere, notazioni grafiche, con semantica poco formalizzata; sono di facile interpretazione; non consentono, o almeno riducono, interpretazioni ambigue; sono accompagnate da descrizioni in linguaggio naturale Struttura dell SRS (IEEE94) Table of contents 1.Introduction 1.1. Purpose 1.2. Scope 1.3. Definitions, Acronyms and Abbreviations 1.4. References 1.5. Overview 2.General Description 2.1. Product Perspective 2.2. Product Functions 2.3. User Characteristics 2.4. General Constraints 2.5. Assumptions and Dependencies 3.Specific Requirements 3.1. Functional Requirements Functional Requirement Introduction Inputs Processing Output Functional Requiremtnt Functional Requirement n 3.2. External Interface Requirements User Interfaces Hardware Interfaces Software Interfaces Communications Interfaces 3.3. Performances Requirements 3.4. Design Constraints Standard Compliance Hardware Limitation 3.5. Attributes Security Maintenability 3.6. Other Requirements DATABASE Operati Site Adaptation

12 Validazione delle Specifiche L obiettivo è quello di assicurare che l SRS rifletta accuratamente e con chiarezza i requisiti effettivamente richiesti al software Tipi di errori riscontrabili in un SRS Omissione (mancata presenza di un requisito) Inconsistenza (contraddizione fra i vari requisiti o dei requisiti rispetto all ambiente operativo) Incorrettezza (fatti non corretti nell SRS) Ambiguità (requisiti con significati multipli) Le tecniche di validazione devono puntare su tali errori Tecniche di Validazione Revisioni ed ispezioni manuali le tecniche più efficienti per la individuazione di errori/ difetti partecipano alle riunioni di revisione l autore dell SRS, il cliente, un progettista, un esperto di qualità ogni partecipante rivede l SRS prima della riunione uso di checklist durante l ispezione Tecnica di Reading qualcuno diverso dall autore legge l SRS per coglierne potenziali problemi (ambiguità, ) Uso di Scenari relativi alle varie modalità operative del sistema

13 Ingegneria del Software Analisi Strutturata - DFD Data Flow Diagram Rappresenta le trasformazioni che i dati subiscono nel loro flusso all interno del sistema Ogni sistema di elaborazione effettua una trasformazione di dati di ingresso in dati di uscita input computer based system output

14 Data Flow Diagram (2) Permette anche di descrivere processi di business Elementi Sintattici external entity process data flow data store

15 External Entity Un produttore o consumatore di dati Esempi: persone, dispositivi, sensori Un altro esempio: : computer-based system I dati devono sempre essere originati da qualche parte E devono sempre essere spediti a qualcuno o qualcosa Process Un elaboratore di dati (trasforma dati di input in dati di output) Esempi: calcolo di funzioni, elaborazione testi, rappresentazione grafica, I dati devono essere elaborati in qualche modo per ottenere le funzioni di sistema

16 Data Flow Il flusso dati in un sistema inizia come input e termina come output base altezza calcola area del rettangolo area Data Store I dati devo essere spesso memorizzati per elaborazioni successive report required sensor # look-up sensor data sensor number sensor #, type, location, age type, location, age sensor data

17 Gerarchia di un DFD Il DFD può essere realizzato su più livelli di dettaglio x a P b y level 0 a p1 c p2 f level 1 d p3 e p4 g 5 b