Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI Obiettivi Specifica dei Requisiti Assembly Lines Esercizi 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 SI-2011 Sistemi Informativi SPECIFICA DEI REQUISITI FUNZIONALI Obiettivi Specifica dei Requisiti Assembly Lines Esercizi Modello di riferimento 4 SI-2011 Flusso di lavoro di modellazione – Raccolta Requisiti IT 5 SI-2011 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 SI-2011 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 SI-2011 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 SI-2011 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 SI-2011 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 SI-2011 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 SI-2011 Tipologie di collaudo • Le fasi del collaudo corrispondono alle fasi dell’ideale modello a cascata di sviluppo del software 12 SI-2011 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 SI-2011 Tipologie di collaudo • Acceptance Testing – 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 SI-2011 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 SI-2011 Esempio. Test per classi di equivalenza • In questa specifica si partizionano gli input in tre categorie: 16 SI-2011 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 SI-2011 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 SI-2011 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 SI-2011 Esempio di un Piano di Test 20 SI-2011 Sistemi Informativi SPECIFICA DEI REQUISITI FUNZIONALI Obiettivi Specifica dei Requisiti Assembly Lines Esercizi 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 SI-2011 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 SI-2011 Assembly Lines con Entità Candidate Attività indicate negli Activity Diagrams Identificazione fabbisogni di produzione per i codici gestiti a scorta Fabbisogni Lordi in Pezzi Identificazione Previsioni Identificazione tipologia codice Identificazione Impegni e Prenotazioni Fabbisogni Produzione Reparti Make [codice in make] Calcolo Capacità Necessaria Make [codice in buy] Calcolo Capacità Necessaria Buy Candidate Entity da SIRE Conferma Quote Ordinate Carica Previsioni Imposta Previsioni Calcolo Capacità Necessaria Make Calcola Fabbisogni Lordi Calcolo Capacità Necessaria Buy Fabbisogni Produzione Reparti Buy Casi d’uso candidati PREV (Previsioni Commerciale) PC (Previsioni Cliente) P (Prenotazioni) read I (Impegni) AA (Anagrafica Articoli) DISTINTA (Distinta Base) write CICLI (Cicli Produzione) FABB (Fabbisogni) 24 SI-2011 Tabelle CRUD di rapporto attività/entità 25 SI-2011 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 SI-2011 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 SI-2011 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 SI-2011 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 SI-2011 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 SI-2011 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 SI-2011 Sistemi Informativi SPECIFICA DEI REQUISITI FUNZIONALI Obiettivi Specifica dei Requisiti Assembly Lines Esercizi Esercizi in classe • • • • • Caso Vendite ABC Caso Mutui Superbanca Caso Telefonica San Giulio Caso Supereco Caso Volafacile 33 SI-2011