Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI. Obiettivi Specifica dei Requisiti Assembly Lines Esercizi

Transcript

1 Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI Obiettivi Specifica dei Requisiti Assembly Lines Esercizi

2 Obiettivi Nelle lezioni precedenti abbiamo descritto come modellare i requisiti funzionali L obiettivo di oggi é: Come far discendere i requisiti funzionali dal diagramma di sequenza. 2

3 Sistemi Informativi SPECIFICA DEI REQUISITI FUNZIONALI Obiettivi Specifica dei Requisiti Assembly Lines Esercizi

4 Modello di riferimento 4

5 Flusso di lavoro di modellazione Raccolta Requisiti IT 5

6 Rischio sui Requisiti L analisi del rischio sui requisiti identifica i requisiti che potrebbero causare difficoltà nello sviluppo. La valutazione della priorità è necessaria per permettere una semplice taratura del progetto rispetto ai tempi La valutazione della frequenza permette di individuare i casi d uso più incisivi nel funzionamento del sistema La valutazione della criticità comprende una valutazione complessiva riguardante importanza della funzione nel sistema, difficoltà di sviluppo, complessità di implementazione 6

7 Valutazione delle criticità La criticità può comprendere i seguenti fattori di rischio: Rischio Tecnico, difficoltà di implementazione a livello tecnico Rischio Prestazionale, se un requisito implementato può far diminuire in modo non accettabile il tempo di risposta del sistema Rischio di sicurezza, se l implementazione del requisito espone il sistema a problematiche di sicurezza Rischio Integrità Dati, se l impl. Req. può causare inconsistenza nei dati, e questo è difficile da riscontrare Rischio Sviluppo, se l impl. Richiede l uso di strumenti di sviluppo non convenzionale o di cui si ha limitata esperienza Rischio Politico, quando parte della committenza o del team di sviluppo è contraria all implementazione del requisito Rischio legale, quando un requisito potrebbe violare leggi attualmente in vigore Rischio di volatilità, quando il requisito è particolarmente soggetto ad essere modificato 7

8 Requirements Management La gestione dei requisiti riguarda tre punti principali: Identificare, classificare, organizzare e documentare i requisiti Gestire le modifiche dei requisiti (proposta, negoziazione con il committente/implementatore, validazione, documentazione) Tracciabilità dei requisiti (mutue relazioni tra requisiti e come uno dipenda dall altro) 8

9 Identificazione e Classificazione dei Requisiti I requisiti sono descritti principalmente mediante asserzioni in linguaggio naturale I requisiti devono essere numerati seguendo uno schema: Numerazione generata in base alla struttura del documento dei requisiti Numerazione sequenziale rispetto alla categoria del requisito, eventualmente corredata da una etichetta mnemonica che ne identifica la categoria di appartenenza Identificatore unico generato da un database dei requisiti (compilazione dei requisiti guidata da uno strumento CASE) 9

10 Gerarchie di Requisiti I requisiti possono essere strutturati gerarchicamente (un requisito può essere composto da sotto-requisiti). La suddivisione corrisponde a livelli diversi di astrazione/dettaglio A ciascun livello di specifica dei requisiti è possibile associare un caso d uso UML ed illustrare la relazione tra requisiti e attori mediante diagrammi dei casi d uso. 10

11 Progettazione del collaudo dei requisiti L attività di collaudo è parte integrante del processo di sviluppo del software. Il collaudo può essere considerato sotto tre punti di vista: Il collaudo è un attività rivolta a valutare gli attributi o le capacità di un software o sistema, e di determinare che esso risponda ai risultati richiesti. Il collaudo è il processo di eseguire un software o sistema con l intento di trovarne dei difetti. Il collaudo è un processo con cui si esplora e si valuto lo stato dei vantaggi e dei rischi offerti da un software e collegati al suo rilascio. Le attività di collaudo avvengono in tutte le fasi di sviluppo del software/sistema. Non è pensabile un attività di sviluppo di successo per cui non siano pianificate adeguate attività di collaudo. Il collaudo di accettazione è il collaudo con cui si comprova presso il committente la rispondenza alle specifiche dei requisiti 11

12 Tipologie di collaudo Le fasi del collaudo corrispondono alle fasi dell ideale modello a cascata di sviluppo del software 12

13 Tipologie di collaudo (2) Unit Testing Detto anche collaudo dei componenti è una parte fondamentale del processo di implementazione. Consiste nel scrivere software o realizzare architetture di collaudo diretto del software. Uno dei principi cardini dell Xtreme Programming è lo scrivere i casi di test durante la scrittura delle unità. Questo migliora anche l architettura generale del software perché questa tecnica richiede scrittura di codice altamente modulare per consentirne la verificabilità automatica mediante attrezzature di test. Lo unit testing riguarda il team di sviluppo e il programmatore del componente. Il test dell unità è studiato e realizzato dal programmatore del componente. Integration Testing/System Testing L obiettivo del test di integrazione è assicurare che tutti i moduli compresi nell Applicazione Oggetto del Collaudo (AOC) si interfaccino e interagiscano tra loro in modo stabile, corretto e coerente. Il test di integrazione riguarda solitamente il team di sviluppo. I test di integrazione sono studiati dal progettista di sistema. 13

14 Acceptance Testing Tipologie di collaudo Lo scopo dell Acceptance Testing è di confermare che il sistema soddisfi i suoi requisiti di business, fornendo garanzie che il sistema funzioni correttamente e sia utilizzabile prima di essere consegnato agli utenti. I test di accettazione sono stilati dagli analisti, sia del team di sviluppo che del cliente, che redigono dei piani di test a partire dalla definizione dei requisiti del sistema sviluppato. Test di Regressione Lo scopo del test di regressione è fornire garanzie che AOC funzioni ancora correttamente dopo le modifiche o le estensioni apportati al sistema o al software. Non è propriamente una fase di test, ma una tecnica di test che viene applicata trasversalmente ad ogni fase di test. Il test di regressione avviene solitamente ripercorrendo i piani di test o i casi di test stilati per ogni fase, per verificare che essi diano ancora esito positivo. 14

15 Esempio Un sistema informativo per la rendicontazione di missioni dei commessi venditori prevede le seguenti specifiche per la parte di sistema che registra le spese di tipo alberghiero: C è un limite massimo di 80 per la rendicontazione di spese alberghiere, al giorno Qualsiasi registrazione che superi gli 80 viene respinta e causa la visualizzazione di un messaggio di errore Una registrazione deve essere > 0 per essere registrata, in caso contrario viene visualizzato un errore 15

16 Esempio. Test per classi di equivalenza In questa specifica si partizionano gli input in tre categorie: 16

17 Analisi al valor limite Si tratta di una tecnica collegata al partizionamento ai valori limite, che si basa sullo stesso principio: il raggruppamento in classi degli ingressi e delle uscite. Mentre il partizionamento in classi prevede la scelta di un valore rappresentativo per ogni partizione individuata, l analisi al valor limite si concentra sul collaudo utilizzando valori scelti ai limiti delle partizioni. L analista progetterà un caso di test per ciascuno dei valori al limite delle partizioni, oltre che per il valore all interno. 17

18 Esempio. Analisi al valor limite Considerando la specifica del sistema di rendicontazione, si individuano due confini: -1, 0, 1 e 79, 80, 81. Si possono aggiungere casi di test relativi ai seguenti valor limite: 18

19 Collaudo per funzione Viene utilizzato per collaudare le funzionalità business o la business logic della Applicazione Oggetto di Collaudo, nel modo con cui un utente o operatore può interagire con il sistema durante il suo normale uso. Tipicamente corrisponde alla creazione di script di test che ricalcano scenari di casi d uso elaborati dalle specifiche dei requisiti. Spesso questi script di test vengono raccolti in moduli e fanno parte del Test di Accettazione. 19

20 Esempio di un Piano di Test 20

21 Sistemi Informativi SPECIFICA DEI REQUISITI FUNZIONALI Obiettivi Specifica dei Requisiti Assembly Lines Esercizi

22 Derivazione dei Requisiti IT La definizione dei requisiti IT si fa discendere dai diagrammi di Assembly Line I diagrammi di Assembly Line non sono uno standard UML, ma sono un utile meccanismo per individuare entità candidate e casi d uso candidati Una volta derivati entità e casi candidati, essi vanno specificati e modellati secondo le canoniche metodologie UML La derivazione dalle Assembly Line è un processo di selezione di alcune attività business, raccolte dentro uno o più casi d uso 22

23 Entità Candidate Le entità candidate rappresentano strutture dati o unità informative la cui presenza si individua come significativa o probabile all interno del sistema IT di supporto. Le entità sono dette candidate perché solo una successiva analisi più dettagliata dei requisiti determina se esse sopravvivranno, evolveranno, o andranno ad inglobarsi con altre entità In generale una attività di business si svolge entrando in relazione di lettura/scrittura (tabella CRUD) con più entità candidate. Le assembly Line indicano graficamente i rapporti tra attività ed entità IT mediante relazioni dirette di lettura e di scrittura 23

24 Assembly Lines con Entità Candidate Attività indicate negli Activity Diagrams Identificazione Previsioni Identificazione tipologia codice Identificazione fabbisogni di produzione per i codici gestiti a scorta Identificazione Impegni e Prenotazioni Fabbisogni Lordi in Pezzi [codice in make] Calcolo Capacità Necessaria Make [codice in buy] Fabbisogni Produzione Reparti Make Candidate Entity da SIRE Carica Previsioni Imposta Previsioni Conferma Quote Ordinate Calcola Fabbisogni Lordi Calcolo Capacità Necessaria Make Calcolo Capacità Necessaria Buy Calcolo Capacità Necessaria Buy Fabbisogni Produzione Reparti Buy Casi d uso candidati PREV (Previsioni Commerciale) PC (Previsioni Cliente) P (Prenotazioni) I (Impegni) read AA (Anagrafica Articoli) DISTINTA (Distinta Base) CICLI (Cicli Produzione) write FABB (Fabbisogni) 24

25 Tabelle CRUD di rapporto attività/entità 25

26 Casi d uso candidati I casi d uso candidati riguardano funzionalità del sistema, che si svolgono mediante una serie di interazioni con le entità candidate, rilevate durante le associazioni di lettura/scrittura tra attività business ed entità candidate Non è necessario che tutte le associazioni r/w ricadano entro un caso d uso candidato 26

27 Criteri di buona formazione AL Questi criteri preparano il processo riprogettato per individuare con precisione adeguata entità e casi d uso candidati Occorre che ciascuna attività business da cui discende la AL sia atomica, cioè l attore di business non possa pensare ulteriori scomposizioni dell attività Gli output devono essere derivabili, a partire da tutti gli input che entrano nel processo business modellato (es. se escono dei materiali deve essere chiaro in che forma entrano) 27

28 La raccolta dei requisi IT La derivazione da AL consente di raccogliere requisiti IT a partire dalla riprogettazione del processo Altri requisiti IT possono essere derivati dall analisi di documentazione IT esistente, documentazione organizzativa, moduli, rapporti, studio delle funzionalità ERP correntemente utilizzate L utilizzo di prototipi software può essere utile per convalidare, investigare o scoprire ulteriori requisiti insieme al committente I requisiti evolvono durante lo sviluppo e la gestione di come essi cambiano e impattano sul processo di sviluppo viene detto Requirements Change Management. 28

29 Diagrammi dei casi d uso e Assembly Lines I diagrammi dei casi d uso rappresentano i requisiti raccolti durante la derivazione dalle AL Possono essere redatti a successivi livelli di astrazione (un caso d uso astratto può contenere gerarchicamente un diagramma dei casi d uso più specifico). Rappresentando i requisiti del sistema, si enfatizza cosa il sistema fa e chi fa che cosa (attori) Un caso d uso richiede l esecuzione di una computazione che avviene tramite interazione tra le entità candidate individuate nelle AL Le computazioni legate ad un caso d uso possono essere specificate con diagrammi di attività o di sequenza, in questi ultimi sono coinvolte le entità candidate. I modelli dei casi d uso, ed i relativi diagrammi dinamici di specifica sono sviluppati iterativamente e parallelamente al diagramma statico delle classi (entità candidate) 29

30 Assembly Lines: Metodo Individuare le entità candidate Iniziare dalla prima attività Individuare le informazioni anagrafiche lette o scritte (p.e. cliente, prodotto ecc.) Riportare le informazioni come entità candidate Individuare le informazioni dinamiche lette o scritte (p.e. ordini cliente, conferme ordine) Riportare le informazioni come entità candidate Continuare con le altre attività Per ogni attività individuare i casi d uso candidati (uno o più) Rivedere e rifinire le entità candidate e i casi d uso candidati 30

31 Controllo di integrità: Tavola CRUD (Create, Read, Update, Delete) Verifica delle precedenze. Individua le eventuali anomalie di precedenza in sede di progetto. L ordinamento delle funzioni nella tabella, infatti, rispecchia parzialmente l ordine di precedenza delle attività: una C non può seguire una R o U (una registrazione deve esistere per essere letta o modificata); una D non può precedere una R o U (una registrazione non può essere letta o modificata se è già stata cancellata). Verifica di chiusura. Individua le informazioni che non completano il loro ciclo vitale di creazione, modifica, lettura e cancellazione nell ambito delle funzioni di aggiornamento elencate nella tabella. Importazione. Le informazioni sono consultate (R) o modificate (U), ma non create (C) dal sistema. Queste informazioni devono essere generate da altri sistemi o da apposite funzioni di gestione archivi. Ridondanza. Le informazioni sono create (C) ma non consultate (R) né modificate (U). Le informazioni ridondanti, quando non utilizzate effettivamente da altri sistemi, vanno eliminate in quanto appesantiscono inutilmente le elaborazioni. Distruzione. Le informazioni sono cancellate (D) ma non create (C) né modificate (U). Questa casistica è segno di errori o di analisi incomplete. 31

32 Sistemi Informativi SPECIFICA DEI REQUISITI FUNZIONALI Obiettivi Specifica dei Requisiti Assembly Lines Esercizi

33 Esercizi in classe Caso Vendite ABC Caso Mutui Superbanca Caso Telefonica San Giulio Caso Supereco Caso Volafacile 33