Roger S. Pressman, Principi di Ingegneria del software, a cura di M. Cerioli e G. Reggio, Copyright The McGraw-Hill Companies Srl

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Roger S. Pressman, Principi di Ingegneria del software, a cura di M. Cerioli e G. Reggio, Copyright 2008 - The McGraw-Hill Companies Srl"

Transcript

1 Soluzioni CAPITOLO 1 IL SOFTWARE E L INGEGNERIA DEL SOFTWARE 1.1 Chi avrebbe pensato che il software avrebbe indotto cambiamenti in: (1) modalità di corteggiamento (appuntamenti e conoscenze via Internet); (2) tipologia di comunicazione fra persone (telefoni cellulari); (3) metodologie belliche (armi cibernetiche); (4) diagnostica (TAC ed altre simili apparecchiature basate sui computer), e (5) acquisizione e fruizione di musica ed altre forme di intrattenimento (musica, DVD, itunes, etc.). 1.2 Questo è un buon problema per le discussioni in aula (se si trova il tempo). Invece di focalizzarsi su argomenti ben noti ed abusati (per quanto importanti e fondamentali), quali la privacy, la qualità della vita, ecc., potrebbe essere interessante discutere le paranoie tecnologiche e come il software possa contribuire ad esacerbarle o placarle. Un altra possibilità interessante è usare un articolo recente dalla Inside Risks Columns di Neumann (http://www.csl.sri.com/users/neumann/insiderisks.html) per focalizzare la discussione. Si potrebbero anche discutere nuove proposte di mercati economici e valute virtuali, nuovi modelli di intrattenimento interattivo, realtà virtuali, commercio elettronico ecc. 1.3 La realizzazione di un programma richiede tempi così lunghi perché a. Gli strumenti e l ambiente di sviluppo non sono disponibili online. b. Gli strumenti di sviluppo non funzionano come ci si aspettava. c. Il cliente pretende nuovi requisiti che a loro volta impongono di ripetere il design e lo sviluppo. d. Il prodotto dipende da regolamenti e leggi che cambiano inaspettatamente. e. Requisiti stringenti di compatibilità con sistemi preesistenti richiedono un maggiore sforzo di test, design ed implementazione rispetto a quanto previsto. f. Requisiti di operabilità su diverse piattaforme e sistemi operativi richiedono più tempo del previsto per essere soddisfatti. g. La gestione dei rischi del progetto software richiede più tempo del previsto. h. La necessità di impiegare nel progetto una tecnologia innovativa ancora in via di sviluppo allunga i tempi previsti. I costi di sviluppo sono così elevati perché a. Un livello inaccettabilmente basso di qualità richiede rielaborazioni (del design, dell implementazione e nuovo testing) inattese. b. Lo sviluppo di funzionalità sbagliate (rispetto alle aspettative del cliente) richiede di ripetere il design e/o l implementazione. c. Lo sviluppo di interfacce sbagliate (rispetto alle aspettative del cliente) richiede di ripetere il design e/o l implementazione.

2 d. Lo sviluppo di funzionalità ulteriori e non richieste prolunga lo schedule. Non è possibile individuare tutti gli errori prima di consegnare il prodotto perché a. Il prodotto dipende da regolamenti e leggi che cambiano inaspettatamente. b. Il prodotto dipende da standard tecnici, non ancora stabilizzati ufficialmente che cambiano inaspettatamente. c. Nuovo personale di sviluppo viene inserito a progetto già avanzato senza le dovute cautele. d. All interno del team di sviluppo si creano conflitti che producono scarsa comunicazione e quindi design di bassa qualità. e. Chi dovrebbe gestire il progetto lo sabota (anche non intenzionalmente) con schedule inefficiente e pianificazione inefficace. f. I componenti acquisiti sono di bassa qualità e richiedono ulteriori sforzi in design, extra testing e lavoro di integrazione, nonché in gestione della relazione col cliente. Occorre dedicare tanto tempo e impegno alla manutenzione dei programmi esistenti perché a. In molti casi i programmi sono indispensabili al buon funzionamento della ditta. b. Gli utenti sono abituati ad un prodotto e non vogliono cambiarlo con uno più moderno. c. Lo sforzo economico per sostituire il sistema non può essere sostenuto in un dato momento, mentre la manutenzione risulta più economica sul breve periodo. d. La tecnologia evolve rapidamente ed il sistema deve essere aggiornato per non diventare obsoleto. Continua a essere difficile misurare i progressi dello sviluppo del software perché a. Non sempre lo scopo del progetto è chiaro. b. Vi sono molti rischi gestionali coinvolti. c. Lo scope del progetto non è ben definito. d. Tutte le attività si ripetono iterativamente, cosicché non è banale capire quali sono i task da svolgere e in quale momento. e. Manca un buon meccanismo di monitoraggio del progetto. f. I membri del team si rifiutano di fornire lo stato di avanzamento. 1.4 La definizione di software presentata nel Paragrafo 1.2 si applica anche ai siti Web. Vi sono tuttavia delle differenze sottili fra un sito Web ed un software convenzionale. Una delle più notevoli è che i contenuti presentati da un sito Web vengono considerati parte dell applicazione Web, mentre usualmente i dati elaborati dal software convenzionale si considerano distinti dalle funzioni offerte dal software.

3 1.5 Molte applicazioni moderne cambiano più volte prima di essere presentate al cliente ed anche dopo che la prima versione è entrata in uso. Alcune tecniche per costruire software in modo da evitare che si deteriori con le modifiche (o quanto meno limitarne i peggioramenti) potrebbero essere: Assicurarsi che la progettazione del software garantisca che i cambi in una parte del programma non abbiano effetti indesiderati in altre parti. Assicurarsi che il software sia progettato in modo da evitare dipendenze esterne da altri sistemi o apparecchiature con alta probabilità di cambiamenti futuri. Assicurarsi di archiviare i test case ed i relativi risultati in modo che sia agevole riusarli nella fase dei test del software modificato. Assicurarsi di avere capito a fondo le esigenze del cliente. 1.6 Lo stesso approccio all ingegneria del software può essere applicato ad ognuna delle categorie, ma deve essere adattato per soddisfare i requisiti specifici di ciascuna di esse. 1.7 Ciascuna di queste nuove sfide indubitabilmente seguirà la Legge delle Conseguenze inattese ed avrà effetti (sui commerciali,gli ingegneri software e gli utenti finali) che non si possono prevedere ora. Tuttavia gli ingegneri software possono prepararsi adottando un processo sufficientemente agile ed adattabile da poter gestire drammatici cambiamenti nella tecnologia o nelle regole business che inevitabilmente si presenteranno nella prossima decade. A.I. Dopo quasi 40 anni di false partenze, l intelligenza artificiale (AI, per Artificial Intelligence) sta finalmente diventando un successo tecnologico ed industriale. Attualmente si possiede un arsenale di tecniche per la costruzione di programmi che controllano processi manifatturieri, diagnosticano fault nei computer e malattie negli esseri umani,progettano computer, giocano a scacchi e così via. In associazione con il riconoscimento vocale e l incredibile capacità di calcolo delle macchine moderne, molto probabilmente le applicazioni di AI diventeranno sempre più umane col passare degli anni. Vi saranno, inevitabilmente, conseguenze inattese. 1.8 La legge della conservazione della stabilità organizzativa: il tasso medio di attività effettiva globale è invariante durante tutto il ciclo di vita del software. 1.9 La legge della conservazione della familiarità: durante l evoluzione del sistema tutte le figure coinvolte, utenti, ingegneri software, sviluppatori, devono avere una conoscenza completa dei suoi contenuti e behavior per ottenere risultati soddisfacenti. Un eccessivo aumento del tasso di crescita può diminuire tale conoscenza (padronanza); pertanto il tasso medio di crescita rimane invariante durante l evoluzione del sistema La legge della riduzione della qualità: la qualità dei sistemi tende a diminuire a meno che non vengano mantenuti mediante apposite procedure per adattarli ai cambiamenti dell ambiente. Questo concetto è analogo al deterioramento discusso nei problemi Gli esempi della vita reale fra cui scegliere sono letteralmente dozzine. Ad

4 esempio, gli errori software che hanno causato il fallimento delle principali reti telefoniche, i fallimenti nell industria aeronautica che hanno contribuito alle catastrofi aeree, i virus informatici (ad esempio Michelangelo, Slammer, o Code red) che hanno causato ingenti danni economici e attacchi ad importanti siti di e- commerce Le due categorie più ampie raccolgono i rischi economici e quelli che mettono in pericolo il benessere e la salute degli individui. Potrebbe essere una buona idea scegliere (dalle fonti suggerite) 5 rischi e discuterli in aula. È meglio selezionare alcuni rischi seri ed altri più ridicoli e divertenti.

5 Soluzioni CAPITOLO 2 PANORAMICA SUL PROCESSO 2.1 a. I progettisti dovrebbero chiedere agli utenti: o Che cosa vuoi che faccia questo prodotto? o Quali sono gli output fondamentali di questo software? o Quali funzionalità e caratteristiche desideri? o Quali output, funzioni e caratteristiche probabilmente cambieranno nei prossimi 6 mesi, un anno? o Ci sono domande che avrei dovuto porre e non ho fatto? o Come farai a decidere se il nostro prodotto corrisponde alle tue aspettative? b. Gli utenti dovrebbero chiedere ai progettisti: o Ho chiarito sufficientemente le mie esigenze? o Abbiamo gli strumenti e le persone con le competenze necessarie allo sviluppo? o I requisiti sono ben definiti? Servono ulteriori requisiti? o Le caratteristiche e le funzionalità del prodotto si possono sviluppare nel tempo previsto? o Avete parlato con altre classi di utenti? c. Gli utenti dovrebbero chiedersi sul prodotto software che viene realizzato: o Ho chiesto più di quello che mi serve realmente? o Ho fissato delle deadline non realistiche? o Ho incertezze riguardanti qualche funzionalità o caratteristica? o Per alcune funzionalità o caratteristiche, sarebbe utile un prototipo? o Mi sono impegnato a lavorare con i progettisti sul lungo periodo? d. I progettisti dovrebbero chiedersi sul prodotto software che stanno realizzando e i processi che verranno utilizzati per costruirlo: o Ho capito lo scope e lo scopo del software? o Ho capito i problemi del design ed i vincoli a cui è soggetto? o Quali strumenti si useranno? o Ho capito la tecnologia e l area applicativa di riferimento del software da produrre? o Abbiamo stabilito criteri di qualità per poter giudicare il nostro

6 lavoro? 2.2 Si potrebbe suggerire agli studenti di utilizzare i riferimenti segnalati nella sezione Ulteriori letture e fonti di informazioni del Capitolo La fase di supporto si applica differentemente per il software embedded. Nella maggioranza dei casi, il software embedded viene specificato e sviluppato, ma una volta inserito nell apparato che lo ospita, non è probabile che debba cambiare finché non ha luogo un aggiornamento del prodotto che lo contiene. 2.4 Le attività ombrello sono presenti durante tutto il processo di sviluppo software, ma non necessariamente sono applicate uniformemente. Ad esempio, l analisi dei rischi richiede molta attenzione durante la pianificazione del progetto e viene poi mantenuta aggiornata durante le successive attività strutturali, ma non viene applicata in ugual misura in ciascuna di esse. Al contrario, la gestione della qualità si applica pressa poco in uguale misura durante tutto il processo. 2.5 La struttura di un processo si applica a tutti i processi; pertanto le stesse attività strutturali si applicano a tutti i processi, indipendentemente dalla loro dimensione o complessità. La struttura di un processo richiede anzitutto una stretta comunicazione con il cliente per raccogliere i requisiti; questa attività stabilisce un piano per il lavoro di ingegneria del software che seguirà. La struttura di un processo prevede inoltre la creazione di modelli che faciliteranno la comprensione fra lo sviluppatore ed il cliente nello sforzo di capire e progettare i requisiti; in seguito richiede una fase di costruzione (generazione del codice e testing). Infine fornisce feedback basato sulla valutazione. 2.6 Un Task Set per l attività di Comunicazione: un Task Set dovrebbe definire in concreto i singoli task da svolgere per raggiungere gli obiettivi di un attività di ingegneria del software. Nel caso dell attività di comunicazione essi sono: 1. Stendere una lista degli stakeholder del progetto 2. Invitarli tutti ad un incontro informale 3. Chiedere a ciascuno di loro di produrre una lista delle funzionalità e caratteristiche desiderate 4. Discutere i requisiti e compilare una lista finale 5. Attribuire a ciascun requisito una priorità e annotarsi le aree in cui gli stakeholder presentano incertezze Questi task potrebbero essere espansi nel caso di progetti software complessi, ad esempio prendendo in considerazione i seguenti: Condurre una serie di incontri per le specifiche, stilare una lista preliminare delle funzionalità e delle caratteristiche basate sugli input degli stakeholder. Produrre una lista riveduta dei requisiti degli stakeholder usando tecniche di QFD (Quality Function Deployment) per assegnare priorità ai requisiti. Annotarsi vincoli e restrizioni sul sistema.

7 Discutere i metodi di validazione del sistema. 2.7 Il CMMI rappresenta un meta-modello di processo in due sensi diversi il modello continuo e quello a fasi. I vantaggi del CMMI: omnicomprensivo, copre sostanzialmente ogni aspetto del processo, ben organizzato, molto adottato. I contro: pesante, eccessivo per molti tipi di processo, l agilità è discutibile. Si dovrebbe sempre adottare lo spirito del CMMI, ma ciascun processo deve poi essere adattato per adeguarsi alle necessità del team di sviluppo e per raggiungere un elevato livello di qualità nel prodotto finale. Si dovrebbero applicare i requisiti del CMMI a tutti i modelli di processo, ma carenze su uno specifico criterio non necessariamente significano che il processo sia scadente. Può darsi che il CMMI sia corretto in situazioni in cui una cultura organizzativa possa essere migliorata verso un modello di processo standard e la direzione si impegni fortemente per ottenere tale risultato. Tuttavia, il CMMI può essere troppo pesante per essere totalmente assimilato da un organizzazione. Quindi lo stesso CMMI che è adatto ad un organizzazione può non esserlo ad un altra. 2.8 Il lettore interessato può scaricare il testo completo del CMMI da 2.9 Nome pattern: Scopo: Tipo: Comunicazione Stabilire una collaborazione con i clienti allo scopo di definire lo scope del progetto, i requisiti business e altri vincoli del progetto Pattern a stadi Contesto iniziale: (1) Sono stati identificati gli stakeholder appropriati ed essi sono disponibili a partecipare all attività di comunicazione (2) Gli stakeholder concordano sul fatto che esiste un problema e che un sistema software potrebbe offrirne una soluzione. Problema: Bisogna raccogliere dagli stakeholder i requisiti ed organizzarli in modo che gli ingegneri software possano usarli facilmente. Tutti gli stakeholder devono collaborare alla definizione dei requisiti ed all identificazione delle aree in cui i requisiti non sono chiari. Soluzione: Ciascuno stakeholder deve sviluppare una descrizione delle funzionalità, caratteristiche, informazioni e behavior che saranno proprie del software. A questo scopo si terrà un incontro strutturato e facilitato. Per maggiori dettagli consultare le sezioni 9.3, 9.4 e 9.5. Contesto risultante: Al termine di un corretto svolgimento di questo pattern, saranno state raccolte ed opportunamente documentate le informazioni di base sufficienti allo sviluppo di un modello analitico. Si sono sviluppati use case (esempi d uso), come pure descrizioni di base delle

8 Pattern correlati: Applicazioni note/esempi: funzionalità e del behavior del sistema, dei dati che saranno manipolati e/o prodotti. Condurre un incontro; raccolta dei requisiti; sviluppo di use case; costruzione di una minispecifica; negoziazione dei requisiti; prioritarizzazione. L attività di comunicazione è obbligatoria all inizio di ogni progetto software; è inoltre raccomandata durante tutto lo sviluppo del progetto ed è nuovamente obbligatoria durante l attività di deployment La valutazione del processo esamina il processo software adottato da un organizzazione per determinare se è efficace per ottenere gli scopi dell ingegneria del software. La valutazione caratterizza la pratica corrente di una unità organizzativa in termini della capacità dei processi selezionati. Lo standard SPICE (ISO/IEC15504) definisce un insieme di requisiti per la valutazione del processo software. Per effettuare la valutazione, SPICE specifica un modello di riferimento che esamina lo scopo e gli obiettivi misurabili del processo (la dimensione del processo ) e l insieme di attributi del processo che dovrebbero essere presenti (la dimensione di capacità ) Il processo PSP (Personal Software Process) enfatizza la misura personale sia del prodotto realizzato sia della sua qualità. Il modello del processo PSP definisce cinque attività strutturali: pianificazione, progettazione ad alto livello, revisione del progetto ad alto livello, sviluppo e post-mortem. Inoltre, PSP rende ciascuno sviluppatore responsabile per la pianificazione del progetto (ad esempio stime e pianificazioni temporali) e gli attribuisce il controllo della qualità di tutti i prodotti software sviluppati Gli script definiscono specifiche attività del processo (lancio del progetto, progettazione, implementazione, integrazione e testing, post-mortem) e altre funzioni di lavoro più dettagliate (pianificazione dello sviluppo, sviluppo dei requisiti, gestione della configurazione software e testing delle unità) che fanno parte del processo del team. Gli script possono essere utili quando il team ha bisogno di indicazioni per pianificare e tenere traccia del proprio lavoro, stabilire gli obiettivi e definire gli effettivi task set per le attività tecniche. Per team con maggiore esperienza, d altra parte, possono impedire gli adattamenti in corso d opera che sono spesso necessari in ambienti agili.

9 Soluzioni CAPITOLO 3 MODELLI DI PROCESSO PRESCRITTIVI 3.1 La vera domanda che un testo dovrebbe affrontare è: Come si può sviluppare un processo che riesca a gestire i molti e caotici attributi del moderno sviluppo software? Gli autori suggeriscono processi che siano focalizzati su flessibilità e possibilità di estensione piuttosto che su qualità elevata e ammettono che questo approccio fa paura. Senza dubbio alcuno! In effetti, noi crediamo che sia una sicura ricetta per un disastro. Ad eccezione di alcuni sistemi operativi per PC di grande diffusione (che lasceremo nell anonimato) la qualità sembra un ragionevole indicatore di un software di successo. Un programma, per quanto estensibile e flessibile, non potrà avere successo se fallisce regolarmente ed è imprevedibile. Si dovrebbe considerare che molto si è scritto sul software abbastanza buono. Tutto questo va bene fintanto che non i perde l enfasi sulla parola buono. 3.2 Il modello a cascata è appropriato per progetti con le seguenti caratteristiche: (1) si ha una profonda comprensione del problema (i requisiti sono ben definiti); (2) la data di consegna è realistica; (3) è improbabile che vengano richieste modifiche sostanziali dei requisiti durante lo sviluppo. Esempi specifici potrebbero essere: (1) una modifica di un programma esistente che sia stata studiata a fondo; (2) un implementazione immediata di un algoritmo numerico o di una regola business per quanto complessa; (3) un miglioramento soggetto a vincoli di codice esistente. 3.3 Le applicazioni software sufficientemente facili da sviluppare a prototipi riguardano quasi sempre interazioni uomo-macchina e/o molta computer graphics. Altre applicazioni che si possono talvolta adattare a questo tipo di sviluppo sono certe classi di algoritmi matematici, sottoinsiemi di sistemi gestiti mediante comandi e altre applicazioni in cui i risultati possano essere esaminati facilmente senza interazioni real-time. Applicazioni più difficili da realizzare mediante uno sviluppo a prototipi comprendono le funzioni di controllo e di controllo dei processi, molte classi di funzioni real-time e di software embedded. 3.4 Se si pianifica di far evolvere il prototipo fino ad ottenere un applicazione da consegnare al cliente, bisogna applicare fin dall inizio regole di progettazione e procedure di SQA (controllo qualità) molto più rigorose. Inoltre, il prototipo deve essere progettato tenendo bene a mente la necessità di evoluzione e deve essere implementato usando un ambiente di programmazione compatibile con quello per lo sviluppo del sistema. Inizialmente il prototipo serve come meccanismo per l identificazione dei requisiti. Una volta completato, il prototipo diventa lo scheletro (l impalcatura) per le estensioni che lo trasformeranno in un sistema finale, realistico ed accettabile dal cliente. 3.5 RAD assume che un progetto possa essere suddiviso in moduli in maniera tale per cui ciascuna funzionalità principale possa essere consegnata in una finestra

10 temporale di giorni. Benché questa condizione si verifichi spesso, vi sono situazioni in cui i tempi di realizzazione sono inevitabilmente più lunghi. Inoltre RAD assume che siano disponibili risorse umane sufficienti per portare avanti in parallelo i vari incrementi. Non sempre questa assunzione è realistica. 3.6 Tutti i progetti software che hanno funzionalità significative da consegnare in tempi molto (troppo) ristretti sono buoni candidati per un approccio incrementale. L idea è consegnare le funzionalità in incrementi successivi. Ad esempio, un prodotto software sofisticato che può essere rilasciato sul mercato con solo parte delle funzionalità operative e l annuncio di imminenti nuove versioni migliorate. Un esempio concreto è un elaboratore di testi sviluppato secondo il paradigma incrementale, che potrebbe fornire nel primo incremento solo funzionalità base di gestione dei file, di formattazione e produzione di documenti, nel secondo incremento funzionalità più sofisticate per formattazione e produzione di documenti, nel terzo incremento verifiche lessicali e grammaticali e nel quarto incremento capacità di impaginazione avanzate. Il processo di sviluppo di ciascun incremento potrebbe valersi del paradigma a prototipi. Lo sviluppo incrementale è particolarmente utile quando il personale è insufficiente per completare l implementazione entro i termini richiesti dal business e stabili come deadline del progetto. 3.7 Mentre si procede lungo il flusso del processo a spirale, il prodotto procede verso uno stato sempre più completo ed il livello di astrazione a cui silavora si riduce (ovvero, il lavoro specifico dell implementazione accelera man mano che ci si allontana dall origine). 3.8 I modelli di processo possono essere combinati. Ciascun modello suggerisce un flusso di processo lievemente differente, ma tutti prevedono lo stesso insieme di attività strutturali: comunicazione, pianificazione, modellazione,costruzione e deployment. Ad esempio il modello sequenziale lineare (a cascata) può essere utile in situazioni in cui i requisiti sono fissati ed il lavoro procede linearmente fino al completamento del sistema. In alcuni casi, in cui lo sviluppatore non è sicuro dell efficienza di un algoritmo, dell adattabilità di un sistema operativo, e della forma che dovrebbe assumere l interazione uomo-macchina, un modello a prototipi può essere la scelta migliore. In altri casi, un approccio incrementale può avere senso ed il flusso delmodelloa spirale può essere efficiente. Speciali modelli di processo assumono molte caratteristiche di uno o più modelli tradizionali. 3.9 In parole povere, il modello di processo concorrente assume che differenti parti di uno stesso processo si troveranno in diversi stati di completezza e che, perciò, differenti attività di ingegneria del software saranno eseguite concorrentemente. La sfida è gestire la concorrenza e riuscire a stabilire lo stato complessivo del progetto Il vantaggio dello sviluppo di software in cui la qualità è abbastanza buona è che il prodotto software sarà consegnato in tempo, tuttavia questo tipo di sviluppo può indurre a consegnare software di bassa qualità, che richiederà tempo per migliorarne la qualità. Quando si privilegia la velocità sulla qualità, il processo può portare a molti difetti il software può richiedere più testing, e

11 rielaborazioni del design e dell implementazione Questo problema può servire ad introdurre l importanza del riuso. Per risolverlo, lo studente dovrebbe indagare librerie di componenti esistenti per determinare quali componenti riusabili siano disponibili. Ad esempio esistono molti componenti riusabili per interfacce utenti. Pertanto qualsiasi applicazione con una parte preponderante, o quanto meno rilevante di interfaccia utente sarà un candidato per il CBSE È possibile usare tecniche matematiche per provare la correttezza di componenti software e perfino di interi programmi. Tuttavia, si tratta di un processo che richiede molto tempo se il programma è complesso. Non è possibile provare la correttezza di programmi non banali mediante testing esaustivo Le proprietà richieste dai clienti o le aree di interesse tecnico spesso hanno impatto sull intera architettura. Quando queste proprietà, dette concern, hanno impatto su molteplici funzioni, caratteristiche, informazioni del sistema, si dicono crosscutting concerns. Lo sviluppo aspect-oriented di software, spesso detto anche programmazione aspect-oriented (AOP), è un paradigma di ingegneria del software relativamente innovativo che fornisce un processo ed un approccio metodologico alla definizione, design e costruzione di aspetti meccanismi al di fuori di subroutine ed ereditarietà per localizzare l espressione di un crosscutting concern UML fornisce la tecnologia necessaria a supportare la pratica dell ingegneria del software object-oriented (e tradizionale), ma non fornisce l infrastruttura di processo per guidare i team di progetto nella loro applicazione della tecnologia. Il Processo Unificato è un infrastruttura per l ingegneria del software che usa UML. Attualmente il processo unificato ed UML si usano in progetti di ogni tipo. Tuttavia, non sono affatto la stessa cosa. UML è una notazione ed un linguaggio di modellazione (si veda il Capitolo 7). UP è un modello di processo in cui UML può essere applicato come parte delle attività di ingegneria del software Un flusso di lavoro di ingegneria del software è distribuito su tutte le fasi del processo unificato. Nel contesto di UP, un flusso di lavoro è analogo ad un task set. In altre parole, un flusso di lavoro identifica i task necessari per completare un importante azione di ingegneria del software e i prodotti risultanti del corretto completamento dei task stessi. In UP si ha un flusso di lavoro per ogni progetto software, mentre le fasi di UP non si verificano necessariamente in sequenza, ma piuttosto approssimativamente concorrenti. È molto probabile che in UP si svolgano contemporaneamente le fasi di costruzione, transizione e produzione, mentre il lavoro è già iniziato sull incremento software successivo.

12 Soluzioni CAPITOLO 4 SVILUPPO AGILE 4.1 Ciascuno dei quattro valori è lodevole, ma ciascuno può mettere nei guai il team di sviluppo. Ad esempio, gli individui e le loro interazioni sono molto importanti, ma un progetto complesso può fallire a causa di una cattiva scelta tecnologica (ad esempio, i processi e gli strumenti sono di bassa qualità). La disponibilità di software funzionante è senza dubbio lo scopo ultimo, ma provate a dirlo a chi dovrà mantenere l applicazione da lì a tre anni quando tutti i membri del team di sviluppo originale se ne sano andati. La collaborazione col cliente è certo lodevole, ma la negoziazione aiuta ad evitare aspettative non realistiche e, nei casi peggiori, dispute legali. La pronta risposta ai cambiamenti è fondamentale, ma un ambiente di progetto caotico (senza pianificazione) in molti casi porta direttamente al fallimento. 4.2 L agilità può essere applicata a qualsiasi processo software. Tuttavia, per farlo, è essenziale che il processo sia progettato in modo da permettere al team di sviluppo di adattare i task e la loro distribuzione, di pianificare in modo compatibile con la fluidità di un approccio agile allo sviluppo, di eliminare tutti i prodotti intermedi tranne quelli veramente indispensabili e di ridurli all essenziale, di enfatizzare una strategia di consegna incrementale che permetta al cliente di avere software funzionante con la massima rapidità compatibile col tipo di prodotto e l ambiente di sviluppo. 4.3 Il team di sviluppo software gestisce i cambiamenti focalizzandosi su incrementi ben definiti (cioè lo scope del singolo incremento è ben definito) e rimandando ciascun cambiamento all incremento successivo. Tutti i modelli di processo agili sono iterativi/incrementali. Ad esempio, ASD usa un processo iterativo che incorpora la pianificazione di un ciclo adattivo, metodi di raccolta dei requisiti relativamente rigorosi, ed un ciclo di sviluppo iterativo che prevede focus group di clienti e revisioni tecniche formali come meccanismi per ricevere feedback in tempo utile durante le sviluppo. Il metodo DSDM definisce tre diversi cicli iterativi functional model iteration (iterazione sul modello funzionale), design and build iteration (iterazione di progettazione e realizzazione) e implementation (implementazione) preceduti da altre due attività feasability study (studio di fattibilità) e business study (studio del business). 4.4 Si possono applicare le attività strutturali generiche ai processi agili trattati in questo capitolo. La tabella dovrebbe elencare tutti i processi agili nella prima riga e tutte le attività generiche (comunicazione, pianificazione, modellazione, costruzione e deployment) nella prima colonna. Si analizzi la descrizione di ciascun processo agile per individuare il nome dell analoga attività del processo, ad esempio: Comunicazione XP: pianificazione - user stories

13 Pianificazione XP: Modellazione XP: Costruzione XP: Deployment XP: pianificazione assunzione d impegno per uno specifico incremento software design, spike solution, refactoring pair programming, unit testing acceptance testing, customer tests 4.5 Un ulteriore principio di agilità che aiuterebbe un team di ingegneria del software a divenire ancora più manovrabile potrebbe essere Un team dovrebbe conoscere di chi sono le competenze che più si addicono ad un particolare progetto e far assegnare questi professionisti al loro progetto, in modo da rendere più efficace lo sviluppo del software. Un altro potrebbe essere: La comunicazione è la chiave, utente e sviluppatore dovrebbero comunicare regolarmente anche se geograficamente separati. 4.6 Uno dei principi di agilità presentati nel Paragrafo 4.1 è Si devono accettare con entusiasmo le richieste di cambiamento, anche se intervengono in una fase avanzata dello sviluppo. I processi agili accettano il cambiamento in quanto essenziale per garantire un vantaggio competitivo al cliente. Ciascun processo presentato in questo capitolo segue questo principio. 4.7 I requisiti cambiano così tanto perché è difficile prevedere in anticipo quali requisiti resteranno validi e quali cambieranno. È altrettanto difficile prevedere come cambieranno le priorità dei clienti durante lo sviluppo del progetto. Spesso è difficile per le persone esprimere le loro necessità relative al software prima di aver visto un prototipo funzionante, perché solo allora realizzano di aver dimenticato di prendere in considerazione un aspetto importante. 4.8 Considerando i sette tratti presentati nel Paragrafo 4.2.2, sulla base dell opinione personale i tratti potrebbero essere ordinati dal più al meno importante come segue: Competenza. In un contesto di sviluppo agile (come in ogni altro settore dell ingegneria del software convenzionale), la competenza comprende talento innato, specifiche abilità nella realizzazione del software e una conoscenza generale del processo scelto dal team. Obiettivi comuni. Sebbene i membri di un team agile possano svolgere compiti differenti e portare nel progetto abilità differenti, tutti dovrebbero concentrarsi su un unico obiettivo. Collaborazione. L ingegneria del software (indipendentemente dal processo utilizzato) prevede la valutazione, l analisi e l uso di informazioni che vengono comunicate al team di sviluppo software. Reciproca fiducia e rispetto. Il team coeso dimostra la fiducia e il rispetto necessari a renderli così ben amalgamati che l intero è maggiore della somma delle parti. Auto-organizzazione. Il team dovrebbe avere il controllo sulla propria struttura interna. Capacità di prendere decisioni. Ogni buon team di sviluppo software (compresi i

14 team agili) deve avere la libertà di controllare il proprio destino. Capacità di soluzione creativa dei problemi. I manager dell attività di sviluppo software devono riconoscere il fatto che il team agile continuerà ad avere a che fare con forme di ambiguità ed a subire assestamenti per i costanti cambi. È importante realizzare che non c è una sola risposta corretta. Ciascuno può percepire differentemente l importanza dei singoli tratti. 4.9 La vicinanza fisica è importante. Una domanda può avere una risposta immediata, un problema può essere discusso senza ritardi, la negoziazione avviene naturalmente attraverso la comunicazione personale senza bisogno di pianificarla (e quindi in modo più efficace). Non c è modo migliore di lavorare! Tuttavia la vicinanza fisica non sempre è possibile. La maggior parte dei modelli di processi agili consiglia la comunicazione di persona. Attualmente, questo può essere ottenuto con video-conferenze di costo contenuto, gruppi di discussioni basati sul Web e altri metodi elettronici. Queste soluzioni non sono altrettanto efficaci della vicinanza fisica, ma possono in gran parte portare ad analoghi risultati Esempio: Ciascun sito Web che intendo poter visitare nuovamente in futuro può essere memorizzato nei Preferiti. Dovrei essere in grado di associare dei nomi agli URL dei siti e raggrupparli secondo categorie di mia definizione, memorizzare un preferito sotto una particolare categoria, ordinare le URL nel modo che preferisco, ed accedere all elenco dei Preferiti in qualsiasi momento dal menu del browser. Dovrei essere in grado di visualizzare tutti i miei Preferiti nella finestra del mio browser raggruppati secondo le categorie di appartenenza, selezionarne uno col mouse in modo che il browser individui l URL corrispondente e visualizzi il contenuto del sito Se nell ambito della progettazione di una user story viene rilevato un problema progettuale difficoltoso, XP prevede l immediata creazione di un prototipo operativo per tale porzione del progetto. Questo prototipo progettuale, chiamato spike solution (un esperimento mirato, letteralmente soluzione puntuale ), viene poi implementato e valutato. Lo scopo è quello di ridurre i rischi all avvio dell implementazione e convalidare le stime originarie per la user story contenente il problema progettuale La programmazione XP incoraggia anche il refactoring una tecnica realizzativa che è anche una tecnica progettuale. Il refactoring è il processo di modifica di un sistema software in modo da non alterare il comportamento esterno del codice ma da migliorarne la struttura interna. Una nozione fondamentale in XP è il fatto che la progettazione non si conclude con l inizio della programmazione. A causa del refactoring, la progettazione si ripresenta costantemente a mano a mano che viene costruito il sistema. Un concetto chiave durante l attività di programmazione è il pair programming. XP prevede l impiego di due persone che collaborano alla stessa workstation per sviluppare il codice corrispondente ad una user story. Questo fornisce un meccanismo di soluzione in tempo reale dei problemi (due teste ragionano meglio di una) e una garanzia di qualità.

15 4.13 Esempio di Pattern di processo per Scrum Nome pattern: Scopo: Tipo: Contesto iniziale: Problema: Soluzione: Contesto risultante: Pattern correlati: Applicazioni note/esempi: Scrum riunione quotidiana rispondere alle tre domande di base mediante un breve incontro da svolgersi quotidianamente pattern a compito (1) il progetto deve essere stato avviato ed il backlog già definito; (2) si sta svolgendo uno sprint; (3) Tutti i membri del team Scrum si sono accordati per incontrarsi quotidianamente in un luogo specifico per la riunione Scrum; (4) e stato individuato un leader per il team. Spesso è difficile per i membri del team rendersi conto dello stato del progetto e di a che punto siano gli altri membri del team con il loro lavoro. Quando si organizzano riunioni per mettere tutti a parte dello stato di avanzamento molto spesso si perde troppo tempo senza conseguire lo scopo. Si veda la descrizione della riunione Scrum in Sezione Alla conclusione della riunione ciascun partecipante ha risposto alle domande: (1) Che cosa hai fatto dall ultima riunione Scrum? (2) Che ostacoli stai affrontando? (3) Che cosa pensi di ottenere prima della prossima riunione? preparazione del backlog, gestione di uno sprint Le riunioni Scrum vengono effettuate durante ciascun progetto Scrum e sono un importante elemento di comunicazione Come altri metodi agili, l approccio Crystal enfatizza collaborazione e comunicazione fra le persone che hanno vari interessi sul progetto software. Il metodo è anche adattabile a varie culture del team e può prevedere approcci sia informali sia relativamente formali all ingegneria del software ed è per questo definita una famiglia di metodi agili. In realtà la famiglia Crystal è un insieme di esempi di processi agili che si sono dimostrati effettivi per differenti tipi di progetto. Il suo scopo è permettere al team agile di selezionare il membro della famiglia Crystal che è più appropriato per il loro tipo di progetto e di ambiente Il template per la definizione di una feature in FDD è il seguente: <azione> il/lo/la/i/gli/le <risultato> <mediante per di a> un(o/a) <oggetto> Esempi: specificare l URL di un sito Web visualizzare il contenuto di un sito Web compilare una form Web visualizzare tutte le URL dei Preferiti

16 4.16 Un sito web da esaminare per i principi AM potrebbe essere

17 Soluzioni CAPITOLO 5 PANORAMICA SUGLI ASPETTI PRATICI DELL INGEGNERIA DEL SOFTWARE 5.1 David Hooker ha proposto sette principi base che si concentrano sulla pratica dell ingegneria del software nel suo complesso: 1. Il primo principio: il senso dell esistenza Un sistema software esiste per un unico motivo, dare valore ad i suoi utenti. 2. Il secondo principio: il principio di semplicità KISS (Keep It Simple, Stupid!) La progettazione di software non può essere un processo vago. In ogni attività di progettazione vi sono molti fattori da considerare. Tutta la progettazione deve essere improntata alla massima semplicità ma senza esagerare. 3. Il terzo principio: concentrarsi sulla visione Una visione chiara è essenziale per il successo di un progetto software. Senza una visione, un progetto finirà quasi certamente per avere di se stesso una visione schizofrenica. 4. Il quarto principio: ciò che si sta producendo verrà consumato da altri Raramente un sistema software a livello industriale viene costruito e utilizzato nel vuoto. In un modo o nell altro, vi sarà qualcuno che lo utilizza, lo gestisce, lo documenta o in qualche modo dipende dalla capacità di comprendere il sistema. 5. Il quinto principio: essere aperti verso il futuro Un sistema di lunga durata avrà un valore superiore. 6. Il sesto principio: pianificare per il riuso Il riuso consente di risparmiare tempo e fatica. 7. Il settimo principio: riflettere! Una riflessione chiara e completa prima di ogni azione produce quasi sempre risultati migliori. Riassumendo in un'unica frase: Bisogna assicurarsi che il sistema che si vuole costruire costituisca un valore aggiunto per i suoi utenti. Mentre lo si costruisce, bisogna mantenere tanto il sistema stesso quanto il processo usato per costruirlo quanto più semplici è possibile, mantenendo allo stesso tempo chiaro in mente lo scopo finale. Non bisogna dimenticare che il sistema sarà mantenuto da altri né che deve essere possibile cambiarlo, man mano che le esigenze a cui risponde si modificano col passare del tempo. Durante la costruzione, bisogna cercare di creare astrazioni che possano essere riusate in altri progetti, ma soprattutto non bisogna mai spegnere il cervello quando si lavora. 5.2 Gli elementi tecnici fondamentali consigliabili per l ingegneria del software comprendono: (1) la necessità di testare approfonditamente il software allo scopo di trovare errori; (2) la necessità di utilizzare strumenti automatici per facilitare lo sviluppo e migliorare la comprensione tecnica; (3) la necessità di misurare il prodotto ed utilizzare le misure effettuate per migliorare la qualità

18 tecnica. 5.3 Gli elementi gestionali fondamentali consigliabili per l ingegneria del software comprendono: (1) comunicazione continua ed efficace con tutti gli stakeholder; (2) adozione di un punto di vista agile, indipendentemente dal modello di processo adottato; (3) un insieme di pratiche gestionali e tecniche che permettano al team di definire il proprio percorso mentre avanza verso il suo scopo ultimo. 5.4 Un importante principio della comunicazione stabilisce che occorre prepararsi prima di comunicare. I principi ed i concetti di comunicazione con il cliente si concentrano sulla necessità di diminuire il rumore e migliorare la banda al progredire della conversazione fra sviluppatori e clienti. Entrambe le parti devono collaborare per ottenere una migliore comunicazione. A questo scopo, l ingegnere software deve: (1) studiare il dominio business a cui si rivolge il sistema di costruire, (2) comprendere i giocatori (cioè gli stakeholder) che specificheranno i requisiti; (3) sviluppare una strategia ben definita per la raccolta dei requisiti; (4) comprendere il fine di ciascuno stakeholder; (5) capire che la negoziazione è inevitabile. 5.5 La facilitazione dell attività di comunicazione è essenziale durante la raccolta dei requisiti. Ogni riunione di comunicazione dovrebbe avere un leader (un facilitatore) allo scopo di (1) mantenere la conversazione concentrata in una direzione produttiva, (2) mediare i conflitti che si dovessero verificare, (3) garantire l aderenza agli altri principi. Semplici linee guida sono: Comprendere il dominio business. Capire chi sono gli stakeholder e quali fini hanno. Stabilire un meccanismo ben definito per la raccolta dei requisiti. Creare un metodo per la memorizzazione dei requisiti. Stabilire un modo per assegnare priorità ai bisogni. 5.6 Il punto di vista agile sulla comunicazione e sulla collaborazione col cliente enfatizza la necessità per tutti gli stakeholder di lavorare (sempre) come una squadra, di condividere il luogo di lavoro e di riconoscere che il cambiamento è una parte ineluttabile del processo. Tuttavia, i punti fondamentali della filosofia agile della comunicazione si possono applicare ad ogni pratica di ingegneria del software e come tutte le altre pratiche anche comunicazione e collaborazione sono iterative. Ogni iterazione diffonde nuove importanti informazioni e migliora la comprensione complessiva del software da produrre. 5.7 È necessario procedere oltre perché la comunicazione, come tutte le altre attività di ingegneria del software, richiede tempo. Piuttosto che iterare interminabilmente, le persone coinvolte dovrebbero riconoscere che molti punti richiedono discussione e che procedere oltre è talvolta il modo migliore di conseguire una vera agilità di comunicazione. Inoltre, il progetto deve progredire incessantemente. Non bisogna permettere che bloccarsi su un punto lo faccia diventare un collo di bottiglia del processo. 5.8 La negoziazione per l attività di comunicazione funziona al meglio se entrambe le parti vincono. Semplici linee guida comprendono:

19 Stabilire che siamo tutti nella stessa squadra e abbiamo tutti lo stesso scopo per produrre un sistema che effettivamente soddisfi le esigenze dell utente. Cercare sempre di trovare un punto di accordo quello su cui si è tutti concordi. Riconoscere che entrambi i lati dovranno cedere qualcosa al compromesso. Non trascendere mai su aspetti personali, né recriminare mantenere la discussione sul software. 5.9 Il termine granularità fa riferimento al livello di dettaglio scelto durante lo sviluppo del piano di progetto. Un piano a granularità fine fornisce dettagli significativi per un task di lavoro pianificato su un intervallo temporale relativamente breve (cosicché verifiche e controlli siano frequenti). Un piano a granularità grossolana fornisce task di lavoro pianificati su intervalli temporali più lunghi. In generale, la granularità diventa progressivamente meno fine quanto più ci si allontana dal momento attuale verso il futuro nel piano di sviluppo del progetto Il modello del design per il software è l equivalente dei progetti di un architetto per una casa. In principio rappresenta la visione d insieme delle cose da costruire (ad esempio un modellino tridimensionale della casa) e lentamente viene raffinato per fornire la guida necessaria alla costruzione di ciascun aspetto (ad esempio il piano della rete idraulica). Analogamente, il modello del design fornisce un insieme di diverse viste del sistema ed è quindi necessario per tutti i progetti meno che banali I modelli analitici definiscono i requisiti del cliente, rappresentando il software in tre diversi domini: il dominio delle informazioni, il dominio delle funzioni ed il dominio del behaviour. I modelli del design rappresentano invece le caratteristiche del software che aiutano gli sviluppatori a produrlo efficacemente: l architettura, l interfaccia utente ed i dettagli a livello dei componenti Un principio ulteriore rispetto a quelli affermati sulla programmazione nel Paragrafo 5.6 potrebbe essere Il codice dovrebbe auto-documentarsi, cioè il codice dovrebbe essere scritto in modo così chiaro da risultare auto-esplicativo Un test di successo è quello che consente di scoprire un errore ancora ignoto Non si può concordare con la frase proposta. Ciascun incremento si basa sui precedenti e nessuno vorrebbe costruire su fondamenta di bassa qualità. Inoltre, se i primi incrementi hanno una qualità insoddisfacente, clienti ed utenti si preoccupano (perdono fiducia nella competenza del team); si potrebbe sviluppare un inutile tensione e la comunicazione successiva ne potrebbe risultare compromessa Il feedback è importante per il team software perché fornisce le informazioni da usare per correggere gli errori di modellazione, cambiare i fraintendimenti e aggiungere funzionalità o caratteristiche che erano state involontariamente

20 omesse.

I Valori del Manifesto Agile sono direttamente applicabili a Scrum:!

I Valori del Manifesto Agile sono direttamente applicabili a Scrum:! Scrum descrizione I Principi di Scrum I Valori dal Manifesto Agile Scrum è il framework Agile più noto. E la sorgente di molte delle idee che si trovano oggi nei Principi e nei Valori del Manifesto Agile,

Dettagli

Processi (di sviluppo del) software. Fase di Analisi dei Requisiti. Esempi di Feature e Requisiti. Progettazione ed implementazione

Processi (di sviluppo del) software. Fase di Analisi dei Requisiti. Esempi di Feature e Requisiti. Progettazione ed implementazione Processi (di sviluppo del) software Fase di Analisi dei Requisiti Un processo software descrive le attività (o task) necessarie allo sviluppo di un prodotto software e come queste attività sono collegate

Dettagli

RUP (Rational Unified Process)

RUP (Rational Unified Process) RUP (Rational Unified Process) Caratteristiche, Punti di forza, Limiti versione del tutorial: 3.3 (febbraio 2007) Pag. 1 Unified Process Booch, Rumbaugh, Jacobson UML (Unified Modeling Language) notazione

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

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

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

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

Cos è l Ingegneria del Software?

Cos è l Ingegneria del Software? Cos è l Ingegneria del Software? Corpus di metodologie e tecniche per la produzione di sistemi software. L ingegneria del software è la disciplina tecnologica e gestionale che riguarda la produzione sistematica

Dettagli

Il ciclo di vita del software

Il ciclo di vita del software Il ciclo di vita del software Il ciclo di vita del software Definisce un modello per il software, dalla sua concezione iniziale fino al suo sviluppo completo, al suo rilascio, alla sua successiva evoluzione,

Dettagli

Sistemi di supporto alle decisioni Ing. Valerio Lacagnina

Sistemi di supporto alle decisioni Ing. Valerio Lacagnina Cosa è il DSS L elevato sviluppo dei personal computer, delle reti di calcolatori, dei sistemi database di grandi dimensioni, e la forte espansione di modelli basati sui calcolatori rappresentano gli sviluppi

Dettagli

LAVORO DI GRUPPO. Caratteristiche dei gruppi di lavoro transnazionali

LAVORO DI GRUPPO. Caratteristiche dei gruppi di lavoro transnazionali LAVORO DI GRUPPO Caratteristiche dei gruppi di lavoro transnazionali Esistono molti manuali e teorie sulla costituzione di gruppi e sull efficacia del lavoro di gruppo. Un coordinatore dovrebbe tenere

Dettagli

Corso di Programmazione ad Oggetti

Corso di Programmazione ad Oggetti Corso di Programmazione ad Oggetti Introduzione alla programmazione ad oggetti a.a. 2008/2009 Claudio De Stefano 1 La programmazione modulare Un programma può essere visto come un insieme di moduli che

Dettagli

La Valutazione Euristica

La Valutazione Euristica 1/38 E un metodo ispettivo di tipo discount effettuato da esperti di usabilità. Consiste nel valutare se una serie di principi di buona progettazione sono stati applicati correttamente. Si basa sull uso

Dettagli

UML: Class Diagram. Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it

UML: Class Diagram. Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it UML: Class Diagram Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania Class Diagram Forniscono una vista strutturale

Dettagli

Che cos è un focus-group?

Che cos è un focus-group? Che cos è un focus-group? Si tratta di interviste di tipo qualitativo condotte su un ristretto numero di persone, accuratamente selezionate, che vengono riunite per discutere degli argomenti più svariati,

Dettagli

GLI ASSI CULTURALI. Allegato 1 - Gli assi culturali. Nota. rimessa all autonomia didattica del docente e alla programmazione collegiale del

GLI ASSI CULTURALI. Allegato 1 - Gli assi culturali. Nota. rimessa all autonomia didattica del docente e alla programmazione collegiale del GLI ASSI CULTURALI Nota rimessa all autonomia didattica del docente e alla programmazione collegiale del La normativa italiana dal 2007 13 L Asse dei linguaggi un adeguato utilizzo delle tecnologie dell

Dettagli

Modal 2 Modulo Analisi modale Modulo per l Analisi della dinamica strutturale.

Modal 2 Modulo Analisi modale Modulo per l Analisi della dinamica strutturale. Modal 2 Modulo Analisi modale Modulo per l Analisi della dinamica strutturale. L analisi modale è un approccio molto efficace al comportamento dinamico delle strutture, alla verifica di modelli di calcolo

Dettagli

Progettazione Orientata agli Oggetti

Progettazione Orientata agli Oggetti Progettazione Orientata agli Oggetti Sviluppo del software Ciclo di vita del software: comprende tutte le attività dall analisi iniziale fino all obsolescenza (sviluppo, aggiornamento, manutenzione) Procedimento

Dettagli

Introduzione alla Programmazione ad Oggetti in C++

Introduzione alla Programmazione ad Oggetti in C++ Introduzione alla Programmazione ad Oggetti in C++ Lezione 1 Cosa è la Programmazione Orientata agli Oggetti Metodologia per costruire prodotti software di grosse dimensioni che siano affidabili e facilmente

Dettagli

Il Business Process Management: nuova via verso la competitività aziendale

Il Business Process Management: nuova via verso la competitività aziendale Il Business Process Management: nuova via verso la competitività Renata Bortolin Che cosa significa Business Process Management? In che cosa si distingue dal Business Process Reingeneering? Cosa ha a che

Dettagli

Corso di Amministrazione di Sistema Parte I ITIL 3

Corso di Amministrazione di Sistema Parte I ITIL 3 Corso di Amministrazione di Sistema Parte I ITIL 3 Francesco Clabot Responsabile erogazione servizi tecnici 1 francesco.clabot@netcom-srl.it Fondamenti di ITIL per la Gestione dei Servizi Informatici Il

Dettagli

***** Il software IBM e semplice *****

***** Il software IBM e semplice ***** Il IBM e semplice ***** ***** Tutto quello che hai sempre voluto sapere sui prodotti IBM per qualificare i potenziali clienti, sensibilizzarli sulle nostre offerte e riuscire a convincerli. WebSphere IL

Dettagli

Release Management. Obiettivi. Definizioni. Responsabilità. Attività. Input

Release Management. Obiettivi. Definizioni. Responsabilità. Attività. Input Release Management Obiettivi Obiettivo del Release Management è di raggiungere una visione d insieme del cambiamento nei servizi IT e accertarsi che tutti gli aspetti di una release (tecnici e non) siano

Dettagli

Le funzionalità di un DBMS

Le funzionalità di un DBMS Le funzionalità di un DBMS Sistemi Informativi L-A Home Page del corso: http://www-db.deis.unibo.it/courses/sil-a/ Versione elettronica: DBMS.pdf Sistemi Informativi L-A DBMS: principali funzionalità Le

Dettagli

Informatica Applicata

Informatica Applicata Ing. Irina Trubitsyna Concetti Introduttivi Programma del corso Obiettivi: Il corso di illustra i principi fondamentali della programmazione con riferimento al linguaggio C. In particolare privilegia gli

Dettagli

Parole Chiave: Sviluppo di un nuovo prodotto, MSNP, design di prodotto, Stage-Gate

Parole Chiave: Sviluppo di un nuovo prodotto, MSNP, design di prodotto, Stage-Gate 6.1 Metodi per lo sviluppo di nuovi prodotti (MSNP) Parole Chiave: Sviluppo di un nuovo prodotto, MSNP, design di prodotto, Stage-Gate Questo capitolo presenta alcune metodologie per gestire al meglio

Dettagli

Neomobile incentra l infrastruttura IT su Microsoft ALM, arrivando a 40 nuovi rilasci a settimana

Neomobile incentra l infrastruttura IT su Microsoft ALM, arrivando a 40 nuovi rilasci a settimana Storie di successo Microsoft per le Imprese Scenario: Software e Development Settore: Servizi In collaborazione con Neomobile incentra l infrastruttura IT su Microsoft ALM, arrivando a 40 nuovi rilasci

Dettagli

UML Component and Deployment diagram

UML Component and Deployment diagram UML Component and Deployment diagram Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania I diagrammi UML Classificazione

Dettagli

PROCEDURA DI AUDIT AI TEST CENTER AICA

PROCEDURA DI AUDIT AI TEST CENTER AICA Pag. 1 di 14 PROCEDURA DI AUDIT REVISIONI 1 19/12/2002 Prima revisione 2 07/01/2004 Seconda revisione 3 11/01/2005 Terza revisione 4 12/01/2006 Quarta revisione 5 09/12/2013 Quinta revisione Adeguamenti

Dettagli

White Paper. Operational DashBoard. per una Business Intelligence. in real-time

White Paper. Operational DashBoard. per una Business Intelligence. in real-time White Paper Operational DashBoard per una Business Intelligence in real-time Settembre 2011 www.axiante.com A Paper Published by Axiante CAMBIARE LE TRADIZIONI C'è stato un tempo in cui la Business Intelligence

Dettagli

How to Develop Accessible Linux Applications

How to Develop Accessible Linux Applications How to Develop Accessible Linux Applications Sharon Snider Copyright 2002 IBM Corporation v1.1, 2002-05-03 Diario delle Revisioni Revisione v1.1 2002-05-03 Revisionato da: sds Convertito in DocBook XML

Dettagli

Algoritmo euclideo, massimo comun divisore ed equazioni diofantee

Algoritmo euclideo, massimo comun divisore ed equazioni diofantee Algoritmo euclideo, massimo comun divisore ed equazioni diofantee Se a e b sono numeri interi, si dice che a divide b, in simboli: a b, se e solo se esiste c Z tale che b = ac. Si può subito notare che:

Dettagli

Dall italiano alla logica proposizionale

Dall italiano alla logica proposizionale Rappresentare l italiano in LP Dall italiano alla logica proposizionale Sandro Zucchi 2009-10 In questa lezione, vediamo come fare uso del linguaggio LP per rappresentare frasi dell italiano. Questo ci

Dettagli

Il mondo in cui viviamo

Il mondo in cui viviamo Il mondo in cui viviamo Il modo in cui lo vediamo/ conosciamo Dalle esperienze alle idee Dalle idee alla comunicazione delle idee Quando sono curioso di una cosa, matematica o no, io le faccio delle domande.

Dettagli

white paper La Process Intelligence migliora le prestazioni operative del settore assicurativo

white paper La Process Intelligence migliora le prestazioni operative del settore assicurativo white paper La Process Intelligence migliora le prestazioni operative del settore assicurativo White paper La Process Intelligence migliora le prestazioni operative del settore assicurativo Pagina 2 Sintesi

Dettagli

L 8 maggio 2002 il Ministero

L 8 maggio 2002 il Ministero > > > > > Prima strategia: ascoltare le esigenze degli utenti, semplificare il linguaggio e la navigazione del sito. Seconda: sviluppare al nostro interno le competenze e le tecnologie per gestire in proprio

Dettagli

Elaidon Web Solutions

Elaidon Web Solutions Elaidon Web Solutions Realizzazione siti web e pubblicità sui motori di ricerca Consulente Lorenzo Stefano Piscioli Via Siena, 6 21040 Gerenzano (VA) Telefono +39 02 96 48 10 35 elaidonwebsolutions@gmail.com

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

Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN)

Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN) Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN) System Overview di Mattia Bargellini 1 CAPITOLO 1 1.1 Introduzione Il seguente progetto intende estendere

Dettagli

Informatica. Scopo della lezione

Informatica. Scopo della lezione 1 Informatica per laurea diarea non informatica LEZIONE 1 - Cos è l informatica 2 Scopo della lezione Introdurre le nozioni base della materia Definire le differenze tra hardware e software Individuare

Dettagli

Abstract Data Type (ADT)

Abstract Data Type (ADT) Abstract Data Type Pag. 1/10 Abstract Data Type (ADT) Iniziamo la nostra trattazione presentando una nozione che ci accompagnerà lungo l intero corso di Laboratorio Algoritmi e Strutture Dati: il Tipo

Dettagli

Definizione e struttura della comunicazione

Definizione e struttura della comunicazione Definizione e struttura della comunicazione Sono state date molteplici definizioni della comunicazione; la più semplice e comprensiva è forse questa: passaggio di un'informazione da un emittente ad un

Dettagli

Guida alle offerte di finanziamento per le medie imprese

Guida alle offerte di finanziamento per le medie imprese IBM Global Financing Guida alle offerte di finanziamento per le medie imprese Realizzata da IBM Global Financing ibm.com/financing/it Guida alle offerte di finanziamento per le medie imprese La gestione

Dettagli

Cos è il BULATS. Quali sono i livelli del BULATS?

Cos è il BULATS. Quali sono i livelli del BULATS? Cos è il BULATS Il Business Language Testing Service (BULATS) è ideato per valutare il livello delle competenze linguistiche dei candidati che hanno necessità di utilizzare un lingua straniera (Inglese,

Dettagli

ORACLE BUSINESS INTELLIGENCE STANDARD EDITION ONE A WORLD CLASS PERFORMANCE

ORACLE BUSINESS INTELLIGENCE STANDARD EDITION ONE A WORLD CLASS PERFORMANCE ORACLE BUSINESS INTELLIGENCE STANDARD EDITION ONE A WORLD CLASS PERFORMANCE Oracle Business Intelligence Standard Edition One è una soluzione BI completa, integrata destinata alle piccole e medie imprese.oracle

Dettagli

GUIDA ALLA COMPILAZIONE

GUIDA ALLA COMPILAZIONE GUIDA ALLA COMPILAZIONE 1. L istanza di riconoscimento dei CFP, deve essere presentata esclusivamente al CNI mediante una compilazione online di apposito modulo disponibile sulla piattaforma della formazione

Dettagli

PRESIDENZA DEL CONSIGLIO DEI MINISTRI DIPARTIMENTO DELLA FUNZIONE PUBBLICA

PRESIDENZA DEL CONSIGLIO DEI MINISTRI DIPARTIMENTO DELLA FUNZIONE PUBBLICA PRESIDENZA DEL CONSIGLIO DEI MINISTRI DIPARTIMENTO DELLA FUNZIONE PUBBLICA DIRETTIVA DEL MINISTRO DELLA FUNZIONE PUBBLICA SULLA RILEVAZIONE DELLA QUALITA PERCEPITA DAI CITTADINI A tutti i Ministeri - Uffici

Dettagli

Organizzazione: teoria, progettazione e cambiamento

Organizzazione: teoria, progettazione e cambiamento Organizzazione: teoria, progettazione e cambiamento Edizione italiana a cura di G. Soda Capitolo 6 La progettazione della struttura organizzativa: specializzazione e coordinamento Jones, Organizzazione

Dettagli

Rapporto dai Questionari Studenti Insegnanti - Genitori. per la Primaria ISTITUTO COMPRENSIVO IST.COMPR. BATTIPAGLIA "GATTO" SAIC83800T

Rapporto dai Questionari Studenti Insegnanti - Genitori. per la Primaria ISTITUTO COMPRENSIVO IST.COMPR. BATTIPAGLIA GATTO SAIC83800T Rapporto dai Questionari Studenti Insegnanti - Genitori per la ISTITUTO COMPRENSIVO IST.COMPR. BATTIPAGLIA "GATTO" SAIC83800T Progetto VALES a.s. 2012/13 Rapporto Questionari Studenti Insegnanti Genitori

Dettagli

Un'infrastruttura IT inadeguata provoca danni in tre organizzazioni su cinque

Un'infrastruttura IT inadeguata provoca danni in tre organizzazioni su cinque L'attuale ambiente di business è senz'altro maturo e ricco di opportunità, ma anche pieno di rischi. Questa dicotomia si sta facendo sempre più evidente nel mondo dell'it, oltre che in tutte le sale riunioni

Dettagli

Panoramica su ITIL V3 ed esempio di implementazione del Service Design

Panoramica su ITIL V3 ed esempio di implementazione del Service Design Master Universitario di II livello in Interoperabilità Per la Pubblica Amministrazione e Le Imprese Panoramica su ITIL V3 ed esempio di implementazione del Service Design Lavoro pratico II Periodo didattico

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

Bandi 2015 ARTE E CULTURA. Progetto ic-innovazioneculturale 2015 Bando di idee. www.fondazionecariplo.it

Bandi 2015 ARTE E CULTURA. Progetto ic-innovazioneculturale 2015 Bando di idee. www.fondazionecariplo.it Bandi 2015 ARTE E CULTURA Progetto ic-innovazioneculturale 2015 Bando di idee BENESSERE GIOVANI COMUNITÀ www.fondazionecariplo.it BANDI 2015 1 Progetto ic-innovazioneculturale 2015 Bando di idee IL CONTESTO

Dettagli

Corso SOL Gestione catalogo libro moderno 21-22 settembre 2009

Corso SOL Gestione catalogo libro moderno 21-22 settembre 2009 Corso SOL Gestione catalogo libro moderno 21-22 settembre 2009 Introduzione generale Autenticazione dell operatore https://sebina1.unife.it/sebinatest Al primo accesso ai servizi di Back Office, utilizzando

Dettagli

Informatica Industriale Modello funzionale: Informazione Progettazione concettuale

Informatica Industriale Modello funzionale: Informazione Progettazione concettuale DIIGA - Università Politecnica delle Marche A.A. 2006/2007 Informatica Industriale Modello funzionale: Informazione Progettazione concettuale Luca Spalazzi spalazzi@diiga.univpm.it www.diiga.univpm.it/~spalazzi/

Dettagli

APPLICAZIONE WEB PER LA GESTIONE DELLE RICHIESTE DI ACQUISTO DEL MATERIALE INFORMATICO. Francesco Marchione e Dario Richichi

APPLICAZIONE WEB PER LA GESTIONE DELLE RICHIESTE DI ACQUISTO DEL MATERIALE INFORMATICO. Francesco Marchione e Dario Richichi APPLICAZIONE WEB PER LA GESTIONE DELLE RICHIESTE DI ACQUISTO DEL MATERIALE INFORMATICO Francesco Marchione e Dario Richichi Istituto Nazionale di Geofisica e Vulcanologia Sezione di Palermo Indice Introduzione...

Dettagli

STRUMENTI DI ANALISI E DI INTERPRETAZIONE DEI PROBLEMI: LE TECNICHE DI PROBLEM SOLVING

STRUMENTI DI ANALISI E DI INTERPRETAZIONE DEI PROBLEMI: LE TECNICHE DI PROBLEM SOLVING STRUMENTI DI ANALISI E DI INTERPRETAZIONE DEI PROBLEMI: LE TECNICHE DI PROBLEM SOLVING Gianna Maria Agnelli Psicologa Clinica e Psicoterapeuta Clinica del Lavoro "Luigi Devoto Fondazione IRCCS Ospedale

Dettagli

Cross Software ltd Malta Pro.Sy.T Srl. Il gestionale come l'avete sempre sognato... Pag. 1

Cross Software ltd Malta Pro.Sy.T Srl. Il gestionale come l'avete sempre sognato... Pag. 1 Il gestionale come l'avete sempre sognato... Pag. 1 Le funzionalità di X-Cross La sofisticata tecnologia di CrossModel, oltre a permettere di lavorare in Internet come nel proprio ufficio e ad avere una

Dettagli

2. GESTIONE DOCUMENTI NON SBN

2. GESTIONE DOCUMENTI NON SBN Istituto centrale per il catalogo unico delle biblioteche italiane e per le informazioni bibliografiche APPLICATIVO SBN-UNIX IN ARCHITETTURA CLIENT/SERVER 2. GESTIONE DOCUMENTI NON SBN Manuale d uso (Versione

Dettagli

ITALIANO TRAGUARDI PER LO SVILUPPO DELLE COMPETENZE AL TERMINE DELLA SCUOLA PRIMARIA

ITALIANO TRAGUARDI PER LO SVILUPPO DELLE COMPETENZE AL TERMINE DELLA SCUOLA PRIMARIA ITALIANO TRAGUARDI PER LO SVILUPPO DELLE COMPETENZE AL TERMINE DELLA SCUOLA PRIMARIA L allievo partecipa a scambi comunicativi (conversazione, discussione di classe o di gruppo) con compagni e insegnanti

Dettagli

END-TO-END SERVICE QUALITY. LA CULTURA DELLA QUALITÀ DAL CONTROLLO DELLE RISORSE ALLA SODDISFAZIONE DEL CLIENTE

END-TO-END SERVICE QUALITY. LA CULTURA DELLA QUALITÀ DAL CONTROLLO DELLE RISORSE ALLA SODDISFAZIONE DEL CLIENTE END-TO-END SERVICE QUALITY. LA CULTURA DELLA QUALITÀ DAL CONTROLLO DELLE RISORSE ALLA SODDISFAZIONE In un mercato delle Telecomunicazioni sempre più orientato alla riduzione delle tariffe e dei costi di

Dettagli

Scuola Specializzazione Istruzione Superiore. Object Oriented Programming (OOP) Introduzione alla programmazione orientata agli oggetti

Scuola Specializzazione Istruzione Superiore. Object Oriented Programming (OOP) Introduzione alla programmazione orientata agli oggetti Scuola Specializzazione Istruzione Superiore Object Oriented Programming (OOP) Introduzione alla programmazione orientata agli oggetti Michele Batocchi ITC Vittorio Emanuele II Perugia A.S. 2007/2008 Introduzione

Dettagli

10 errori e-mail da evitare!

10 errori e-mail da evitare! 10 errori e-mail da evitare! Dal sito PILLOLE DI MARKETING WEB Le e-mail sono parte integrante dell attività di business come mezzo di contatto e di relazione e come tali diffondono l immagine di aziende

Dettagli

ANALISI DEI RISCHI IN UN PROGETTO DI SVILUPPO SOFTWARE

ANALISI DEI RISCHI IN UN PROGETTO DI SVILUPPO SOFTWARE ANALISI DEI RISCHI IN UN PROGETTO DI SVILUPPO SOFTWARE Roma, dicembre 1999 Analisi dei rischi in un progetto di sviluppo sw RISCHIO = potenziale difetto il cui verificarsi comporta dei danni Danno Non

Dettagli

IL CURRICOLO D ITALIANO COME LINGUA STARNIERA

IL CURRICOLO D ITALIANO COME LINGUA STARNIERA IL CURRICOLO D ITALIANO COME LINGUA STARNIERA INDICE INTRODUZIONE scuola media obiettivo generale linee di fondo : mete educative e mete specifiche le abilità da sviluppare durante le sei sessioni alcune

Dettagli

La collaborazione come strumento per l'innovazione.

La collaborazione come strumento per l'innovazione. La collaborazione come strumento per l'innovazione. Gabriele Peroni Manager of IBM Integrated Communication Services 1 La collaborazione come strumento per l'innovazione. I Drivers del Cambiamento: Le

Dettagli

Le Dashboard di cui non si può fare a meno

Le Dashboard di cui non si può fare a meno Le Dashboard di cui non si può fare a meno Le aziende più sensibili ai cambiamenti stanno facendo di tutto per cogliere qualsiasi opportunità che consenta loro di incrementare il business e di battere

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

CONFERENZA STATO-REGIONI SEDUTA DEL 15 GENNAIO 2004

CONFERENZA STATO-REGIONI SEDUTA DEL 15 GENNAIO 2004 Repertorio Atti n. 1901 del 15 gennaio 2004 CONFERENZA STATO-REGIONI SEDUTA DEL 15 GENNAIO 2004 Oggetto: Accordo tra il Ministro dell istruzione, dell università e della ricerca, il Ministro del lavoro

Dettagli

LA PROGETTAZIONE Come fare un progetto. LA PROGETTAZIONE Come fare un progetto

LA PROGETTAZIONE Come fare un progetto. LA PROGETTAZIONE Come fare un progetto LA PROGETTAZIONE 1 LA PROGETTAZIONE Oggi il raggiungimento di un obiettivo passa per la predisposizione di un progetto. Dal mercato al terzo settore passando per lo Stato: aziende, imprese, organizzazioni,

Dettagli

John Dewey. Le fonti di una scienza dell educazione. educazione

John Dewey. Le fonti di una scienza dell educazione. educazione John Dewey Le fonti di una scienza dell educazione educazione 1929 L educazione come scienza indipendente Esiste una scienza dell educazione? Può esistere una scienza dell educazione? Ṫali questioni ineriscono

Dettagli

Come evitare i rischi di una due diligence tradizionale

Come evitare i rischi di una due diligence tradizionale Mergers & Acquisitions Come evitare i rischi di una due diligence tradizionale Di Michael May, Patricia Anslinger e Justin Jenk Un controllo troppo affrettato e una focalizzazione troppo rigida sono la

Dettagli

SOFTWARE GESTIONE SMS DA INTERFACCE CL MANUALE D INSTALLAZIONE ED USO

SOFTWARE GESTIONE SMS DA INTERFACCE CL MANUALE D INSTALLAZIONE ED USO CLSMS SOFTWARE GESTIONE SMS DA INTERFACCE CL MANUALE D INSTALLAZIONE ED USO Sommario e introduzione CLSMS SOMMARIO INSTALLAZIONE E CONFIGURAZIONE... 3 Parametri di configurazione... 4 Attivazione Software...

Dettagli

AUL22: FactoryTalk View SE Scoprite i vantaggi chiave di una soluzione SCADA integrata

AUL22: FactoryTalk View SE Scoprite i vantaggi chiave di una soluzione SCADA integrata AUL22: FactoryTalk View SE Scoprite i vantaggi chiave di una soluzione SCADA integrata Giampiero Carboni Davide Travaglia David Board Rev 5058-CO900C Interfaccia operatore a livello di sito FactoryTalk

Dettagli

Soluzioni di risparmio

Soluzioni di risparmio Soluzioni di risparmio Alla ricerca delle spese nascoste Visibile Gestita totalmente Aereo Treno Gestita tradizionalmente Servizi generalmente prenotati in anticipo e approvati dal line manager Meno potenziale

Dettagli

Scuola primaria: obiettivi al termine della classe 5

Scuola primaria: obiettivi al termine della classe 5 Competenza: partecipare e interagire con gli altri in diverse situazioni comunicative Scuola Infanzia : 3 anni Obiettivi di *Esprime e comunica agli altri emozioni, sentimenti, pensieri attraverso il linguaggio

Dettagli

Mario Polito IARE: Press - ROMA

Mario Polito IARE: Press - ROMA Mario Polito info@mariopolito.it www.mariopolito.it IMPARARE A STUD IARE: LE TECNICHE DI STUDIO Come sottolineare, prendere appunti, creare schemi e mappe, archiviare Pubblicato dagli Editori Riuniti University

Dettagli

La Borsa delle idee Innovare: il reale valore dei social network

La Borsa delle idee Innovare: il reale valore dei social network La Borsa delle idee Innovare: il reale valore dei social network Di cosa parliamo? La Borsa delle Idee è la soluzione per consentire alle aziende di coinvolgere attivamente le persone (dipendenti, clienti,

Dettagli

Guida agli strumenti etwinning

Guida agli strumenti etwinning Guida agli strumenti etwinning Registrarsi in etwinning Prima tappa: Dati di chi effettua la registrazione Seconda tappa: Preferenze di gemellaggio Terza tappa: Dati della scuola Quarta tappa: Profilo

Dettagli

Permutazione degli elementi di una lista

Permutazione degli elementi di una lista Permutazione degli elementi di una lista Luca Padovani padovani@sti.uniurb.it Sommario Prendiamo spunto da un esercizio non banale per fare alcune riflessioni su un approccio strutturato alla risoluzione

Dettagli

Risolvere un problema significa individuare un procedimento che permetta di arrivare al risultato partendo dai dati

Risolvere un problema significa individuare un procedimento che permetta di arrivare al risultato partendo dai dati Algoritmi Algoritmi Risolvere un problema significa individuare un procedimento che permetta di arrivare al risultato partendo dai dati Il procedimento (chiamato algoritmo) è composto da passi elementari

Dettagli

Dalla Mappatura dei Processi al Business Process Management

Dalla Mappatura dei Processi al Business Process Management Dalla Mappatura dei Processi al Business Process Management Romano Stasi Responsabile Segreteria Tecnica ABI Lab Roma, 4 dicembre 2007 Agenda Il percorso metodologico Analizzare per conoscere: la mappatura

Dettagli

Energy Studio Manager Manuale Utente USO DEL SOFTWARE

Energy Studio Manager Manuale Utente USO DEL SOFTWARE Energy Studio Manager Manuale Utente USO DEL SOFTWARE 1 ANALYSIS.EXE IL PROGRAMMA: Una volta aperto il programma e visualizzato uno strumento il programma apparirà come nell esempio seguente: Il programma

Dettagli

progettiamo e realizziamo architetture informatiche Company Profile

progettiamo e realizziamo architetture informatiche Company Profile Company Profile Chi siamo Kammatech Consulting S.r.l. nasce nel 2000 con l'obiettivo di operare nel settore I.C.T., fornendo servizi di progettazione, realizzazione e manutenzione di reti aziendali. Nel

Dettagli

Allegato 8 MISURE MINIME ED IDONEE

Allegato 8 MISURE MINIME ED IDONEE Allegato 8 MISURE MINIME ED IDONEE SOMMARIO 1 POLITICHE DELLA SICUREZZA INFORMATICA...3 2 ORGANIZZAZIONE PER LA SICUREZZA...3 3 SICUREZZA DEL PERSONALE...3 4 SICUREZZA MATERIALE E AMBIENTALE...4 5 GESTIONE

Dettagli

QUESTIONARIO SUGLI STILI DI APPRENDIMENTO

QUESTIONARIO SUGLI STILI DI APPRENDIMENTO QUESTIONARIO SUGLI STILI DI APPRENDIMENTO Le seguenti affermazioni descrivono alcune abitudini di studio e modi di imparare. Decidi in quale misura ogni affermazione si applica nel tuo caso: metti una

Dettagli

FARE IN MODO EHE SI REALIZZI. Guida Allo Sviluppo Dei Progetti Di Club

FARE IN MODO EHE SI REALIZZI. Guida Allo Sviluppo Dei Progetti Di Club FARE IN MODO EHE SI REALIZZI Guida Allo Sviluppo Dei Progetti Di Club FARLO ACCADERE! I Lions clubs che organizzano progetti di servizio utili alla comunità hanno un impatto considerevole sulle persone

Dettagli

IT FINANCIAL MANAGEMENT

IT FINANCIAL MANAGEMENT IT FINANCIAL MANAGEMENT L IT Financial Management è una disciplina per la pianificazione e il controllo economico-finanziario, di carattere sia strategico sia operativo, basata su un ampio insieme di metodologie

Dettagli

Schema Professionista della Security Profilo Senior Security Manager - III Livello

Schema Professionista della Security Profilo Senior Security Manager - III Livello STATO DELLE REVISIONI rev. n SINTESI DELLA MODIFICA DATA 0 05-05-2015 VERIFICA Direttore Qualità & Industrializzazione Maria Anzilotta APPROVAZIONE Direttore Generale Giampiero Belcredi rev. 0 del 2015-05-05

Dettagli

Il Comitato dei Ministri, ai sensi dell'articolo 15.b dello Statuto del Consiglio d'europa,

Il Comitato dei Ministri, ai sensi dell'articolo 15.b dello Statuto del Consiglio d'europa, CONSIGLIO D EUROPA Raccomandazione CM/REC(2014) 3 del Comitato dei Ministri agli Stati Membri relativa ai delinquenti pericolosi (adottata dal Comitato dei Ministri il 19 febbraio 2014 nel corso della

Dettagli

ATTUAZIONE DEL PROGETTO E IL MANAGEMENT: alcune definizioni e indicazioni generali

ATTUAZIONE DEL PROGETTO E IL MANAGEMENT: alcune definizioni e indicazioni generali ATTUAZIONE DEL PROGETTO E IL MANAGEMENT: alcune definizioni e indicazioni generali Cos è un progetto? Un iniziativa temporanea intrapresa per creare un prodotto o un servizio univoco (PMI - Project Management

Dettagli

Relazione sul data warehouse e sul data mining

Relazione sul data warehouse e sul data mining Relazione sul data warehouse e sul data mining INTRODUZIONE Inquadrando il sistema informativo aziendale automatizzato come costituito dall insieme delle risorse messe a disposizione della tecnologia,

Dettagli

Come realizzare una buona presentazione (traduzione libera a cura della redazione di EpiCentro)

Come realizzare una buona presentazione (traduzione libera a cura della redazione di EpiCentro) Come realizzare una buona presentazione (traduzione libera a cura della redazione di EpiCentro) Quando si realizzano dei documenti visivi per illustrare dati e informazioni chiave, bisogna sforzarsi di

Dettagli

MOSSE PER COSTRUIRE UN INDUSTRIA EUROPEA PER IL TERZO MILLENNIO

MOSSE PER COSTRUIRE UN INDUSTRIA EUROPEA PER IL TERZO MILLENNIO MOSSE PER COSTRUIRE UN INDUSTRIA EUROPEA PER IL TERZO MILLENNIO Premessa: RITORNARE ALL ECONOMIA REALE L economia virtuale e speculativa è al cuore della crisi economica e sociale che colpisce l Europa.

Dettagli

CAPITOLO 3. Elementi fondamentali della struttura organizzativa

CAPITOLO 3. Elementi fondamentali della struttura organizzativa CAPITOLO 3 Elementi fondamentali della struttura organizzativa Agenda La struttura organizzativa Le esigenze informative Tipologia di strutture Struttura funzionale Struttura divisionale Struttura per

Dettagli

Integrazione. Ecad. Mcad. Ecad - MENTOR GRAPHICS

Integrazione. Ecad. Mcad. Ecad - MENTOR GRAPHICS Integrazione Ecad Mcad Ecad - MENTOR GRAPHICS MENTOR GRAPHICS - PADS La crescente complessità del mercato della progettazione elettronica impone l esigenza di realizzare prodotti di dimensioni sempre più

Dettagli

ACCREDITAMENTO EVENTI

ACCREDITAMENTO EVENTI E.C.M. Educazione Continua in Medicina ACCREDITAMENTO EVENTI Manuale utente Versione 1.5 Maggio 2015 E.C.M. Manuale utente per Indice 2 Indice Revisioni 4 1. Introduzione 5 2. Accesso al sistema 6 2.1

Dettagli

Manipolazione di testi: espressioni regolari

Manipolazione di testi: espressioni regolari Manipolazione di testi: espressioni regolari Un meccanismo per specificare un pattern, che, di fatto, è la rappresentazione sintetica di un insieme (eventualmente infinito) di stringhe: il pattern viene

Dettagli

Aiutare le persone a trovare lavoro. Il Fondo sociale europeo al lavoro. L Europa sociale

Aiutare le persone a trovare lavoro. Il Fondo sociale europeo al lavoro. L Europa sociale Il Fondo sociale europeo al lavoro Aiutare le persone a trovare lavoro Il Fondo sociale europeo (FSE) finanzia progetti in tutta l UE per consentire a più persone di trovare posti di lavoro migliori, attraverso

Dettagli