Business Analysis II. Analisi Tecnica Prof. Thimoty Barbieri Università degli Studi di Pavia

Transcript

1 Analisi Tecnica Prof. Università degli Studi di Pavia

2 Obiettivi del Corso Mostrare una tecnica di riprogettazione dei processi gestionali: Scelta della strategia informatica per il miglioramento degli indicatori riscontrati Mostrare come raccogliere i requisiti informativi e Progettare il sw Utilizzo di tecniche standard dell ingegneria del sw Introdurre alla stima dei tempi e alla progettazione operativa Tecniche di dimensionamento Programmazione di Progetto Presentare tecniche di realizzazione SOA Oriented BPM / jbpm / BPEL 2

3 Laboratorio di analisi delle informazioni e dei processi produttivi e logistici Indirizzo Logistico Produttivo Analisi e Specifica dei Requisiti IT

4 Flusso di lavoro di modellazione Raccolta Requisiti IT Business Structure View Organigrammi User View Business Process View Process Diagrams Assembly Lines Class Diagrams Use Case Diagrams Business Modeling Business Behavior View State Diagrams Activity Diagrams Sequence Diagrams Descrizione in Linguaggio Naturale Piani di Collaudo Structural View Class Diagrams Object Diagrams State Diagrams Behavioral View Activity Diagrams Sequence Diagrams System Modeling GUI 4

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

6 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 sopravviveranno, 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 6

7 Assembly Line con Entità Candidate 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 Entità Candidata PREV (Previsioni Commerciale) 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 PC (Previsioni Cliente) P (Prenotazioni) I (Impegni) Lettura AA (Anagrafica Articoli) DISTINTA (Distinta Base) CICLI (Cicli Produzione) Scrittura FABB (Fabbisogni) 7

8 Tabelle CRUD di rapporto attività/entit /entità Identificazione Previsioni Identificazione Tipologia Codice Identificazione Impegni e Previsioni Calcolo Capacità Necessaria Buy Calcolo Capacità Necessaria Make PREV CRU PC R P R AA R R R I CR DISTINTA R R CICLI R R FABB C RU RU 8

9 Casi d uso d 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 9

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

11 La raccolta dei requisiti 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. 11

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

13 Valutazione della 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 13

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

15 Identificazione e Classificazione 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) 15

16 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 illustrarre la relazione tra requisiti e attori mediante diagrammi dei casi d uso. 16

17 Esempio di Requisiti CU 3: INSERIMENTO CONFERMA D ORDINE/ORDINE [CU3.1] Il commerciale riceve da un cliente una conferma d ordine o un ordine. [CU3.2] Il commerciale apre la finestra di Conferma ordinativo per un dato cliente. [CU3.3] Il commerciale carica le previsioni effettuate da se stesso per un determinato articolo e periodo temporale [CU3.4] Il sistema evidenza se l articolo viene prodotto in make oppure in buy [CU3.5] Il sistema evidenza il prezzo standard dell articolo e il tempo medio di realizzazione. [CU3.5.1] Se presenti, il commerciale carica le previsioni effettuate ed inviate dal cliente, per un determinato articolo e periodo temporale [CU3.6] Il commerciale inserisce i dati di conferma ordinativo pervenuti dal cliente per un determinato articolo. [CU3.6.1] Se i dati sono corrispondenti a una previsione, è sufficiente inserire i dati di conferma e trasformare la previsione in un impegno. [CU 3.6.2] Se i dati non sono corrispondenti a una previsione, si inseriscono tutti i dati necessari e si crea un impegno. 17

18 Diagrammi dei Casi d Usod 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) 18

19 Modellazione Casi d Usod I requisiti testuali si mappano 1:1 con i casi d uso dei diagrammi. Nella ricerca dei casi d uso occorre tenere presente che: Un caso d uso modella una funzionalità completa (comprendente il flusso principale di esecuzione, le sue deviazioni, e le condizioni di eccezione Un caso d uso è una funzionalità visibile esternamente all utente e come tale da esso percepita, interagendo con il sistema/software Ha un comportamento ortogonale rispetto ai comportamenti espressi dagli altri casi d uso (i casi d uso possono condividere oggetti durante l esecuzione, ma ciascuna esecuzione è indipendente dalle altre) Un caso d uso rappresenta una funzionalità che è sempre iniziata da un attore (ma una volta iniziato, il caso d uso può poi interagire con altri attori); è possibile che un attore riceva semplicemente i risultati di un caso d uso iniziato da un altro attore Un caso d uso è una funzionalità che produce sempre al termine dell esecuzione del singolo caso d uso un risultato significativo e come tale percepibile esternamente per un altro attore 19

20 Ricerca dei Casi d usod E utile porsi queste domande, aiutandosi a rispondere dalla mappatura derivante dalle AL: Quali sono le principali attività eseguite da ciascun attore? Un attore accede o modifica l informazione nel sistema? Un attore informa il sistema su variazioni in altri sistemi? Un attore dovrebbe essere informato su modifiche avvenute nel sistema? 20

21 Disegno del Diagramma Use Case Lo stickman rappresenta lo stereotipo <<actor>>. L ovale rappresenta lo stereotipo di caso d uso. Ciascun nome deve riflettere una funzionalità del sistema secondo l analisi dei requisiti. La freccia di associazione determina se l attore innesca il caso d uso o ne subisce gli effetti. Venditore Inserimento Ordine Cliente Convalida Ordine Direttore 21

22 Esempio di Diagramma Calcola Fabbisogni Lordi <<includes> > Calcolo Capacità Necessaria Make <<uses>> <<includes>> Calcolo Capacità Necessaria Buy Commerciale Conferma Quote Ordinate Direttore Produzione Carica Previsioni <<includes>> Imposta Previsioni 22

23 Stereotipi e Tipi di Associazione I casi d uso possono essere in relazione tra loro mediante particolari associazioni: Associazione normale: stabiliste una comunicazione tra attore e caso d uso Generalizzazione: permette a un caso d uso specializzato la modifica o l estensione di un aspetto del caso d uso di base Inclusione <<include>>: specifica che un caso d uso di base comprende sistematicamente il comportamento descritto dal caso d uso incluso. Il caso d uso incluso non è mai eseguito da solo ma solamente in quanto parte del caso d uso di base. Estensione <<extend>>: estende il comportamento del caso d uso base attivando un altro caso d uso solamente in alcuni particolari casi (opzionali nel regolare funzionamento del caso d uso base) Utilizzo <<use>>: specifica che un caso d uso utilizza in parte o in tutto un altro caso d uso per il suo completamento 23

24 Generalizzazione tra Attori La generalizzazione tra attori consente di individuare diverse categorie di accesso a determinate funzionalità. I casi d uso legati agli attori padri sono legati anche agli attori figli, che possono avere associazioni aggiuntive (specializzanti) ad altri casi d uso. 24

25 Specifica di un flusso di requisiti mediante Activity Diagram I diagrammi di attività possono essere utilizzati per chiarire i flussi con cui i requisiti di dettaglio compongono un caso d uso Nel diagramma risulta anche semplice spiegare a chi compete una determinata attività, e se questa attività sia innescata da un evento in ingresso, o produca un determinato evento in uscita. Nei diagrammi di attività vengono spesso indicati eventi in ingresso o in uscita ad una sequenza di attività, ed elementi informativi di transito che evolvono passando tra un attività e l altra di una sequenza. 25

26 Diagramma di Cli ente Venditore attività Inserimento Ordine Direttore Verifica Ordine [ > 5000 Euro ] [ <= 5000 Euro ] Convalida Ordine Controlla Solvibilità Invio Acconto [ Non Solvibile ] Annulla Ordine [ Solvibile ] Ordina Spedizione 26

27 Finestra impegni vuota Diagramma di Seleziona Cliente Attività Visualizza Previsioni Venditore per Cliente Visualizza Previsioni Cliente per Cliente [dati da verificare rispetto a previsioni] Inserimento Interrotto [Ordine non previsto] [Conferma coincide con previsione] Inserisci Conferma Ordine per Articolo per Cliente Conferma una Previsione come Impegno Aggiorna Errore Previsionale per Inserimento Aggiorna Errore Previsionale Impegno Inserito 27

28 Schema Documentale Completo di Specifica di Caso d Usod Ogni caso d uso individuato deve essere descritto utilizzando il seguente schema: Attori: elenco di attori afferenti o efferenti al caso Breve Descrizione: una frase che sintetizza la natura del caso Flusso di Eventi: l elenco numerato dei sottorequisiti che compongono il caso. I Flussi Alternativi spiegano eventuali modalità alternative di esecuzione del caso. Pre Condizioni: una serie di asserzioni che devono essere verificate perché il caso possa essere iniziato in esecuzione (si usa per stilare i piani di collaudo) Post Condizioni: una serie di asserzioni che devono essere verificate alla fine dell esecuzione del caso d uso (si usa per stilare i piani di collaudo) Eccezioni: una serie di possibili errori che devono essere rilevati nel sistema, o di eventi che possono causare una non lineare/corretta esecuzione del caso d uso (si usa per stilare i piani di collaudo) Frequenza Stimata di Utilizzo (si usa per decidere le priorità nel piano di sviluppo) Criticità (si usa per stimare il rischio legato al requisito) 28

29 Esempio di Specifica Caso d Usod [CU3]: Identificazione dei fabbisogni per codici a scorta :: Conferma Quote Ordinate Attori Commerciale Breve Descrizione Questa funzione consente di visualizzare per cliente e articolo le previsioni di ordinativo, inserire un ordinativo effettivo e confrontare la previsione con l ordine effettivo Flussi Alternativi [CU3.10] Il commerciale decide di non inserire l impegno perché l ordine è sensibilmente difforme alla previsione venditore. [CU3.11] Il commerciale decide di non inserire l impegno perché l ordine è sensibilmente difforme alla previsione cliente. [CU3.12] Il commerciale decide di non inserire l ordine perché il prezzo concordato è sensibilmente difforme al prezzo standard Flusso di Eventi Flusso Base [CU3.1] [CU3.2] [CU3.3] Il commerciale riceve da un cliente una conferma d ordine o un ordine. Il commerciale apre la finestra di Conferma ordinativo per un dato cliente. Il commerciale carica le previsioni effettuate da se stesso per un determinato articolo e periodo temporale [CU3.4] Il sistema evidenza se l articolo viene prodotto in make oppure in buy [CU3.5] Il sistema evidenza il prezzo standard dell articolo e il tempo medio di realizzazione. [CU3.6] Se presenti, il commerciale carica le previsioni effettuate ed inviate dal cliente, per un determinato articolo e periodo temporale [CU3.7] Il commerciale inserisce i dati di conferma ordinativo pervenuti dal cliente per un determinato articolo. [CU3.8] Se i dati sono corrispondenti a una previsione, è sufficiente inserire i dati di conferma e trasformare la previsione in un impegno. [CU3.9] Se i dati non sono corrispondenti a una previsione, si inseriscono tutti i dati necessari e si crea un impegno Pre Condizioni Al commerciale perviene un ordine da trasformare in impegno Post Condizioni E stato inserito un impegno a fronte dell ordinativo, oppure non si è in alcun modo modificata la situazione precedente Eccezioni Dati inseriti non validi Frequenza Stimata di Utilizzo (bassa, media, alta) ALTA Criticità (bassa, media, alta) ALTA 29

30 Progettazione del Collaudo sui 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 30

31 Tipologie di Collaudo Le fasi di collaudo corrispondono alle principali fasi dell ideale modello a cascata di sviluppo del software. Regression Test 31

32 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 (fixtures) 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. 32

33 Acceptance Testing Tipologie di Collaudo (3) 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. 33

34 Criteri di Analisi per Scrittura di Piani di Collaudo Il collaudo avviene seguendo dei Piani, elenco di attività di collaudo che prevedono l esecuzione di determinate operazioni, tipicamente la prova delle funzionalità principali del sistema, sottoponendo opportune collezioni di dati in input, a fronte delle quali ci si aspettano definite collezioni di dati in output. Compito dell analista è individuare le funzionalità da testare, e quali input ed output sono i più convenienti per verificare in modo efficiente ed efficace le funzionalità del sistema A questo fine esistono alcuni criteri guida di analisi del dato legato alla funzione IT e business. 34

35 Criteri di Collaudo I criteri di collaudo si possono suddividere in tre principali gruppi: Criteri di Collaudo Generali Collaudo Positivo e Negativo Collaudo White Box e Black Box Intuizione dell errore Collaudo software automatizzato Criteri di Collaudo Funzionali Partizionamento per Classi di Equivalenza Analisi al valor limite Collaudo Casuale Collaudo per transizione di stato Collaudo per funzione 35

36 Criteri di Collaudo (2) Criteri di Collaudo Non Funzionali Collaudo di Configurazione/Installazione Collaudo di compatibilità Collaudo di Ripristino da Guasto Collaudo di Prestazioni Collaudo di Affidabilità Collaudo di Carico Collaudo di Sicurezza Collaudo di Usabilità 36

37 Collaudo Positivo e Negativo L intento del collaudo positivo è verificare che un sistema risponda ai suoi requisiti. I casi di test vengono sviluppati mediante analisi dei requisiti di sistema, tipicamente attorno alle funzionalità cardine comprese nel test di accettazione. Il processo di collaudo negativo serve a dimostrare che un sistema non fa quello che non deve fare. A questo scopo i casi di test sono progettati per investigare il comportamento di AOC fuori dalle specifiche dei requisiti. Il collaudo negativo viene spesso utilizzato per collaudare aspetti di AOC che non sono stati documentati, o sono stati documentati male o in modo incompleto nelle specifiche dei requisiti. 37

38 Collaudo per Transizione di Stato L analisi delle transizioni di stato parte da uno o più diagramma degli stati UML, in cui si modellano i possibili stati in cui si trova il sistema, e gli eventi che lo fanno transire, più le eventuali azioni contestuali alla transizione. L analista disegna dei casi di test il cui scopo è attivare tutte le transizioni tra uno stato e l altro, specificando: Lo stato iniziale Gli input del sistema Gli output attesi Lo stato finale atteso L analisi della transizione degli stati solitamente produce casi di test di tipo positivo o negativo. 38

39 Specifica dei requisiti: Videoregistratore. Esempio Il videoregistratore può trovarsi in uno di tre stati: standby, acceso, in riproduzione. 1. Quando si trova in standby, il videoregistratore può essere acceso premendo una volta il pulsante standby (un indicatore luminoso passa da rosso a verde ad indicare che il videoregistratore è acceso). 2. Quando il videoregistratore è acceso, può tornare in modo standby premendo il pulante standby una volta (un indicatore luminoso passa da verde a rosso ad indicare che il videoregistratore è in modo standby) 3. Quando il videoregistratore è acceso premendo il pulsante Play si riproduce la cassetta correntemente inserita nell apparecchio. Premendo il pulsante Stop quando il videoregistratore sta riproducendo, causa l arresto della riproduzione video. 39

40 Esempio Casi di Test Positivi: Verificare che con il videoregistratore in standby, la pressione del tasto standby causi il passaggio dell indicatore luminoso da rosso a verde e l accensione del videoregistratore. Verificare che con il videoregistratore in stato acceso, la pressione del tasto standby causa il passaggio allo stato di standby e l indicatore luminoso passa da verde a rosso Casi di test negativi: Determinare cosa succede se il tasto standby viene premuto mentre il videoregistratore sta riproducendo un nastro Determinare cosa succede se il videoregistratore è acceso e viene premuto il tasto play senza una videocassetta caricata nell unità Standby Standby Premuto / luce verde Acceso Play[ Videocassetta Caricata ] In Riproduzione Standby Premuto / luce rossa Stop 40

41 Partizionamento per Classi di Equivalenza Il partizionamento per classi di equivalenza si basa sul fatto che gli input e gli output della AOC si possono raggruppare e suddividere in gruppi o classi, e che tutte le istanze di queste classi sono trattate allo stesso modo dal sistema/software. Si assume dunque che testare un membro di ciascuna classe equivalga a testarne tutti i membri. 41

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

43 Esempio In questa specifica si partizionano gli input in tre categorie: N. Caso Test Input Partizione Output n < val <= 80 OK n Val <= 0 Errore n Val > 80 Errore 43

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

45 Esempio 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 valori limite: N. Caso di Test Input Confine Output n Errore n Errore n OK n OK n OK n Errore 45

46 Collaudo per funzione Viene utilizzato per collaudare le funzionalità business o la business logic della AOC, 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. 46

47 Esempio di Piano di Test ID Progetto ID Test Scopo del Test <Client> Test Script Presenza di test e codifica derivata da struttura requisiti (continuation sheet) S.I.A. SITAL SPA MAKE/BUY ENHANCEMENT MAINTENANCE CASO TEST UC3 INSERIMENTO ORDINE/ORDINE CLIENTE Verificare il funzionamento UC 3 ORDINE CLIENTE FLUSSO PRINCIPALE Ambiente di Test Passi del Test Risultato Atteso Passi di test derivati da specifica requisiti Dati di collaudo derivati da analisi a classi equiv. e valor limite Risultati derivati da specifica requisiti o da analisi collaudo negativa/positiva APPLICAZIONE SIA AVVIATA. UTENTE AUTENTICATO. NESSUNA OPERAZIONE PRECEDENTE. FINESTRA INSERIMENTO ORDINE APERTA E VUOTA. FILE DI DATABASE TEST_DB CARICATO SU MACCHINA DI TEST. INSERIRE CODICE CLIENTE CONFERMARE PREMENDO TASTO SX SU PULSANTE CERCA. SELEZIONE DELLA TERZA RIGA. INSERIMENTO DEL VALORE 20/03/03 IN CAMPO DATA IMPEGNO. INSERIMENTO 400 SU QTA PREVISTA. INSERIMENTO 15/04/03 SU DATA CONSEGNA. INSERIMENTO ,00 SU PREZZO. CHECKBOX CONFERMA E AGGIORNA ATTIVE. PRESSIONE SU TASTO INSERISCI. FINESTRA CONFERMA INSERIMENTO. CAMBIAMENTO DI STATO DATABASE, TERZA RIGA PASSATA A STATO CONFERMATO. CAMBIAMENTO NEL DATABASE ERRORE PREVISIONALE DA 0,30 A 0, Page of Pages

48 Associazione tra piani di test e casi d usod Stato superiore::inserimento Chiamata Periodicità Richiesta: 999 Anni Data Chiamata: 01/01/03 Importo Finanziamento: Importo Richiesto: 9,999,999, Periodicità Finanziamento: 999 Anni Caso di test al Valore Limite Superiore Stato superiore::valutazione Pratica Accettazione Deal Structurer Stato superiore::flag Pratica Stato superiore::generazione Offerta L associazione tra piani di test e casi d uso Si utilizza per determinare i piani di test di casi d uso più importanti (utilizzando per la scelta dei test come criteri la priorità, la criticità e la frequenza di ciascun caso d uso, e inserendo questi test nel piano di test di accettazione) Si può modellare con un estensione del diagramma dei casi d uso 48

49 Flusso di lavoro di modellazione Specifica Requisiti IT Business Structure View Organigrammi User View Business Process View Process Diagrams Assembly Lines Class Diagrams Use Case Diagrams Business Modeling Business Behavior View State Diagrams Activity Diagrams Sequence Diagrams Descrizione in Linguaggio Naturale Piani di Collaudo Structural View Class Diagrams Object Diagrams State Diagrams Behavioral View Activity Diagrams Sequence Diagrams System Modeling GUI 49

50 La Specifica dei Requisiti La specifica dei requisiti è un attività che prevede il dettaglio, mediante modellazione dell effettivo funzionamento dei requisiti. Il risultato dell attività di analisi consente di specificare con dettaglio la struttura dei requisiti di un caso d uso (come nell esempio UC3 precedente) L attività di analisi consente inoltre di individuare tutte le caratteristiche delle entità presenti nel sistema IT di supporto 50

51 Modellazione Statica delle Entità (Class Diagram) L individuazione delle entità/classi presenti nel sistema parte da alcune linee guida di base: Si considerano le entità candidate evidenziate dall analisi AL Ogni classe deve avere una chiara finalità nel sistema Ogni classe descrive uno stampo per un insieme di oggetti Ogni classe deve essere specificata tramite un insieme di attributi. Determinare tra questi l attributo di identificazione univoca (chiave). Alcuni attributi complessi potrebbero diventare essi stessi Classi. Ogni classe comprende un insieme di operazioni. Le operazioni costituiscono l interfaccia della classe e sono espresse sotto forma di segnature (parametri in ingresso e parametri in uscita). 51