La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

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

Presentazioni simili


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

3 Sintesi Due casi di determinazione dei requisiti ove si è visto che lattività di determinazione dei requisiti (o comunicazione) e quella di specifica (o modellazione analitica) sono state svolte a partire da una richiesta del committente (dal nulla – greenfield engineering - con richiesta più o meno innovativa) Si è evidenziato che: –La richiesta del committente, in generale, non indica direttamente i requisiti del software ma tali requisiti devono essere esplicitamente determinati; infatti, la richiesta del committente, in generale, riguarda un sistema in cui il software da sviluppare è solo una parte (il sistema è perciò costituito sia dal software da sviluppare che dallambiente circostante a tale software e che con questo interagisce), indica, in particolare, cosa tale sistema dovrebbe permettere, anche dicendo poco o nulla su come tale sistema dovrà essere realizzato –La tracciabilità di un requisito è, di conseguenza, un elemento fondamentale poiché giustifica un requisito in termini della richiesta del committente

4 Sintesi Non si è distinto tra le due attività: –Le diverse notazioni – semiformali – (cioè DFD, DFD esteso, UML) usate sono servite per svolgere analisi per verificare se ciò che è stato fatto è corretto, è completo o per ragionare su alternative possibili (determinazione dei requisiti), quindi permettere eventuale negoziazione anche in termini di tempi e costi –E fatto osservare che i requisiti del software da sviluppare devono essere esplicitamente accettati o convalidati dal committente; il ruolo dellingegnere del software è solo quello di aiutare il committente nel definire e nel convalidare i requisiti del software (determinazione dei requisiti) –Ma si è anche detto che ciò che è rappresentato con una o più notazioni è efficacemente usabile per progettare il software (specifica dei requisiti) Nelluso delle notazioni si è evidenziato come lingegneria del software è sistematica cioè tenta di applicare regole definite per costruire diverse rappresentazioni (dei requisiti) con la medesima o diverse notazioni

5 Se un sensore non funziona, il sistema dovrebbe fermare lascensore in funzione ai piani precedenti o successivi Lascensore deve fermarsi se il sensore del piano selezionato rileva il passaggio dellascensore Movimento Comprensione Modellazione Analisi Convalida Negoziazione Verifica Ammettiamo che un sensore non funziona; cosa accade? Sensori Ev_ascensorepiano(x) Movimento

6 Notazioni usate per la modellazione Matrici DFD Casi dUso (UML) Statechart (UML) DFD estesi Diagramma delle classi (UML) Diagramma di sequenza (UML)

7

8 Generalizzazione

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 è lambiente 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 i legami tra tali requisiti (inclusa la tracciabilità) Spesso tale collezione coincide con un documento dei requisiti

10 Specifica dei requisiti: una definizione Obiettivo: produrre una specifica dei requisiti cioè una precisa descrizione (modello) informale, semiformale ovvero formale, di tutti requisiti determinati, che permette di passare sistematicamente alla progettazione del software Qualunque sia il modo di operare, dovrebbe essere chiaro il legame tra i requisiti determinati e il modello qui costruito (tracciabilità) La specifica può essere più o meno formale ma dovrebbe essere sempre sufficientemente precisa, completa e corretta; come vedremo, la scelta per una specifica formale è essenzialmente legata alla necessità di provare una relazione fondamentale, tra i requisiti del software, il comportamento dellambiente circostante il software e, ciò che è richiesto dal committente

11 I prodotti principali delle due attività e le loro relazioni Il documento dei requisiti (una o più notazioni) che raccoglie la collezione organizzata dei requisiti determinati Il modello dei requisiti o modello analitico (una più notazioni) che rappresenta in modo opportuno la collezione dei requisiti determinati Il modello dei requisiti può far riferimento a modelli già presenti nel documento dei requisiti I due elaborati devono essere consistenti cioè non devono essere mutuamente contradditori

12 Dettaglio delle attività di determinazione e specifica dei requisiti Comprensione Modellazione Analisi Convalida Negoziazione Verifica Prototipo (*) Modellazione (*) dipende dal processo può riusare o riferirsi devono essere non contradditori (verifica) Requisiti (Collezione + Documento dei Requisiti) Modello Linguaggio Comune Modello dei Requisiti (Modello Analitico o Specifica dei Requisiti) Modello Linguaggio Comune

13 Notazioni alternative per la specifica dei requisiti e la determinazione dei requisiti Una loro combinazione Formale Semi-Formale Informale

14 Esempio Fermare Spegnere i pulsanti (una passo del caso duso) Partire (una caratteristica del sistema) Descritto come traced to (from)

15

16 Rumore – le affermazioni non indicano informazioni utili Silente – qualcosa di non coperto dalle affermazioni Sovra-specificato – si indica nelle affermazioni troppo sul come realizzare Contraddizione – parti delle affermazioni che si contraddicono. Ambiguità – esistono varie interpretazioni di unaffermazione, non necessariamte contradditorie Forward reference – riferimenti a termini o altri elementi non ancora definiti nelle affermazioni Non validabile – non si è certi che è possibile convalidare ciò che è affermato Frammentati – gli elementi chiave contenuti nelle affermazioni sono dispersi in un documento Requisiti oca – affermazioni formalmente corrispondenti a standard Terminologia inconsistente – Invenzioni e modifiche della terminologia usata nelle affermazioni Rimandare il problema ad altri – Obbligo per chi deve usare le affermazioni di decifrare il loro significato Formulazione per il lettore ostile I problemi del linguaggio comune per esprimere i requisiti

17 Esempio di misure di qualità dei requisiti scritti in linguaggio comune Imperatives identified by words such as shall, must, is required, etc. Imperatives measure how explicit a requirement document is. Continuances follow an imperative and introduce requirements indicated by below:, as follows: etc. measure the structure of an a requirement document. Option indicated by words such as can, may, optionally etc. measure how much latitude does a requirement document leave Weak phrases cause uncertainty e.g. adequate, as applicable etc. Directives indicated by tables, figures etc these strengthen the quality of the document Size in terms of lines of text, indicators and subjects roughly, the number of subjects for all the imperatives Text structure measures the number of statement identifiers Specification depth measures how deep are the subsections of the a requirement document gives an indication of a requirement document structure. Readability statistics e.g average number of syllables per word, number of words per sentence

18 Cosè un requisito del software Un requisito del software è unaffermazione sul software che riguarda proprietà, comportamenti, vincoli (di varia natura) del software Tali affermazioni possono riguardare come si deve comportare (requisiti funzionali), ed altre affermazioni sul software ovvero del prodotto software (requisiti non funzionali) Ma per essere requisiti, tali affermazioni dovrebbero possedere almeno alcune caratteristiche!

19 Caratteristiche di un requisito (qualunque sia la notazione) Grado di priorità Grado di stabilità Grado di rischio Condiviso Non ambiguo Completo Non in conflitto Tracciabile Verificabile Manutenibile Traceability (IEEE) : the degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor- successor or master-subordinate relationship to one another Traceability (ISO 8402) : is the ability to trace the history, application or location of an entity by means of recorded identifications

20 ambiguo ridondanteinconsistente incomprensibile incompleto espandere sintetizzare ridurre spiegare formalizzare espandere risolvere Esistono affermazioni perfette per i requisiti? formalizzare

21 Verification and Validation assessing adequacy of test suite assessing conformance to requirements assessing completeness, consistency, impact analysis assessing over- and under-design investigating high level behaviour impact on detailed specifications detecting requirements conflicts checking consistency of decision making across the lifecycle Maintenance Assessing change requests Tracing design rationale Document access ability to find information quickly in large documents Process visibility ability to see how the software was developed provides an audit trail Management change management risk management control of the development process Importanza della Tracciabilità

22 I requisiti hanno sempre un doppio ruolo requisito Committente Affermazione sufficientemente precisa, anche sufficientemente comprensibile al committente, giustificata in termini della sua richiesta Affermazione sufficientemente precisa (cioè non ambigua), (direttamente) usabile da progettisti e sviluppatori e, talvolta, anche al committente Progettisti, Sviluppatori, Committente non contradditori (verifica)

23 Esempio I: il doppio ruolo dei requisiti Un utente deve poter inserire la sua partenza e la sua destinazione, le ore ed i giorni di partenza e di arrivo E possibile effettuare una ricerca sui possibili treni esistenti secondo i seguenti criteri….. Ricercare utente Treni Cosa è più comprensibile per il Committente? If Dest and Arr are available then Seleziona Treni tali che… Cosa è necessario per rispondere adeguatamente alla richiesta del Committente? Rif. Esempio Treno Dest+Arr | Dest+Arr+Hp|Ha | … Il requisito espresso in linguaggio comune pur astrattamente ambiguo potrebbe essere accettabile se il committente e lingegnere dei requisiti sono daccordo che questo rappresenta tutte le possibili situazioni ovvero una qualunque situazione Cosa è necessario affinché sia possibile progettare il software?

24 Esempio II: il doppio ruolo dei requisiti Se un sensore non funziona, il sistema dovrebbe fermare lascensore in funzione ai piani precedenti o successivi Lascensore deve fermarsi se il sensore del piano selezionato rileva il passaggio dellascensore Fermare& Partire Sensori Ev_ascensorepiano(x) If Ev_ascensorepiano (x) and Direction=Down and ProssimaRichiesta(y) and x

25 Il documento dei requisiti In generale il documento dei requisiti raccoglie in modo organizzato i requisiti determinati, descritti in una o più notazioni, ed anche informazioni ulteriori sulla richiesta del committente e su come la determinazione ha avuto luogo La forma di tale documento è generalmente standardizzata nella forma e nei contenuti dalla meteodologia adottata (anche perché spesso costituisce una base contrattutale) Tale standardizzazione può essere relativa alla metodologia specifica ovvero coincidere con uno standard di riferimento come ad esempio IEEE

26 Il documento dei requisiti Il documento dei requisiti contiene generalmente diagrammi e, collegate, affermazioni in linguaggio comune

27 La forma del modello analitico In generale una metodologia propone una forma del modello analitico che sispira alluso di una o più notazioni, legate da regole più o meno precise Le metodologie si differenziano spesso in base alla tipologia delle notazioni usate (non alla notazione poiché si è detto che esistono notazioni diverse per DFD, DFD estesi, mentre per UML la notazione è adattabile ovvero si possono usare diverse notazioni per esprimere classi, scambio di messaggi etc.)

28 (Analisi Strutturata)

29 Modello Object-Oriented di Analisi (Esempio) Classi (attributi ed operazioni) Diagrammi di Sequenza Casi dUso Statecharts

30 Quali requisiti vengono specificati I requisiti sono di varia natura; i requisiti che vengono specificati sono: –I requisiti funzionali –Parte dei requisiti non funzionali, se necessario I requisiti funzionali indicano tipicamente le funzionalità, i comportamenti, le proprietà ovvero le informazioni desiderati I requisiti non funzionali indicano talvolta delle proprietà desiderate che devono essere soddisfatte dal prodotto software; linteresse per i requisiti non funzionali deve essere considerato nella specifica dei requisiti funzionali (ad esempio, nel caso ascensore, se il tempo di trattamento per richieste prioritarie deve essere inferiore a 0,01ms può obbligare a requisiti funzionali diversi)

31 Una tassonomia dei requisiti non funzionali

32 Uso delle notazioni nella Ingegneria dei Requisiti

33 Metodi-Pratiche Metodi/Pratiche che aiutano a trasformare una descrizione testuale anche imprecisa in un diagramma (per estrarre, dedurre, etc. i requisiti) Metodi/Pratiche che aiutano a trasformare una notazione in unaltra (ed associati, Metodi/Pratiche che aiutano a verificare la eventuale equivalenza): –Per passaggio, –Per incremento. Metodi/Pratiche di analisi che aiutano a valutare la completezza e la correttezza di ciò che è stato rappresentato tramite un diagramma (per estrarre, dedurre, etc. i requisiti) Metodi/Pratiche per provare formalmente la relazione fondamentale (verificare)

34 Riepilogo: Notazioni Usate Linguaggio (notazione)Uso Diagramma dei casi dusoScenari DFDFunzioni DFD di contestoFunzione DFD ed ERFunzioni e Dati DFD Estesi (con Statechart)Comportamento StatechartComportamento Diagramma delle classiOggetti concettuali Diagramma di sequenzaInterazioni degli oggetti (concettuali)

35 Sistematizzazione dei passaggi usati negli esempi (Metodi-Pratiche) Che abbiamo usato: –DFD --- DFD –Un caso duso (passo) --- una funzione (Treno) –Un caso duso --- uno stato (Ascensore) –Un caso duso --- una transizione di stato (Ascensore) –Una condizione --- un evento (Ascensore) –Statechart --- DFD estesi (Ascensore) –Statechart --- casi duso (Ascensore) Un passaggio è tipicamente caratterizzato dal fatto che la rappresentazione da cui si parte è SOSTITUITA dalla nuova rappresentazione

36 Modello Object-Oriented di Analisi (Esempio) Classi (attributi ed operazioni) Diagrammi di Sequenza Casi dUso Statecharts

37 Cosa è stato fatto nellesempio dellascensore Partire Sensore Piano Piano numero Pulsante Stato Tempo di reazione Direzione Data controllo Porta Sensore Tipo Stato Tempo di reazione Data controllo classe: una tipologia di oggetti, con propri attributi ed operazioni nomeclasse attributi Fermare Cabina Richiesta Leggendo i passi

38 Cosa è stato fatto nellesempio dellascensore Partire Leggendo i passi Pulsante Stato Tempo di reazione Direzione Data controllo illuminare( ) spegnere() Leggendo loperazione operazioni

39 Cosa è stato fatto nellesempio dellascensore Sensore Piano 1 1..* Piano numero 1 Pulsante Stato Tempo di reazione Direzione Data controllo illuminare( ) spegnere() Porta Sensore Tipo Stato Tempo di reazione Data controllo 1 1 classe: una tipologia di oggetti, con propri attributi ed operazioni associazione attributi Cabina Richiesta Cosa è necessario per eseguire loperazione dimmi quali sono i pulsanti da illuminare cardinalità

40 Sistematizzazione dei passaggi nel caso del modello di analisi object- oriented (Metodi-Pratiche) Che abbiamo usato: –Casi duso (passo) --- classi, attributi –Casi duso --- sequenza –Sequenza --- classi e operazioni –Precondizioni --- messaggi (operazioni) Che si possono usare: –Sequenza --- Statechart –Statechart --- classi, Statechart

41 Sistematizzazione degli incrementi modello di analisi object-oriented (ordinati) (Metodi-Pratiche) Che abbiamo usato: –Operazioni --- associazioni, attributi Che si possono usare: –Classe --- Statechart –Classe --- Classe –Classe --- associazioni –Classe --- attributi Un incremento è tipicamente caratterizzato dal fatto che la rappresentazione da cui si parte è COMPLETATA dalla nuova rappresentazione

42 Sistematizzazione degli incrementi modello di analisi object-oriented (ordinati) (Metodi-Pratiche) Diagramma delle Classi Diagramma Casi dUsoDiagrammi Sequenza incrementare

43 Relazione tra Ingegneria dei Sistemi ed Ingegneria dei Requisiti

44 Sistema(i), requisiti del software: una visione dinsieme Diminuire le code Cercare, Prenotare, Pagare etc. Ricerca Prenotazione Con quale sistema? Con quale software? Requisiti del software Requisiti del sistema ove sistema = software + ambiente del software Rif. Esempio Treno

45 Sistema e Requisiti del Software: relazione fondamentale (Requisiti del Software AND Ipotesi sullambiente circostante il Software) SODDISFA Requisiti del Sistema dove: Sistema=Software+Ambiente circostante al software Provare formalmente? (= Verificare)

46 Treno (Requisiti del Software: Casi duso AND Ipotesi sullambiente circostante il Software: almeno il 5% dei clienti possiede una carta di credito AND …) SODDISFA Requisiti del Sistema: le code devono diminuire del 10% rispetto alla situazione attuale)

47 Treno (Requisiti del Software: Casi duso AND Ipotesi sullambiente circostante il Software: almeno il 5% dei clienti possiede una carta di credito AND almeno il 30% dei clienti abituali userà il software AND …) SODDISFA Requisiti del Sistema: le code devono diminuire del 10% rispetto alla situazione attuale)

48 Ascensore (Requisiti del Software: casi duso + statechart + DFD esteso (formalizzabile) AND Ipotesi sullambiente circostante il Software: statechart dei vari dispositivi o software circostanti al software da sviluppare) (formalizzabile) SODDISFA Requisiti del Sistema: in condizioni normali di operatività, se un utente preme il pulsante, lascensore arriva mediamente in 1 (proprietà formalmente esprimibile)

49 Organizzazione della Ingegneria del Sistema e dei Requisiti Desiderata del sistema Estrarre Requisiti del sistemaSoddisfare Estrarre, dedurre, etc. Ipotesi ambiente del software Requisiti del software Ingegneria di sistema Ingegneria dei requisiti Richiesta del committente

50 Ascensore: un caso dIngegneria di Prodotto Lingegneria di prodotto (una tipologia di ingegneria dei sistemi) si pone come finalità la costruzione di un prodotto nel perseguimento di determinati obiettivi Il punto chiave è la definizione e la valutazione delle alternative per sviluppare il prodotto Ad esempio, nel caso dellascensore è importante dare una risposta ai seguenti quesiti: quanti sensori è necessario avere, quale manutenzione dei componenti dovrebbe essere messa in opera, quante cabine devono essere disponibili etc.

51 Ingegneria di Processo Pressman propone come esempio di sistema industriale un sistema dinstradamento di scatole su nastro trasportatore Come decidere su qual è il software da sviluppare? Diagramma attività (UML)

52 Capitoli del Pressman per Ingegneria dei Requisiti – e dei Sistemi - 5, 6, 7, 8 (alcuni paragrafi verranno trattati in dettaglio più avanti parlando di test) Tranne 5.3, 5.4.2, 5.5, 5.6


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

Presentazioni simili


Annunci Google