Business Analysis II Analisi Tecnica Prof. Thimoty Barbieri Università degli Studi di Pavia
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Business Analysis II Analisi Tecnica Prof. Thimoty Barbieri Università degli Studi di Pavia
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 Business Analysis II 2 Thimoty Barbieri
Laboratorio di analisi delle informazioni e dei processi produttivi e logistici Thimoty Barbieri Indirizzo Logistico Produttivo Analisi e Specifica dei Requisiti IT
Flusso di lavoro di modellazione – Raccolta Requisiti IT Business Modeling Business Process View Business Structure View Process Class Business Behavior View Diagrams Diagrams State Activity Sequence Organigrammi Diagrams Diagrams Diagrams Assembly Lines Descrizione in Linguaggio Naturale User View Use Case Diagrams Piani di Collaudo System Modeling Structural View Behavioral View Class Object State Activity Sequence Diagrams Diagrams Diagrams Diagrams GUI Diagrams Business Analysis II 4 Thimoty Barbieri
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 Business Analysis II 5 Thimoty Barbieri
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 Business Analysis II 6 Thimoty Barbieri
Assembly Line con Entità Candidate Identificazione fabbisogni di produzione per i codici gestiti a scorta Fabbisogni Produzione Fabbisogni Reparti [codice in make] Lordi in Pezzi Calcolo Capacità Necessaria Make Make Identificazione Previsioni Identificazione tipologia Identificazione Impegni codice e Prenotazioni [codice in buy] Calcolo Capacità Necessaria Buy Fabbisogni Produzione Entità Reparti Buy Candidata Carica Previsioni Conferma Quote Ordinate Calcolo Capacità Necessaria Make Calcolo Capacità Necessaria Buy Imposta Previsioni Calcola Fabbisogni Lordi Casi d’uso Candidati PREV (Previsioni Commerciale) PC (Previsioni Cliente) P (Prenotazioni) I (Impegni) Lettura AA (Anagrafica Articoli) DISTINTA (Distinta Base) CICLI (Cicli Produzione) Scrittura FABB (Fabbisogni) Business Analysis II 7 Thimoty Barbieri
Tabelle CRUD di rapporto attività/entità Identificazione Identificazione Identificazione Calcolo Calcolo Previsioni Tipologia Impegni e Capacità Capacità Codice Previsioni Necessaria Necessaria Buy Make PREV CRU PC R P R AA R R R I CR DISTINTA R R CICLI R R FABB C RU RU Business Analysis II 8 Thimoty Barbieri
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 Business Analysis II 9 Thimoty Barbieri
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) Business Analysis II 10 Thimoty Barbieri
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. Business Analysis II 11 Thimoty Barbieri
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 Business Analysis II 12 Thimoty Barbieri
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 Business Analysis II 13 Thimoty Barbieri
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) Business Analysis II 14 Thimoty Barbieri
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) Business Analysis II 15 Thimoty Barbieri
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. Business Analysis II 16 Thimoty Barbieri
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. Business Analysis II 17 Thimoty Barbieri
Diagrammi dei Casi d’Uso 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) Business Analysis II 18 Thimoty Barbieri
Modellazione Casi d’Uso 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 Business Analysis II 19 Thimoty Barbieri
Ricerca dei Casi d’uso 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? Business Analysis II 20 Thimoty Barbieri
Disegno del Diagramma Use Case Lo stickman rappresenta lo stereotipo . 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 Business Analysis II 21 Thimoty Barbieri
Esempio di Diagramma Calcolo Capacità Lordi Calcolo Capacità Necessaria Buy Conferma Quote Ordinate Commerciale Direttore Produzione Carica Previsioni Imposta Previsioni Business Analysis II 22 Thimoty Barbieri
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 : 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 : 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 : specifica che un caso d’uso utilizza in parte o in tutto un altro caso d’uso per il suo completamento Business Analysis II 23 Thimoty Barbieri
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. Business Analysis II 24 Thimoty Barbieri
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. Business Analysis II 25 Thimoty Barbieri
Diagramma di Cli ente Venditore Direttore attività Inseriment o Ordine Verifica Ordine [ > 5000 Euro ] [
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 Business Analysis II 27 Thimoty Barbieri
Schema Documentale Completo di Specifica di Caso d’Uso 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) Business Analysis II 28 Thimoty Barbieri
Esempio di Specifica Caso d’Uso 1.1.1 [CU3]: Identificazione dei fabbisogni per codici a scorta :: Conferma Quote Ordinate 1.1.1.3.2 Flussi Alternativi 1.1.1.1 Attori Commerciale [CU3.10] Il commerciale decide di non inserire l’impegno perché l’ordine è sensibilmente difforme alla previsione venditore. 1.1.1.2 Breve Descrizione [CU3.11] Il commerciale decide di non inserire l’impegno perché l’ordine è sensibilmente difforme alla previsione cliente. Questa funzione consente di visualizzare per cliente e articolo le previsioni di ordinativo, [CU3.12] Il commerciale decide di non inserire l’ordine perché il inserire un ordinativo effettivo e confrontare la previsione con l’ordine effettivo. prezzo concordato è sensibilmente difforme al prezzo standard. 1.1.1.3 Flusso di Eventi 1.1.1.4 Pre Condizioni 1.1.1.3.1 Flusso Base Al commerciale perviene un ordine da trasformare in impegno. [CU3.1] Il commerciale riceve da un cliente una conferma d’ordine o un ordine. 1.1.1.5 Post Condizioni [CU3.2] Il commerciale apre la finestra di Conferma ordinativo per un dato cliente. E’ stato inserito un impegno a fronte dell’ordinativo, oppure non si è in [CU3.3] Il commerciale carica le previsioni effettuate da se stesso per un alcun modo modificata la situazione precedente. determinato articolo e periodo temporale [CU3.4] Il sistema evidenza se l’articolo viene prodotto in make oppure in buy 1.1.1.6 Eccezioni [CU3.5] Il sistema evidenza il prezzo standard dell’articolo e il tempo medio di Dati inseriti non validi realizzazione. [CU3.6] Se presenti, il commerciale carica le previsioni effettuate ed inviate dal 1.1.1.7 Frequenza Stimata di Utilizzo (bassa, media, alta) cliente, per un determinato articolo e periodo temporale ALTA [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 1.1.1.8 Criticità (bassa, media, alta) conferma e trasformare la previsione in un impegno. ALTA [CU3.9] Se i dati non sono corrispondenti a una previsione, si inseriscono tutti i dati necessari e si crea un impegno. Business Analysis II 29 Thimoty Barbieri
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 Business Analysis II 30 Thimoty Barbieri
Tipologie di Collaudo Le fasi di collaudo corrispondono alle principali fasi dell’ideale modello a cascata di sviluppo del software. Regression Test Business Analysis II 31 Thimoty Barbieri
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. Business Analysis II 32 Thimoty Barbieri
Tipologie di Collaudo (3) 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. Business Analysis II 33 Thimoty Barbieri
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. Business Analysis II 34 Thimoty Barbieri
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 Business Analysis II 35 Thimoty Barbieri
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à Business Analysis II 36 Thimoty Barbieri
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. Business Analysis II 37 Thimoty Barbieri
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. Business Analysis II 38 Thimoty Barbieri
Esempio Specifica dei requisiti: Videoregistratore. 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. Business Analysis II 39 Thimoty Barbieri
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 Standby acceso, la pressione del tasto standby causa il passaggio allo stato di standby e l’indicatore luminoso passa da verde a rosso Standby Premuto / luce rossa Standby Premuto / luce verde Casi di test negativi: – Determinare cosa succede se il tasto standby viene Acceso premuto mentre il videoregistratore sta riproducendo un nastro Play[ Videocassetta Caricata ] Stop – Determinare cosa succede se il videoregistratore è acceso e viene premuto il tasto play senza una In Riproduzione videocassetta caricata nell’unità Business Analysis II 40 Thimoty Barbieri
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. Business Analysis II 41 Thimoty Barbieri
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 Business Analysis II 42 Thimoty Barbieri
Esempio In questa specifica si partizionano gli input in tre categorie: N. Caso Test Input Partizione Output n. 1 50 0< val
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”. Business Analysis II 44 Thimoty Barbieri
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 Input Confine Output Test n. 4 -1 0 Errore n. 5 0 0 Errore n. 6 1 0 OK n. 7 79 80 OK n. 8 80 80 OK n. 9 81 80 Errore Business Analysis II 45 Thimoty Barbieri
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. Business Analysis II 46 Thimoty Barbieri
Esempio di Piano di Test Test Script (continuation sheet) ID Progetto S.I.A. SITAL SPA – MAKE/BUY ENHANCEMENT MAINTENANCE ID Test Presenza di test CASO TEST UC3 – INSERIMENTO ORDINE/ORDINE CLIENTE e codifica derivata da struttura Scopo del Test Verificare il funzionamento UC 3 ORDINE CLIENTE FLUSSO requisiti PRINCIPALE Ambiente di Test Passi di test APPLICAZIONE SIA AVVIATA. UTENTE AUTENTICATO. derivati da NESSUNA OPERAZIONE PRECEDENTE. FINESTRA specifica requisiti INSERIMENTO ORDINE APERTA E VUOTA. FILE DI DATABASE TEST_DB CARICATO SU MACCHINA DI TEST. Passi del Test INSERIRE CODICE CLIENTE 005200. CONFERMARE Dati di collaudo PREMENDO TASTO SX SU PULSANTE CERCA. SELEZIONE derivati da analisi DELLA TERZA RIGA. INSERIMENTO DEL VALORE 20/03/03 IN a classi equiv. CAMPO DATA IMPEGNO. INSERIMENTO 400 SU QTA e valor limite PREVISTA. INSERIMENTO 15/04/03 SU DATA CONSEGNA. INSERIMENTO 12.350,00 SU PREZZO. CHECKBOX CONFERMA E AGGIORNA ATTIVE. PRESSIONE SU TASTO INSERISCI. Risultato Atteso Risultati derivati FINESTRA CONFERMA INSERIMENTO. CAMBIAMENTO DI da specifica STATO DATABASE, TERZA RIGA PASSATA A STATO CONFERMATO. CAMBIAMENTO NEL DATABASE ERRORE requisiti o da analisi PREVISIONALE DA 0,30 A 0,25. collaudo negativa/positiva Page of Pages Business Analysis II 47 Thimoty Barbieri
Associazione tra piani di test e casi d’uso Caso di test al Valore Limite Superiore Periodicità Richiesta: 999 Stato superiore::Inserimento Anni Data Chiamata: 01/01/03 Chiamata Importo Finanziamento: Importo Richiesto: 9,999,999,999 € 9.999.999.999.999 € Periodicità Finanziamento: 999 Anni Stato superiore::Valutazione Pratica Accettazione L’associazione tra piani di test e casi d’uso Stato superiore::Flag Pratica – Si utilizza per determinare i piani di test di casi d’uso più importanti (utilizzando per la scelta Deal Structurer Stato superiore::Generazione Offerta 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 Business Analysis II 48 Thimoty Barbieri
Flusso di lavoro di modellazione – Specifica Requisiti IT Business Modeling Business Process View Business Structure View Process Class Business Behavior View Diagrams Diagrams State Activity Sequence Organigrammi Diagrams Diagrams Diagrams Assembly Lines Descrizione in Linguaggio Naturale User View Use Case Diagrams Piani di Collaudo System Modeling Structural View Behavioral View Class Object State Activity Sequence Diagrams Diagrams Diagrams Diagrams GUI Diagrams Business Analysis II 49 Thimoty Barbieri
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 Business Analysis II 50 Thimoty Barbieri
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). Business Analysis II 51 Thimoty Barbieri
Class Diagram Ordine Cliente Data : Date (from Use Case View) Numero : int Nome : String CodiceCliente : String +intestatario Cognome : String Reparto : int Indirizzo : String Approvato : boolean 0..* testata 1 BancaAppoggio : String Citta : String calcolaTotale() CAP : int approva() 1 1..* RigaOrdine Prodotto Numero : int Codice : int Sconto : float Descrizione : String Quantità : int 0..* 1 Attivo : boolean Business Analysis II 52 Thimoty Barbieri
Associazioni tra Classi La ricerca delle associazioni è effetto dell’avvenuto censimento delle classi. In questa fase si individuano gli attributi di classe e si decide quali attributi non siano sufficientemente elementari, e quindi costituiscano classi a sé, associate (o aggregate) con la classe di provenienza. Ulteriori associazioni si trovano immaginando di “eseguire” i casi d’uso trovati: si stabiliscono infatti dei “canali di collaborazione” tra classe, che si realizzano solitamente mediante associazione o mediante una relazione di dipendenza (linea tratteggiata) Business Analysis II 53 Thimoty Barbieri
Specifica delle Associazioni Specificare un’associazione implica – Assegnarle un nome – Assegnare i nomi dei ruoli: sono usati per chiarire meglio associazioni complesse, in particolare quelle ricorsive. Per sceglierne i nomi ricordare che essi diventano il nome dell’attributo nella classe posta al capo opposto della linea che rappresenta l’associazione. – Determinarne la molteplicità: vanno specificate per entrambi i terminali (ruoli) dell’associazione. Se non evidenti, possono essere omesse. – L’aggregazione è trattata come un forma di associazione (nel caso in cui l’associazioni implichi un concetto del tipo possiede in modo esclusivo, possiede, ha, raggruppa) Business Analysis II 54 Thimoty Barbieri
Generalizzazioni tra Classi Le caratteristiche (attributi e operazioni) di una o più classi possono essere astratte in una classe più generica (generalizzazione). La relazione di generalizzazione è una connessione tra una classe generica (superclasse) e classi più specifiche (sottoclassi). La generalizzazione permette l’ereditarietà (riuso) delle caratteristiche nella superclasse da parte delle sottoclassi. Oltre all’ereditarietà, la generalizzazione ha anche due altri obiettivi: – Sostituibilità: l’oggetto di una sottoclasse è un valore ammesso per una variabile sulla superclasse (ma non viceversa): ad esempio una variabile Frutto accoglie come valore una istanza di Mela. – Polimorfismo/Binding Dinamico: la stessa operazione ha implementazioni differenti in classi distinte. Si usa spesso definendo operazioni astratte sulle superclasse, per costringere le sottoclassi a fornire diverse implementazioni operative. Business Analysis II 55 Thimoty Barbieri
Esempio Ordine Cliente idOrdine PortafoglioOrdini pIva dataOrdine ragioneSociale dataScadenza 1..* 1 aggiungiProdotto() 0 +rigaProdotto 1..* Prodot to gestisce Magazzino 1..* 1 riordina() ProdottoPull ProdottoPush riordina() riordina() Business Analysis II 56 Thimoty Barbieri
Esempio Fabb -codArticolo -dataFabbisogno -qtaFabbisogno -lordaOrNetta +calcolaFabbisognoArticolo() * +calcolaFabbisognoLordoArticolo() Distinta * * -codArticolo * -codComponente AA -ncomp * Prev -codArticolo Cliente 1 * -codCliente -erroreMedioPrevisionale * -codCliente -codArticolo -codDistinta -ragioneSociale -qtaPrev -codCiclo -tipoPagamento +inserisciPrevisione() 1 -makeOrBuy : bool * -tipoArticolo +prelevaPrevisione() -tempoConsegnaDaBuy Cicli -prezzoStd * -codMacchina -tempoMedioProd -codPasso 1 -codPassoSucc Pc -codPassoPrec -dataConsegna -dataArrivoOrdine +confermaPrevisione() +prelevaPrevisioneCliente() un impegno e' una previsione cliente confermata, pertanto in fase di analisi statica la rappresento come una Cicli Make Cicli Buy PC generalizzata -repartoEsterno I -numImpegno -prezzo -dataConfermaImpegno +inserisciImpegno() Business Analysis II 57 Thimoty Barbieri
Analisi Dinamica dei Casi d’Uso nella Specifica dei Requisiti L’analisi dinamica per la specifica dei requisiti richiede l’utilizzo di diagrammi di interazione: collaboration diagram e sequence diagram. I diagrammi di sequenza mostrano lo scambio di messaggi tra oggetti, organizzato in una sequenza temporale. I diagrammi di collaborazione enfatizzano le relazioni tra oggetti lungo cui i messaggi sono scambiati. Poiché i modelli di interazione fanno riferimento ad oggetti, richiedono che sia stata completata almeno la prima iterazione nella modellazione statica. I modelli di iterazione non specificano esplicitamente il cambiamento di stato degli oggetti (questo è modellato utilizzando i diagrammi di stato) Business Analysis II 58 Thimoty Barbieri
Diagrammi di Sequenza La ricerca delle sequenze dei messaggi segue i modelli delle attività. Le attività di un diagramma sono associate a messaggi in un diagramma di sequenza. Se i livello di astrazione usati tra activity diagram e sequence diagram sono simili, questa corrispondenza risulta più semplice per l’analista. Specificando i messaggi, si può distinguere tra segnali e chiamate. Un segnale denota una comunicazione asincrona tra oggetti: il mittente può continuare la propria esecuzione non appena inviato il segnale. Una chiamata indica un’invocazione sincrona di un’operazione appartenente alla classe ricevente la chiamata. Il messaggio di ritorno può contenere alcuni valori destinati al chiamante, o semplicemente notificare l’avvenuta invocazione dell’operazione. L’analisi della sequenza porta alla scoperta di nuove operazioni nelle classi individuate Business Analysis II 59 Thimoty Barbieri
Diagrammi di Sequenza : Ordine : RigaOrdine : Prodott o : : Cliente BollaSpedizione Inseriment o Creazione Nuova Riga Scelta Prodotto Scelta Modalità Spedizione Convalida Riga in Ordine Conferma Inserimento Ordine calcolaTotale( ) Business Analysis II 60 Thimoty Barbieri
Diagrammi di Sequenza Prev Pc I FinestraCommerciale apriFinestraImpegno() prelevaPrevisione() visualizzaPrevisione() prelevaPrevisioneCliente() visualizzaPrevisioneCliente() inserisciConferma() confermaPrevisione() Business Analysis II 61 Thimoty Barbieri
Specifiche del Cambiamento di Stato Lo stato di un oggetto in un certo istante di tempo è determinato dai valori dei suoi attributi, inclusi gli attributi di relazione. Mentre le specifiche dello stato definiscono gli attributi di una classe, le specifiche del comportamento definiscono le operazioni di una classe, alcune delle quali possono avere come effetto un cambiamento di stato. Un diagramma a stati fornisce l’elenco degli stati possibili di un oggetto e delle transizioni (legate ad operazioni) che causano il passaggio da uno stato all’altro Il processo di ricerca degli stati di un oggetto è basato sull’analisi degli attributi contenuti in una classe, e determinando quali attributi sono chiamati in causa dai casi d’uso L’analisi a stati può generare nuovi attributi con cui arricchire l’analisi statica Business Analysis II 62 Thimoty Barbieri
Forma Generale di uno Stato Business Analysis II 63 Thimoty Barbieri
Diagramma Ordine non Inserito di stato Richiesta Inserimento Ordine Vuoto Inserimento Dati[ Cliente in Archivio ] Ordine con Testata Annullamento Inserimento Riga Riga Annullata[ Righe < 1 ] Inserimento Riga Inizio Riga Prodotto Selezionato Quantità Selezionata Ordine Abortito Consegna Selezionata Riga Completata Inseriment o Riga Riga Confermata Ordine con Riga Annullata[ Righe > 1 ] Annullamento Riga Salvataggio Ordine Salvato Approvazione / Not ific a Responsabile Ordine Approvato Ordine inserito Business Analysis II 64 Thimoty Barbieri
Progettazione della Base Dati Praticamente la totalità dei S.I. si fonda su un database relazionale (RDBMS). L’analisi statica è il punto di partenza per individuare quali entità devono essere “persistite”, in altre parole occorre tenerne una memorizzazione persistente su un sistema di archiviazione e ripristino del dato (il database). Altre entità invece sono funzionali solo all’esecuzione runtime del sistema. Le entità con “persistenza” devono essere organizzate in tabelle (entità e relazioni) all’interno di uno schema di database. Solitamente lo schema strutturale della base dati prende la forma di un diagramma E/R (entità e relazioni), da cui si deriva un tracciato logico ed uno fisico. Il tracciato fisico viene direttamente utilizzato per la creazione della struttura delle tabelle presenti nel database. La realizzazione di questi tracciati è solitamente affidata ad esperti progettisti di basi dati. L’analisi statica del class diagram è un prezioso punto di partenza. Business Analysis II 65 Thimoty Barbieri
Progettazione dell’Interfaccia Grafica (GUI) Il progetto dell’interfaccia grafica tra utente e sistema (GUI) nasce con la specifica dei requisiti. Il disegno della GUI consente di chiarificarsi anche la sequenza dei requisiti nei vari casi d’uso. Requisiti e disegno della GUI si arricchiscono iterativamente. Nel progettare l’interfaccia si parte sempre dal principio che l’utente ha il controllo non deve mai avere l’impressione di perderlo. L’interazione con la GUI è sempre event-driven, si generano e si raccolgono eventi a cui utente e oggetti reagiscono. La GUI contribuisce alla prima impressione che ha l’utente del software, pertanto deve essere gradevole da vedere, ordinata, coerente. Business Analysis II 66 Thimoty Barbieri
Linee guida per il disegno di GUI L’utente ha il controllo – Il programma non deve dare l’impressione di eseguire operazioni “senza motivo” o fuori dal controllo dell’utente – Nei momenti di attesa deve essere fornito all’utente un modo per valutare cosa sta facendo il sistema (clessidra, barra di progresso…) – Deve essere dato un feedback ad ogni azione dell’utente – Deve essere dato un feedback ad ogni evento scatenato internamente dal programma che debba essere notato dall’utente Business Analysis II 67 Thimoty Barbieri
Linee guida per il disegno di GUI Consistenza – Indica l’aderenza ad uno standard ed al moto consueto “di fare le cose”. Ci sono due dimensioni di consistenza: • Conformità agli standard tecnologici della piattaforma adottata (Windows 2000/XP, XWindow, MacOS X Aqua) • Conformità di nomenclatura, codifica, e altre consuetudini sviluppate internamente all’organizzazione che utilizza il sistema (standard interni) – Adeguarsi agli standard è importantissimo per evitare di confondere inutilmente gli utenti (che a priori sono già contrari a qualsiasi innovazione costituita dall’ingresso in esercizio di un nuovo sistema informatico) Business Analysis II 68 Thimoty Barbieri
Linee guida per il disegno di GUI Personalizzazione e Configurazione – La Gui deve consentire personalizzazione: cioè variazioni atte a rendere più comodo l’utilizzo personale dell’utente, ad es. ridimensionare colonne e finestre, cambiare i colori, ecc. – Il sistema deve consentire la configurazione, in altre parole offrire modi diversi di operare a seconda della tipologia di utente (ad es. diversa complessità di finestre, localizzazione della lingua, attivazione o disattivazione di messaggi di aiuto più o meno dettagliati/invadenti) Business Analysis II 69 Thimoty Barbieri
Linee guida per il disegno di GUI Tolleranza e Guida – Una buona interfaccia tollera che gli utenti provino, commettano errori, prendano strade errate, e se necessario consentono di tornare indietro di uno o più passi, o al punto iniziale. Le Gui tolleranti mettono a disposizione operazioni di annullamento, di modifica e di ripristino a più livelli. – Le operazioni di inserimento possono essere assistite (autocompletamento) e i dati verificati (ad es. la / delle date viene inserita automaticamente, date errate sono rifiutate dal sistema) Business Analysis II 70 Thimoty Barbieri
Linee guida per il disegno di GUI Retroazione – Quando il controllo è temporaneamente in mano al programma l’utente deve sapere cosa sta accadendo: il sistema fornisce sempre informazioni audio/visive sul proprio stato di esecuzione: – Cursore con clessidra, messaggi di attesa, barre di avanzamento, etc. Business Analysis II 71 Thimoty Barbieri
Linee guida per il disegno di GUI Estetica e usabilità – Occorre tenere presente l’estetica e l’ordine della GUI • I campi devono essere disposti ben in colonna • I pulsanti raggruppati in buon ordine • Le etichette e i testi devono essere scritti correttamente e in buona lingua • Devono essere forniti suggerimenti interattivi (tool tip) • In generale la semplicità nella costruzione è la migliore garanzia di estetica ed usabilità in una interfaccia GUI Business Analysis II 72 Thimoty Barbieri
Componenti Base della GUI La form è l’unità base di progettazione della GUI: la raccolta di eventi e di dati avviene mediante una finestra. Dedicare una Form per ogni funzionalità generale base del sistema. Decidere Se possibile Decidere Immettere il titolo qui AB chiudere, Titolo C minimizzare… Form Considerare Pulsanti Strumenti Per Prevedere Operazioni Più Spazio Per Frequenti Input e Output Fornire Dati, Controllo Feedback operazioni Con Cursore Comunicare Campo stato Stato Finestra con Barra di Stato Business Analysis II 73 Thimoty Barbieri
Componenti Base della GUI z Il menu a tendina è uno dei modi più usati per raccogliere funzionalità principali in più categorie. z Solitamente si usa solamente nella form principale di ingresso generale a tutte le funzionalità. z Di solito per una voce di menu si apre una relativa form di funzione. Nome menu Nome menu Nome menu Nome menu Voce di menu Voce di menu Voce di menu Voce di menu Voce di menu Voce di menu z I pulsanti servono a eseguire una singola azione. Annulla Esegui Business Analysis II 74 Thimoty Barbieri
Componenti Base della GUI Le form contengono vari elementi base per la raccolta degli input: dati oppure particolari varianti di azioni che devono essere eseguite. Label: testo fisso di richiesta Immettere il titolo qui TextField: per l’immissione di testo/dati, Label sempre accoppiato ad una label Slider: per l’immissione approssimata di valori numerici Immettere il testo Checkbox: gruppi di Opzione1 Spunta1 Spunta1 azioni non esclusive tra Opzione2 Spunta1 loro Opzione3 Ghosting: indica che l’opzione/funzione Campo stato temporaneamente non è accessibile a Radiobox: gruppi di Raggruppamento causa dello stato o degli input correnti opzioni mutuamente Di opzioni esclusive Business Analysis II 75 Thimoty Barbieri
Componenti Base della GUI Testi complessi sono visualizzabili in aree di maggiori dimensioni Vanno sempre corredate dalla possibilità di scorrere il testo, aumentare/diminuire l’area visualizzata Immettere il titolo qui Scrollbars, possono essere messe in orizzontale oppure verticale. Sono legate sempre ad un’area con contenuto. Campo stato Business Analysis II 76 Thimoty Barbieri
Componenti Base della GUI In alcuni casi è preferibile non consentire all’utente di digitare valori liberi, ma di scegliere tra valori pre-esistenti o predefiniti. Immettere il titolo qui Lista: consente la selezione multipla di più valori (tasto ctrl o shift) ComboBox a discesa: la parte superiore è un campo editabile, ma si può scegliere tra una lista Campo stato Business Analysis II 77 Thimoty Barbieri
Componenti Base della GUI z Per mantenere semplice una form (con un numero contenuto di elementi) si può dividere la finestra in sotto schede attivabili mediante la “linguetta” o “tab sheet” Immettere il titolo qui Selezionare e digitare Selezionare eFiglio digitare Selezionare e digitare Ciascun tab corrisponde Ad una form sottostante diversa Campo stato Business Analysis II 78 Thimoty Barbieri
Tipologie di Finestre Finestra visualiz- zazione dati tabellare (righe e colonne) Business Analysis II 79 Thimoty Barbieri
Tipologie di Finestre Finestre master/detail (la selezione sul dato nel comparti-mento superiore fa da filtro per i dati nei compartimenti inferiori) Business Analysis II 80 Thimoty Barbieri
Tipologie di Finestre Finestra struttura albero/dato Business Analysis II 81 Thimoty Barbieri
Tipologie di Finestre Finestra inserimento dati guidato, con validazioni Business Analysis II 82 Thimoty Barbieri
Tipologie di Finestre Inserimento dati guidato con uso di combo box Business Analysis II 83 Thimoty Barbieri
Tipologie di Finestre Finestre di dialogo A uno o due pulsanti (OK / Annulla) Eventualmente con scelte ulteriori o possibilità di digitare brevi informazioni e confermare (es. Login/Password) Business Analysis II 84 Thimoty Barbieri
Tipologie di Finestre Tipologia frame principale MDI/SDI (Multiple/Single Document Interface) Business Analysis II 85 Thimoty Barbieri
Derivazione GUI da Requisiti Inserimento Conferme Ordine Ricerca Previsioni Mese Finestra Articoli Gruppo Codice 1 Articolo FG3400 Cliente CASTOR ELETTRODOMOTICA SPA Articolo in make Cerca Previsioni Tipo Previsione Data Previsione Quantità Prevista Impegnato INTERNA 05/02/03 350 CLIENTE 08/02/03 400 CLIENTE 10/03/03 400 Inserimento Impegno Data Impegno 20/03/03 Conferma Impegno da Previsione Selezionata 400 Qta Prevista Aggiorna Errore Medio Previsionale per Articolo Data Consegna 15/04/03 Prezzo 12.350,00 Inserisci Annulla [Anno Corrente: 2003] Previsioni Caricate. 1 Previsione Commerciale Presente. 1 Previsione Cliente Presente. Business Analysis II 86 Thimoty Barbieri
Puoi anche leggere