Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI

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