9. Principi di ingegneria del so9ware

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "9. Principi di ingegneria del so9ware"

Transcript

1 Corso di Laurea in Matema1ca Dipar9mento di Matema9ca e Fisica Sistemi per l elaborazione delle informazioni 9. Principi di ingegneria del so9ware Dispense del corso IN530 prof. Marco Liverani Scopo dell ingegneria del so9ware L ingegneria del somware definisce modelli e metodologie per formalizzare il processo di progeaazione, realizzazione e manutenzione di un sistema informa9co In questo ambito si definisce un vero e proprio ciclo di vita del so9ware, nel tenta9vo di trasformare lo sviluppo somware da un arvità ar9gianale verso un processo industriale in un arvità ar1gianale si possono raggiungere eleva9 livelli qualita9vi e di performance, ma questo è stretamente legato all abilità dell ar1giano; non sempre l abilità può essere trasferita ad altri mediante un processo di formazione in un arvità industriale si cerca di raggiungere un livello di qualità e di performance adegua1 al posizionamento di mercato del prodoao; qualità e performance sono otenu9 mediante la definizione e la formalizzazione di processi e modalità di realizzazione di ciascuna arvità necessaria nel ciclo di produzione; le arvità sono misurabili e controllabili M. Liverani - Dispense del corso IN530 - Sistemi per l'elaborazione delle informazioni 1

2 Ciclo di vita del so9ware Un prodoto somware ha un suo ciclo di vita, ossia esistono diverse fasi successive durante il processo di realizzazione e manutenzione del somware che vanno dal suo concepimento iniziale, fino alla sua defini9va dismissione 1. Analisi preliminare Studio di farbilità, definizione delle esigenze, definizione del contesto Definizione dei requisi9 2. ProgeAazione del so9ware Specifiche funzionali ed architeturali del somware Iden9ficazione di librerie e componen9 somware riusabili ProgeTazione delle componen9 del sistema somware 3. Realizzazione del so9ware Specifiche di detaglio dei moduli Sviluppo dei moduli somware, test unitario 4. Test, collaudo e rilascio in produzione Integrazione dei moduli e test unitari e di integrazione Collaudo e validazione del sistema integrato Rilascio, migrazione e caricamento dei da9, avvio in produzione 5. Ges1one del sistema so9ware U9lizzo del somware e manutenzione ordinaria, adegua9va, correrva (MAC), evolu9va (MEV) Rilascio di nuove release, ripetendo i passi Termine del ciclo di vita del so9ware Messa fuori servizio del somware, backup dei da9, migrazione da9 e servizi su nuovo somware Prima fase: Analisi preliminare ARvità principali: Studio di farbilità, definizione dell esigenza e della soluzione informa9ca, definizione dell ambito del somware, iden9ficazione degli stakeholders (uten9, altri sistemi, ecc.) Definizione dei requisi1 Output prodor: Nota tecnica o documento di vision : contesto, esigenze e soluzioni, problema9che, disegno generale del sistema Iden9ficazione delle risorse necessarie (umane e strumentali) e s9me di impegno Documento dei requisi9 (carateris9che del prodoto somware, cosa deve fare) Figure professionali coinvolte: Project Manager, Account Manager Analista SoMware Architect, System Architect Esperto del contesto di business Modalità opera9va: Interviste presso il cliente Analisi dei da9 e dei sistemi informa9ci preesisten9 Iden9ficazione di soluzioni di mercato, open source o presen9 in azienda u9li al progeto M. Liverani - Dispense del corso IN530 - Sistemi per l'elaborazione delle informazioni 2

3 Seconda fase: ProgeAazione del so9ware ARvità principali: Definizione delle specifiche grafico- funzionali del somware Definizione delle specifiche di disegno architeturale (architetura fisica, architetura di rete, architetura logica e delle componen9) ProgeTazione delle componen9 del sistema somware Output prodor: Documento di specifiche funzionali, specifiche sui da9 Documento di disegno architeturale, iden9ficazione dei prodor hardware e somware e delle componen9 riusabili Figure coinvolte: Project Manager Analista SoMware Architect, System Architect Specialista di prodoto Modalità opera9va: Lavoro in- house Use case diagram, sequence diagram, component diagram, en9ty/rela9onship diagram Studio di soluzioni di mercato, open source o presen9 in azienda Terza fase: Realizzazione del so9ware Avviene anche in concomitanza con la progetazione (le due fasi possono essere concorren9, con uno slitamento in avan9 della fase di realizzazione); si svolge in- house o presso il cliente a seconda degli strumen9 tecnologici impiega9 e dei vincoli contratuali ARvità principali: Specifiche di detaglio dei moduli somware ProgeTazione dei moduli somware (classi, funzioni, package e librerie) Sviluppo dei moduli somware, test unitario Output prodor: Specifiche tecniche per lo sviluppo dei singoli moduli somware (il detaglio dipende dalla complessità del sistema e dal livello di coinvolgimento degli sviluppatori nella progetazione) Specifiche che descrivono la strutura ad ogger del modulo o il modello relazionale dei da9 SoMware documentato, soto controllo di configurazione Figure coinvolte: Project Manager SoMware Architect Analista- Programmatore, Programmatore Modalità opera9va: Lavoro in- house o presso il cliente Class diagram, flow chart, documentazione del codice (es.: Javadoc) Uso di strumen9 di sviluppo in base al 9po di tecnologia scelta Uso di strumen9 di versioning e di tracciamento delle modifiche (controllo di configurazione) Test con9nuo dei moduli rilascia9 nel repository di progeto (il somware si compila?) M. Liverani - Dispense del corso IN530 - Sistemi per l'elaborazione delle informazioni 3

4 Quarta fase: Test, collaudo e rilascio in produzione Avviene al termine dello sviluppo di un modulo somware auto- consistente e cos9tuisce una milestone significa9va per il progeto ARvità principali: Integrazione dei moduli e test unitari e di integrazione Test del sistema integrato Pianificazione del rilascio in produzione e predisposizione delle risorse necessarie (server, rete, ecc.) Rilascio e messa in produzione Output prodor: Piano dei test e report di esecuzione dei test unitari e di integrazione Piano dei test e report di esecuzione dei test di sistema Piano di indirizzamento di rete Sistema funzionante nell ambiente di produzione iden9ficato insieme al cliente Manuale di configurazione e ges9one Manuale utente Piano di backup, piano di disaster recovery Istruzioni per il change management e il por6ng dei da9 Figure coinvolte: Project Manager SoMware Architect Analista- Programmatore, Programmatore Sistemista Modalità opera9va: Lavoro presso il cliente nell ambiente di produzione finale del prodoto (in alcuni casi nell ambiente di collaudo, supportando poi il cliente per il passaggio in ambiente di produzione) Quinta fase: Ges1one e manutenzione del sistema in produzione Avviene dopo l entrata in esercizio di almeno una delle componen9 somware significa9ve; è un arvità priva di scadenze intermedie, ma con necessità di rendicontazione puntuale delle arvità con una periodicità e un detaglio defini9 a livello contratuale; la manutenzione correrva è soggeta a SLA (service level agreement) defini9 contratualmente ARvità principali: Supporto agli uten9 nell u9lizzo del sistema e formazione, supporto agli amministratori nella ges9one del sistema Manutenzione ordinaria Manutenzione correrva ed evolu9va Output prodor: Report di intervento Piano di formazione Documentazione delle modifiche somware, con aggiornamento della documentazione Figure coinvolte: Project Manager Programmatore, Analista- Programmatore Sistemista Esperto di prodoto/di sistema Operatore help desk Modalità opera9va: Lavoro presso il cliente nell ambiente di produzione finale del prodoto per le arvità di assistenza, ges9one e formazione Lavoro in- house e presso il cliente per le arvità di manutenzione correrva ed evolu9va M. Liverani - Dispense del corso IN530 - Sistemi per l'elaborazione delle informazioni 4

5 Sesta fase: Termine del ciclo di vita del sistema ARvità principali: Supporto agli amministratori per il trasferimento dei da9 Backup finale dei da9 e del somware Supporto al cliente per la definizione di un processo di passaggio dal vecchio al nuovo sistema Output prodor: Istruzioni per il change management e il por6ng dei da9 Figure coinvolte: Project Manager, Account Manager Analista Sistemista Esperto di prodoto/di sistema Modalità opera9va: Lavoro presso il cliente nell ambiente di produzione finale del prodoto, in collaborazione con il team che si occupa di implementare il nuovo sistema informa9co AspeQ rilevan1 per la progeaazione del prodoao so9ware A monte del processo di progetazione e sviluppo del somware, devono essere presi in esame ed analizza9 atentamente alcuni asper che condizionano il prodoto somware stesso Scopo del progeao Contesto di business in cui si opera ObieRvi del progeto Cliente, commiaente ed altri aaori Descrizione del cliente, ossia colui che ci pagherà per il lavoro svolto Descrizione del commitente, ossia colui che ha richiesto il lavoro Altri sogger coinvol9: sponsor, altre aziende, esper9 di vario genere coinvol9 dal cliente o dal commitente Uten1 del prodoao so9ware Uten9 finali, possibilmente raggruppa9 per ruolo nell ambito del contesto di business e iden9ficando la competenza nel setore di business e in ambito informa9co Priorità degli uten9 nella valutazione del nostro lavoro Partecipazione degli uten9 al progeto (definizione dei requisi9, fornitura di informazioni cri9che per la riuscita del progeto, test, approvazione, ecc.) Uten9 adder alla ges9one del sistema (sistemis9, e altri adder) M. Liverani - Dispense del corso IN530 - Sistemi per l'elaborazione delle informazioni 5

6 AspeQ rilevan1 per la progeaazione del prodoao so9ware Vincoli obbligatori Vincoli alla soluzione (vincoli tecnici sulle carateris9che generali o sui prodor da usare o non usare) Ambiente per l implementazione (piataforma di base, framework o altri middleware da usare) Applicazioni da integrare (altri sistemi preesisten9 con cui il nostro somware si deve integrare) ProdoR di mercato o open source da u9lizzare Ambiente di lavoro in cui è impiegato il prodoto (descrizione tecnica o anche logis9ca o culturale ) Vincoli temporali (vincoli di tempo dovu9 a fatori esterni o opportunità che devono essere colte entro una determinata finestra temporale) Vincoli di budget (la pianificazione delle arvità, le risorse e il tempo impiegato devono essere defini9 tenendo conto di questo vincolo) Convenzioni sui nomi Definizioni e acronimi u9lizza9 nell ambito del progeto FaQ rilevan1 e altre assunzioni Fa8: fatori che hanno impato sul sistema, pur non cos9tuendo dei vincoli o dei requisi9 (regole di business, processi esterni al sistema, ma che possono avere impato su di esso in determinate condizioni, ecc.) Assunzioni: ipotesi verosimili che vengono assunte come veri9ere e su cui si basano alcune delle scelte di progeto; devono essere condivise con il cliente e con il commitente e non possono contraddire la realtà oggerva (es.: mi aspeto che tur gli uten9 abbiano un PC con certe carateris9che; mi aspeto che i device mobili possano essere con9nuamente connessi alla rete, ecc.) AspeQ rilevan1 per la progeaazione del prodoao so9ware Ambito in cui viene eseguito il progeao La situazione atuale (come fanno ora, senza il nostro prodoto?) Contesto in cui si inserisce il prodoto somware Business event che devono essere implementa9/supporta9 dal prodoto somware Ambito del prodoao so9ware Limi9 di competenza del prodoto somware (fino a dove deve supportare il processo di business e cosa non deve fare) Use case (casi d uso) del prodoto somware, ossia azioni auto- consisten9 da parte degli uten9 o di altri sistemi che il prodoto deve implementare o supportare M. Liverani - Dispense del corso IN530 - Sistemi per l'elaborazione delle informazioni 6

7 Definizione dei requisi1 I requisi1 del prodoto descrivono cosa il sistema deve offrire (dominio del problema) e non come il sistema deve essere sviluppato (dominio della soluzione) La correaa definizione dei requisi1 è una delle arvità che determinano la riuscita di un progeao e che talvolta si tende erroneamente a sotovalutare Applicarsi nella definizione dei requisi9 è fondamentale per darsi la possibilità di analizzare a fondo il contesto e le problema9che organizza9ve e tecniche con cui ci si dovrà misurare nell ambito del progeto I modelli di ciclo di vita del somware moderni hanno abbandonato l idea che sia possibile iden9ficare i requisi9 di un sistema somware a priori: tendono a privilegiare approcci itera1vi I requisi1 sono l elemento di riscontro per verificare se il prodoto somware è un prodoao di qualità; spesso i requisi9 del prodoto e la verifica del recepimento dei requisi9 sono un aspeto rilevante del contrato tra il commitente e l azienda che sviluppa il somware Esistono diversi 9pi di requisi9 che possono essere defini9 anche in momen9 diversi nell ambito di un progeto somware: Requisi1 funzionali: cosa fa il sistema, come deve interagire con gli uten9 o con altri sistemi Requisi1 non funzionali: da9, performance, affidabilità, ecc. Requisi1 architeaurali: prodor/piataforme che si devono o non si devono usare, strutura del sistema, ecc. Requisi1 di progeao: tempo, budget, risorse, logis9ca, ecc. Driver di progeao: obiervi organizza9vi, poli9ci, opportunità di mercato, ecc. Altri asper che caraterizzano il progeto Definizione dei requisi1 I requisi9 devono essere riporta9 su uno o più documen9 e devono poter essere iden9fica9 chiaramente e in modo sinte9co Esempio di schema per la definizione di un requisito: ID del requisito: codice iden9fica9vo univoco del requisito Tipo di requisito: funzionale, non funzionale, ecc. Business event o Use case che richiede il requisito Descrizione: breve descrizione del requisito Mo1vazione: gius9ficazione del requisito (cosa succede se non viene implementato?) Criterio di verifica: descrizione del criterio con cui si potrà verificare se il requisito è soddisfato oppure no Priorità: priorità del requisito rispeto ad altri (indispensabile o superfluo? Lo ha richiesto esplicitamente il cliente o è solo un modo per migliorare il sistema?) Dipendenze: iden9fica9vi di altri requisi9 da cui dipende questo requisito Data/versione: data di creazione o modifica del requisito I requisi9 e le dipendenze tra i requisi9 cos9tuiscono un grafo orientato (aciclico!) di cui si deve tenere conto, quando si intende modificare uno dei requisi9 del sistema Si deve poter tracciare i requisi9 in ogni componente del progeto: codice, casi di test, La tracciabilità è un aspeto di qualità di un progeto somware fondamentale per molte arvità: l analisi degli impar di un cambiamento di requisi9, la verifica della corretezza di un implementazione, il test e il regression test M. Liverani - Dispense del corso IN530 - Sistemi per l'elaborazione delle informazioni 7

8 Definizione dei requisi1 Requisi1 funzionali e sui da1 1. Requisi9 funzionali (cosa deve fare il sistema?) 2. Requisi9 grafico- funzionali (come deve presentarsi o deve reagire il sistema? Quale s9le deve adotare? Come viene garan9ta la coerenza dell interfaccia utente?) 3. Requisi9 sui da9 (un diagramma E/R, ma anche altri requisi9 rela9vi al ciclo di vita dei da9, alla loro persistenza, alla quan9tà, alla codifica, ecc.) Requisi1 sull usabilità 1. Requisi9 sulla facilità d uso 2. Requisi9 per l accesso di uten9 con disabilità o in condizioni logis9che disagevoli 3. Requisi9 per l internazionalizzazione del prodoto (prodoto mul9lingua) Requisi1 sulle performance 1. Requisi9 sulla rapidità di risposta e sulla latenza del sistema 2. Requisi9 di precisione e accuratezza (precisione numerica, precisione nelle conversioni di da9, ecc.) 3. Affidabilità e disponibilità del sistema (quali livelli di servizio deve reggere? Per quanto tempo il sistema può non essere disponibile?) 4. Fault- tolerance (condizioni di errore a cui il sistema deve poter resistere) 5. Requisi9 di capacità (capacità di memorizzazione, capacità di servire un elevato numero di client contemporanei, ecc.) 6. Requisi9 di scalabilità (capacità del sistema di crescere orizzontalmente o ver9calmente per venire incontro alla crescita delle esigenze del cliente) Definizione dei requisi1 Requisi1 sulla sicurezza 1. Requisi9 sul controllo degli accessi (chi è autorizzato ad accedere, a quali condizioni, con quali metodi di iden9ficazione, ecc.) 2. Requisi9 sull integrità dei da9 3. Requisi9 sulla privacy (quali da9 non devono essere memorizza9, chi può accedere a determina9 da9, ecc.) 4. Requisi9 di audi9ng (quali even9 devono essere traccia9 nei log del sistema, secondo quale modalità tecnica, ecc.) Requisi1 legali 1. Requisi9 sulle norma9ve a cui deve aderire il sistema (es.: ges9one delle utenze come stabilito dal DPR 196/2003) 2. Requisi9 sugli standard da adotare (formato dei da9, protocolli, ecc.) Requisi1 sulla documentazione e sulla formazione 1. Manuali e documen9 da produrre, lingua della documentazione, formato della documentazione 2. Requisi9 sui sistemi di aiuto on- line per l uso del sistema, requisi9 sul materiale didarco a supporto della formazione M. Liverani - Dispense del corso IN530 - Sistemi per l'elaborazione delle informazioni 8

9 Definizione dell architeaura La descrizione dell architeaura è un aspeto essenziale nella progetazione del somware, dal momento che ciò che viene prodoto è spesso un sistema, formato da diverse componen9 che interagiscono fra di loro I requisi9 che hanno un impato direto sull architetura del sistema e che quindi concorrono alla sua definizione, possono essere raggruppa9 sulla base della seguente classificazione FURPS : Funzionalità: il sistema deve essere capace di fornire determinate funzioni Usabilità: il sistema deve essere facilmente fruibile dall utente finale Affidabilità (Reliability): il sistema deve ges9re e possibilmente resistere ad errori e crash Prestazioni: il sistema deve avere performance adeguate Supportabilità: il sistema deve essere tale da consen9re una correta ges9one e manutenzione Definizione dell architeaura Per descrivere l architetura del sistema è necessario adotare viste diverse, fra loro complementari Vista logica organizzazione concetuale del somware in termini di stra9, sotosistemi, package, framework, classi e interfacce più importan9; in questa vista si riassumono anche le funzionalità offerte dalle componen9 somware e dai sotosistemi Può mostrare gli scenari d uso più importan9 o più cri9ci al fine di metere in evidenza il ruolo di ciascuna componente logica del somware Vista dei processi Descrive il modello del progeto e l organizzazione in processi Vista di deployment Descrive il livello fisico con cui sarà pubblicato in ambiente di produzione il sistema somware Vista sui da1 Descrive il modello di rappresentazione delle informazioni ges9te dal sistema ed i flussi di trasmissione Vista sulla sicurezza Auten9cazione degli uten9, single sign- on, modello autorizza9vo, cifratura, ecc. M. Liverani - Dispense del corso IN530 - Sistemi per l'elaborazione delle informazioni 9

10 UML: Unified Modeling Language UML è un formalismo grafico per descrivere e documentare l architeaura e le funzionalità di un sistema; è un linguaggio di modellazione e specifica basato sul paradigma object- oriented UML svolge una funzione di lingua franca nella comunità della progetazione e programmazione a ogger Il modello è struturato secondo un insieme di viste che rappresentano diversi asper del sistema modellato (funzionamento, strutura, comportamento, ecc.) UML consente di descrivere un sistema secondo tre asper principali: il modello funzionale (diagrammi dei casi d'uso) il modello a oggeq (diagrammi delle classi) il modello dinamico (diagrammi di sequenza) La documentazione del progeto è uno strumento che obbliga ad una atenta riflessione u9le per evitare di compiere errori nella successiva fase di realizzazione UML offre uno strumento di documentazione vicino e compa9bile con gli asper più tecnici di realizzazione del somware; adota inoltre un formalismo noto e comune; per ques9 due mo9vi principali ha avuto un successo notevole UML viene usato per descrivere e documentare asper assai complessi ed astrar, per cui non è di per sé sufficiente: va integrato con documentazione più descrirva o di maggiore detaglio su alcuni asper UML, modello funzionale: use case diagrams Il caso d uso (use case) è la descrizione di uno scenario elementare di u9lizzo del sistema La specifica di un caso d uso dovrebbe includere un nome, con cui iden9ficare il caso d uso gli aaori principali e secondari, ossia i sogger (umani o tecnologici) che partecipano allo scenario un obieqvo, il mo9vo per cui gli atori principali avviano il caso d uso la precondizione nella quale è eseguibile il caso d uso Lo use case diagram di UML fornisce una rappresentazione del caso d uso Sistema Sistema Autenticazione Utente <extends> chiede OTP ATore Use Case Autenticazione forte Amministratore M. Liverani - Dispense del corso IN530 - Sistemi per l'elaborazione delle informazioni 10

11 UML, modello a oggeq: class diagrams Nella programmazione object oriented la classe è il conceto fondamentale su cui si ar9cola l intero programma: descrivere corretamente le classi con i loro metodi e atribu9 e le relazioni esisten9 tra ogger di classi diverse è di cruciale importanza I class diagram forniscono una visione sta1ca delle classi presen9 in un progeto somware object oriented Il class diagram del linguaggio UML rappresenta le classi come box contenen9 gli atribu9 della classe e collegate fra loro da linee che rappresentano i diversi 9pi di relazione esisten9 tra le classi la molteplicità è un 9po di associazione in cui si mostra il numero di ogger appartenen9 ad una classe che interagisce con il numero di ogger della classe associata l ereditarietà mostra le proprietà che vengono condivise tra classe padre e classe figlio UML, modello dinamico: sequence diagram Un diagramma di sequenza (sequence diagram) descrive uno scenario, evidenziando la sequenza di azioni svolte dagli atori sul sistema (o messaggi scambia9 tra gli atori e il sistema) Uno scenario è una determinata sequenza di azioni in cui tute le scelte sono state già effetuate; in pra9ca nel diagramma non compaiono scelte, né flussi alterna9vi Normalmente da ogni ac6vity diagram sono deriva9 uno o più sequence diagram ad esempio se un ac9vity diagram descrive due flussi di azioni alterna9vi, se ne possono ricavare due scenari, e quindi due sequence diagram alterna9vi linea della vita Studente Sistema ESSE3 Docente Pubblica esame Iscrizione esame Invia notifica atore arvazione Consulta libretto esami Consulta iscrizioni Registra voti Firma verbale azioni o messaggi M. Liverani - Dispense del corso IN530 - Sistemi per l'elaborazione delle informazioni 11

12 UML, modello dinamico: ac1vity diagram Rappresenta i passi di un processo implementato da un sistema per realizzare le sue funzionalità; è un formalismo simile a quello dei diagrammi di flusso, ma può essere impiegato in contes9 di minor detaglio, più astrar In UML 2.x il formalismo degli ac-vity diagram è stato ridisegnato per seguire quello delle Re9 di Petri In un ac6vity diagram sono evidenzia9 i seguen9 elemen9: azioni decisioni (che portano a dividere il processo in più flussi dis9n9) pun9 di separazione del processo o pun9 di ricongiungimento pun9 di avvio e di conclusione del processo possono essere anche evidenzia9 gli atori responsabili di una determinata azione (creando una ibridazione con i sequence diagram) decisioni autenticaz. utente sì gestione ordine cerca prodotto gestisci carrello acquisto utente registrato? no arvità consultaz. ordine registraz. utente processi concorren9 consegna Altri diagrammi Business Process Model Nota6on (BPMN) rappresentazione e descrizione di un processo di business (workflow) Data Flow Diagram rappresentazione del flusso delle informazioni tra i diversi moduli di un sistema informa9co che si scambiano da9 atraverso aree di memoria comuni, archivi condivisi, protocolli di rete o meccanismi di interprocess communica9on State Diagram rappresenta gli sta9 in cui può trovarsi un sistema e le transizioni di stato lecite (o ges9te/ implementate dal sistema stesso) che consentono il passaggio da uno stato ad un altro M. Liverani - Dispense del corso IN530 - Sistemi per l'elaborazione delle informazioni 12

13 Ges1one della configurazione Il configura1on management supporta la ges9one ed il controllo degli elemen9 che compongono un sistema somware La ges9one di tali elemen9 (configura-on items) è affidata ad un database (repository di configurazione) in cui sono censi9 gli ogger sotopos9 a controllo di configurazione Nell'ambito del configura-on management vengono ges99 gli input/output diretamente o indiretamente lega9 alla costruzione di un prodoto somware Si archiviano in modo controllato le varie versioni del codice sorgente sviluppato, i documen9, i test, i da9 di configurazione, ecc. Una delle funzioni svolte da un sistema di controllo della configurazione (CMS, configura6on management system) è quella di correlare tra loro i vari ogger archivia9 rela9vamente alle diverse versioni o ai diversi branch di un prodoto somware Versione: è un sotoinsieme dei configura6on item che definisce completamente una release del prodoto somware; possono coesistere più versioni successive dello stesso prodoto (manutenzione correrva ed evolu9va di versioni preceden9 a quella corrente, con modifiche che sono recepite dalle versioni successive) uno stesso configura9on item può essere presente in una o più versioni del prodoto Branch: è una copia di una versione del prodoto, in modo da portare avan9 versioni diverse e indipenden9 del prodoto (le modifiche su un branch non impatano sugli altri) Ges1one della configurazione Un prodoto CMS è un somware che ges9sce un archivio di file e offre un protocollo di comunicazione per eseguire delle operazioni sul repository del prodoto somware check out: si estraggono dal repository i configura6on item e se ne produce una copia locale su cui l utente (programmatore) può lavorare update: si aggiorna il progeto locale con eventuali modifiche occorse sui configura6on item presen9 sul repository di progeto add, delete, move, copy: si aggiunge o si modifica la configurazione del progeto con elemen9 presen9 nella configurazione locale (nuovi file, eliminazione di file, ecc.) commit: si carica sul repository la copia locale del progeto (o di singoli configura6on item) lock: si blocca sul repository la modifica ad un configura6on item che è in lavorazione da parte di un utente (programmatore) sul proprio repository locale Il somware CMS rileva eventuali confliq (es.: aggiornamen9 diversi da parte di due uten9 allo stesso configura6on item) e aiuta gli uten9 del gruppo di lavoro a ges9rli Il somware CMS ad ogni aggiornamento di un configura6on item ne crea una nuova versione, mantenendo in archivio le vecchie versioni (versioning) Il somware CMS ges9sce il controllo degli accessi degli uten1 ai repository dei diversi prodor somware M. Liverani - Dispense del corso IN530 - Sistemi per l'elaborazione delle informazioni 13

14 Ges1one della configurazione Alcuni prodor somware di configura9on management CVS, concurrent version system (open source) SVN, subversions, nato come evoluzione di CVS (open source) GIT, realizzato da Linus Torvalds per il controllo di configurazione del kernel di Linux (open source) IBM Ra1onal ClearCase, componente della suite di tool di progetazione e sviluppo somware IBM Ra9onal (proprietario) Microso9 Visual SourceSafe, componente della suite di tool di sviluppo somware MicrosoM Visual Studio (proprietario) Sistemi di Ges1one per la Qualità Terminologia: ProdoAo: output di un processo di lavorazione Processo di lavorazione: un progeao per realizzare un sistema informa9co, un insieme di arvità per realizzare un prodoao, un insieme di arvità per erogare un servizio, ecc. Requisi1: caraaeris1che che ci si aspeta debba avere il prodoto ProdoAo di Qualità: ProdoAo che rispeta in pieno ai requisi1 Sistemi di Ges1one per la Qualità Complesso di procedure, regole e strumen1 (tecnici e documentali) di cui un organizzazione si dota per ges9re il processo produrvo in modo tale da realizzare prodor di qualità Si basano su alcuni principi fondamentali: DOCUMENTAZIONE: descrizione esplicita delle informazioni necessarie per la realizzazione del prodoto TRACCIABILITÀ: iden9ficare con certezza lo stato del processo, delle arvità e delle componen9 in lavorazione IDENTIFICAZIONE: possibilità di iden9ficare con certezza ogni elemento che entra a far parte del processo produrvo, rendendo eviden9 le modifiche e lo stato di aggiornamento di ciascun elemento RIPRODUCIBILITÀ: possibilità di ripetere un processo (è possibile se è documentato) MISURAZIONE: ogni arvità deve essere caraterizzata da un insieme di indicatori che consentano di misurare la qualità Norma9va internazionale che definisce i requisi9 di un buon sistema di ges9one per la qualità: UNI EN ISO 9001:2000 (ul9ma revisione: novembre 2008) M. Liverani - Dispense del corso IN530 - Sistemi per l'elaborazione delle informazioni 14

15 Sistemi di Ges1one per la Qualità Un Sistema di Ges9one per la Qualità cer9ficato secondo la norma ISO 9001 è caraterizzato da un insieme di documen9: Poli1ca per la qualità: documento con cui il top management dell azienda dichiara la mo9vazione ad adotare il sistema e le linee guida di alto livello per la definizione del sistema Organigramma funzionale e nominale: è il documento in cui si dichiara la strutura organizza9va e i ruoli Manuale della qualità: documento che descrive macroscopicamente i processi presen9 nell organizzazione e i workflow che determinano i contribu9 delle diverse figure professionali Procedure ges1onali: ogni processo macroscopico viene descrito in una procedura che evidenzia gli step e le responsabilità e indica in che modo il processo viene documentato (es.: processo selezione del personale, processo acquisto, processo progetazione e sviluppo somware, ecc.) Istruzioni opera1ve: servono per descrivere in detaglio specifiche operazioni svolte nell ambito di un processo (es.: ges9one della corrispondenza in entrata o in uscita, creazione di un nuovo ambiente di sviluppo per un progeto somware, ecc.) Modulis1ca: sono documen9 u9li per le registrazioni della qualità e per la rilevazione degli indicatori di performance Il sistema di ges9one per la Qualità si applica ad ogni progeto di sviluppo somware Per proger par9colarmente rilevan9 è possibile definire un Piano della Qualità specifico per un determinato progeto È importante definire una codifica univoca per iden1ficare i documen9 prodor nell ambito del progeto : alcune milestone degli ul6mi 50 anni di informa6ca Alcuni computer che negli ul6mi 50 anni hanno segnato dei passi in avan6 significa6vi nell evoluzione della tecnologia informa6ca M. Liverani - Dispense del corso IN530 - Sistemi per l'elaborazione delle informazioni 15

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

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

RUBRICA ERP L implementazione e la gesone di un ERP può seguire i principi dell IT Governance? L IT Governance applicata ai sistemi ERP

RUBRICA ERP L implementazione e la gesone di un ERP può seguire i principi dell IT Governance? L IT Governance applicata ai sistemi ERP RUBRICA ERP L implementazione e la gesone di un ERP può seguire i principi dell IT Governance? L IT Governance applicata ai sistemi ERP INDICE Introduzione Intervista all Ing. Paolo Di Mar!no, Responsabile

Dettagli

Gare di appalto della PA per forniture so2ware. Alessandra Donnini

Gare di appalto della PA per forniture so2ware. Alessandra Donnini Gare di appalto della PA per forniture so2ware Alessandra Donnini Premesse Forniture so2ware Punto di vista del fornitore Valutazioni qualita;ve sui documen; di gara Sono escluse le aste ele?roniche 2

Dettagli

Basi di Dati. Programmazione e gestione di sistemi telematici

Basi di Dati. Programmazione e gestione di sistemi telematici Basi di Dati. Programmazione e gestione di sistemi telematici Coordinatore: Prof. Paolo Nesi Docenti: Prof. Paolo Nesi Dr.sa Michela Paolucci Dr. Emanuele Bellini UML La prima versione ufficiale risale

Dettagli

TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE

TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE I.C.T. Information and Communication Technology TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI

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

SPECIFICHE TECNICHE DI SISTEMA TITOLO DOCUMENTO

SPECIFICHE TECNICHE DI SISTEMA TITOLO DOCUMENTO DIREZIONE EMITTENTE CONTROLLO DELLE COPIE Il presente documento, se non preceduto dalla pagina di controllo identificata con il numero della copia, il destinatario, la data e la firma autografa del Responsabile

Dettagli

Gestione Requisiti. Ingegneria dei Requisiti. Requisito. Tipi di Requisiti e Relativi Documenti. La gestione requisiti consiste in

Gestione Requisiti. Ingegneria dei Requisiti. Requisito. Tipi di Requisiti e Relativi Documenti. La gestione requisiti consiste in Ingegneria dei Requisiti Il processo che stabilisce i servizi che il cliente richiede I requisiti sono la descrizione dei servizi del sistema Funzionalità astratte che il sistema deve fornire Le proprietà

Dettagli

Introduzione al Configura1on & Source Management. Ingegneria del So-ware e Lab. Università di Modena e Reggio Emilia Do<.

Introduzione al Configura1on & Source Management. Ingegneria del So-ware e Lab. Università di Modena e Reggio Emilia Do<. Introduzione al Configura1on & Source Management Ingegneria del So-ware e Lab. Università di Modena e Reggio Emilia Do

Dettagli

Realizzazione di un applicazione per la stesura di un Business Plan

Realizzazione di un applicazione per la stesura di un Business Plan tesi di laurea Anno Accademico 2006/2007 relatore Ch.mo prof. Porfirio Tramontana candidato Vincenzo Malzone Matr. 534/1173 Obiettivi Realizzare un applicazione desktop per la stesura di un documento di

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

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

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

Progettaz. e sviluppo Data Base

Progettaz. e sviluppo Data Base Progettaz. e sviluppo Data Base! Introduzione ai Database! Tipologie di DB (gerarchici, reticolari, relazionali, oodb) Introduzione ai database Cos è un Database Cos e un Data Base Management System (DBMS)

Dettagli

Processo parte VII. Strumenti. Maggiore integrazione. Sviluppo tecnologico

Processo parte VII. Strumenti. Maggiore integrazione. Sviluppo tecnologico Strumenti Processo parte VII Leggere Cap. 9 Ghezzi et al. Strumenti software che assistono gli ingegneri del software in tutte le fasi del progetto; in particolare progettazione codifica test Evoluzione

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

Soluzioni e Proge-! Datakey Software Engineering Srl 1

Soluzioni e Proge-! Datakey Software Engineering Srl 1 Soluzioni e Proge- 1 Datakey 30 anni di SoSware Datakey nasce Nel 1985, avente ad ogge0o l a2vità di proge0azione di servizi informa:ci opera trasformazioni orientate alla crescita; E cer:ficata ISO 9001

Dettagli

ASSEGNA LE SEGUENTI COMPETENZE ISTITUZIONALI AGLI UFFICI DELLA DIREZIONE GENERALE OSSERVATORIO SERVIZI INFORMATICI E DELLE TELECOMUNICAZIONI:

ASSEGNA LE SEGUENTI COMPETENZE ISTITUZIONALI AGLI UFFICI DELLA DIREZIONE GENERALE OSSERVATORIO SERVIZI INFORMATICI E DELLE TELECOMUNICAZIONI: IL PRESIDENTE VISTO il decreto legislativo 12 aprile 2006, n. 163 e successive modifiche ed integrazioni, in particolare l art. 8, comma 2, ai sensi del quale l Autorità stabilisce le norme sulla propria

Dettagli

Ingegneria del Software - Il Ciclo Lungo

Ingegneria del Software - Il Ciclo Lungo Ingegneria del Software - Il Ciclo Lungo Alessandro Martinelli alessandro.martinelli@unipv.it 10 Marzo 2014 Il Ciclo Lungo Il Versioning e la Condivisione di Codice Organizzazione dei Pacchetti La Modellazione

Dettagli

SISTEMA E-LEARNING INeOUT

SISTEMA E-LEARNING INeOUT SISTEMA E-LEARNING INeOUT AMBIENTE OPERATIVO 1 Premesse metodologiche La complessità di un sistema informatico dipende dall aumento esponenziale degli stati possibili della sua architettura. Se è vero

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

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

7. Esigenze informative e FAQ. 8. Allegati. Repository documentale.

7. Esigenze informative e FAQ. 8. Allegati. Repository documentale. Titolo Documento: Specifica customer service e knowledge base Codice Documento e versione template: MR CRZ 17 - v2.0 Repository documentale. I contenuti relativi al sistema/servizio possono essere di varia

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

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica A.A. 2007-08 CORSO DI INGEGNERIA DEL SOFTWARE Prof. Giulio Destri http://www.areasp.com (C) 2007 AreaSP for

Dettagli

Università degli Studi di Salerno Ingegneria del Software: Tecniche Avanzate

Università degli Studi di Salerno Ingegneria del Software: Tecniche Avanzate Università degli Studi di Salerno Ingegneria del Software: Tecniche Avanzate Mystic Pizza Gestione Pizzeria Scheda di Progetto Version 1.0 Data 19/03/2007 Indice degli argomenti 1. Introduzione 3 a. Scenario

Dettagli

TECNOLOGIE DELL INFORMAZIONE E DELLA COMUNICAZIONE PER LE AZIENDE

TECNOLOGIE DELL INFORMAZIONE E DELLA COMUNICAZIONE PER LE AZIENDE TECNOLOGIE DELL INFORMAZIONE E DELLA COMUNICAZIONE PER LE AZIENDE Materiale di supporto alla didattica Tecnologie dell informazione e della comunicazione per le aziende CAPITOLO 3: Progettazione e sviluppo

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

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

Introduzione. Il software e l ingegneria del software. Marina Mongiello Ingegneria del software 1

Introduzione. Il software e l ingegneria del software. Marina Mongiello Ingegneria del software 1 Introduzione Il software e l ingegneria del software Marina Mongiello Ingegneria del software 1 Sommario Il software L ingegneria del software Fasi del ciclo di vita del software Pianificazione di sistema

Dettagli

Product Overview. ITI Apps Enterprise apps for mobile devices

Product Overview. ITI Apps Enterprise apps for mobile devices Product Overview ITI Apps Enterprise apps for mobile devices ITI idea, proge2a e sviluppa apps per gli uten6 business/enterprise che nell ipad, e nelle altre pia2aforme mobili, possono trovare un device

Dettagli

OGGETTO DELLA FORNITURA...4

OGGETTO DELLA FORNITURA...4 Gara d appalto per la fornitura di licenze software e servizi per la realizzazione del progetto di Identity and Access Management in Cassa Depositi e Prestiti S.p.A. CAPITOLATO TECNICO Indice 1 GENERALITÀ...3

Dettagli

EQDL Start. Approccio per processi. Temi: Individuazione e descrizione dei processi. Syllabus da 3.1.3.1 a 3.1.3.6

EQDL Start. Approccio per processi. Temi: Individuazione e descrizione dei processi. Syllabus da 3.1.3.1 a 3.1.3.6 EQDL Start Approccio per Temi: Individuazione e descrizione dei Syllabus da 3.1.3.1 a 3.1.3.6 La patente europea della Qualità - EQDL START European Quality Driving Licence MOD 3 Start: APPROCCIO PER PROCESSI

Dettagli

Centro Nazionale per l Informatica nella Pubblica Amministrazione. Gara a procedura aperta n. 1/2007. per l appalto dei

Centro Nazionale per l Informatica nella Pubblica Amministrazione. Gara a procedura aperta n. 1/2007. per l appalto dei Centro Nazionale per l Informatica nella Pubblica Amministrazione Gara a procedura aperta n. 1/2007 per l appalto dei Servizi di rilevazione e valutazione sullo stato di attuazione della normativa vigente

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

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

Concetti di base di ingegneria del software

Concetti di base di ingegneria del software Concetti di base di ingegneria del software [Dalle dispense del corso «Ingegneria del software» del prof. A. Furfaro (UNICAL)] Principali qualità del software Correttezza Affidabilità Robustezza Efficienza

Dettagli

Anno Scolastico: 2014/2015. Indirizzo: Sistemi informativi aziendali. Classe quarta AS. Disciplina: Informatica. prof.

Anno Scolastico: 2014/2015. Indirizzo: Sistemi informativi aziendali. Classe quarta AS. Disciplina: Informatica. prof. Anno Scolastico: 2014/2015 Indirizzo: Sistemi informativi aziendali Classe quarta AS Disciplina: Informatica prof. Competenze disciplinari: Secondo biennio 1. Identificare e applicare le metodologie e

Dettagli

Software di sistema e software applicativo. I programmi che fanno funzionare il computer e quelli che gli permettono di svolgere attività specifiche

Software di sistema e software applicativo. I programmi che fanno funzionare il computer e quelli che gli permettono di svolgere attività specifiche Software di sistema e software applicativo I programmi che fanno funzionare il computer e quelli che gli permettono di svolgere attività specifiche Software soft ware soffice componente è la parte logica

Dettagli

So.ware. Insieme di programmi che perme6ono al calcolatore di eseguire determinate funzionalità Si dis,ngue tra:

So.ware. Insieme di programmi che perme6ono al calcolatore di eseguire determinate funzionalità Si dis,ngue tra: Sistemi opera,vi So.ware Insieme di programmi che perme6ono al calcolatore di eseguire determinate funzionalità Si dis,ngue tra: So.ware di sistema: Sistema Opera,vo So.ware applica,vo: Applicazioni Programma

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

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

Modello OAIS. Modello di riferimento. Il Modello. Prof.ssa E. Gentile a.a. 2011-2012. Un modello di riferimento dovrebbe descrivere:

Modello OAIS. Modello di riferimento. Il Modello. Prof.ssa E. Gentile a.a. 2011-2012. Un modello di riferimento dovrebbe descrivere: Modello OAIS Prof.ssa E. Gentile a.a. 2011-2012 Prof.ssa E. Gentile Progettazione e Produzione di Contenuti Digitali 1 Modello di riferimento Un modello di riferimento dovrebbe descrivere: le componenti

Dettagli

Ingegneria del Software Requisiti e Specifiche

Ingegneria del Software Requisiti e Specifiche Ingegneria del Software Requisiti e Specifiche Obiettivi. Affrontare i primi passi della produzione del software: la definizione dei requisiti ed il progetto architetturale che porta alla definizione delle

Dettagli

Document Management DOMA PRESENTAZIONE

Document Management DOMA PRESENTAZIONE Document Management DOMA PRESENTAZIONE INDICE 0 DEFINIZIONI E ACRONIMI...3 1 PARTE INTRODUTTIVA...5 1.1 COSA È DO.MA....5 1.2 ARCHITETTURA FUNZIONALE...7 1.3 MODELLO DELLA SICUREZZA...8 1.4 LOGICA DI ARCHIVIAZIONE...8

Dettagli

Copyright Università degli Studi di Torino, Progetto Atlante delle Professioni 2009 IT PROCESS EXPERT

Copyright Università degli Studi di Torino, Progetto Atlante delle Professioni 2009 IT PROCESS EXPERT IT PROCESS EXPERT 1. CARTA D IDENTITÀ... 2 2. CHE COSA FA... 3 3. DOVE LAVORA... 4 4. CONDIZIONI DI LAVORO... 5 5. COMPETENZE... 6 Quali competenze sono necessarie... 6 Conoscenze... 8 Abilità... 9 Comportamenti

Dettagli

STRONG AUTHENTICATION VIA SMS Come aumentare sicurezza e privacy in modo semplice e a basso costo. Claudio Zanaroli Sales Manager Skebby

STRONG AUTHENTICATION VIA SMS Come aumentare sicurezza e privacy in modo semplice e a basso costo. Claudio Zanaroli Sales Manager Skebby STRONG AUTHENTICATION VIA SMS Come aumentare sicurezza e privacy in modo semplice e a basso costo Claudio Zanaroli Sales Manager Skebby 1 Agenda E-Commerce Forum 21 Aprile 2015 ü Cos è la Strong Authentication

Dettagli

COMPA Bologna 7/8/9 novembre 2006. ITIL / CMDBuild: un esempio di progetto di BPR e riuso in ambito ICT

COMPA Bologna 7/8/9 novembre 2006. ITIL / CMDBuild: un esempio di progetto di BPR e riuso in ambito ICT COMPA Bologna 7/8/9 novembre 2006 ITIL / CMDBuild: un esempio di progetto di BPR e riuso in ambito ICT 1 Motivazioni del progetto (1) Il Servizio Sistemi Informativi e Telematici del Comune di Udine è

Dettagli

Scope Management. IT Project Management. Lezione 3 Scope Management. Monitoring del progetto (Earned Value) Creazione diagrammi Pert/CPM/Gantt

Scope Management. IT Project Management. Lezione 3 Scope Management. Monitoring del progetto (Earned Value) Creazione diagrammi Pert/CPM/Gantt IT Project Management Lezione 3 Scope Management Federica Spiga A.A. 2009-2010 1 Check list del PM Identificare i requisiti del cliente Monitoring del progetto (Earned Value) Identificare i deliverable

Dettagli

Prova Finale Controllo delle versioni

Prova Finale Controllo delle versioni Prova Finale Controllo delle versioni 1 Controllo delle versioni: a cosa serve? Tenere traccia dei cambiamenti Semplificare la collaborazione Gestione di diverse diramazioni (branch) di sviluppo Differen3

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

Donato Ma(urro Marke'ng & Web Communica'on Consultant

Donato Ma(urro Marke'ng & Web Communica'on Consultant Donato Ma(urro Marke'ng & Web Communica'on Consultant Presidente Associazione Joomla!lombardia Ceo & founder E-mail: presidente@joomlalombardia.org Web: www.joomlalombardia.org Premessa: Considerato che:

Dettagli

"Sanità Ele,ronica e Innovazione delle Re5"

Sanità Ele,ronica e Innovazione delle Re5 Angelo Lino Del Favero Presidente Angelo di Lino Federsanità Del Favero ANCI Dire9ore Is:tuto Superiore di Sanità Presidente di Federsanità ANCI Direttore Istituto Superiore di Sanità Slide 1 "Sanità Ele,ronica

Dettagli

SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB

SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB Relatore Chiarissimo

Dettagli

PROGETTO SOCIALE D INIZIATIVA WIN (WELLFARE DI INIZIATIVA).

PROGETTO SOCIALE D INIZIATIVA WIN (WELLFARE DI INIZIATIVA). PROGETTO SOCIALE D INIZIATIVA WIN (WELLFARE DI INIZIATIVA). Ing Paolo Neri 4 Settembre 2014 Associazione Vecchie e Nuove Povertà Empoli IL «PROGETTO SOCIALE D INIZIATIVA» Missione: favorire l uscita dal

Dettagli

Caso di Studio: Avant Dernier

Caso di Studio: Avant Dernier Caso di Studio: Avant Dernier Specifiche: Nel gioco si affrontano 4 giocatori, ciascuno individuato con un numero progressivo (da 1 a 4). Inizialmente, i giocatori ricevono 5 carte ciascuno, e una carta

Dettagli

PROCEDURA PR.07/03. Progettazione e sviluppo software STATO DI REVISIONE. Verificato da

PROCEDURA PR.07/03. Progettazione e sviluppo software STATO DI REVISIONE. Verificato da PROCEDURA PR.07/03 Progettazione e sviluppo software STATO DI REVISIONE NUMERO REVISIONE DATA Emesso da DT Fabio 0 15/07/03 Matteucci 1 22/12/03 Fabio Matteucci 2 Verificato da Rappresentante della Direzione

Dettagli

Software project management. www.vincenzocalabro.it

Software project management. www.vincenzocalabro.it Software project management Software project management Sono le attività necessarie per assicurare che un prodotto software sia sviluppato rispettando le scadenze fissate rispondendo a determinati standard

Dettagli

La Soluzione per CdA e Top Management. La soluzione è Secure Board by Boole Server

La Soluzione per CdA e Top Management. La soluzione è Secure Board by Boole Server La Soluzione per Fusioni e acquisizioni, changing management, pianificazione e sviluppo del business, la documentazione correlata ai consigli di amministrazione, il corretto utilizzo dei documenti riservati

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

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

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014 Processi di business sovra-regionali relativi ai sistemi regionali di FSE Versione 1.0 24 Giugno 2014 1 Indice Indice... 2 Indice delle figure... 3 Indice delle tabelle... 4 Obiettivi del documento...

Dettagli

Base di dati e sistemi informativi

Base di dati e sistemi informativi Base di dati e sistemi informativi Una base di dati è un insieme organizzato di dati opportunamente strutturato per lo svolgimento di determinate attività La base di dati è un elemento fondamentale per

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

DISCIPLINE CONCORRE NTI CONOSCENZE UDA DISCIPLINA DI RIFERIMENTO UDA

DISCIPLINE CONCORRE NTI CONOSCENZE UDA DISCIPLINA DI RIFERIMENTO UDA UDA ISTITUTO TECNICO INDUSTRIALE ITI "E. MEDI" PIANO DI STUDIO DELLA DISCIPLINA TECNOLOGIE E PROGETTAZIONE DI SISTEMI INFORMATICI E DI TELECOMUNICAZIONI PIANO DELLE UDA 3 /Inf. prof. COMPETENZE della UDA

Dettagli

Sistema di spedizione per azienda logistica LBDS

Sistema di spedizione per azienda logistica LBDS CONFIGURATION MANAGEMENT PLAN Sistema di spedizione per azienda logistica LBDS Gruppo Laboratorio di Ingegneria del Software 2 Anno Accademico2009/2010 Gruppo Kairos: Maiero Matteo, Bertoni Alan, Zolli

Dettagli

Concepire un ambiente in grado di offrire le seguenti possibilità in modo semplice ed accattivante:

Concepire un ambiente in grado di offrire le seguenti possibilità in modo semplice ed accattivante: MULTIMEDIA 1 2 TELEMATICA AE Concepire un ambiente in grado di offrire le seguenti possibilità in modo semplice ed accattivante: Disegnare un modello elettronico di qualunque tipo e renderlo editabile

Dettagli

Corso di Progettazione di sistemi multimediali

Corso di Progettazione di sistemi multimediali Corso di Progettazione di sistemi multimediali prof. Pierluigi Feliciati a.a.2012/13 Modulo 0 Progettare, sistemi, multimedialità: Definizioni, strumenti, ciclo di vita dei progetti, figure professionali

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

SCHEDULAZIONI RIEPILOGATIVE E CONFRONTO DI: - FASI E ATTIVITA' DEL WBS; - PRODOTTI; - COMPITI; - RISORSE PROFESSIONALI; - EFFORT.

SCHEDULAZIONI RIEPILOGATIVE E CONFRONTO DI: - FASI E ATTIVITA' DEL WBS; - PRODOTTI; - COMPITI; - RISORSE PROFESSIONALI; - EFFORT. Cod. Figure professionali q.tà gg.uu. Riepilogo di Progetto 1.092 SCHEDULAZIONI RIEPILOGATIVE E CONFRONTO DI: - FASI E ATTIVITA' DEL WBS; - PRODOTTI; - COMPITI; - RISORSE PROFESSIONALI; - EFFORT. 001 Comitato

Dettagli

Gli strumen, social e l usabilità al servizio della scuola. Da MatchPoint a La Buona Scuola

Gli strumen, social e l usabilità al servizio della scuola. Da MatchPoint a La Buona Scuola Gli strumen, social e l usabilità al servizio della scuola Da MatchPoint a La Buona Scuola premessa Social media: tecnologie online che le persone u7lizzano per interagire e condividere contenu7 Potenzialmente

Dettagli

DOMOTICA Fonte:Manuale illustrato per la domo8ca ad uso sociale.tecniche nuove

DOMOTICA Fonte:Manuale illustrato per la domo8ca ad uso sociale.tecniche nuove La Domo'ca è la disciplina che studia e consente la ges'one semplice, sicura, organica e sostenibile degli impian' e dei disposi'vi presen' nelle case, migliorando la qualità della vita dei suoi abitan'.

Dettagli

Piattaforma Informatica di Knowledge Risk

Piattaforma Informatica di Knowledge Risk Piattaforma Informatica di Knowledge Risk La guida sicura per la certificazione e la conformità 2012 1 IL CONCETTO INNOVATIVO PI-KR E UNA SOLUZIONE INTEGRATA PER I SISTEMI DI GESTIONE E DI GOVERNO AZIENDALE

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

Esercizi UML. Angelo Di Iorio

Esercizi UML. Angelo Di Iorio Esercizi UML Angelo Di Iorio Esercizio 1 Disegnare un diagramma dei casi d uso rela9vo ad una biglie

Dettagli

JSIS JSIS L architettura JSIS

JSIS JSIS L architettura JSIS JSIS JSIS L architettura JSIS La piattaforma JSIS Java Solution Integrated Suites, interamente realizzata dai nostri laboratori di sviluppo software, è una soluzione che integra la gestione di diverse

Dettagli

La soluzione software per CdA e Top Management

La soluzione software per CdA e Top Management La soluzione software per CdA e Top Management DATI E DOCUMENTI PROTETTI Sempre. Ovunque. La Soluzione per Quando si parla di fusioni e acquisizioni, di cambiamenti di gestione, di pianificazione o di

Dettagli

Rischio, formazione professionale e ges3one di proge5: la natura complessa del conce9o di rischio e della sua valutazione in due esperienze reali

Rischio, formazione professionale e ges3one di proge5: la natura complessa del conce9o di rischio e della sua valutazione in due esperienze reali Rischio, formazione professionale e ges3one di proge5: la natura complessa del conce9o di rischio e della sua valutazione in due esperienze reali Marco Cremonini Dipar.mento di Informa.ca Università degli

Dettagli

5. Requisiti del Software II

5. Requisiti del Software II 5. Requisiti del Software II Come scoprire cosa? Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 5. Requisiti del Software II 1 / 22 Sommario 1 Generalità

Dettagli

LIBERA L EFFICIENZA E LA COMPETITIVITÀ DEI TUOI STRUMENTI! Open Solutions, Smart Integration

LIBERA L EFFICIENZA E LA COMPETITIVITÀ DEI TUOI STRUMENTI! Open Solutions, Smart Integration LIBERA L EFFICIENZA E LA COMPETITIVITÀ DEI TUOI STRUMENTI! Open Solutions, Smart Integration COSA FACCIAMO SEMPLIFICHIAMO I PROCESSI DEL TUO BUSINESS CON SOLUZIONI SU MISURA EXTRA supporta lo sviluppo

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

GESTIONE DI PROGETTO E ORGANIZZAZIONE DI IMPRESA

GESTIONE DI PROGETTO E ORGANIZZAZIONE DI IMPRESA GESTIONE DI PROGETTO E ORGANIZZAZIONE DI IMPRESA Il project management nella scuola superiore di Antonio e Martina Dell Anna 2 PARTE II ORGANIZZAZIONE DEL PROGETTO UDA 4 IL TEAM DI PROGETTO LEZIONE: IL

Dettagli

Cosa è un Sistema Informativo. Introduzione ai sistemi informativi. Tipici esempi di sistemi informativi. Cosa è un Sistema Informatico

Cosa è un Sistema Informativo. Introduzione ai sistemi informativi. Tipici esempi di sistemi informativi. Cosa è un Sistema Informatico Introduzione ai sistemi informativi Cosa è un Sistema Informativo Insieme degli strumenti, risorse e procedure che consentono la gestione delle informazioni aziendali è essenziale per il funzionamento

Dettagli

IL SOFTWARE SECONDO LA NORMA UNI EN ISO 13849-1:2008 (IIA PARTE) 1

IL SOFTWARE SECONDO LA NORMA UNI EN ISO 13849-1:2008 (IIA PARTE) 1 Ernesto Cappelletti (ErnestoCappelletti) IL SOFTWARE SECONDO LA NORMA UNI EN ISO 13849-1:2008 (IIA PARTE) 6 April 2012 1. Requisiti per la scrittura del software secondo la norma UNI EN ISO 13849-1:2008

Dettagli

PROCEDURA 4.1 Gestione della documentazione e delle registrazioni. Redazione (referente di processo) Responsabile Sistema Qualità (RSG)

PROCEDURA 4.1 Gestione della documentazione e delle registrazioni. Redazione (referente di processo) Responsabile Sistema Qualità (RSG) PROCEDURA 4.1 Gestione della documentazione e delle registrazioni Ed.2 Rev.0 del 22/07/2014 Redazione (referente di processo) Approvazione Andrea Marchesi Responsabile Sistema Qualità (RSG) Silvio Braini

Dettagli

The ITIL Foundation Examination

The ITIL Foundation Examination The ITIL Foundation Examination Esempio di Prova Scritta A, versione 5.1 Risposte Multiple Istruzioni 1. Tutte le 40 domande dovrebbero essere tentate. 2. Le risposte devono essere fornite negli spazi

Dettagli

TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE

TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE I.C.T. Information and Communication Technology TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI DESCRIZIONE

Dettagli

Mutui Connect La piattaforma informativa per l erogazione e la portabilità dei mutui

Mutui Connect La piattaforma informativa per l erogazione e la portabilità dei mutui Mutui Connect La piattaforma informativa per l erogazione e la portabilità dei mutui Vincenzo Gunnella Notaio Angelo Peppetti - ABI Organo collegiale Mutui Conncet 1 dicembre 2014 Ø La collaborazione ABI

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

PS_01 PROCEDURA PER LA GESTIONE DEI DOCUMENTI E DELLE REGISTRAZIONI

PS_01 PROCEDURA PER LA GESTIONE DEI DOCUMENTI E DELLE REGISTRAZIONI Pagina 1 di 8 PS_01 PROCEDURA PER LA GESTIONE DEI DOCUMENTI E DELLE REGISTRAZIONI STATO DEL DOCUMENTO REV. PAR. PAG. MOTIVO DATA 00 - - Emissione documento 31.05.2013 Responsabile Area Servizi per la Didattica

Dettagli

Dettaglio dei corsi in aula

Dettaglio dei corsi in aula L offerta formativa Dettaglio dei corsi in aula Software Engineering Object Oriented Analysis and Design: fondamenti e principi dell object orientation. Dall analisi alla progettazione. I Design Pattern.

Dettagli

ALL. C AFFIDAMENTO AI SENSI DELL ART. 125, COMMI 10 E 11, DEL D.LGS. 163/2006 E S.M.I. DELLA PROGETTAZIONE E REALIZZAZIONE DI UN

ALL. C AFFIDAMENTO AI SENSI DELL ART. 125, COMMI 10 E 11, DEL D.LGS. 163/2006 E S.M.I. DELLA PROGETTAZIONE E REALIZZAZIONE DI UN ALL. C AFFIDAMENTO AI SENSI DELL ART. 125, COMMI 10 E 11, DEL D.LGS. 163/2006 E S.M.I. DELLA PROGETTAZIONE E REALIZZAZIONE DI UN PORTALE WEB NELL AMBITO DELLA MISURA 2.6. DEL POI ENERGIA FESR 2007 2013

Dettagli

Progetto n.1: Student s Magazine 2.0

Progetto n.1: Student s Magazine 2.0 Progetto n.1: Student s Magazine 2.0 Requisiti Lo Student s Magazine 2.0 è un magazine on line a gestione distribuita. Non c è un organizzazione centrale, tutti gli utenti possono essere giornalisti e

Dettagli

Il ciclo di progetto focus su. Fase di Pianificazione o Formulazione Work Breakdown Structure Diagramma di GANTT Diagramma di PERT

Il ciclo di progetto focus su. Fase di Pianificazione o Formulazione Work Breakdown Structure Diagramma di GANTT Diagramma di PERT Il ciclo di progetto focus su Fase di Pianificazione o Formulazione Work Breakdown Structure Diagramma di GANTT Diagramma di PERT analisi periodica e finale di: efficienza, efficacia, impatto atteso, sostenibilità

Dettagli

-Sistemi per il rilevamento di flussi di persone- Progetto:

-Sistemi per il rilevamento di flussi di persone- Progetto: -Sistemi per il rilevamento di flussi di persone- Progetto: Sistema per il rilevamento e l analisi dei flussi dei clienti in un megastore di 1 piano di 1250m 2, composto da 20 corsie di 1m di lunghezza

Dettagli

SAP Business Objects XI R3.1

SAP Business Objects XI R3.1 SAP Business Objects XI R3.1 Sistemi Informa;vi Avanza; Anno Accademico 2012/2013 Corso di Laurea Magistrale in Ingegneria Ges3onale Reggio Emilia, 12 aprile 2013 UNIVERSITÀ DEGLI STUDI DI MODENA E REGGIO

Dettagli

MANUALE INTRODUTTIVO

MANUALE INTRODUTTIVO MANUALE INTRODUTTIVO Scaricamento da internet e installazione Fenice è liberamente disponibile su internet, all indirizzo h#p://www.fenicex.it/downloads.html, cliccando sul pulsante Download posto sulla

Dettagli

Configuration Management

Configuration Management Configuration Management Obiettivi Obiettivo del Configuration Management è di fornire un modello logico dell infrastruttura informatica identificando, controllando, mantenendo e verificando le versioni

Dettagli

Introduzione alla ges0one delle risorse umane

Introduzione alla ges0one delle risorse umane Introduzione alla ges0one delle risorse umane Logiche, principi, a/ori Marco Briolini Cos è la ges5one delle risorse umane Strategia e ges5one Il modello di riferimento: i principi della ges5one le dimensioni

Dettagli