Automazione della gestione degli ordini d acquisto di una società di autonoleggio

Save this PDF as:
 WORD  PNG  TXT  JPG

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Automazione della gestione degli ordini d acquisto di una società di autonoleggio"

Transcript

1 Automazione della gestione degli ordini d acquisto di una società di autonoleggio Professore Gaetanino Paolone Studenti Paolo Del Gizzi Maurizio Di Stefano 1

2 INDICE INTRODUZIONE.pag.3 IL PIANO METODOLOGICO DI RIFERIMENTO pag.4 CAPITOLO 1 IL BUSINESS MODELLING L ATTIVITA DI BUSINESS MODELLING...pag.5 I MODELLI UTILIZZATI NEL BUSINESS MODELLING...pag.5 IL COSTRUTTO CASO D USO E GLI STEREOTIPI UTILIZZATI..pag.6 COME SI SVOLGE LA DISCIPLINA DEL BUSINESS MODELLING.pag.9 Unit Organization Diagram. pag.9 Business System Diagram...pag.10 Business Use Case Diagrams..... pag.11 Business Use Case Realization Diagrams.pag.17 Il Diagramma delle Classi pag.23 I diagrammi di stato.. pag.25 I diagrammi delle attività. pag.27 CAPITOLO 2 ANALISI E DEFINIZIONE DEI REQUISITI DAL BUSINESS MODELLING AL SYSTEM MODELLING..pag.31 APPROCCIO METODOLOGICO UTILIZZATO..pag.32 DEFINIZIONE DEGLI STEREOTIPI.pag.35 IL DOCUMENTO DEI REQUISITI pag.36 TRACE DIAGRAM:USE CASE E USE CASE REALIZATION..pag.38 TRACE DIAGRAM: ACTOR.. pag.43 2

3 INTRODUZIONE L obiettivo della tesina è l automazione della gestione degli ordini di acquisto di una società di autonoleggio. In particolare si vuole controllare i flussi delle spese di marketing, controllare il budget, controllare la gestione dei pagamenti relativi agli ordini d acquisto, verificare i codici di budget, raggruppare le spese di investimento per singolo progetto pubblicitario. Attualmente viene fatta una gestione manuale attraverso una cartella MS EXCEL contenente più file. Ad ogni file corrisponde un area di investimento (Es. Luminose, radio, televisione, altro); ogni file è suddiviso in più fogli ognuno corrispondente ad una sottocategoria (ad esempio per l area Luminose si hanno le sottocategorie Luminose Aeroportuali, Luminose Ferroviarie, Luminose su strada, ecc). Nella tesina è stato proposto il piano metodologico di riferimento dove sono state analizzate, in particolare, le discipline del Business Modelling e dell analisi e definizione dei requisiti con la conseguente stesura di tutti gli elaborati di riferimento elencati nel piano metodologico. 3

4 IL PIANO METODOLOGICO DI RIFERIMENTO Per lo sviluppo del progetto si fa riferimento al seguente piano metodologico: DISCIPLINA MODELLO ELABORATO BUSINESS MODELLING Linguaggio naturale UML Organization Unit Diagram Business System Diagram Business Use Case Diagrams Business Use Case Realization Diagrams State diagrams Class diagram Activity diagrams ANALISI E DEFINIZIONE DEI REQUISITI Linguaggio naturale UML Trace diagram: use case Trace diagram: use case realization Trace diagram: actor Documento dei requisiti Avvalersi di un piano metodologico di riferimento equivale ad avere chiare: Le discipline ovvero le attività da svolgere; I modelli da utilizzare per ogni singola attività; Gli elaborati da produrre 4

5 CAPITOLO 1 BUSINESS MODELLING 1.1 L ATTIVITA DI BUSINESS MODELLING Nel caso di automazione di un sistema o di parte del sistema il punto da cui partire è la modellazione di business. L obiettivo del Business Modelling è la realizzazione di modelli del dominio del problema che descrivono logicamente la proposta di soluzione del sistema (il cosa deve fare) che sarà successivamente dettagliata e realizzata durante la progettazione e realizzazione. In questa attività verranno prodotti degli elaborati (diagrammi statici e dinamici, rappresentati con la notazione UML) che costituiscono una rappresentazione del problema che deve essere risolto. La finalità della modellazione sono: La visualizzazione del sistema così com è; Specifica della struttura e del comportamento del sistema; Definizione delle linee guida per la costruzione di un sistema; Documentazione delle decisioni prese. 1.2 I MODELLI UTILIZZATI NEL BUSINESS MODELLING Per quanto riguarda la disciplina del Business Modelling i modelli utilizzati sono il linguaggio naturale e UML. L UML è un linguaggio per descrivere, specificare e documentare i prodotti del processo di sviluppo del software. UML consente di rappresentare e di mantenere diverse viste di uno stesso sistema descrivendo gli oggetti che lo compongono da diversi punti di 5

6 osservazione, strutturale e comportamentale e a diversi livelli di astrazione. UML è un linguaggio di progettazione e non un linguaggio di programmazione come JAVA, Visual Basic, C++.. UML, nella versione 2.0, comprende 13 diagrammi ufficiali che vengono classificati in funzione dell aspetto del sistema che si propongono di descrivere: Diagrammi strutturali, che consentono di modellare la struttura del sistema; Diagrammi comportamentali, che descrivono il comportamento assunto dal sistema. Ogni diagramma va a rappresentare una vista (parziale) del sistema. Oltre alla vista strutturale ( diagramma delle classi ) e comportamentale ( diagramma use case, diagramma delle attività ), è possibile descrivere anche come il sistema evolve nel tempo, offrendo una vista dinamica del sistema (ad es. con il diagramma di stato macchina ). 1.3 IL COSTRUTTO CASO D USO E GLI STEREOTIPI UTILIZZATI In primo luogo occorre chiarire il concetto di caso d uso. I casi d uso rappresentano la modalità di utilizzo del sistema da parte di uno o più utilizzatori (attori). Descrivono l interazione tra attori e sistema, non la logica interna della funzione e vengono espressi in forma testuale, in modo tale che siano comprensibili anche ai non addetti ai lavori. Costrutto CASO D USO; 6

7 Il caso d uso può essere utilizzato a livello di business e a livello di sistema. In ciascuno di questi due casi sarà assegnato uno stereotipo diverso in modo da poter distinguere quando il costrutto descrive l interazione con il sistema o l interazione con il software. Di seguito vengo riportati gli stereotipi utilizzati nella modellazione di business: - Stereotipo Business Use Case - Stereotipo Business Use Case Realization - Stereotipo Business Worker I Business Worker rappresentano un ruolo all interno dell organizzazione che partecipa in un processo di business e che può manipolare degli oggetti di business e interagire con altri business worker. 7

8 - Stereotipo Business Actor Il Business Actor rappresenta un ruolo esterno all organizzazione che interagisce con un processo di business. Stereotipo Organization Unit Si assegna lo stereotipo di Organization Unit a rappresentare l azienda (Enterprise) nella sua totalità. Stereotipo Business System Lo stereotipo Business System si assegna per rappresentare ciascuna delle parti (Department) che compongono l azienda. 8

9 1.4 COME SI SVOLGE LA DISCIPLINA DEL BUSINESS MODELLING È possibile riassumere l attività di modellazione in una serie di passaggi: 1) Individuazione delle Organization Unit; Unit Organization Diagram Nel nostro caso il sistema azienda è costituito dall unità organizzativa società di autonoleggio. SOCIETA DI AUTONOLEGGIO 2) Per l Organization Unit si trovano i Business System; Business System diagram L approccio più attuale per affrontare lo studio delle organizzazioni aziendali è quello di applicare a queste i concetti della teoria dei sistemi, secondo la quale, un sistema complesso, può essere suddiviso in sottosistemi che sono a loro volta dei sistemi più semplici. Nel nostro caso, l Organization Unit società di autonoleggio è stata scomposta nei 3 Business System che sono: 9

10 UFFICIO ACQUISTI; MARKETING; AMMINISTRAZIONE. I Business System in cui è stata suddivisa l azienda, nella successiva fase di modellazione, saranno sottoposti ad una specifica più approfondita: 2 livelli, quello dei Business Use Case (BUC) e quello dei Business Use Case Realization (BUCR). 3) Per ogni Business System individuo le classi di attori in gioco; Nel Business System Ufficio Acquisti sono coinvolti le seguenti classi di attori: Responsabile Ufficio Acquisti Operatore acquisti Fornitore 10

11 Nel Business System Marketing abbiamo come attore il Responsabile Marketing. Nel Business System Amministrazione abbiamo la classe d attore operatore amministrativo. Di seguito si riporta il diagramma degli attori relativo a ciascun Business System: Al fornitore è stato assegnato lo stereotipo Business Actor in quanto rappresenta un ruolo esterno all organizzazione che interagisce con l Ufficio Acquisti; gli altri attori coinvolti sono contrassegnati con lo stereotipo Business Worker in quanto rappresentano un ruolo all interno dell organizzazione e possono manipolare oggetti di business. 4) Per ogni classe di attori si individuano i Business Use Cases (BUCs) Business Use Case Diagrams Un caso d uso equivale alla descrizione di un insieme di azioni in sequenza, incluse le possibili varianti, svolte al fine di generare un risultato osservabile dal punto di vista dell utente. Quest ultimo assume il ruolo di 11

12 attore che interagisce con il sistema proprio tramite i casi d uso, con lo scopo di perseguire un obiettivo ben specifico. Il sistema azienda può essere descritto da un insieme di Business Use Cases capaci di fornire servizi agli attori interni ed esterni. Il caso d uso di Business descrive una sequenza di attività, effettuate nel Business, che producono un risultato osservabile e di valore per un attore. Di seguito si riportano i Business Use Case diagrams relativi ai 3 Business System: Per quanto riguarda l attore operatore acquisti sono stati individuati 4 business use case rilevanti per l organizzazione. Essi sono: 12

13 1) gestione archivio fornitori: l operatore acquisti può aggiungere un fornitore all archivio (caricando tutti i suoi dati: numero di telefono, ragione sociale, partita IVA, indirizzo), eliminarlo dall archivio o modificare i suoi dati. 2) gestione archivio preventivi: l operatore acquisti registra i preventivi effettuati dai vari fornitori. La registrazione di un nuovo preventivo pervenuto avviene attraverso la scelta del fornitore, la registrazione del codice identificativo del preventivo (proprio del fornitore) e la descrizione del preventivo. Allo stesso tempo può anche eliminare i preventivi dall archivio. 3) gestione archivio ordini d acquisto: l operatore acquisti crea l ordine ed inserisce l ordine creato nell archivio. Per inserire l ordine d acquisto occorre indicare: il progetto di riferimento, il numero di ordine, l area e la sottocategoria di riferimento, il fornitore scelto, le spese di investimento cui fa riferimento e l importo della specifica spesa. Deve essere possibile richiamare tutti gli ordini di acquisto per numero d ordine o per sottocategoria. Selezionato un ordine devono essere visualizzati i dettagli dell ordine e permettere di modificare, eliminare, aggiungerne eventuali altri relative a nuove spese di investimento. L emissione dell ordine avviene dopo la validazione da parte del responsabile ufficio acquisti. 4) gestione archivio fatture passive: occorre registrare le fatture passive indicando il fornitore, la data di emissione, il numero della fattura, l importo complessivo, il numero di preventivo di riferimento e altri dettagli. Le fatture passive registrate devono essere richiamate per fornitore, n preventivo e sottocategoria per vedere le fatture da pagare, pagate o in pagamento, in un intervallo di tempo. 13

14 Al fornitore, attore esterno all organizzazione, sono legati due casi d uso: emissione preventivo ed emissione fattura passiva. Il responsabile ufficio acquisti è legato a 4 casi d uso rilevanti per il sistema azienda: 1) la validazione e messa in pagamento delle fatture passive: dopo la registrazione della fattura passiva da parte dell operatore acquisti, il responsabile ufficio acquisti provvede alla validazione e messa in pagamento delle fatture passive. Il pagamento spetterà, poi, all operatore amministrativo. 14

15 2) la validazione dei preventivi 3) la validazione dell ordine: il responsabile acquisti valida l ordine dopo di che l operatore acquisti emette l ordine. 4) l operazione di riconciliazione: la riconciliazione è l operazione che permette di quadrare il budget per una sottocategoria o area rispetto alle spese effettivamente sostenute, ovvero di cui si è emesso l ordine d acquisto. Essa permette, quindi, di sapere in ogni momento il budget residuo per area e/o per sottocategoria. Al responsabile marketing sono associati 4 casi d uso rilevanti per l organizzazione: 15

16 1) definizione del piano d investimento: annualmente il responsabile marketing aveva il compito di creare nuova/e area/e di investimento; successivamente creava nuova/e sottocategoria/e associata/e a quell area/e ed infine andava a definire la spesa di investimento. Per ogni area creata vi si assegna un codice (una lettera dell alfabeto che indica l area di investimento). Per ogni sottocategoria creata vi si assegna un codice numerico di tre cifre. 2) Definizione budget annuale: il responsabile marketing assegnava un budget all area e un budget per ogni sottocategoria dell area. 3) Avanzamento: l avanzamento deve avvenire a richiesta e calcola il totale di tutte le spese di investimento degli ordini per ciascuna sottocategoria fino ad una data indicata. Effettuata l elaborazione, occorre visualizzare il budget per area e il totale speso per area. 4) Gestione archivio aree di investimento: deve essere possibile l inserimento di una nuova area e sottocategoria con i rispettivi codici per cui si intende visualizzare il budget; per ogni area si deve visualizzare il budget totale e il budget di tutte le sottocategorie dell area. Deve essere possibile visualizzare budget, budget speso e budget residuo per area e anche per singola sottocategoria. Calcolato il totale di tutte le spese di investimento degli ordini di ciascuna sottocategoria ad una certa data (avanzamento) occorre visualizzare il budget per area e il totale speso per area. 16

17 La classe operatore amministrativo è responsabile del pagamento delle fatture. 5) Per ogni Business Use Case, si vanno ad individuare da 1 n Business Use Case Realization; Business Use Case Realization Diagrams Il BUCR Diagram rappresenta le modalità secondo le quali lo USE Case viene realizzato rispetto alla classe di attori attraverso un processo di <<realize>>. Per ogni BUC sono stati individuati i BUCRs. Di seguito sono riportati i BUCR Diagram per ogni Use Case del Business System: UFFICIO ACQUISTI 17

18 Il Business Use Case Gestione archivio preventivi viene realizzato dagli Business Use Case Realization Gestione preventivi e validazione dei preventivi rispettivamente rispetto alle classi di attori operatore acquisti e responsabile ufficio acquisti, attraverso un processo di <<realize>>. 18

19 Il Business Use Case Gestione archivio ordini d acquisto viene realizzato dagli Business Use Case Realization Gestione ordini d acquisto e validazione degli ordini d acquisto rispettivamente rispetto alle classi di attori operatore acquisti e responsabile ufficio acquisti, attraverso un processo di <<realize>>. Il Business Use Case Gestione archivio fatture passive viene realizzato dagli Business Use Case Realization Gestione fatture passive, validazione e messa in pagamento delle fatture passive, pagamento delle fatture passive rispettivamente rispetto alle classi di attori operatore acquisti, responsabile ufficio acquisti e operatore amministrativo, attraverso un processo di <<realize>>. 19

20 20

21 MARKETING 21

22 22

23 AMMINISTRAZIONE IL DIAGRAMMA DELLE CLASSI Il diagramma delle classi è uno strumento fondamentale per le metodologie Object Oriented ed è utilizzato in diversi momenti del ciclo di vita di un sistema informativo per modellarne la struttura statica a diversi livelli di astrazione: per descrivere modelli concettuali nelle attività di analisi, per definire delle specifiche nel corso del progetto, per definire particolari tecniche di implementazione. I diagrammi delle classi mostrano le classi che modellano un dominio di un problema e le loro relazioni, in particolare descrive i tipi di oggetti che fanno parte di una classe. Descrive, infine, le relazioni statiche che intercorrono tra le classi (di dipendenza, associazione, generalizzazione e realizzazione), le proprietà ovvero gli attributi e le operazioni di una classe. Nel nostro caso sono state individuate 15 classi. La classe personale è legata a quella di responsabile ufficio acquisti, responsabile marketing, operatore acquisti e operatore amministrativo tramite una relazione di specializzazione. 23

24 24

25 I DIAGRAMMI DI STATO Descrivono il comportamento assunto da un singolo oggetto durante il suo ciclo di vita, cioè mostrano la macchina a stati che modella la logica di controllo di un oggetto. Un oggetto può assumere diversi stati nel contesto dei casi d uso ai quali partecipa e i suddetti diagrammi servono proprio a chiarire la logica con la quale avviene il passaggio da uno stato all altro. Gli elementi principali di questo diagramma sono tutti i possibili stati e le transizioni che indicano i possibili passaggi di stato. I diagrammi di stato offrono una vista dinamica del sistema. Di seguito sono riportati i diagrammi di stato relativi alle istanze: Preventivo 25

26 I possibili stati dell oggetto preventivo sono: non caricato, caricato e validato. Le transizioni, che determinano il passaggio da uno stato all altro, sono: preventivo creato, caricamento e validazione. Fattura passiva: I possibili stati degli oggetti della classe fattura passiva sono: non registrata, registrata, validata, in attesa di pagamento e poi pagata parzialmente o pagata a seconda che il pagamento sia parziale o totale. Le transizioni che determinano il passaggio da uno stato all altro sono: fattura creata, registrazione, validazione, messa in pagamento, pagamento parziale, pagamento totale. 26

27 Ordine d acquisto: I possibili stati dell oggetto ordine d acquisto sono: non registrato, registrato, validato, emesso. Le transizioni che determinano il passaggio da uno stato all altro sono: ordine creato, registrazione, validazione, emissione. I DIAGRAMMI DELLE ATTIVITA I diagrammi delle attività sono in grado di modellare gli aspetti dinamici di un sistema in quanto rappresentano l insieme di azioni da svolgere per ottenere un certo risultato. Tali diagrammi mostrano i flussi tra le attività, cioè fra azioni non atomiche e permettono la rappresentazione di processi paralleli e della relativa sincronizzazione. Di seguito sono riportati i diagrammi delle attività relativi: 27

28 Al sottoprocesso gestione ordini d acquisto: L operatore acquisti crea l ordine di acquisto. Si procede, poi, con la registrazione dell ordine da parte dell operatore acquisti. Se l ordine caricato viene validato dal responsabile ufficio acquisti si procede con l emissione dell ordine d acquisto da parte dell operatore acquisti. Il processo termina con la ricezione dell ordine da parte del fornitore. In caso di ordine non validato si procede con la creazione di un nuovo ordine d acquisto da parte dell operatore acquisti. 28

29 Al sottoprocesso gestione fattura passiva; Il fornitore emette ed invia la fattura passiva. L operatore la riceve e provvede alla sua registrazione. Dopo di che il responsabile ufficio acquisti provvede alla validazione e messa in pagamento della fattura. 29

30 Al Sottoprocesso gestione preventivo: L operatore acquisti emette la richiesta di preventivo; il fornitore la riceve e successivamente emette il preventivo e lo invia. L operatore acquisti lo riceve e provvede poi al caricamento. Il responsabile ufficio acquisti fa la validazione dei preventivi. In caso di non validazione il preventivo viene respinto. 30

31 CAPITOLO 2 ANALISI E DEFINIZIONE DEI REQUISITI 2.1 DAL BUSINESS MODELLING AL SYSTEM MODELLING La disciplina di analisi e definizione dei requisiti ha l obiettivo di documentare compiutamente ciò che il sistema deve fare, in modo da garantire facilità di comunicazione tra cliente e sviluppatori. Per realizzare il trasferimento dei requisiti di business a livello dei requisiti software si procede ad una duplice operazione di <<trace>> che interessa sia l aspetto comportamentale che quello strutturale, permettendo dunque che entrambi gli aspetti progrediscano parallelamente. La logica da seguire nell applicazione dell operazione di tracciatura si riassume nella scelta di quali siano le parti del business che necessitano di essere automatizzate: la prima operazione di <<trace>> interesserà esclusivamente i BUCs che devono essere automatizzati; la seconda operazione di <<trace>> in SUCRs sarà effettuata limitatamente ai BUCRs che, in qualche maniera, prendono parte all automazione del processo. Allo stesso modo vengono tracciati tutti quegli attori di business che comporteranno un corrispettivo a livello di sistema: si ottiene così un primo modello del sistema. La disciplina di analisi e definizione dei requisiti si avvale del linguaggio naturale e di UML. 31

32 2.2 L APPROCCIO METODOLOGICO UTILIZZATO Per quanto riguarda il passaggio dal Business Modeling al System Modeling esistono due differenti approcci metodologici: 1. La metodologia tradizionale, basata sul RUP, propone una soluzione di carattere iterativo e incrementale ricorrendo a un framework di tipo model driven che pone i casi d uso al centro dell attività di modellazione. La metodologia a cui ci si riferisce è costituita da 4 layers distinti ed è basata su un approccio top down di tipo iterativo e incrementale che procede per raffinamenti successivi: i primi due layers di analisi dei casi d uso riguardano più specificamente la modellazione di business ed hanno l obiettivo di fornire una rappresentazione completa e approfondita della realtà aziendale; i due layers sottostanti invece, riguardano la modellazione 32

33 di sistema, che equivale alla rappresentazione del software destinato ad automatizzare il sistema aziendale o un sottosistema. Con l applicazione di tale metodologia si ha la possiblità di descrivere entrambi gli aspetti, quello di business e quello di sistema, con ricchezza sempre maggiore di particolari e, soprattutto, viene assicurato il passaggio da un modello all altro senza perdita di informazioni. Il processo è, infatti, guidato dai casi d'uso, use case driven, che ritroviamo sia a livello di business che di sistema, seppur rappresentati con stereotipi differenti a sottolineare la diversa valenza. Con la metodologia RUP il passaggio dal modello CIM (Computetional Indipendent Model), formato dai primi due layers, al modello PIM (Platform Indipendent Model) avviene attraverso un operazione di <<trace>>. La logica da seguire è semplice: una volta individuati tutti i BUCRs (per ognuno dei BUCs) si stabilisce quali di questi andranno automatizzati. In questo modo si individuano i SUCs e, con il successivo <<realize>>, i SUCRs che completano il modello PIM. In altre parole, i passi da seguire sono i seguenti: a) Individuo i business system b) Individuo i BUCs c) Vado a realizzare ciascun BUC attraverso 1 n BUCR d) Faccio l operazione di trace per ogni BUCR definisco un SUC e per ogni SUC individuo le sue realizzazioni (SUCRs). 2. C è poi una metodologia innovativa che introduce alcune novità significative: 33

34 Anche questo approccio prevede 4 layers distinti, due per la modellazione a livello di business e due per la modellazione a livello di sistema, entrambi collegati tra loro da un operazione di <<realize>>. Quello che cambia è la relazione che intercorre tra modello di business e modello di sistema: viene introdotta, infatti, una doppia operazione di <<trace>> che dai livelli di business conduce ai due livelli di modellazione del sistema. In questo modo si possono riprodurre tutti i BUCs e i relativi BUCRs nella prospettiva di sistema, trasformandoli rispettivamente nei SUCs e nei SUCRs. L obiettivo dell operazione di <<trace>> resta quello di trasferire alla modellazione di sistema solo ciò che è destinato all automazione. Procedendo secondo questo approccio metodologico, si esegue una doppia operazione di <<trace>> con la quale i BUCs vengono tracciati nella prospettiva di sistema divenendo SUCs (terzo layer) e, parallelamente, i BUCRs vengono tracciati divenendo SUCRs (quarto layer). 34

35 Con questa metodologia prendo i BUC e uno a uno li trasformo in SUC; poi prendo i BUCR e uno a uno li trasformo in SUCRs. Con questo approccio, si va ad eliminare qualsiasi forma di aleatorietà, che, invece, poteva sorgere utilizzando la metodologia RUP. Per il nostro progetto faremo riferimento alla seconda proposta metodologica. OSS. Nell operazione di trace devo dire quali sono gli elementi del Business Modeling interessati all automazione prendo solo i BUC interessati all automazione e li traccio. I BUC non interessati dall automazione non vanno tracciati. Grazie al doppio trace definisco un modello PIM perfettamente aderente al CIM. 2.3 DEFINIZIONE DEGLI STEREOTIPI Stereotipo System Use Case; Stereotipo System Use Case Realization; Stereotipo System Actor; 35

36 2.4 IL DOCUMENTO DEI REQUISITI L input per la realizzazione del documento dei requisiti sono tutti gli elaborati prodotti nella attività di Business Modeling. Tale documento conterrà l insieme dei requisiti finalizzati ad individuare le parti del sistema da automatizzare. La raccolta dei requisiti è stata fatta tramite colloqui formali e documenti scritti. Di seguito sono riportati i requisiti principali prima a livello di sistema globale (a livello di unit Organization) e, successivamente, a livello di singolo sottosistema (Business System). Requisiti a livello di unit Organization Il sistema deve automatizzare la gestione degli ordini di acquisto della società di autonoleggio; bisogna controllare i flussi delle spese di 36

37 marketing; bisogna controllare il budget; verificare i codici di budget; controllare la gestione dei pagamenti relativi agli ordini di acquisto; raggruppare le spese di investimento per singolo progetto pubblicitario. Requisiti a livello dei singoli Business System: a) Ufficio acquisti: 1) L operatore acquisti crea l ordine e lo inserisce nell archivio indicando il progetto di riferimento, il numero di ordine, la sottocategoria di riferimento, l importo complessivo previsto, il fornitore scelto. 2) L operatore acquisti deve poter richiamare tutti gli ordini d acquisto per numero d ordine o per sottocategoria. 3) L operatore acquisti deve poter richiamare una fattura passiva già registrata per fornitore, n preventivo e sottocategoria. L operatore acquisti registra tutte le fatture emesse a fronte di un ordine ognuna nella pagina della sottocategoria di riferimento, indicando il fornitore, la data di emissione, il numero, l importo complessivo, il n di preventivo di riferimento e altri dettagli eventualmente. 4) L operatore acquisti carica i preventivi nell archivio indicando la descrizione del progetto di riferimento, i dettagli del fornitore e il codice identificativo del preventivo (proprio del fornitore). 5) Il responsabile acquisti chiede la riconciliazione: l operazione che permette di quadrare il budget per una sottocategoria o area rispetto alle spese effettivamente sostenute, ovvero di cui si è emesso l ordine di acquisto. Essa permette, quindi, di sapere, in ogni momento il budget residuo per area e/o per sottocategoria. b) Marketing: 1) Il responsabile marketing definisce annualmente il piano di investimento, ovvero crea nuove aree di investimento, crea nuove sottocategorie e definisce le spese di investimento. 37

38 2)Il responsabile marketing deve definire un budget annuale per ciascuna area e per ciascuna sottocategoria dell area. 3)Il responsabile marketing effettua l avanzamento, cioè calcola il totale di tutte le spese di investimento degli ordini per ciascuna sottocategoria fino ad una data indicata. 4)Deve essere possibile visualizzare il budget totale per area e per sottocategoria, calcolare e visualizzare il budget residuo per area e per sottocategoria e il budget speso. c) Amministrazione: 1) L operatore amministrativo paga le fatture passive, totalmente o parzialmente. 2.5 TRACE DIAGRAM: USE CASE E USE CASE REALIZATION Il passaggio dal Business Modelling al System Modelling è stato svolto con una doppia operazione di trace coerentemente con quanto introdotto dalla proposta metodologica utilizzata. Con questo nuovo approccio è possibile raggruppare assieme in un unico diagramma dei casi d uso le varie attività di <<realize>> e <<trace>> in modo da avere così una visione globale di come le modalità operative aziendali sono portate avanti e come esse devono essere automatizzate. L operazione di trace degli BUCs in SUCs e degli BUCRs in SUCRs viene realizzato nello stesso istante. Nel processo di trace vanno considerati solo i BUCs ed i relativi BUCRs interessati all automazione. Nel nostro caso i BUCs da automatizzare e che, quindi, verranno tracciati per diventare SUCs, sono Gestione archivio ordini d acquisto, gestione 38

39 archivio fatture passive, riconciliazione, gestione archivio aree di investimento, avanzamento. La prima operazione di <<trace>> interessa il BUC Gestione archivio ordini d acquisto ; la seconda operazione di <<trace>> interessa il BUCR Gestione ordini d acquisto che prende parte all automazione del processo. 39

40 La prima operazione di <<trace>> interessa il BUC Gestione archivio fatture passive ; la seconda operazione di <<trace>> interessa il BUCR Gestione fatture passive che prende parte all automazione del processo. 40

41 La prima operazione di <<trace>> interessa il BUC Riconciliazione ; la seconda operazione di <<trace>> interessa il BUCR Riconciliazione che prende parte all automazione del processo. La prima operazione di <<trace>> interessa il BUC Gestione archivio aree di investimento ; la seconda operazione di <<trace>> interessa il BUCR Gestione aree di investimento che prende parte all automazione del processo. 41

42 La prima operazione di <<trace>> interessa il BUC Avanzamento ; la seconda operazione di <<trace>> interessa il BUCR Avanzamento che prende parte all automazione del processo. 42

43 2.6 TRACE DIAGRAM: ACTOR Vengono, infine, tracciati tutti quegli attori di business che comporteranno un corrispettivo a livello di sistema 43

Modellazione di sistema

Modellazione di sistema Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Modellazione di sistema E. TINELLI Contenuti Approcci di analisi Linguaggi di specifica Modelli di

Dettagli

UniRoma2 - Ingegneria del Software 1 1

UniRoma2 - Ingegneria del Software 1 1 Object Oriented Analysis - OOA La fase di OOA definisce, secondo un approccio ad oggetti, COSA un prodotto software deve fare (mentre la fase di OOD definisce, sempre secondo un approccio ad oggetti, COME

Dettagli

Rational Unified Process Introduzione

Rational Unified Process Introduzione Rational Unified Process Introduzione G.Raiss - A.Apolloni - 4 maggio 2001 1 Cosa è E un processo di sviluppo definito da Booch, Rumbaugh, Jacobson (autori dell Unified Modeling Language). Il RUP è un

Dettagli

UML e (R)UP (an overview)

UML e (R)UP (an overview) Lo sviluppo di sistemi OO UML e (R)UP (an overview) http://www.rational.com http://www.omg.org 1 Riassumento UML E un insieme di notazioni diagrammatiche che, utilizzate congiuntamente, consentono di descrivere/modellare

Dettagli

Ingegneria del Software UML - Unified Modeling Language

Ingegneria del Software UML - Unified Modeling Language Ingegneria del Software UML - Unified Modeling Language Obiettivi. Presentare un approccio visuale alla progettazione. Illustrare i vantaggi dell utilizzo di diagrammi nella fase di progettazione. Rispondere

Dettagli

Università degli studi dell Aquila. Sistemi informativi aziendali

Università degli studi dell Aquila. Sistemi informativi aziendali Università degli studi dell Aquila Sistemi informativi aziendali 6 C.F.U. 9 C.F.U. Ing. Gaetanino Paolone (gaetanino.paolone@univaq.it) Prof. Dr. Luciano Fratocchi (luciano.fratocchi@univaq.it) Contenuti

Dettagli

Sistemi Informativi. Introduzione. Processi fisici. Tipologie di processi. Processi informativi. Processi aziendali

Sistemi Informativi. Introduzione. Processi fisici. Tipologie di processi. Processi informativi. Processi aziendali Introduzione Sistemi Informativi Linguaggi per la modellazione dei processi aziendali Paolo Maggi Per progettare un sistema informativo è necessario identificare tutti i suoi elementi

Dettagli

Gestione del workflow

Gestione del workflow Gestione del workflow Stefania Marrara Corso di Tecnologie dei Sistemi Informativi 2004/2005 Progettazione di un Sistema Informativo Analisi dei processi Per progettare un sistema informativo è necessario

Dettagli

Modellazione dei dati in UML

Modellazione dei dati in UML Corso di Basi di Dati e Sistemi Informativi Modellazione dei dati in UML Angelo Montanari Dipartimento di Matematica e Informatica Università degli Studi di Udine Introduzione UML (Unified Modeling Language):

Dettagli

[Larman] Applicare UML e i pattern, Capitolo 28, Diagrammi di attività di UML e modellazione

[Larman] Applicare UML e i pattern, Capitolo 28, Diagrammi di attività di UML e modellazione Luca Cabibbo Architetture Software Dispensa T 1 ottobre 2008 1 -Fonti [Larman] Applicare UML e i pattern, Capitolo 28, Diagrammi di attività di UML e modellazione [Larman] Applicare UML e i pattern, Capitolo

Dettagli

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Progettazione OO E. TINELLI Punto di Partenza Il modello di analisi E una rappresentazione minima del

Dettagli

SISTEMI E RETI 4(2) 4(2) 4(2) caratteristiche funzionali

SISTEMI E RETI 4(2) 4(2) 4(2) caratteristiche funzionali CL AS SE INFORMATICA 6(3) 6(4) - 6(4) SISTEMI E RETI 4(2) 4(2) 4(2) TECNOLOGIE E PROGETTAZIONE DI SISTEMI INFORMATICI E DI TELECOMUNICAZIONI COMPETENZE 3 Essere in grado di sviluppare semplici applicazioni

Dettagli

Progettazione concettuale

Progettazione concettuale Progettazione concettuale Strategie top-down A partire da uno schema che descrive le specifiche mediante pochi concetti molto astratti, si produce uno schema concettuale mediante raffinamenti successivi

Dettagli

La specifica del problema

La specifica del problema 2.9 (Caso di studio facoltativo) Pensare a oggetti: esame del problema Iniziamo ora a esaminare il nostro caso di studio di progettazione e implementazione orientate agli oggetti. Le sezioni Pensare a

Dettagli

Casi d uso (use cases)

Casi d uso (use cases) Casi d uso (use cases) proposti da Ivar Jacobson nel 1992 termine nuovo, ma tecnica consolidata (studio degli scenari di operatività degli utilizzatori di un sistema) sono i modi in cui il sistema può

Dettagli

Corso di Informatica

Corso di Informatica Corso di Informatica Modulo T2 B1 - Progettazione dei DB 1 Prerequisiti Ciclo di vita del software file system Metodologia di progettazione razionale del software 2 1 Introduzione Per la realizzazione

Dettagli

Ingegneria del Software I. UML - Use Case Diagram

Ingegneria del Software I. UML - Use Case Diagram Requisiti e casi d uso Unified Modeling Language Use Case Diagram 1 Il primo passo di qualsiasi processo di sviluppo è la definizione dei requisiti Definizione del Business Model Solitamente informale

Dettagli

Model Driven Software Development con Eclipse, StatechartUMC

Model Driven Software Development con Eclipse, StatechartUMC Model Driven Software Development con Eclipse, StatechartUMC Aldi Sulova Istituto di Scienza e Tecnologie dell Informazione A. Faedo - CNR Via G. Moruzzi 1, 56124 Pisa, Italy aldi.sulova@isti.cnr.it Abstract.

Dettagli

Università degli studi dell Aquila. Sistemi informativi aziendali 9 C.F.U.

Università degli studi dell Aquila. Sistemi informativi aziendali 9 C.F.U. Università degli studi dell Aquila Sistemi informativi aziendali 9 C.F.U. Ing. Gaetanino Paolone (gaetanino.paolone@univaq.it) Prof. Dr. Luciano Fratocchi (luciano.fratocchi@univaq.it) Contenuti (2 ore)

Dettagli

Progettazione del Software A.A.2008/09

Progettazione del Software A.A.2008/09 Laurea in Ing. Informatica ed Ing. dell Informazione Sede di latina Progettazione del Software A.A.2008/09 Domenico Lembo* Dipartimento di Informatica e Sistemistica A. Ruberti SAPIENZA Università di Roma

Dettagli

Testo Esercizio. Un modello è ragionevole quando contiene queste tre caratteristiche.

Testo Esercizio. Un modello è ragionevole quando contiene queste tre caratteristiche. Testo Esercizio Un negozio di musica vende anche libri e riviste musicali. Si intende automatizzare l intero processo, dall approvvigionamento alla vendita. Si analizzino i requisiti e se ne rappresentino

Dettagli

Statechart Diagrams. Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it

Statechart Diagrams. Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Statechart Diagrams Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania Agenda Cosa è uno Statechart Diagram Quando

Dettagli

Software a supporto della Gestione amministrativa dello Sportello Unico Versione 2.1

Software a supporto della Gestione amministrativa dello Sportello Unico Versione 2.1 Pag. 1 di 9 Software a supporto della Gestione amministrativa dello Sportello Unico Versione 2.1 Interventi sul software RE V. REDAZIONE VERIFICHE ED APPROVAZIONI CONTROLLO APPROVAZIONE AUTORIZZAZIONE

Dettagli

Business Process Management

Business Process Management Business Process Management Comprendere, gestire, organizzare e migliorare i processi di business Caso di studio a cura della dott. Danzi Francesca e della prof. Cecilia Rossignoli 1 Business process Un

Dettagli

Organizzazione aziendale Lezione 16 BPMN. Ing. Marco Greco m.greco@unicas.it Tel.0776.299.3641 Stanza 1S-28

Organizzazione aziendale Lezione 16 BPMN. Ing. Marco Greco m.greco@unicas.it Tel.0776.299.3641 Stanza 1S-28 Organizzazione aziendale Lezione 16 BPMN Ing. Marco Greco m.greco@unicas.it Tel.0776.299.3641 Stanza 1S-28 Nozioni di base Un sistema è una collezione di entità (es. persone o macchine) che interagiscono

Dettagli

Manuale di Aggiornamento COMUNICAZIONE OPERAZIONI RILEVANTI AI FINI IVA 2011. DATALOG Soluzioni Integrate a 32 Bit

Manuale di Aggiornamento COMUNICAZIONE OPERAZIONI RILEVANTI AI FINI IVA 2011. DATALOG Soluzioni Integrate a 32 Bit KING Manuale di Aggiornamento COMUNICAZIONE OPERAZIONI RILEVANTI AI FINI IVA 2011 DATALOG Soluzioni Integrate a 32 Bit - 2 - Manuale di Aggiornamento Sommario 1 Comunicazione Operazioni rilevanti IVA per

Dettagli

Reti e sistemi informativi II Il ruolo delle IT nell organizzazione

Reti e sistemi informativi II Il ruolo delle IT nell organizzazione Reti e sistemi informativi II Il ruolo delle IT nell organizzazione Prof. Andrea Borghesan & Dr.ssa Francesca Colgato venus.unive.it/borg borg@unive.it Ricevimento: mercoledì dalle 10.00 alle 11.00 Modalità

Dettagli

Il diagramma dei casi d uso

Il diagramma dei casi d uso Il diagramma dei casi d uso Laboratorio di Ingegneria del Software Prof. Paolo Ciancarini Dott. Sara Zuppiroli A.A. 2010/2011 Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011

Dettagli

Progetto. Struttura del documento di specifica dei requisiti, Casi d uso. manuel.comparetti@iet.unipi.it

Progetto. Struttura del documento di specifica dei requisiti, Casi d uso. manuel.comparetti@iet.unipi.it Progetto Struttura del documento di specifica dei requisiti, Casi d uso manuel.comparetti@iet.unipi.it 1 Documenti da produrre Il progetto deve comprendere i seguenti documenti: Documento di specifica

Dettagli

Università di Pisa Polo Sistemi Logistici Economia e Legislazione dei Sistemi Logistici. Informatica per la Logistica. Lezioni

Università di Pisa Polo Sistemi Logistici Economia e Legislazione dei Sistemi Logistici. Informatica per la Logistica. Lezioni Università di Pisa Polo Sistemi Logistici Economia e Legislazione dei Sistemi Logistici Le grandi e complesse organizzazioni aziendali sono la manifestazione tangibile della tecnologia avanzata, più delle

Dettagli

Logistica Magazzino: Distinta base

Logistica Magazzino: Distinta base Logistica Magazzino: Distinta base Premessa 2 Centri di lavoro 2 Cicli di lavorazione 3 Fasi cicli di lavorazione 4 Dettaglio costi 4 Distinta base 5 Archivio distinta base 5 Dettaglio distinta 5 Duplicazione

Dettagli

Ciclo di Vita Evolutivo

Ciclo di Vita Evolutivo Ciclo di Vita Evolutivo Prof.ssa Enrica Gentile a.a. 2011-2012 Modello del ciclo di vita Stabiliti gli obiettivi ed i requisiti Si procede: All analisi del sistema nella sua interezza Alla progettazione

Dettagli

Raccolta dei Requisiti con i Casi D'uso. Corso di Ingegneria del Software Anno Accademico 2012/13

Raccolta dei Requisiti con i Casi D'uso. Corso di Ingegneria del Software Anno Accademico 2012/13 Raccolta dei Requisiti con i Casi D'uso Corso di Ingegneria del Software Anno Accademico 2012/13 I casi d uso I casi d'uso (use case) sono una tecnica utilizzata per identificare i requisiti funzionali

Dettagli

Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica. Ingegneria del Software. La fase di Analisi

Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica. Ingegneria del Software. La fase di Analisi Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Ingegneria del Software La fase di Analisi Giulio Destri Ing. del software: Analisi - 1 Scopo del modulo Definire

Dettagli

Modellazione e progettazione con UML. Eduard Roccatello 3D GIS Specialist <eduard.roccatello@3dgis.it> www.roccatello.it

Modellazione e progettazione con UML. Eduard Roccatello 3D GIS Specialist <eduard.roccatello@3dgis.it> www.roccatello.it Modellazione e progettazione con UML Eduard Roccatello 3D GIS Specialist www.roccatello.it Object Oriented Analysis and Design Consente di modellare un sistema attraverso l

Dettagli

PROGRAMMAZIONE MODULARE DI INFORMATICA CLASSE QUINTA - INDIRIZZO MERCURIO SEZIONE TECNICO

PROGRAMMAZIONE MODULARE DI INFORMATICA CLASSE QUINTA - INDIRIZZO MERCURIO SEZIONE TECNICO PROGRAMMAZIONE MODULARE DI INFORMATICA CLASSE QUINTA - INDIRIZZO MERCURIO SEZIONE TECNICO Modulo 1: IL LINGUAGGIO HTML Formato degli oggetti utilizzati nel Web Elementi del linguaggio HTML: tag, e attributi

Dettagli

TEORIA sulle BASI DI DATI

TEORIA sulle BASI DI DATI TEORIA sulle BASI DI DATI A cura del Prof. Enea Ferri Cos è un DATA BASE E un insieme di archivi legati tra loro da relazioni. Vengono memorizzati su memorie di massa come un unico insieme, e possono essere

Dettagli

Il linguaggio per la moderna progettazione dei processi aziendali

Il linguaggio per la moderna progettazione dei processi aziendali Il linguaggio per la moderna progettazione dei processi aziendali Organizzare un azienda sotto il profilo dei processi è oramai diventata una disciplina a cavallo tra la competenza aziendalistica ed informatica.

Dettagli

In legenda sono riportate le fasi R, P, C/T e I/SA come specificato nella norma ISO/IEC 12207.

In legenda sono riportate le fasi R, P, C/T e I/SA come specificato nella norma ISO/IEC 12207. Durante le attività di sviluppo del software applicativo è spesso utilizzato un ciclo di vita incrementale il cui schema di processo è sintetizzato nella figura seguente. In legenda sono riportate le fasi

Dettagli

ISTITUTO TECNICO ECONOMICO MOSSOTTI

ISTITUTO TECNICO ECONOMICO MOSSOTTI CLASSE III INDIRIZZO S.I.A. UdA n. 1 Titolo: conoscenze di base Conoscenza delle caratteristiche dell informatica e degli strumenti utilizzati Informatica e sistemi di elaborazione Conoscenza delle caratteristiche

Dettagli

Organizzazione aziendale Lezione 22 BPMN. Ing. Marco Greco m.greco@unicas.it Tel.0776.299.3641 Stanza 1S-28

Organizzazione aziendale Lezione 22 BPMN. Ing. Marco Greco m.greco@unicas.it Tel.0776.299.3641 Stanza 1S-28 Organizzazione aziendale Lezione 22 BPMN Ing. Marco Greco m.greco@unicas.it Tel.0776.299.3641 Stanza 1S-28 Prima di cominciare: Erasmus! Scadenza: 5 luglio 2012 Durata: min 3 max 12 mesi Dal 1 giugno 2012

Dettagli

Strumenti di modellazione. Gabriella Trucco

Strumenti di modellazione. Gabriella Trucco Strumenti di modellazione Gabriella Trucco Linguaggio di modellazione Linguaggio formale che può essere utilizzato per descrivere (modellare) un sistema Il concetto trova applicazione soprattutto nell

Dettagli

IL SISTEMA INFORMATIVO AZIENDALE

IL SISTEMA INFORMATIVO AZIENDALE IL SISTEMA INFORMATIVO AZIENDALE CL. 5ATP - A.S. 2006/2007 L azienda e i suoi elementi PERSONE AZIENDA BENI ECONOMICI ORGANIZZAZIONE L azienda è un insieme di beni organizzati e coordinati dall imprenditore

Dettagli

UML - Unified Modeling Language

UML - Unified Modeling Language UML E CASI D USO UML - Unified Modeling Language Linguaggio stardardizzato per identificare e modellizzare le specifiche di un S.I. Coerente con il paradigma della programmazione ad oggetti Definito a

Dettagli

Introduzione ad UML. Perché modelliamo

Introduzione ad UML. Perché modelliamo Introduzione ad UML Pag. 1 Perché modelliamo Un modello è una semplificazione della realtà I modelli ci aiutano a visualizzare un sistema come è o come vorremmo che fosse ci permettono di specificare la

Dettagli

EXPLOit Content Management Data Base per documenti SGML/XML

EXPLOit Content Management Data Base per documenti SGML/XML EXPLOit Content Management Data Base per documenti SGML/XML Introduzione L applicazione EXPLOit gestisce i contenuti dei documenti strutturati in SGML o XML, utilizzando il prodotto Adobe FrameMaker per

Dettagli

Introduzione a UML. Iolanda Salinari

Introduzione a UML. Iolanda Salinari Introduzione a UML Iolanda Salinari Perché modelliamo Un modello è una semplificazione della realtà I modelli ci aiutano a visualizzare un sistema come è o come vorremmo che fosse ci permettono di specificare

Dettagli

ANALISI E MAPPATURA DEI PROCESSI AZIENDALI

ANALISI E MAPPATURA DEI PROCESSI AZIENDALI ANALISI E MAPPATURA DEI PROCESSI AZIENDALI Cos è un processo aziendale Processo come trasformazione (dal verbo procedere ) Processo aziendale: insieme di attività interdipendenti finalizzate a un obiettivo

Dettagli

[http://www.mokabyte.it/umlbook/index.htm] Gentleware: Poseidon for UML 3.0". [http://www.gentleware.com/] Sparxsystems: Enterprise Architect 6.1".

[http://www.mokabyte.it/umlbook/index.htm] Gentleware: Poseidon for UML 3.0. [http://www.gentleware.com/] Sparxsystems: Enterprise Architect 6.1. La lezione di oggi Vetti Tagliati: Uml e Ingegneria del software: dalla teoria alla pratica". [http://www.mokabyte.it/umlbook/index.htm] Gentleware: Poseidon for UML 3.0". [http://www.gentleware.com/]

Dettagli

Linguaggi di Programmazione I Lezione 5

Linguaggi di Programmazione I Lezione 5 Linguaggi di Programmazione I Lezione 5 Prof. Marcello Sette mailto://marcello.sette@gmail.com http://sette.dnsalias.org 1 aprile 2008 Diagrammi UML 3 UML: richiami..........................................................

Dettagli

Object Oriented Programming

Object Oriented Programming OOP Object Oriented Programming Programmazione orientata agli oggetti La programmazione orientata agli oggetti (Object Oriented Programming) è un paradigma di programmazione Permette di raggruppare in

Dettagli

ACADEMY MICROSOFT DYNAMICS CRM ONLINE

ACADEMY MICROSOFT DYNAMICS CRM ONLINE SKILL4YOU ACADEMY MICROSOFT DYNAMICS CRM ONLINE 2015 PERCORSO ACADEMY MICROSOFT DYNAMICS CRM ONLINE 2015 A CHI E RIVOLTO IL CORSO Questo piano formativo si rivolge a tutte le persone che desiderano acquisire

Dettagli

Dominio applicativo. Analisi e ricognizione delle fonti dati

Dominio applicativo. Analisi e ricognizione delle fonti dati Dominio applicativo La Società chiamata StraSport, si occupa di vendite all ingrosso di articoli sportivi. Ha agenzie distribuite sul territorio italiano che gestiscono le vendite, ognuna di esse gestisce

Dettagli

ING SW. Progetto di Ingegneria del Software. e-travel. Requisiti Utente. Specifiche Funzionali del Sistema

ING SW. Progetto di Ingegneria del Software. e-travel. Requisiti Utente. Specifiche Funzionali del Sistema Pagina: 1 e-travel ING SW Progetto di Ingegneria del Software e-travel Requisiti Utente Specifiche Funzionali del Sistema e Pagina: 2 di 9 Indice dei contenuti 1 INTRODUZIONE... 3 1.1 SCOPO DEL DOCUMENTO...

Dettagli

IL SISTEMA DEI CONTI ECONOMICI NAZIONALI. a cura di Claudio Picozza

IL SISTEMA DEI CONTI ECONOMICI NAZIONALI. a cura di Claudio Picozza IL SISTEMA DEI CONTI ECONOMICI NAZIONALI a cura di Claudio Picozza 1 CONTABILITA NAZIONALE E CONTI ECONOMICI NAZIONALI La Contabilità Nazionale è rappresentata da l'insieme di tutti i conti economici che

Dettagli

Appunti lezione Database del 07/10/2015

Appunti lezione Database del 07/10/2015 Appunti lezione Database del 07/10/2015 Nelle lezioni precedenti si è visto come qualunque applicazione informativa è almeno formata da tre livelli o layers che ogni progettista conosce e sa gestire: Livello

Dettagli

ANALISI E PROGETTAZIONE OBJECT ORIENTED UNIFIED MODELLING LANGUAGE (UML)

ANALISI E PROGETTAZIONE OBJECT ORIENTED UNIFIED MODELLING LANGUAGE (UML) ANALISI E PROGETTAZIONE OBJECT ORIENTED UNIFIED MODELLING LANGUAGE (UML) a cura di Giacomo PISCITELLI Dipartimento di Elettrotecnica ed Elettronica Politecnico di Bari Questi appunti sono ricavati da una

Dettagli

Principi dell ingegneria del software Relazioni fra

Principi dell ingegneria del software Relazioni fra Sommario Principi dell ingegneria del software Leggere Cap. 3 Ghezzi et al. Principi dell ingegneria del software Relazioni fra Principi Metodi e tecniche Metodologie Strumenti Descrizione dei principi

Dettagli

per le decisioni economiche e

per le decisioni economiche e Elaborazione automatica dei dati per le decisioni economiche e finanziarie VBA-MODULO 1 Introduzione al Visual Basic for Applications Università di Foggia Facoltà di Economia Prof. Crescenzio Gallo c.gallo@unifg.it

Dettagli

BASI DATI BIOINGEGNERIA ED INFORMATICA MEDICA. Lezione II - BioIngInfMed

BASI DATI BIOINGEGNERIA ED INFORMATICA MEDICA. Lezione II - BioIngInfMed BASI DATI BIOINGEGNERIA ED INFORMATICA MEDICA 1 Sistema Informativo Un sistema informativo (SI) è un componente di una organizzazione il cui obiettivo è gestire le informazioni utili per gli scopi dell

Dettagli

Identificare come i vari elementi dei Microsoft Dynamics CRM possono essere utilizzati per le relazioni con i clienti

Identificare come i vari elementi dei Microsoft Dynamics CRM possono essere utilizzati per le relazioni con i clienti PERIODO : Dal 11 novembre 2015 AL 4 dicembre 2015 Sede del corso: Presso GI Formazione in Piazza IV novembre 5, Milano Orari dalle 9.00 alle 13.00 e dalle 14.00 alle 18.00 A CHI E RIVOLTO IL CORSO Questo

Dettagli

Analisi dei Requisiti

Analisi dei Requisiti Analisi dei Requisiti Pagina 1 di 16 Analisi dei Requisiti Indice 1 - INTRODUZIONE... 4 1.1 - OBIETTIVO DEL DOCUMENTO...4 1.2 - STRUTTURA DEL DOCUMENTO...4 1.3 - RIFERIMENTI...4 1.4 - STORIA DEL DOCUMENTO...4

Dettagli

Progettaz. e sviluppo Data Base

Progettaz. e sviluppo Data Base Progettaz. e sviluppo Data Base! Progettazione Basi Dati: Metodologie e modelli!modello Entita -Relazione Progettazione Base Dati Introduzione alla Progettazione: Il ciclo di vita di un Sist. Informativo

Dettagli

Progettazione orientata agli oggetti Introduzione a UML

Progettazione orientata agli oggetti Introduzione a UML Progettazione orientata agli oggetti Introduzione a UML Claudia Raibulet raibulet@disco.unimib.it Il processo di sviluppo software Rappresenta un insieme di attività per la specifica, progettazione, implementazione,

Dettagli

B.P.S. Business Process Server ALLEGATO C10

B.P.S. Business Process Server ALLEGATO C10 B.P.S. Business Process Server ALLEGATO C10 REGIONE BASILICATA DIPARTIMENTO PRESIDENZA DELLA GIUNTA REGIONALE UFFICIO SISTEMA INFORMATIVO REGIONALE E STATISTICA Via V. Verrastro, n. 4 85100 Potenza tel

Dettagli

2- Identificazione del processo. (o dei processi) da analizzare. Approcci: Esaustivo. In relazione al problema. Sulla base della rilevanza

2- Identificazione del processo. (o dei processi) da analizzare. Approcci: Esaustivo. In relazione al problema. Sulla base della rilevanza PROCESS MAPPING (2) Approcci: 2- Identificazione del processo Esaustivo (o dei processi) da analizzare Mappatura a largo spettro (es.: vasta implementazione di un ERP) In relazione al problema ad es. i

Dettagli

LABORATORIO. 2 Lezioni su Basi di Dati Contatti:

LABORATORIO. 2 Lezioni su Basi di Dati Contatti: PRINCIPI DI INFORMATICA CORSO DI LAUREA IN SCIENZE BIOLOGICHE Gennaro Cordasco e Rosario De Chiara {cordasco,dechiara}@dia.unisa.it Dipartimento di Informatica ed Applicazioni R.M. Capocelli Laboratorio

Dettagli

Informatica Documentale

Informatica Documentale Informatica Documentale Ivan Scagnetto (scagnett@dimi.uniud.it) Stanza 3, Nodo Sud Dipartimento di Matematica e Informatica Via delle Scienze, n. 206 33100 Udine Tel. 0432 558451 Ricevimento: giovedì,

Dettagli

Sequence Diagram e Collaboration Diagram

Sequence Diagram e Collaboration Diagram Sequence Diagram e Collaboration Diagram Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania Sommario Interaction

Dettagli

La Progettazione Concettuale

La Progettazione Concettuale La Progettazione Concettuale Università degli Studi del Sannio Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica CorsodiBasidiDati Anno Accademico 2006/2007 docente: ing. Corrado Aaron Visaggio

Dettagli

LEGGERE E ANALIZZARE IL BILANCIO D ESERCIZIO

LEGGERE E ANALIZZARE IL BILANCIO D ESERCIZIO B2corporate Maurizio Nizzola LEGGERE E ANALIZZARE IL BILANCIO D ESERCIZIO La lettura e la corretta interpretazione del bilancio d esercizio è di fondamentale importanza per valutare l andamento economico

Dettagli

La norma ISO 50001 per il risparmio energetico delle aziende

La norma ISO 50001 per il risparmio energetico delle aziende La norma ISO 50001 per il risparmio energetico delle aziende La norma UNI CEI EN ISO 50001:2011 Sistemi di gestione dell energia Requisiti e linee guida per l uso è la versione ufficiale italiana della

Dettagli

DFD DISPENSA DEL CORSO DI SISTEMI INFORMATIVI UNIVERSITÀ DEGLI STUDI DI VERONA FACOLTÀ DI MM.FF.NN LAUREA SPECIALISTICA IN INFORMATICA

DFD DISPENSA DEL CORSO DI SISTEMI INFORMATIVI UNIVERSITÀ DEGLI STUDI DI VERONA FACOLTÀ DI MM.FF.NN LAUREA SPECIALISTICA IN INFORMATICA UNIVERSITÀ DEGLI STUDI DI VERONA FACOLTÀ DI MM.FF.NN LAUREA SPECIALISTICA IN INFORMATICA DISPENSA DEL CORSO DI SISTEMI INFORMATIVI Prof. Carlo Combi DFD Appunti a cura di E. Peri M. Devincenzi Indice 1

Dettagli

Sistemi Informativi I Caso di studio con applicazione di UML

Sistemi Informativi I Caso di studio con applicazione di UML 9 CASO DI STUDIO CON APPLICAZIONE DI UML...2 9.1 IL CASO DI STUDIO...2 9.1.1 Il sistema attuale...2 9.2 IL PROBLEM STATEMENT...3 9.2.1 Formulazione del Problem statement per il caso proposto...3 9.3 USE

Dettagli

DD - Design Document

DD - Design Document Politecnico di Milano Progetto di Ingegneria del Software 2 DD - Design Document Autori: Claudia Foglieni Giovanni Matteo Fumarola Massimo Maggi Professori: Elisabetta Di Nitto Raffaela Mirandola 1 gennaio

Dettagli

ANALISI E PROGETTAZIONE OBJECT ORIENTED. Lorenzo Saladini

ANALISI E PROGETTAZIONE OBJECT ORIENTED. Lorenzo Saladini ANALISI E PROGETTAZIONE OBJECT ORIENTED Lorenzo Saladini 1. Introduzione In questo capitolo vengono presentati alcuni degli elementi necessari al corretto sviluppo di sistemi informatici secondo una metodologia

Dettagli

Progetto Campo Base. Università degli Studi di L Aquila. Facoltà di Ingegneria. Corso di Laurea in Ingegneria Elettronica Corso di Sistemi Informativi

Progetto Campo Base. Università degli Studi di L Aquila. Facoltà di Ingegneria. Corso di Laurea in Ingegneria Elettronica Corso di Sistemi Informativi Università degli Studi di L Aquila Facoltà di Ingegneria Corso di Laurea in Ingegneria Elettronica Corso di Sistemi Informativi Prof. Gaetanino Paolone Dott. Ottavio Pascale a.a.2003-2004 Progetto Campo

Dettagli

Sviluppo e Applicazioni Object Oriented Sviluppo e Applicazioni del Commercio Elettronico UML Analisi Object Oriented Programmazione Java

Sviluppo e Applicazioni Object Oriented Sviluppo e Applicazioni del Commercio Elettronico UML Analisi Object Oriented Programmazione Java Associazione Nazionale Aziende distributrici prodotti e servizi per l ufficio, l informatica e la telematica Via Merano, 18 20127 Milano-telefono (02) 28.500.91-telefax (02) 28.500.999 E-Mail: comuff@tin.it

Dettagli

SDD System design document

SDD System design document UNIVERSITA DEGLI STUDI DI PALERMO FACOLTA DI INGEGNERIA CORSO DI LAUREA IN INGEGNERIA INFORMATICA TESINA DI INGEGNERIA DEL SOFTWARE Progetto DocS (Documents Sharing) http://www.magsoft.it/progettodocs

Dettagli

Linguaggi di programmazione

Linguaggi di programmazione Linguaggi di programmazione Programmazione L attività con cui si predispone l elaboratore ad eseguire un particolare insieme di azioni su particolari dati, allo scopo di risolvere un problema Dati Input

Dettagli

PIATTAFORMA PER LA CERTIFICAZIONE DEL CREDITO PCC - Estrazione dati

PIATTAFORMA PER LA CERTIFICAZIONE DEL CREDITO PCC - Estrazione dati PIATTAFORMA PER LA CERTIFICAZIONE DEL CREDITO PCC - Estrazione dati L art. 27 decreto legge 24 aprile 2014 n. 66, convertito con modificazioni dalla legge 23 giugno 2014, n. 89, introduce significative

Dettagli

Tecnopolis CSATA s.c.r.l. APQ in Materia di Ricerca Scientifica nella Regione Puglia

Tecnopolis CSATA s.c.r.l. APQ in Materia di Ricerca Scientifica nella Regione Puglia BANDO ACQUISIZIONI Prodotti Software ALLEGATO 6.3 Capitolato Tecnico Piattaforma per l Analisi e la Progettazione di alto livello del Software Allegato 6.3: capitolato tecnico Pag. 1 1 Ambiente di Analisi

Dettagli

Project Planning. Politecnico di Milano. Progetto di Ingegneria del Software 2. 15 novembre 2011. Elisabetta Di Nitto Raffaela Mirandola

Project Planning. Politecnico di Milano. Progetto di Ingegneria del Software 2. 15 novembre 2011. Elisabetta Di Nitto Raffaela Mirandola Politecnico di Milano Progetto di Ingegneria del Software 2 Project Planning Autori: Claudia Foglieni Giovanni Matteo Fumarola Massimo Maggi Professori: Elisabetta Di Nitto Raffaela Mirandola 15 novembre

Dettagli

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma Unified Process Prof. Agostino Poggi Unified Process Unified Software Development Process (USDP), comunemente chiamato

Dettagli

Corso di Access. Prerequisiti. Modulo L2A (Access) 1.1 Concetti di base. Utilizzo elementare del computer Concetti fondamentali di basi di dati

Corso di Access. Prerequisiti. Modulo L2A (Access) 1.1 Concetti di base. Utilizzo elementare del computer Concetti fondamentali di basi di dati Corso di Access Modulo L2A (Access) 1.1 Concetti di base 1 Prerequisiti Utilizzo elementare del computer Concetti fondamentali di basi di dati 2 1 Introduzione Un ambiente DBMS è un applicazione che consente

Dettagli

MANUALE DELLA QUALITÀ Pag. 1 di 10

MANUALE DELLA QUALITÀ Pag. 1 di 10 MANUALE DELLA QUALITÀ Pag. 1 di 10 INDICE IL SISTEMA DI GESTIONE DELLA QUALITÀ Requisiti generali Responsabilità Struttura del sistema documentale e requisiti relativi alla documentazione Struttura dei

Dettagli

Fasi del ciclo di vita del software (riassunto) Progetto: generalità. Progetto e realizzazione (riassunto)

Fasi del ciclo di vita del software (riassunto) Progetto: generalità. Progetto e realizzazione (riassunto) Università degli Studi di Roma La Sapienza Facoltà di Ingegneria Sede di Latina Laurea in Ingegneria dell Informazione Fasi del ciclo di vita del software (riassunto) Corso di PROGETTAZIONE DEL SOFTWARE

Dettagli

Business Process Modeling and Notation e WebML

Business Process Modeling and Notation e WebML Business Process Modeling and Notation e WebML 24 Introduzione I Web Service e BPMN sono standard de facto per l interoperabilità in rete a servizio delle imprese moderne I Web Service sono utilizzati

Dettagli

Gestione remota archivi cartelle sanitarie e di rischio informatizzate

Gestione remota archivi cartelle sanitarie e di rischio informatizzate Gestione remota archivi cartelle sanitarie e di rischio informatizzate L odierna realtà economica impone alle aziende di differenziarsi sempre più dai concorrenti, investendo in tecnologie che possano

Dettagli

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0 PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0 PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO ELEMENTI FONDAMENTALI PER LO SVILUPPO DI SISTEMI INFORMATIVI ELABORAZIONE DI

Dettagli

Introduzione alla progettazione. Metodologie e modelli per la progettazione di basi di dati. Il ciclo di vita dei sistemi informativi

Introduzione alla progettazione. Metodologie e modelli per la progettazione di basi di dati. Il ciclo di vita dei sistemi informativi Metodologie e modelli per la progettazione di basi di dati Introduzione alla progettazione Il problema: progettare una base di base di dati a partire dai suoi requisiti Progettare: definire la struttura,

Dettagli

Work World WORK WORLD PROGETTO INGEGNERIA DEL SOFTWARE. Alessandro Spinelli

Work World WORK WORLD PROGETTO INGEGNERIA DEL SOFTWARE. Alessandro Spinelli WORK WORLD PROGETTO INGEGNERIA DEL SOFTWARE di Alessandro Spinelli Indice 1 - Introduzione 2 - Descrizione del problema 2.1 Requisiti funzionali 2.2 Requisiti non funzionali 3 - Analisi 3.1 Dizionario

Dettagli

Liceo scientifico statale Galileo Galilei 35030 Selvazzano Dentro (PD) Anno scolastico 2013-2014 Dipartimento di Informatica: Obiettivi Disciplinari

Liceo scientifico statale Galileo Galilei 35030 Selvazzano Dentro (PD) Anno scolastico 2013-2014 Dipartimento di Informatica: Obiettivi Disciplinari Liceo scientifico statale Galileo Galilei 35030 Selvazzano Dentro (PD) Anno scolastico 2013-2014 Dipartimento di Informatica: Obiettivi Disciplinari Il presente documento descrive gli obiettivi disciplinari

Dettagli

Generazione Automatica di Asserzioni da Modelli di Specifica

Generazione Automatica di Asserzioni da Modelli di Specifica UNIVERSITÀ DEGLI STUDI DI MILANO BICOCCA FACOLTÀ DI SCIENZE MATEMATICHE FISICHE E NATURALI Corso di Laurea Magistrale in Informatica Generazione Automatica di Asserzioni da Modelli di Specifica Relatore:

Dettagli

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

Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI. Obiettivi Specifica dei Requisiti Assembly Lines Esercizi Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI Obiettivi Specifica dei Requisiti Assembly Lines Esercizi Obiettivi Nelle lezioni precedenti abbiamo descritto come modellare i requisiti funzionali

Dettagli

MODULI AGGIUNTIVI. I moduli di WE4Broker REL Rami Elementari

MODULI AGGIUNTIVI. I moduli di WE4Broker REL Rami Elementari ULI AGGIUNTIVI MODULI AGGIUNTIVI Modulo REL Fees Interfacciamento Do-Print Trattative Analisi portafoglio statistiche avanzate FEES La gestione delle fees attive prevede delle tabelle parametriche per

Dettagli

WAM E-Invoice Fatturazione Elettronica a standard PA con integrazione ad Archiviazione e Conservazione Sostitutiva. Faber System è certificata

WAM E-Invoice Fatturazione Elettronica a standard PA con integrazione ad Archiviazione e Conservazione Sostitutiva. Faber System è certificata WAM E-Invoice Fatturazione Elettronica a standard PA con integrazione ad Archiviazione e Conservazione Sostitutiva Faber System è certificata La Fatturazione Elettronica 23.05.2013 Pubblicato in Gazzetta

Dettagli

SCHEDA PRODOTTO PAG. 1 J O B T I M E W F. Variazioni mensili al cartellino presenze. Versione 6.1. JOBTIME Work Flow

SCHEDA PRODOTTO PAG. 1 J O B T I M E W F. Variazioni mensili al cartellino presenze. Versione 6.1. JOBTIME Work Flow SCHEDA PRODOTTO PAG. 1 J O B T I M E W F Variazioni mensili al cartellino presenze Versione 6.1 SCHEDA PRODOTTO PAG. 2 INTRODUZIONE Il mercato degli applicativi informatici si sta consolidando sempre più

Dettagli

Modellazione di processi

Modellazione di processi Luca Cabibbo Architetture Software Dispensa ASW 910 ottobre 2014 La modellazione è un mestiere e a volte è un arte. William C. Burkett 1 -Fonti [Papazoglou] Papazoglou, Web Services Principles and Technology,

Dettagli

Testo Esercizio Sommario Note relative alla modellazione UML. Note relative al testo dell esercizio.

Testo Esercizio Sommario Note relative alla modellazione UML. Note relative al testo dell esercizio. Testo Esercizio Si consideri un sistema per la gestione di un magazzino di un negozio scelto a piacere dal candidato Il sistema è in grado di gestire le seguenti operazioni: Arrivo di nuovi prodotti; Controllo

Dettagli