Università Politecnica delle Marche

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Università Politecnica delle Marche"

Transcript

1 Università Politecnica delle Marche Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica Dipartimento di Ingegneria dell'informazione CONTINUOUS INTEGRATION IN UNA WEB AGENCY Laureando: Giorgio Mandolini Relatrice: Prof.ssa Claudia Diamantini Anno Accademico 2010/2011

2

3 L entusiasmo è quando le gambe iniziano il primo passo ed il cuore è già a destinazione

4 Indice Indice 1 Introduzione Obiettivi Trattazione degli argomenti La Continuous Integration Definizione ed obiettivi Ciclo di vita del software Modello di sviluppo Waterfall Modello di sviluppo Iterativo Continuous Integration e modello di sviluppo iterativo Panoramica di un ambiente di Continuous Integration Best practices della Continuous Integration...12 i

5 Indice Utilizzo di un sistema di controllo versione Centralizzare tutto il necessario Automatizzare le build Build testate automaticamente Commit frequenti Eseguire delle build private nelle workstation locali Non inviare codice diffettoso Eseguire una build ad ogni cambiamento Non scaricare codice difettoso Riparare immediatamente le build difettose Trattare il database come il codice sorgente Garantire un feedback rapido ed efficiente Vantaggi offerti Rilasciabilità del software Rivelazione degli errori Visibilità di progetto ed aumento della comunicazione Qualità del codice Applicazione della metodologia: analisi iniziale Analisi della situazione iniziale Prima dell'introduzione del sistema di controllo versione Dopo l'introduzione del sistema di controllo versione...32 ii

6 Indice 3.2 Analisi delle mancanze Environment eterogenei Mancanza di controllo sull'integrazione Mancanza di visibilità di progetto Nessuna integrazione del database Difficoltà di ingresso nel progetto Difficoltà nel rilascio di demo Difficoltà di rilascio dell'applicazione Progettazione del cambiamento Scelta degli strumenti Sistema di controllo versione Web Server e DBMS Build scripting system Strumenti di testing Server di Continuous Integration Standardizzazione delle workstation e dei progetti Standardizzazione della struttura cartelle _data library _test web...48 iii

7 Indice _xhtml Comandi fondamentali Standardizzazione del database Introduzione del build scripting system Il target build Il target make-sql Introduzione di uno script di installazione Introduzione dei test Installazione del server di Continuous Integration Training del personale Lezioni frontali Redazione di documenti operativi Post sul corporate blog Risultati ottenuti Soluzione del problema degli environment eterogenei Soluzione del problema di integrazione del codice Soluzione del problema della visibilità di progetto Soluzione del problema di integrazione del DB Soluzione del problema di ingresso al progetto Soluzione del problema delle demo Futuri sviluppi: automatizzare il deploy iv

8 Indice 6 Bibliografia Letteratura Risorse e strumenti...72 v

9 1 Introduzione 1 Introduzione La seguente tesi si occupa di descrivere il lavoro svolto in una web agency 1, presso la quale è stata presa in considerazione l'adozione della pratica della Continuous Integration. Verranno trattate tutte le fasi che hanno contribuito alla realizzazione del lavoro: da uno studio iniziale della metodologia da introdurre, all'applicazione dei cambiamenti necessari al fine di una sua corretta implementazione. 1.1 Obiettivi L'obiettivo principale del lavoro svolto è lo studio e l'implementazione di un sistema informativo che organizzi l'azienda secondo le best practices della Continuous Integration, al fine di migliorare il processo di sviluppo software. Verranno introdotti 1 e-xtrategy s.r.l. 1

10 1 Introduzione strumenti come un sistema di controllo versione ed un server di Continuous Integration, affiancati ad un insieme di regole da rispettare per ottenere il rispetto della pratica ed il raggiungimento dei benefici offerti. 1.2 Trattazione degli argomenti Nel capitolo 2 viene illustrata la Continuous Integration, definendo quali sono i suoi obiettivi ed il problema dell'integrazione del software; viene fornita una panoramica generale di un ambiente tipico di C.I., delle best practices che lo caratterizzano e dei vantaggi promessi dall'utilizzo di questa metodologia. Il capitolo 3 si occupa dell'analisi delle mancanze ed inefficienze riscontrate in azienda: viene fornita una descrizione della metodologia di sviluppo utilizzata prima e dopo l'introduzione del sistema di controllo versione, analizzando i problemi riscontrati dal team di sviluppo in entrambi i casi. Nel capitolo 4 verranno illustrati tutti i cambiamenti necessari al fine di introdurre la Continuous Integration. In questa fase di progettazione saranno motivate le scelte tecniche, secondo due criteri: l'ambito di sviluppo dell'azienda (web application) e l'eventuale preesistenza di strumenti già adatti alla Continuous Integration. Il capitolo 5 descrive i risultati ottenuti a seguito dei cambiamenti introdotti nel capitolo 4, focalizzando l'attenzione, punto per punto, sui problemi riscontrati nel capitolo 3. In questa fase verranno espresse infine delle conclusioni sul lavoro svolto ed eventuali sviluppi futuri. 2

11 2 La Continuous Integration 2 La Continuous Integration In questo capitolo viene illustrata la Continuous Integration, definendo quali sono i suoi obiettivi ed il problema dell'integrazione del software; viene fornita una panoramica generale di un ambiente tipico di C.I., delle best practices che lo caratterizzano e dei vantaggi promessi dall'utilizzo di questa metodologia. 2.1 Definizione ed obiettivi La Continuous Integration è una pratica emersa nella comunità Extreme Programming (XP) 2, ed i principali sostenitori, Martin Fowler 3 e Kent Beck 4, iniziarono a parlarne intorno al Extreme Programming 3 Martin Fowler 4 Kent Beck Beck.htm 3

12 2 La Continuous Integration In accordo con la definizione 5 data da Martin Fowler, si può definire la Continuous Integration una pratica di sviluppo software dove i membri di un team integrano il proprio lavoro frequentemente, da una a più volte al giorno. Ogni integrazione deve essere verificata da una build automatizzata, che include dei test, per individuare errori di integrazione il più presto possibile e permettere ad un team di sviluppare software rapidamente. Il problema dell'integrazione non è nuovo nel campo dello sviluppo ed è tanto più complesso quanto più crescono le dimensioni del software e del team che ne è incaricato allo sviluppo: al crescere della complessità, infatti, cresce anche la necessità di integrare e di garantire il corretto funzionamento di tutti i componenti sviluppati dai diversi membri del team. L'obiettivo principale della Continuous Integration è appunto quello di semplificare l'integrazione del software, facendola diventare parte integrante del processo di sviluppo anziché relegarla ad una fase successiva. 5 Continuous Integration, Martin Fowler 4

13 2 La Continuous Integration 2.2 Ciclo di vita del software Possiamo mettere a confronto due modelli di processo di svulippo software ed analizzare l'impatto della fase di test/integrazione su ciascuno di essi: modello tradizionale Waterfall o A cascata modello Incrementale/Iterativo Modello di sviluppo Waterfall Figura 2.1 Modello di sviluppo Waterfall: il processo scorre dal basso verso l'alto, come una cascata. Nel modello di sviluppo waterfall ogni fase produce un output che è l'input della fase successiva. 5

14 2 La Continuous Integration L'intero software passa per ciascuna fase: 1. Requirements: viene effettuata la raccolta, l'analisi e la ristrutturazione dei requisiti. Vengono definiti i requisiti non elicitati in fase di raccolta, che può essere eseguita più volte, presso i vari stakeholders del sistema. 2. Design: viene progettato il software, in modo da rispettare i requisiti definiti nello step precedente. In questa fase viene scelta l'architettura, definite le interfacce delle classi e le relazioni tra di esse. 3. Implementation: il team procede con lo sviluppo vero e proprio del software, traducendo in linee di codice quanto progettato in fase di design. 4. Verification: tutti i componenti implementati vengono messi insieme ed il software testato. E' qui che avviene l'integrazione. 5. Maintenance: il software è entrato in produzione, in questa fase si procede al suo mantenimento, come eventuali bug fix o aggiornamenti. 6

15 2 La Continuous Integration Modello di sviluppo Iterativo Figura 2.2 Modello di sviluppo Iterativo, il processo evolve all'interno di ciascuna iterazione, a seguito della quale avviene un rilascio di software già funzionante. Nel modello di sviluppo iterativo, si riconoscono fasi simili al modello waterfall, ma in questo caso non si fa passare l'intero software per ogni fase, bensì una sola porzione alla volta. Anche in questo modello ogni fase produce un output che è l'input della fase successiva, con la differenza che al termine di ciascuna iterazione il software sarà aumentato di funzionalità. Ad ogni iterazione si ha una fase di rilascio (deploy) di software già integrato e funzionante. Esclusa la prima iterazione, tutte le successive avranno come input il software già presente ed un insieme di nuovi requisiti da implementare Continuous Integration e modello di sviluppo iterativo Sulla base delle caratteristiche dei modelli di sviluppo precedentemente illustrati, si può 7

16 2 La Continuous Integration affermare che la Continuous Integration ben si coniuga con una metodologia incrementale/iterativa. Su questo tipo di modelli di sviluppo infatti, l'integrazione del software è un evento che avviene frequentemente a differenza del modello a cascata, in cui viene fatta solamente al termine dell'implementazione, per poi essere testata nella sua interezza in fase di collaudo e verifica. Il vantaggio di un modello iterativo sta quindi nel costo di gestione dei bug, sia di sviluppo che di integrazione. E' riconosciuto infatti che tale costo è tanto più elevato quanto più tardi viene scoperto. La Continuous Integration ha inoltre come ulteriore scopo quello di individuare eventuali errori ancora prima: questo significa che per rilevare malfunzionamenti non è necessario attendere il termine dell'iterazione o dell'intero processo di sviluppo. Di seguito due grafici qualitativi, per il costo di risoluzione di un bug: Figura 2.3 Andamento del costo di un bug in funzione del momento di rivelazione, per il modello di sviluppo Waterfall. 8

17 2 La Continuous Integration Figura 2.4 Andamento del costo di un bug in funzione del momento di rivelazione, per il modello di sviluppo Iterativo. Com'è possibile notare, nel caso di un approccio iterativo le tre macro fasi Requisiti, Sviluppo e Test vengono ripetute ad ogni iterazione, portando ai seguenti vantaggi: Requisiti aggiornati ad ogni iterazione: il cliente può decidere di cambiare requisiti in corso d'opera, senza l'implicazione una completa riscrittura del software. Sviluppo incrementale: il software viene scritto sulla base dei requisiti dell'iterazione corrente, che sono quindi temporalmente vicini ed a priorità più alta. Il rischio di scrivere componenti inutilizzati o sovraingegnerizzati è relegato alla singola iterazione e non a tutto lo sviluppo. Test frequenti: ciascuna nuova funzionalità aggiunta viene testata al momento della sua introduzione, rispettando quindi il criterio per cui un bug è tanto meno costoso quanto prima viene scoperto. 9

18 2 La Continuous Integration 2.3 Panoramica di un ambiente di Continuous Integration Gli attori fondamentali in un ambiente di Continuous Integration sono: Lo sviluppatore. Un sistema di controllo versione. Un sistema di automazione delle build. Un sistema di testing delle build. Un server di Continuous Integration. Figura 2.5 Panoramica di un ambiente di Continuous Integration, con i principali attori che contribuiscono al funzionamento del sistema. 10

19 2 La Continuous Integration Il funzionamento generale di un sistema di Continuous Integration è il seguente: 1. Lo sviluppatore esegue i cambiamenti necessari al codice: implementa la feature richiesta, fino a che non la ritiene completata. Insieme ad essa, scrive i test automatici che la riguardano. 2. Esegue una build privata sulla propria workstation: attraverso il processo di build vengono eseguiti tutti i task necessari alla corretta preparazione del software, prima del suo rilascio. In questa fase, oltre alla compilazione, intervengono i test automatici. 3. Invio del codice al repository: una volta soddisfatti tutti i test, lo sviluppatore invia i propri cambiamenti al sistema di controllo versione. 4. Build di integrazione: il Continuous Integration server periodicamente reperisce l'ultima versione del software dal repository ed effettua una nuova build automatica, comprensiva di test, che sarà il prodotto dei cambiamenti inviati da tutti gli sviluppatori del team. 5. Feedback: se il processo di build da parte del Continuous Integration server va a buon fine, erro genera un feedback positivo (es: tramite e- mail o un monitor ben visibile dal team) ed il software è pronto al rilascio. Viceversa il feedback sarà negativo e la soluzione del problema individuato diventa prioritaria rispetto lo sviluppo di nuove funzionalità 11

20 2 La Continuous Integration 2.4 Best practices della Continuous Integration Di seguito verranno illustrate le pratiche fondamentali per implementare correttamente un sistema di Continuous Integration e come esse influenzano il processo di sviluppo. E' importante sottolineare che la Continuous Integration è in primis una pratica e come tale agisce radicalmente sul processo di sviluppo Utilizzo di un sistema di controllo versione L utilizzo di un sistema di controllo versione è un requisito fondamentale per costruire un ambiente di Continuous Integration. Lo scopo di questo strumento è la gestione dei cambiamenti del codice sorgente e di tutto il necessario per la corretta compilazione del software. L'obiettivo principale è quello di avere un repository centralizzato, che permetta di gestire e monitorare i cambiamenti che avvengono sulla base di codice. Non vi è preferenza sulla scelta dello specifico strumento: l'unico requisito è quello di avere un unico punto di accesso al codice, detto mainline o trunk, mentre le differenze che intercorrono tra i vari sistemi di controllo versione non sono influenti. Con questo strumento si introduce la possibilità di rollback dei cambiamenti: viene tenuta traccia della storia di ciascun file, fornendo la possibilità di tornare indietro in caso di necessità. 12

21 2 La Continuous Integration Centralizzare tutto il necessario La Continuous Integration impone che il software e tutto il necessario al suo funzionamento, compresi framework, librerie, dipendenze esterne, test e build script, sia messo sotto controllo versione all interno del repository: esso dovrà fungere da single source point del codice e l'applicazione dovrà essere in grado di funzionare solamente con ciò che vi è contenuto, senza interventi esterni o aggiunte manuali. Questo è necessario per garantire uniformità negli environment di sviluppo: le librerie che i client degli sviluppatori usano per ciascun progetto provengono dal repository e non da fonti esterne, permettendo di: 1. Risparmiare tempo in termini di ricerca ed installazione delle librerie e delle dipendenze da parte dello sviluppatore. 2. Eliminare il rischio di installare versioni di librerie non aggiornate, mal funzionanti o non compatibili. Oltre a ciò, viene aumentata la velocità di ingresso al progetto da parte di eventuali nuovi membri del team: una volta ottenuto l'accesso al repository, non devono essere compiute ulteriori azioni esterne ad esso. 13

22 2 La Continuous Integration Automatizzare le build Il processo di build non include la sola compilazione del codice, ma anche un determinato numero di azioni, tra le quali il setup e popolazione del database con valori noti (fixtures), che permettono al software di essere correttamente costruito e reso funzionante. E' necessario rendere questo insieme di passaggi automatico attraverso un singolo script di build perché in questo modo: 1. Si limita l intervento umano: la probabilità di errori ed omissioni viene ridotta, in quanto lo sviluppatore utilizza un singolo comando. 2. Si migliora la riproducibilità: tutti gli sviluppatori eseguono gli stessi passaggi in maniera identica, evitando il cosiddetto but it works on my machine, dove il software risulta funzionante su alcuni ambienti e non su altri. 14

23 2 La Continuous Integration Figura 2.1 Tipici step di un generico script di build. Lo script stesso deve essere considerato parte del software e come tale soggetto ad evoluzione. 15

24 2 La Continuous Integration Build testate automaticamente Una delle peculiarità della Continuous Integration è l'utilizzo di test automatici che devono essere inoltre inglobati nei build script. A build completata lo sviluppatore conoscerà il risultato del proprio lavoro e grazie all'esito dei test sarà in grado di averne confidenza sulla bontà. Non è contemplata la verifica ed il collaudo manuale dell'applicazione, esplorando di volta in volta ciascuna delle funzionalità richieste, perché è necessario evitare omissioni, soprattutto nel modello di sviluppo che si sta introducendo. La fase di test viene infatti ripetuta ad ogni build, non è umanamente possibile testare il software manualmente numerose volte al giorno, per ogni cambiamento introdotto. Testare le applicazioni manualmente porta alla cattiva pratica di non verificare quelle parti di codice per le quali si da per scontato il corretto funzionamento, in quanto si assume che le modifiche introdotto non influenzino certi punti del software. Questo, sebbene logico, è comunque non accettabile in un ambiente in cui la garanzia di rilevare errori il prima possibile è considerata una priorità. I test automatici servono ad evitare questa situazione: minori saranno le assunzioni e maggiori saranno le garanzie di un software effettivamente funzionante. I test automatici sono sempre ripetibili nella stessa identica maniera, in qualsiasi istante: ad ogni build verificano tutte le funzionalità per cui sono stati scritti, più velocemente ed in maniera più affidabile di un umano. Non è pensabile che una persona riesca ad eseguire un gran numero di volte la stessa batteria di test senza introdurre di volta in 16

25 2 La Continuous Integration volta piccole differenze, perché, proprio per natura, è influenzabile da molteplici fattori non deterministici come l'umore, la concentrazione e la stanchezza. I test automatici sono invece deterministici e si fanno carico di un compito ripetitivo e noioso, ma al tempo stesso critico Commit frequenti Uno dei principi fondamentali per ottenere vantaggi dalla Continuous Integration è quello di integrare poco, presto e spesso. Più si attende prima di inviare codice al repository, più il processo di integrazione richiederà del tempo, per via della maggior quantità di dati da integrare, oltre al fatto che gli altri membri del team, nel frattempo, non avranno tenuto conto degli ultimi cambiamenti. Si possono utilizzare le tecniche a seguito descritte per aumentare la frequenza di commit al repository: 1. Eseguire piccoli cambiamenti: non cambiare più componenti software insieme ma scegliere piccoli task per i quali scrivere dei test automatici ed implementare il codice necessario al loro soddisfacimento. Una volta eseguiti e passati tutti i test, inviare il codice al repository. 2. Suddividere il lavoro in task atomici: in altre parole, favorire la 17

26 2 La Continuous Integration scrittura di unit of work a bassa interdipendenza, quindi semplici da integrare, con codice più snello e meno prono a complessità. In altri termini rispettare il KISS principle (Keep It Simple, Smart) [4], secondo il quale la migliore soluzione ad un problema, a parità di risultati, è quella a complessità minore. La principale motivazione a supporto di questa regola risiede nella probabilità di introduzione di un bug a seguito di una commit. Possiamo infatti affermare che la probabilità di introduzione di un errore di integrazione è funzione crescente del numero delle linee di codice che hanno influenzato la modifica. Per cui: P bug (N 1 ) P bug ( N 1 ) se N 1 N 2, con N 1,N 2 numero di lineedi codice affette dalla modifica. Ne consegue che piccoli cambiamenti integrati frequentemente, rappresentano un criterio di sviluppo più sostenibile, in cui si punta più al non introdurre bug, piuttosto che correggerli in un secondo momento Eseguire delle build private nelle workstation locali Prima di iniziare con lo sviluppo di nuove funzionalità, ciascun membro è tenuto a scaricare dal repository l ultima versione del software. A questo punto potrà lavorare 18

27 2 La Continuous Integration nella propria workstation, effettuando i cambiamenti necessari al completamento del proprio lavoro. Una volta terminato dovrà essere effettuata una build del software sulla workstation ed osservarne i risultati. Se tutto procede correttamente, prima di inviare le proprie modifiche al repository, scaricherà di nuovo da questo gli eventuali cambiamenti effettuati nel frattempo dagli altri sviluppatori e rilancerà la build, integrando di fatto il software. Se tutto va a buon fine, è stato fatto un primo passo verso l integrazione: i cambiamenti sono stati integrati ed è possibile aggiornare la code-base eseguendo la commit verso il repository. Figura 2.2 Step fondamentali eseguiti dallo sviluppatore per eseguire una build di integrazione locale. 19

28 2 La Continuous Integration Non inviare codice diffettoso In caso di fallimento dei test durante la build privata, lo sviluppatore dovrà correggere i malfunzionamenti e rieseguire la build fino alla completa risoluzione dei problemi riscontrati. Non potrà, in nessun caso, inviare modifiche al repository se i test non certificano che esso è correttamente funzionante. Con questa regola si minimizza la probabilità di avere software non funzionante nel repository: la copia malfunzionante resterà confinata nella macchina dello sviluppatore che si occuperà di ripararla Eseguire una build ad ogni cambiamento Ogni volta che il repository viene aggiornato con nuovi cambiamenti, il codice necessita di essere ritestato per avere la garanzia che non siano stati introdotti dei difetti. Successivamente alle build private, quindi, si esegue la vera e propria build di integrazione, su di una macchina dedicata che deve riprodurre il più fedelmente possibile il vero ambiente di produzione. Al pari dei client degli sviluppatori, è importante che questa macchina sia priva di dipendenze e librerie spurie che non provengano direttamente dal repository: in questo modo si accerta che il lavoro dello sviluppatore sia ancora riproducibile e non dipenda da una particolare configurazione a livello locale. L integration build può essere manuale o effettuata automaticamente tramite un Continuous Integration server. 20

29 2 La Continuous Integration Sebbene l'utilizzo di un integration server non sia obbligatorio, è comunque raccomandato usarne uno: esso infatti rileverà i cambiamenti sul repository ed eseguirà le build automaticamente, fornendo inoltre una dashboard con report sui test, code coverage, strumenti di analisi aggiuntivi ed eventuale documentazione auto-generata Non scaricare codice difettoso Nell'ipotesi in cui la build di integrazione fallisca, nonostante siano state correttamente effettuate le build private, sorge il problema della broken build : è entrato un bug nella code base e tutti i membri del team che andranno a scaricarlo otterrebbero del software non funzionante. Quando questo avviene la pratica impone di non scaricare affatto il codice difettoso e, se possibile, continuare lo sviluppo tramite la propria copia locale, sebbene non aggiornata, per poi integrarla in un secondo momento. Piuttosto che sviluppare eventuali workaround per far funzionare il software difettoso nella propria workstation è preferibile aiutare gli altri membri del team a far tornare la build nel suo corretto stato di funzionamento Riparare immediatamente le build difettose E' compito dello sviluppatore che ha eseguito l'ultima commit risolvere il problema di una build difettosa. E' importante che questo venga fatto immediatamente, perché è un 21

30 2 La Continuous Integration problema che coinvolge tutto il team, che a questo punto non può avere fiducia su quanto contenuto nel repository. Nell'ipotesi in cui la build di integrazione fallisca, infatti, deve essere considerata come prioritaria la soluzione dei problemi emersi piuttosto che lo sviluppo di nuove funzionalità. Come detto precedentemente, è vietato scaricare codice non funzionante: di fatto la regola descritta in precedenza attiverebbe subito tutto il team alla soluzione del problema, in quanto non potrebbe aggiornare il codice delle macchine locali per continuarne lo sviluppo Trattare il database come il codice sorgente Il database dell'applicazione fa parte del software e come tale deve essere posto sotto controllo di versione. Figura 2.2 La sequenza dell'integrazione automatica del db. Il build script si occupa di far eseguire lo script di definizione al DBMS, per poi procedere con l'inserimento dei dati. 22

31 2 La Continuous Integration E' compito del build script gestire il DB: così facendo si può tener traccia anche dei cambiamenti effettuati sulla struttura e sui dati nella stessa maniera con cui viene effettuato con il codice sorgente. Per fare ciò è necessario gestire su file le procedure di Data Definition Language (DDL) e Data Manipulation Language (DML) ed aggiungerle al repository, che in questo modo continua ad essere l'unica fonte a cui attingere per lo sviluppo del sofware. Figura 2.3 Esempio di integrazione del database, dove entrambi gli sviluppatori possono eseguire modifiche ai dati ed allo schema. 23

32 2 La Continuous Integration Garantire un feedback rapido ed efficiente E' importante che il processo di build rapido: come regola empirica ci si impone un limite di attesa massimo di 10 minuti per il risultato della build (regola del 10 minute build ). Questo è necessario al fine di non indurre gli sviluppatori ad accumulare troppe linee di codice prima di rieseguire la build, andando contro uno dei principi cardine della Contiuous Integration. Per evitare questo anti pattern sono previste più soluzioni: 1. Eseguire delle staged-build: le build private vanno accompagnate solamente da test unitari e le build di integrazione divise in due: test unitari prima (per individuare subito i problemi più grossolani) per le build lanciate ad ogni commit e test più approfonditi (unitari e funzionali, analisi del codice, delle dipendenze, del code-style, ecc) per build lanciate in un successivo momento, per esempio schedulate in notturna o in seguito al successo delle precedenti build eseguite immediatamente dopo la commit. 2. Aumentare le risorse hardware: garantire una sufficiente potenza di calcolo, sia per le workstation sia per la macchina dedicata all'integrazione finale del codice. Avere una build veloce serve all'ottenimento di un feedback rapido che deve essere coadiuvato da meccanismi che lo rendano facilmente individuabile e interpretabile, 24

33 2 La Continuous Integration alcune soluzioni proposte dalla pratica sono: Un monitor sempre ben visibile al team, sul quale è possibile vedere continuamente lo stato delle build dei vari progetti. Meccanismi di allarme visivi e/o sonori per segnalare malfunzionamenti (lampada verde/rossa, allarme sonoro). Una combinazione dei precedenti. A prescindere dal criterio di feedback scelto, è importante che esso sia incentrato sulle informazioni utili ed essenziali, tutto il superfluo aumenta il rischio di far passare inosservati messaggi realmente importanti. A tal proposito è utile considerare i seguenti fattori, tra essi correlati: L'informazione: ciò che il sistema deve comunicare. Il destinatario: chi deve ricevere il messaggio. Gli sviluppatori sono interessati allo stato di funzionamento della build, mentre un Project Manager è più interessato ad un andamento globale del progetto (es: metriche sulla qualità del software). 25

34 2 La Continuous Integration Il modo: il meccanismo di comunicazione scelto, come ad esempio una barra verde/rossa per lo stato di una build o un grafico (anziché dei dati in forma tabellare) per il suo andamento nel tempo. I tempi: le informazioni sono deperibili nel tempo. E' fondamentale che esse giungano a destinazione e vengano correttamente interpretate entro un determinato tempo massimo, altrimenti diventano inutili. 2.5 Vantaggi offerti Di seguito verranno illustrati i principali vantaggi offerti dal rispetto delle best pratices imposte dalla Continuous Integration Rilasciabilità del software Grazie ad un approccio incrementale, lo sviluppo non è più eseguito orizzontalmente. In altre parole la progettazione del software non viene più fatta a livelli (es: gui, business logic, database) che poi vengono integrati, ma diventa verticale sulla singola funzionalità in fase di realizzazione. Nel primo caso il software è rilasciabile solamente al termine dell'integrazione finale di tutti i livelli, mentre nel secondo ogni funzionalità porta già con se la porzione dei livelli interessati. Grazie alle integrazioni continue tra tutte le funzionalità, nel repository è sempre presente una versione funzionante del software, anche se incompleto, mentre nel 26

35 2 La Continuous Integration caso precedente ciò non è possibile, in quanto un livello interamente sviluppato non ha alcuna utilità se il livello da cui dipende non è stato ancora completato. Intero software GUI Business Logic Database Figura 2.4 Sviluppo non incrementale: il software viene sviluppato orizzontalmente, mentre l'integrazione è verticale. Funzionalità 1 Funzionalità 2 Funzionalità 3 Funzionalità n GUI 1 GUI 2 GUI 3 GUI n Business Logic 1 Business Logic 2 Business Logic 3 Business Logic n Database 1 Database 2 Database 3 Database n Figura 2.5 Sviluppo incrementale: il software viene sviluppato verticalmente, mentre l'integrazione è orizzontale Rivelazione degli errori Il rispetto della pratica delle build private e l'utilizzo dei test automatici fornisce un sistema efficiente di prevenzione e rivelazione degli errori, che vengono individuati velocemente anche grazie ad un feedback opportuno. L'eseguire una build ad ogni cambiamento è un supporto alla rivelazione istantanea dei bug, che restano confinati a porzioni di codice limitate e recenti. Grazie a ciò la risoluzione di eventuali problemi viene semplificata. 27

36 2 La Continuous Integration Visibilità di progetto ed aumento della comunicazione L'utilizzo di un repository in cui centralizzare tutti gli elementi che compongono il software, coadiuvato da un meccanismo di feedback opportuno aumenta la visibilità del progetto da parte del team, che in questo modo è in grado di monitorarne costantemente l'andamento. In questo modo si ha un aumento di comunicazione sia interna che verso l'esterno: è possibile infatti tenere aggiornato il cliente sull'andamento generale del progetto e studiare con esso eventuali misure correttive o cambi di direzione, già prima della scadenza finale Qualità del codice L'utilizzo di un Continuous Integration server permette di eseguire automaticamente e continuamente una serie di task ripetitivi e dispendiosi, come ad esempio: L'analisi della complessità del codice L'analisi dell'interdipendenza tra classi Il rispetto del code style L'analisi della duplicazione del codice L'analisi della copertura dai test 28

37 2 La Continuous Integration Tutte queste operazioni tendono ad aumentare la qualità del prodotto, è infatti possibile scegliere di far fallire una build qualora una o più di queste metriche scendano al di sotto di una soglia prestabilita ed imporre quindi il rispetto degli standard prefissati. 29

38 3 Applicazione della metodologia: analisi iniziale 3 Applicazione della metodologia: analisi iniziale Questo capitolo si occupa dell'analisi delle mancanze ed inefficienze riscontrate in azienda: viene fornita una descrizione della metodologia di sviluppo utilizzata prima e dopo l'introduzione del sistema di controllo versione, analizzando i problemi riscontrati dal team di sviluppo in entrambi i casi. 3.1 Analisi della situazione iniziale Al momento dell'analisi, l'azienda era già in una situazione di transizione verso l'utilizzo di un sistema di controllo versione, nello specifico SVN 6, per la gestione del codice. Lo strumento era già stato introdotto e correttamente configurato, ma non erano ancora state introdotte le conoscenze e la corretta disciplina per un suo utilizzo efficiente. 6 Apache Subversion 30

39 3 Applicazione della metodologia: analisi iniziale Prima dell'introduzione del sistema di controllo versione Lo sviluppo delle applicazioni web veniva effettuato tramite un server centrale contenente i sorgenti, il webserver ed il DBMS necessario alla loro esecuzione: le macchine client degli sviluppatori interagivano direttamente con esso. Gli sviluppatori, connessi ai sorgenti tramite mount point su rete locale effettuavano i cambiamenti necessari al completamento del proprio lavoro. L'approccio era quindi centralizzato, e prevedeva i seguenti step: 1. Accesso alle risorse del server di sviluppo tramite rete LAN, 2. modifica diretta dei file sorgente dell'applicazione in sviluppo, 3. accesso all'applicazione tramite browser web per la verifica dei risultati. Figura 3.1 Flusso di lavoro dell'azienda prima dell'introduzione del sistema di controllo versione. 31

40 3 Applicazione della metodologia: analisi iniziale Con questo approccio l'azienda ha lamentato vari inconvenienti, tra i quali: Mancanza di uno storico delle modifiche ai files e di chi le avesse effettuate. Impossibilità di poter effettuare dei rollback immediati, che non passassero necessariamente per il sistema di backup del server. Possibilità di collisione tra sviluppatori che potevano avere la necessità di modificare lo stesso file contemporaneamente. Blocco del lavoro dell'intero team di sviluppo qualora uno sviluppatore provocasse il malfunzionamento dell'applicazione Dopo l'introduzione del sistema di controllo versione Per i motivi appena citati si è proceduto all'installazione di Subversion sul server di sviluppo e gradualmente migrare tutti i lavori all'interno del nuovo repository. Il processo di sviluppo è quindi passato da centralizzato a distribuito: ogni client si connette al repository contenente i sorgenti, li scarica in locale e lavora con essi, per poi rimandarli al server una volta terminate le modifiche. La modalità appena introdotta è sensibilmente differente da quella vista in precedenza: ciascun client ora dovrà essere dotato di un proprio webserver per eseguire le applicazioni e di un proprio DBMS qualora queste ne richiedano uno. 32

41 3 Applicazione della metodologia: analisi iniziale Figura 3.2 Flusso di lavoro dopo l'introduzione del sistema di controllo versione. Il nuovo processo di sviluppo è caratterizzato quindi dai seguenti step: 1. Installazione del progetto sulla workstation: 1. Modifica manuale del file degli host locale per navigare l'applicazione web. 2. Creazione di un database dedicato all'applicazione. 2. Sviluppo del progetto: 1. Checkout del codice, dal repository verso la macchina client. 2. Sincronizzazione manuale del database, tramite l'importazione di 33

42 3 Applicazione della metodologia: analisi iniziale file SQL provenienti dalla versione legacy dell'applicazione o salvati nel repository. 3. Modifica dei sorgenti in locale. 4. Accesso all'istanza locale dell'applicazione tramite browser web per la verifica dei risultati. 5. Invio dei nuovi sorgenti al repository. 3.2 Analisi delle mancanze L'introduzione di SVN nel processo di sviluppo dell'azienda ha incontrato inizialmente una certa inerzia a causa della prospettiva di sviluppo letteralmente invertita. L'abitudine degli sviluppatori di lavorare direttamente con l'applicazione nel server di sviluppo si è scontrata con l'avere tante copie locali per ciascuna workstation. Di seguito, saranno descritti i probleami individuati Environment eterogenei Ogni client presenta delle differenze, più o meno marcate, a seconda delle preferenze dello sviluppatore che ne fa uso o della configurazione hardware/software. Tali differenze sono risultate essere: il sistema operativo utilizzato (Linux / Mac OS) la configurazione del webserver (es: i path fisici dove viene salvata 34

43 3 Applicazione della metodologia: analisi iniziale l'applicazione). la configurazione del DBMS (es: eterogeneità delle credenziali di accesso al database utilizzato da una determinata applicazione). Le librerie esterne ed i framework necessari al funzionamento del progetto che possono presentare discrepanze sul numero di versione o risiedere in path differenti. Di conseguenza quando l'applicazione viene scaricata sulla macchina locale potrebbe non funzionare correttamente e necessitare di una riconfigurazione. Dato per assunto che tutte le applicazioni siano ben scritte e quindi parametrizzabili tramite un singolo file di configurazione (es: config.xml) resta comunque il problema di dover gestire collisioni di configurazione che sono tante quante sono i client di sviluppo, più la configurazione finale per l'ambiente di produzione, dove la release dovrà lavorare per il cliente. Lo scenario è quindi il seguente: 1. Lo sviluppatore scarica l'applicazione 2. Effettua la riconfigurazione 3. Lavora sull'applicazione 4. Invia le modifiche al repository 35

44 3 Applicazione della metodologia: analisi iniziale Tale modalità evidenzia subito un'inefficienza: si nota infatti che ad ogni commit sul repository la configurazione viene di volta in volta sovrascritta, ed a causa di ciò si va incontro a due problemi: 1. La necessità di riconfigurare l'applicazione ad ogni aggiornamento ricevuto dal repository. 2. Nel repository non è mai presente una versione dell'applicazione che sia già rilasciabile e correttamente configurata per l'ambiente di produzione. Il primo problema è una criticità che abbassa l'efficienza e la produttività del team: oltre al tempo necessario all'effettiva riconfigurazione si introduce un fattore di rischio dovuto alla possibilità di commettere errori durante questa fase. In altre parole si sta sprecando tempo in un task che non porta alcun valore: la riconfigurazione non aggiunge funzionalità all'applicativo, tantomeno ne migliora alcune preesistenti, pertanto ha valore pari a zero. Il secondo problema è un fattore di rischio che potrebbe portare a problemi in fase di rilascio dell'applicazione, che porta con se altri due svantaggi: 1. Non si ha la certezza che l'applicativo sia effettivamente funzionante una volta rilasciato nell'ambiente di produzione. 36

45 3 Applicazione della metodologia: analisi iniziale 2. La pubblicazione di nuove features è ogni volta rallentata dal processo manuale di configurazione Mancanza di controllo sull'integrazione Con la modalità centralizzata ciascuno sviluppatore era costretto a lavorare su porzioni indipendenti dell'applicativo, in quanto non vi era nessun meccanismo di sviluppo concorrente. Con l'introduzione di Subversion questo limite è stato rimosso: grazie al controllo di versione è infatti possibile poter effettuare cambiamenti concorrenti anche sulle stesse aree di codice e poter gestire le collisioni tramite i meccanismi di risoluzione offerti dallo strumento. Resta però il problema dell'integrazione, cioè garantire che la risoluzione dei conflitti sia effettivamente corretta e non causi malfunzionamenti Mancanza di visibilità di progetto Diretta conseguenza del problema visto precedentemente è la mancanza di visibilità sul progetto: il fatto che il software funzioni sulla workstation locale dello sviluppatore non garantisce il corretto funzionamento della build presente nel repository. Qualora due o più sviluppatori lavorino sulla stessa area di codice, al momento della commit Subversion si occupa di segnalare l'avvenuta collisione e permetterne la 37

46 3 Applicazione della metodologia: analisi iniziale risoluzione del conflitto: sebbene questo sia un primo livello di protezione, non si ha comunque la garanzia che l'integrazione sia avvenuta correttamente. Ciascuno sviluppatore è infatti responsabile delle modifiche che introduce, ma senza un meccanismo che permetta automaticamente di evidenziare effetti collaterali in altri punti del codice si potrebbero introdurre inavvertitamente dei malfunzionamenti che in prima analisi potrebbero non essere visibili Nessuna integrazione del database Con l'abbandono del server centrale si è passati da un un'unica istanza dell'applicazione in sviluppo ad n istanze, una per ogni client coinvolto nel processo di sviluppo. Replicare il codice in tutte le workstation locali non è visto come un particolare problema, ma per quanto riguarda la gestione del database sono emerse alcune problematiche: Non esiste più un DBMS centralizzato, al quale tutti fanno riferimento Non c'è un meccanismo di integrazione tra i cambiamenti ai dati e alla struttura, effettuati nelle copie locali. Tali problematiche, non emergevano invece con il vecchio approccio centralizzato: la macchina di sviluppo era unica, come pure il DBMS e l'istanza dell'applicativo. 38

47 3 Applicazione della metodologia: analisi iniziale Difficoltà di ingresso nel progetto Una delle difficoltà avvertite dall'azienda è stata la difficoltà di ingresso nel progetto da parte di nuovi membri del team. E' necessario che tutto passi per un client locale, che deve essere configurato affinché sia in grado di ospitare correttamente il progetto, anche per piccolissime modifiche. Il tempo necessario al setup e bootstrap manuali dell'applicazione in locale, complice anche l'eterogeneità degli environment precedentemente descritta, spesso supera il tempo necessario all'implementazione delle modifiche richieste Difficoltà nel rilascio di demo Creare una demo del software significa consegnare al cliente una prima versione funzionante di ciò che è attualmente in sviluppo dentro il repository. Questo processo è risultato essere lento e macchinoso, in quanto eseguito manualmente. Emerge quindi la necessità di automatizzare questa fase e studiare un meccanismo che automaticamente si occupi di scaricare dal repository l'ultima versione del software e pubblicarla in un server di demo Difficoltà di rilascio dell'applicazione Un problema simile a quello del rilascio di demo, ma molto più delicato e critico è 39

48 3 Applicazione della metodologia: analisi iniziale quello del rilascio ufficiale. La differenza sta nel fatto che in questo caso la destinazione non è più il server di demo, in cui eventuali malfunzionamenti o imprecisioni possono essere ancora tollerati, ma nel server ufficiale di produzione, dove l'applicazione entrerà definitivamente in produzione per il cliente. Diventa quindi necessario l'utilizzo di strumenti come FTP o SFTP per l'invio dei files e prestare la massima attenzione nel non commettere errori in un ambiente in cui questi non sono assolutamente tollerabili. In questa fase si sta consegnando il software al cliente, è quindi necessario ripulirlo di tutti gli assets aggiuntivi come i files di gestione di Subversion e tutto ciò che non è necessario: mantenere questi files potrebbe rappresentare una vulnerabilità del sistema, oltre che uno spreco di spazio. 40

49 4 Progettazione del cambiamento 4 Progettazione del cambiamento In questo capitolo verranno illustrati tutti i cambiamenti necessari al fine di introdurre la Continuous Integration. In questa fase di progettazione saranno motivate le scelte tecniche, secondo due criteri: l'ambito di sviluppo dell'azienda (web application) e l'eventuale preesistenza di strumenti già adatti alla Continuous Integration. 4.1 Scelta degli strumenti La scelta è stata fatta preferendo tutti quegli strumenti inerenti alle tecnologie web, reputati quindi più adatti per la tipologia di applicazioni sviluppate dall'azienda. 41

50 4 Progettazione del cambiamento Sistema di controllo versione E' stato scelto il sistema di controllo di versione Subversion 7 (o SVN) in quanto già utilizzato dall'azienda presa in esame. Per quanto riguarda il server contenente il repository non sono state effettuate modifiche, perché già correttamente configurato per essere usufruito sia dalla rete locale interna che da remoto, tramite una connessione sicura SSH. Sono state dotate di un client SVN tutte le workstation che non ne erano munite, in modo da renderlo disponibile per tutta l'azienda Web Server e DBMS L'azienda sviluppa principalmente applicazioni web in PHP, per le quali il tipico web server è Apache 8. Il DBMS scelto, sempre in relazione al tipo di software sviluppato, è MySQL 9. La tipica installazione scelta è quindi di tipo LAMP (Linux, Apache, MySQL, PHP) per i client di tipo Linux, oppure MAMP (Mac, Apache, MySQL, PHP) per i client basati su sistema operativo Mac OS. Per entrambe è stato scelto il software Zend Server 10. Non sono state infine rilevate macchine dedicate allo sviluppo, dotate di sistema operativo Windows. 7 Apache Subversion 8 Apache HTTP Server Project 9 Oracle MySQL 10 Zend Server 42

51 4 Progettazione del cambiamento Build scripting system Come strumento per lo sviluppo ed esecuzione degli script di build è stato scelto Phing 11, in quanto specifico per il linguaggio PHP, con il quale è possibile scrivere eventuali plugin o estensioni. Esso fa uso di un file di build (di tipo XML), attraverso il quale è possibile definire una serie di attività (dette target ) composte da operazioni (detti task ) da eseguire in automatico. I task che si possono eseguire attraverso Phing coprono ampiamente le richieste della Continuous Integration, infatti con essi si possono effettuare, tra le altre, le seguenti operazioni: operazioni su file system operazioni su database esecuzione di test automatici operazioni FTP ed SFTP interazione con la shell fornita dal sistema operativo 11 Phing 43

52 4 Progettazione del cambiamento Strumenti di testing Con i test unitari si verifica il funzionamento dell'applicazione ad un livello atomico: le classi dell'applicazione vengono testate singolarmente e si testano uno a uno i metodi che le compongono. Con i test funzionali si testa l'applicazione ad un livello più alto: attraverso una procedura automatizzata si simula l'interazione uomo-macchina e si verifica se i risultati ottenuti combaciano con quelli attesi. Per lo sviluppo dei test automatici sono stati scelti i seguenti software: 1. PHPUnit 12 per la scrittura di test unitari. 2. Selenium IDE e Selenium RC 13 per i test funzionali. La scelta di PHPUnit è motivata dal fatto che l'azienda sviluppa le proprie applicazioni utilizzando il linguaggio PHP. PHPUnit fa inoltre parte della famiglia dei framework di testing xunit (disponibile per un elevato numero di linguaggi tra cui Java con JUnit e.net con NUnit) con la quale condivide la sintassi e la modalità di funzionamento. 12 PHPUnit 13 Selenium, Web Browser Automation 44

53 4 Progettazione del cambiamento Figura 4.1 Screenshot del software Selenium IDE, con il quale effettuare la registrazione delle sessioni di navigazione. Selenium IDE e Selenium RC sono stati invece scelti in quanto le applicazioni sviluppate dall'azienda sono nello specifico dei siti internet: Selenium IDE consente di registrare delle sessioni di navigazione, mentre Selenium RC in accoppiata a PHPUnit è in grado di rieseguirle senza intervento umano, lanciando una istanza di browser reale. 45

54 4 Progettazione del cambiamento Server di Continuous Integration Durante la fase di analisi in azienda, è stato scelto Hudson 14 come server di Continuous Integration, in quanto di agevole installazione e configurazione, ma soprattutto integrabile con gli strumenti introdotti in precedenza. Hudson offre infatti supporto a: 1. Numerosi sistemi di controllo di versione, tra cui SVN 2. Vari linguaggi di build scripting, tra cui phing Supporta infine in maniera soddisfacente l'integrazione con i risultati forniti dai test eseguiti con il framework PHPUnit, permettendo la visualizzazione nella dashboard sia dei risultati che di ulteriori dettagli come la code coverage. 4.2 Standardizzazione delle workstation e dei progetti A seguito dell'installazione degli strumenti elencati precedentemente, tutte le workstation sono state configurate in modo da avere a disposizione tutti i comandi necessari ad eseguire il processo di build del software e tutte le operazioni ad esso connesse che vanno automatizzate. 14 Hudson Continuous Integration 46

55 4 Progettazione del cambiamento Oltre alla standardizzazione degli environment delle worstation si è proceduto con la definizione di una struttura comune a tutti i progetti Standardizzazione della struttura cartelle Per ciascun progetto è stata definita una struttura cartelle consistente, che va sempre rispettata con rigore, in modo da permettere a ciascun membro del team di reperire il necessario nel più breve tempo possibile e senza ambiguità. Di seguito la struttura scelta, comprensiva dei files fondamentali:. _data database.create.db.sql database.dati.sql database.struttura.sql install.sh LINUX_dominio.conf MAC_httpd.conf library _tests functional unit web index.php _xhtml build.xml Figura 4.2 Struttura cartelle scelta, da rispettare per ciascun progetto presente nel repository dell'azienda _data In questa cartella sono presenti tutti i dati necessari all'installazione del progetto e la 47

56 4 Progettazione del cambiamento popolazione dei dati a partire da valori noti. Qui possiamo trovare i senguenti files: database.create.db.sql per la creazione del database. database.dati.sql contiene i dati iniziali del database, detti fixtures. database.struttura.sql contiene la struttura del database. install.sh è uno script bash, per l'installazione del progetto nella worskation locale (modifica al file degli host del sistema operativo e creazione di un virtual host). LINUX_dominio.conf contiene il virtual host per i sistemi Linux. MAC_httpd.conf contiene il virtual host per i sistemi Mac OS library E' la cartella dedicata alle librerie ed ai framework utilizzati nel progetto _test E' la cartella sulla quale vengono appoggiati tutti i files relativi ai test. E' ulteriormente suddivisa in due sotto cartelle, unit e functional, contenente rispettivamente i test unitari e funzionali web E' la cartella che viene puntata dai virtual host e sulla quale è presente il file index.php 48

57 4 Progettazione del cambiamento di ciascun progetto. Contiene la vera e propria web application, nello specifico tutti i files che vanno resi accessibili all'esterno. La suddivisione dei files all'interno di essa dipenderà dagli specifici progetti _xhtml E' utilizzata dagli sviluppatori per la creazione dei templates dinamici. Contiene la versione statica della web application, ossia tutti i files HTML da utilizzare come modello per lo sviluppo del frontend. Sono il risultato del lavoro del frontend developer, che esegue il montaggio della grafica progettata dal designer Comandi fondamentali Di seguito un riassunto dei comandi messi a disposizione dopo l'aggiornamento di tutte le workstation: Comando phing mysql mysqldump phpunit Descrizione Per eseguire la build del software Per eseguire operazioni sul database Per eseguire il dump del database su file Per eseguire i test automatici Tabella 4.1 Lista dei comandi messi a disposizione su ciascuna worsktation per implementare la Continuous Integration. In questo modo è stato possibile creare un unico script di build standardizzato per tutti client e tutti i progetti, in modo da garantire una configurazione omogenea. 49

58 4 Progettazione del cambiamento Standardizzazione del database Per eliminare i problemi di eterogeneità è stata definita una convenzione sul nome del database da utilizzare per ogni progetto e le credenziali di autenticazione (utente MySQL) con il quale è possibile interagire con esso. In questo modo è stato garanto a ciascuno sviluppatore di gestire il DBMS della propria workstation in autonomia, mantenendo private le proprie credenziali di amministratore, in quanto sono quelle relative al progetto ad essere condivise: l'applicazione, se non diversamente configurata, fa riferimento sempre alle stesse credenziali di accesso al DB. Sono state poi create le procedure SQL necessarie al setup e popolazione del database, ed in seguito salvate nel repository, insieme a tutto il necessario per ottenere tramite un singolo comando: 1. Un utente di progetto attivo e configurato, con le proprie credenziali ed i permessi correttamente configurati per il proprio database. 2. Un database dal nome univoco per il singolo progetto, con la propria struttura ed eventualmente popolato con ben determinati dati iniziali (detti anche fixtures). 4.3 Introduzione del build scripting system E' stato creato un generico file build.xml ed implementati dei target comuni ad ogni 50

59 4 Progettazione del cambiamento progetto. Questo file viene di volta in volta personalizzato secondo le esigenze e posto sotto controllo di versione insieme ad esso. In questo modo ciascuna applicazione ha il proprio script di generazione della build che diventa parte integrante del software e come tale potrà essere migliorato o ampliato di nuove funzionalità. Sono stati definiti due target fondamentali per ciascun progetto: build e make-sql. 1. <?xml version="1.0" encoding="utf-8"?> 2. <project name="e-xtrategy" basedir="." default="build"> 3. <property name="db.name" value="e-xtrategy" /> 4. <property name="db.user" value="root" /> 5. <property name="db.password" value="" /> <target name="build"> 8. <!-- target definition --> 9. </target> <target name="make-sql"> 12. <!-- target definition --> 13. </target> </project> Listato 4.1 Esempio di file build.xml, contenente i target fondamentali build e makesql Il target build Il target build si occupa dell'effettivo setup dell'applicazione automatizzando la gran parte delle attività che altrimenti sarebbero state manuali e soggette ad errore. 51

60 4 Progettazione del cambiamento Tali attività, tipicamente, sono: 1. Cancellazione dei file temporanei ed eliminazione di residui di vecchie build. 2. Impostazione dei permessi di lettura e scrittura nelle directory. 3. Setup del database e dell'utente di accesso tramite le procedure SQL viste precedentemente. 4. Esecuzione di test automatici 1. <target name="build"> 2. <if> 3. <equals arg1="${db.password}" arg2=""/> 4. <then> 5. <property name="pstring" value=""/> 6. </then> 7. <else> 8. <property name="pstring" value="-p${db.password}"/> 9. </else> 10. </if> 11. <exec command="mysql -u${db.user} ${pstring} < _data/$ {db.name}.create.db.sql" checkreturn="true"/> 12. <exec command="mysql -u${db.user} ${pstring} ${db.name} < _data/${db.name}.struttura.sql"checkreturn="true"/> 13. <exec command="mysql -u${db.user} ${pstring} ${db.name} < 14. </target> _data/${db.name}.dati.sql"checkreturn="true"/> Listato 4.2 Esempio di target build con cui viene creato e popolato il database, partendo dai files sql presenti nel repository. 52

61 4 Progettazione del cambiamento Il target make-sql L'applicazione durante il suo funzionamento interagisce con il database inserendo, modificando o cancellando dei record, oppure lo sviluppatore decide di effettuare dei cambiamenti alla struttura di alcune tabelle o della struttura del database in generale. Qualora lo sviluppatore intenda inviare la nuova versione del database al repository è necessario innanzitutto che ne effettui il dump su file. Questa fase è stata automatizzata creando il target make-sql: vengono effettuati il dump della struttura e dei dati e salvati in due distinti files, che andranno a sostituire quelli contenenti le procedure per la creazione e popolazione della vecchia versione del database. 15. <target name="make-sql"> 16. <if> 17. <equals arg1="${db.password}" arg2=""/> 18. <then> 19. <property name="pstring" value=""/> 20. </then> 21. <else> 22. <property name="pstring" value="-p${db.password}"/> 23. </else> 24. </if> 25. <exec command="mysqldump -u${db.user} ${pstring} --skipcomments --no-create-info ${db.name} >_data/${db.name}.dati.tmp" checkreturn="true"/> 26. <exec command="mysqldump -u${db.user} ${pstring} --skipcomments --no-data ${db.name} >_data/${db.name}.struttura.tmp" checkreturn="true" /> 27. <delete file="_data/${db.name}.dati.sql" /> 28. <delete file="_data/${db.name}.struttura.sql" /> 29. <move file="_data/${db.name}.dati.tmp" tofile="_data/$ 53

62 4 Progettazione del cambiamento {db.name}.dati.sql" /> 30. <move file="_data/${db.name}.struttura.tmp" tofile="_data/$ {db.name}.struttura.sql" /> 31. </target> Listato 4.3 Esempio di target make-sql con cui struttura e dati del database vengono fatti persistere su filesystem, prima dell'invio al repository. Una volta effettuata la commit la nuova versione del DB sarà a questo punto presente nel repository. 4.3 Introduzione di uno script di installazione Come illustrato in precedenza, per poter ottenere il funzionamento di ciascun website in locale, sono necessarie alcune operazioni preliminari, che sono la modifica al file degli host del sistema e la creazione di un virtual host per il webserver. Per facilitare l'installazione di ciascun progetto nelle macchine locali è stato creato uno script bash. 1. #!/bin/bash 2. n=$(grep local.e-xtrategy.net /etc/hosts -c) 3. if [ "$n" = 0 ]; then 4. echo local.e-xtrategy.net >> /etc/hosts 5. fi 6. cp LINUX_dominio.conf /etc/apache2/sites-available/www.extrategy.net.conf 7. cd /etc/apache2/sites-available/ 8. a2ensite 9. /etc/init.d/apache2 restart Listato 4.4 Esempio di file install.sh, per la modifica del file degli host e la creazione del virtual host. 54

63 4 Progettazione del cambiamento 4.5 Introduzione dei test Per testare l'applicazione nella build privata è stato creato il target test che si occupa di lanciare PHPUnit configurato in modo da eseguire i test che sono stati scritti per l'applicazione. I test automatici, come il file build.xml, vanno considerati parte del software ed anch'essi posizionati all'interno del repository, nella cartella _test: in questo modo una procedura di test scritta da uno sviluppatore va a beneficio di tutto il team che può inoltre rivederla e migliorarla. I test documentano le funzionalità del codice e ne verificano l'effettivo funzionamento: se un requisito del software cambia, anche i test ad esso correlati verranno aggiornati. 1. <?php 2. require_once 'PHPUnit/Framework.php'; 3. require_once APPLICATION_PATH. '/models/user/cgauser.php'; 4. require_once APPLICATION_PATH. '/models/user/cgausers.php'; class CgaUsersTest extends PHPUnit_Framework_TestCase { /** 9. * setup delle fixtures 10. */ 11. public function setup() { 12. $u1 = new CgaUser(); 13. $u1->anno_registrazione = 2009; $u2 = new CgaUser(); 16. $u2->anno_registrazione = 2010; $u3 = new CgaUser(); 19. $u3->anno_registrazione = 2008; $this->_users = array($u1, $u2, $u3); 55

64 4 Progettazione del cambiamento 22. $this->_cgausers = new CgaUsers($this->_users); 23. } /** 26. * testa il risultato dell'operazione su tutta la collection 27. * l'operatore (mock) 28. * che assegna sempre lo stato di confermato 29. */ 30. public function testallsocioperation() { 31. // Create a stub for the CgaUser class. 32. $usermock = $this->getmock('cgauser'); 33. // Configure the stub. 34. $usermock->confirmed = true; //Create a stub for the CgaUserChecker Operator class. 37. $operator = $this- >getmock('cgauserchecker1', array('execute')); 38. // Configure the stub. 39. $operator->expects($this->any()) 40. ->method('execute') 41. ->will($this->returnvalue($usermock)); $this->_cgausers->operation(array($operator)); 44. foreach ($this->_cgausers as $user) { 45. $this->asserttrue($user->confirmed); 46. } 47. } /** 50. * testa il risultato dell'operazione su tutta la collection 51. * l'operatore (mock) 52. * che assegna sempre lo stato di non confermato 53. */ 54. public function testnosocioperation() { 55. // Create a stub for the CgaUser class. 56. $usermock = $this->getmock('cgauser'); 57. // Configure the stub. 58. $usermock->confirmed = false; 56

65 4 Progettazione del cambiamento //Create a stub for the CgaUserChecker Operator class. 61. $operator = $this- >getmock('cgauserchecker1', array('execute')); 62. // Configure the stub. 63. $operator->expects($this->any()) 64. ->method('execute') 65. ->will($this->returnvalue($usermock)); $this->_cgausers->operation(array($operator)); 68. foreach ($this->_cgausers as $user) { 69. $this->assertfalse($user->confirmed); 70. } 71. } /** 74. * testa il risultato di più operazioni sulla collection 75. * il primo operatore assegna sempre lo stato di confermato 76. * il secondo operatore assegna sempre l'anno */ 78. public function testmultipleoperations() { 79. // Create a stub for the CgaUser class. 80. $usermock = $this->getmock('cgauser'); 81. // Configure the stub. 82. $usermock->confirmed = true; //Create a stub for the CgaUserChecker Operator class. 85. $op1 = $this- >getmock('cgauserchecker1', array('execute')); 86. // Configure the stub. 87. $op1->expects($this->any()) 88. ->method('execute') 89. ->will($this->returnvalue($usermock)); $usermock2 = clone $usermock; 92. $usermock2->anno_registrazione = 2010; //Create a stub for the CgaUserChecker Operator class. 57

66 4 Progettazione del cambiamento 95. $op2 = $this- >getmock('cgauserchecker1', array('execute')); 96. // Configure the stub. 97. $op2->expects($this->any()) 98. ->method('execute') 99. ->will($this->returnvalue($usermock2)); $this->_cgausers->operation(array($op1, $op2)); 102. foreach ($this->_cgausers as $user) { 103. $this->asserttrue($user->confirmed); 104. $this->assertequals(2010, $user- >anno_registrazione); 105. } 106. } 107. } Listato 4.5 Esempio di batteria di test unitari per una classe, scritti utilizzando il framework di test PHPUnit. 4.6 Installazione del server di Continuous Integration Il server di Continuous Integration Hudson è stato installato nella stessa macchina su cui è presente il repository SVN. La scelta di accorpare le due entità anziché tenerle separate è stata fatta in ottica di una diminuzione di carico della rete LAN, Hudson infatti ad ogni build scarica per intero i progetti da integrare: data l'entità del traffico si è preferito passare direttamente per l'hard disk per non influenzare negativamente le prestazioni ed ottenere un feedback rapido. Hudson è stato poi configurato in modo da effettuare dei polling verso il repository SVN ed individuare eventuali cambiamenti: qualora ve ne fossero scarica il codice del 58

67 4 Progettazione del cambiamento progetto e ne effettua la build utilizzando lo stesso script di build degli sviluppatori, mostrando l'esito delle operazioni sulla propria dashboard. 4.7 Training del personale Prima di terminare l'opera di installazione e configurazione dei client e del server di Continuous Integration si è proceduto con la formazione degli sviluppatori per l'utilizzo del nuovo ambiente. La Continuous Integration è infatti anzitutto una pratica che funziona solamente se viene rispettata ed è importante fare in modo che tutti gli sviluppatori prendano coscienza di quali cambiamenti implicherà nel processo di sviluppo software e delle relative motivazioni Lezioni frontali E' stata redatta una presentazione riguardante i temi della Continuous Integration, delle pratiche su cui si basa e dei problemi che si prefigge di risolvere. Successivamente si è passato ad una lezione frontale, alla quale hanno partecipato tutti gli attori coinvolti nello sviluppo software. Sono stati toccati in particolar modo i temi chiave che presentavano un più immediato beneficio per l'azienda, come ad esempio l'integrazione e l'automatizzazione del database. 59

68 4 Progettazione del cambiamento Redazione di documenti operativi Tutto il materiale visto a lezione è stato messo a disposizione del team di sviluppo e salvato nel wiki aziendale. E' stato redatto inoltre un documento dai toni informali, successivamente appeso in bacheca, per non far perdere l'attenzione circa le nuove tematiche introdotte. Il contenuto del documento è un veloce riassunto delle bestpractises della Continuous Integration, accompagnato da una breve guida che permette di iniziare a lavorare sin da subito con il nuovo ambiente Post sul corporate blog E' stato pubblicato un post 15 sul corporate blog dell'azienda in cui viene spiegata a grandi linee la pratica della Continuous Integration e di come sia importante organizzare il lavoro nel team di sviluppo. Lo scopo della pubblicazione del post è stato quello di mandare un segnale, sia all'interno che all'esterno, della presa di coscienza che il successo o l'insuccesso di un sistema informativo non è solamente decretato dalla tecnologia che utilizza, ma anche da come questa è organizzata all'interno dell'azienda e dal rispetto delle buone pratiche di utilizzo. 15 Continuous Integration: quando la pratica va oltre gli strumenti, Giorgio Mandolini, e-xtrategy s.r.l. 60

69 5 Risultati ottenuti 5 Risultati ottenuti Questo capitolo descrive i risultati ottenuti a seguito dei cambiamenti introdotti nel capitolo 4, focalizzando l'attenzione, punto per punto, sui problemi riscontrati nel capitolo 3. In questa fase verranno espresse infine delle conclusioni sul lavoro svolto ed eventuali sviluppi futuri. 5.1 Soluzione del problema degli environment eterogenei L'utilizzo di una convenzione sulle modalità di installazione e configurazione dei progetti ha portato ad una considerevole diminuzione dei problemi di configurazione delle applicazioni. Oltre a ciò lo script di build, grazie alla possibilità di essere parametrizzato, si è dimostrato una strada molto efficace per uniformare anche client all'apparenza 61

70 5 Risultati ottenuti eterogenei: esso è stato utilizzato infatti sia su macchine Linux che Mac OS, oltre che in macchine Windows, queste ultime approntate solamente a scopo didattico. Anche il server di Continuous Integration utilizza il medesimo script di build per costruire le applicazioni in maniera automatica: in questo modo si è riusciti ad ottenere la garanzia che tutte le operazioni di installazione e configurazione dei lavori vengono effettuate in maniera identica e ripetibile su ogni macchina, ed il software presente nel repository è già pronto per essere rilasciato in produzione. Quello che inizialmente era un problema di riconfigurazione manuale e dispendiosa è diventato il lancio di un unico comando da shell: l'unico onere dello sviluppatore è di fornire eventuali parametri e credenziali di accesso differenti da quelli di default, qualora sia necessario. 5.2 Soluzione del problema di integrazione del codice L'utilizzo di test automatici fornisce una rapida indicazione sul funzionamento del software una volta effettuate delle modifiche ed integrate con il lavoro del resto del team. Come imposto dalla pratica non si può inviare codice al repository se questo non è prima stato verificato da test automatici ed il feedback fornito in seguito dal Continuous Integration server è una seconda prova sull'avvenuta integrazione. I benefici dell'introduzione dei test automatici sono evidenti, ma al tempo stesso 62

71 5 Risultati ottenuti l'effettiva messa in atto di questa buona pratica è il compito che richiede più tempo in azienda. I test automatici infatti necessitano di tempo per essere scritti e vanno visti come un investimento: scrivere una volta un test assicura per sempre che una determinata funzionalità sia testata ed evita il presentarsi due volte dello stesso bug. Oltre a ciò, l'introduzione di test automatici o pratiche di sviluppo come la Test Driven Development (TDD), che si basano su di essi, richiedono un'iniziale curva di apprendimento che durante lo svolgimento del presente lavoro, vista la molteplicità degli argomenti da trattare, non è potuta essere del tutto affrontata. I test automatici sono stati comunque introdotti ed implementati in via sperimentale su alcuni progetti: l'impatto che hanno avuto su di essi è stato giudicato positivo e per questo l'azienda vede il loro utilizzo a regime come un investimento da fare nel prossimo futuro. 5.3 Soluzione del problema della visibilità di progetto La visibilità di progetto ha subito un sensibile miglioramento grazie alla dashboard fornita dal Continuous Integration server. Lo sviluppatore a colpo d'occhio è in grado di monitorare lo status di tutti i progetti seguiti dall'azienda e capire subito se su alcuni di essi vi sono problemi in corso. 63

72 5 Risultati ottenuti Figura 5.1 Dashboard fornita dal C.I. server Hudson. Il verde indica una build funzionante mentre il rosso segnala la presenza di problemi. Figura 5.2 Dettagli relativi ad un progetto, comprensivi della code coverage dei test unitari. 64

73 5 Risultati ottenuti Figura 5.3 Andamento di una build nel tempo. Figura 5.4 Dettagli relativi alla copertura del codice. 65

La strada per sviluppare più rapidamente: Unit Test & Continuous Integration

La strada per sviluppare più rapidamente: Unit Test & Continuous Integration La strada per sviluppare più rapidamente: Unit Test & Continuous Integration by Enrico Zimuel Senior Consultant & Architect Zend Technologies Email: enrico.z@zend.com Blog: http://www.zimuel.it/blog Copyright

Dettagli

DRUPAL CONTINUOUS INTEGRATION. Parte I - Introduzione

DRUPAL CONTINUOUS INTEGRATION. Parte I - Introduzione DRUPAL CONTINUOUS INTEGRATION Parte I - Introduzione La Continuous Integration è una pratica di sviluppo software nella quale i membri di un team integrano il proprio lavoro di frequente, spesso con cadenza

Dettagli

Servizio HP Data Replication Solution per HP 3PAR Virtual Copy

Servizio HP Data Replication Solution per HP 3PAR Virtual Copy Servizio HP Data Replication Solution per HP 3PAR Virtual Copy Servizi HP Care Pack Caratteristiche tecniche Il servizio HP Data Replication Solution per HP 3PAR Virtual Copy prevede l'implementazione

Dettagli

Novità di Visual Studio 2008

Novità di Visual Studio 2008 Guida al prodotto Novità di Visual Studio 2008 Introduzione al sistema di sviluppo di Visual Studio Visual Studio Team System 2008 Visual Studio Team System 2008 Team Foundation Server Visual Studio Team

Dettagli

Test e collaudo del software Continuous Integration and Testing

Test e collaudo del software Continuous Integration and Testing Test e collaudo del software Continuous Integration and Testing Relatore Felice Del Mauro Roma, Cosa è la Continuous Integration A software development practice where members of a team integrate their

Dettagli

Appunti della lezione del 8/10/2008 del corso di Basi di dati I - Università del Salento

Appunti della lezione del 8/10/2008 del corso di Basi di dati I - Università del Salento Appunti della lezione del 8/10/2008 del corso di Basi di dati I - Università del Salento Tecnologie per lo sviluppo di applicazioni La tendenza attuale dell'ingegneria è quella dell'integrazione di componenti

Dettagli

Professional PHP Refactoring

Professional PHP Refactoring Professional PHP Refactoring by Francesco Trucchia (Ideato srl), Enrico Zimuel (Zend Technologies srl) Ci presentiamo... ft@ideato.it Francesco Trucchia, CTO di Ideato srl Fondatore di Ideato srl, esperto

Dettagli

Prof. Pagani Corrado INGEGNERIA DEL SOFTWARE

Prof. Pagani Corrado INGEGNERIA DEL SOFTWARE Prof. Pagani Corrado INGEGNERIA DEL SOFTWARE INTRODUZIONE L ingegneria del software è la disciplina tecnologica e gestionalerelativa alla realizzazione sistematica e alla manutenzione di un software rispettando

Dettagli

Sviluppo di applicazioni web con il pattern Model-View-Controller. Gabriele Pellegrinetti

Sviluppo di applicazioni web con il pattern Model-View-Controller. Gabriele Pellegrinetti Sviluppo di applicazioni web con il pattern Model-View-Controller Gabriele Pellegrinetti 2 MVC: come funziona e quali sono vantaggi che derivano dal suo utilizzo? La grande diffusione della tecnologia

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

Corso di Informatica

Corso di Informatica Corso di Informatica Modulo T2 A2 Introduzione ai database 1 Prerequisiti Concetto di sistema File system Archivi File e record 2 1 Introduzione Nella gestione di una attività, ad esempio un azienda, la

Dettagli

1. Hard Real Time Linux (Laurea VO o specialistica)

1. Hard Real Time Linux (Laurea VO o specialistica) 20/9/06 Elenco Tesi Disponibili Applied Research & Technology Dept. La Società MBDA La MBDA Italia è un azienda leader nella realizzazione di sistemi di difesa che con i suoi prodotti è in grado di soddisfare

Dettagli

Guida pratica alle applicazioni Smart Process

Guida pratica alle applicazioni Smart Process Guida pratica alle applicazioni Smart Process Aprile 2014 Kemsley Design Limited www.kemsleydesign.com www.column2.com Panoramica La qualità delle interazioni con clienti e partner è vitale per il successo

Dettagli

Sistema Gestione Dipendenti SGD

Sistema Gestione Dipendenti SGD Sistema Gestione Dipendenti SGD DOCUMENTO DEI REQUISITI INDICE 1. Introduzione... 4 1.1. Scopo del documento... 4 1.2. Scopo del prodotto... 5 1.3. Definizioni... 5 1.3.1. Termini di dominio... 5 1.3.2.

Dettagli

Corso di Web programming Modulo T3 A2 - Web server

Corso di Web programming Modulo T3 A2 - Web server Corso di Web programming Modulo T3 A2 - Web server 1 Prerequisiti Pagine statiche e dinamiche Pagine HTML Server e client Cenni ai database e all SQL 2 1 Introduzione In questa Unità si illustra il concetto

Dettagli

Programmazione Java Avanzata

Programmazione Java Avanzata Programmazione Java Avanzata Librerie fondamentali Ing. Giuseppe D'Aquì Testi Consigliati Eclipse in Action (David Gallardo, Ed Burnette and Robert McGovern), Manning (2003) JUnit Cookbook [http://junit.sourceforge.net/doc/cookbook/cookbook.htm]

Dettagli

Esercitazione 8. Basi di dati e web

Esercitazione 8. Basi di dati e web Esercitazione 8 Basi di dati e web Rev. 1 Basi di dati - prof. Silvio Salza - a.a. 2014-2015 E8-1 Basi di dati e web Una modalità tipica di accesso alle basi di dati è tramite interfacce web Esiste una

Dettagli

Corso Web programming

Corso Web programming Corso Web programming Modulo T3 A1 Modelli di programmazione 1 Prerequisiti Concetto di rete Processi e thread Concetti generali sui database 2 1 Introduzione Un particolare ambito della programmazione

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

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

PHP ), con l'introduzione di un middleware quale Zend Framework a

PHP ), con l'introduzione di un middleware quale Zend Framework a Quella che segue è la rappresentazione ad alto livello dell'architettura proposta per il sistema in corso di realizzazione. In questa fase non vengono ancora affrontate le tematiche di sicurezza, load

Dettagli

Il Provvedimento del Garante

Il Provvedimento del Garante Il Provvedimento del Garante Il provvedimento del Garante per la Protezione dei dati personali relativo agli Amministratori di Sistema (AdS) Misure e accorgimenti prescritti ai titolari dei trattamenti

Dettagli

SINPAWEB corso per Tecnico della programmazione e dello sviluppo di siti internet e pagine web co.reg 58036 matricola 2012LU1072

SINPAWEB corso per Tecnico della programmazione e dello sviluppo di siti internet e pagine web co.reg 58036 matricola 2012LU1072 Provincia di Lucca Servizio Istruzione, Formazione e Lavoro. Sviluppo Economico SINPAWEB corso per Tecnico della programmazione e dello sviluppo di siti internet e pagine web co.reg 58036 matricola 2012LU1072

Dettagli

Politecnico di Milano

Politecnico di Milano 1 Politecnico di Milano Facoltà di Ingegneria dell Informazione Progetto di Ingegneria del Software 2: SWIMv2 Prof.ssa Mirandola Raffaella A.A 2012/2013 SWIMv2: Small World hypotesis Machine v2 Realizzato

Dettagli

Il software: natura e qualità

Il software: natura e qualità Sommario Il software: natura e qualità Leggere Cap. 2 Ghezzi et al. Natura e peculiarità del software Classificazione delle qualità del software Qualità del prodotto e del processo Qualità interne ed esterne

Dettagli

Strumenti di gestione del ciclo di vita del software

Strumenti di gestione del ciclo di vita del software Strumenti di gestione del ciclo di vita del software Università degli studi di Padova a.a. 2008/09 Laurea in Informatica Corso di Ingegneria del Software mod. A. presenta Nicola Bertazzo nicola.bertazzo@gmail.com

Dettagli

Agile. mercoledì, 1 luglio 2015, 3:05 p. Prof. Tramontano docente Federico II ingegneria del software. Sviluppo Agile: metaprocesso

Agile. mercoledì, 1 luglio 2015, 3:05 p. Prof. Tramontano docente Federico II ingegneria del software. Sviluppo Agile: metaprocesso Agile mercoledì, 1 luglio 2015, 3:05 p. Prof. Tramontano docente Federico II ingegneria del software Sviluppo Agile: metaprocesso Molti progetti software falliscono Sì parte dagli anni 2000 Millennium

Dettagli

Introduzione alle basi di dati. Gestione delle informazioni. Gestione delle informazioni. Sistema informatico

Introduzione alle basi di dati. Gestione delle informazioni. Gestione delle informazioni. Sistema informatico Introduzione alle basi di dati Introduzione alle basi di dati Gestione delle informazioni Base di dati Modello dei dati Indipendenza dei dati Accesso ai dati Vantaggi e svantaggi dei DBMS Gestione delle

Dettagli

MAGO CRESCO - SPI.2. Relazione finale sul Progetto MAGO. Consorzio Campano di Ricerca per l Informatica e l Automazione Industriale S.c.a.r.l.

MAGO CRESCO - SPI.2. Relazione finale sul Progetto MAGO. Consorzio Campano di Ricerca per l Informatica e l Automazione Industriale S.c.a.r.l. CRESCO - SPI.2 MAGO Relazione finale sul Progetto MAGO Relativo al contratto tra ENEA e CRIAI avente per oggetto: Analisi e Realizzazione di tool innovativi a supporto delle funzionalità GRID stipulato

Dettagli

WEBsfa: l automazione della forza vendita via Web

WEBsfa: l automazione della forza vendita via Web WEBsfa: l automazione della forza vendita via Web White Paper 1 Gennaio 2005 White Paper Pag. 1 1/1/2005 L automazione della Forza Vendita Le aziende commerciali che che sviluppano e alimentano il proprio

Dettagli

Introdurre i dati di produzione nel testing prestazionale

Introdurre i dati di produzione nel testing prestazionale Business white paper Introdurre i dati di produzione nel testing prestazionale Il valore del testing continuativo delle prestazioni applicative Le problematiche più comuni nei test prestazionali Nel corso

Dettagli

Tratte da (18. TECNICHE DI ACCESSO AI DATABASE IN AMBIENTE INTERNET)

Tratte da (18. TECNICHE DI ACCESSO AI DATABASE IN AMBIENTE INTERNET) Tratte da (18. TECNICHE DI ACCESSO AI DATABASE IN AMBIENTE INTERNET) Ipotesi di partenza: concetti di base del networking Le ipotesi di partenza indispensabili per poter parlare di tecniche di accesso

Dettagli

Small Software Factories

Small Software Factories NEWITS SERVIZI PER LE NUOVE TECNOLOGIE DELL INFORMAZIONE Small Software Factories Sviluppare software in piccole realtà per grandi clienti Software Configuration Management 1 Software Configuration Management

Dettagli

SUITE SISTEMI. la suite di soluzioni dedicate all ufficio Sistemi Informativi. White Paper

SUITE SISTEMI. la suite di soluzioni dedicate all ufficio Sistemi Informativi. White Paper SUITE SISTEMI la suite di soluzioni dedicate all ufficio Sistemi Informativi White Paper Introduzione Suite Sistemi è un pacchetto di soluzioni per la gestione di tutte le attività che coinvolgono l ufficio

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

tesi di laurea Anno Accademico 2009/2010 relatore Ch.mo prof. Porfirio Tramontana candidato Pasquale Ludi Matr. 534\000438

tesi di laurea Anno Accademico 2009/2010 relatore Ch.mo prof. Porfirio Tramontana candidato Pasquale Ludi Matr. 534\000438 tesi di laurea Anno Accademico 2009/2010 relatore Ch.mo prof. Porfirio Tramontana candidato Pasquale Ludi Matr. 534\000438 Obbiettivi del progetto: Sviluppo di un applicazione Flex in AdobeFlashBuilder

Dettagli

Basi di Dati. Introduzione ai sistemi di basi di dati. K.Donno - Introduzione ai sistemi di basi di dati

Basi di Dati. Introduzione ai sistemi di basi di dati. K.Donno - Introduzione ai sistemi di basi di dati Basi di Dati Introduzione ai sistemi di basi di dati Introduzione ai sistemi di basi di dati Gestione dei Dati Una prospettiva storica File system verso DBSM Vantaggi di un DBMS Modelli dei dati Utenti

Dettagli

Caratteristiche generali

Caratteristiche generali Caratteristiche generali Tecnologie utilizzate Requisiti software/hardware Modalità di installazione del database del PSDR INSTALLAZIONE PSDR Installazione on-line Installazione off-line Primo avvio Riservatezza

Dettagli

Introduzione ai sistemi di basi di dati

Introduzione ai sistemi di basi di dati Basi di Dati Introduzione ai sistemi di basi di dati Alessandro.bardine@gmail.com alessandro.bardine@iet.unipi.it Introduzione ai sistemi di basi di dati Gestione dei Dati Una prospettiva storica File

Dettagli

CV di giuseppe scalzi

CV di giuseppe scalzi CV di giuseppe scalzi Iscritto il 28-12-2010 all'offerta Sviluppatori Web Senior e Junior In esame Nome completo: giuseppe scalzi Luogo: Bologna Data di nascita: 09/12/1978 Provincia: [Emilia-Romagna]

Dettagli

Breve introduzione allo sviluppo WEB. a cura di Ciro Attanasio - ciro.attanasio@email.cz

Breve introduzione allo sviluppo WEB. a cura di Ciro Attanasio - ciro.attanasio@email.cz Breve introduzione allo sviluppo WEB a cura di Ciro Attanasio - ciro.attanasio@email.cz Partiamo (1 di 1) Come funziona il WEB e quali tecnologie lo compongono Cos è un Client (1 di 2) Un client, in informatica,

Dettagli

Le Basi di dati: generalità. Unità di Apprendimento A1 1

Le Basi di dati: generalità. Unità di Apprendimento A1 1 Le Basi di dati: generalità Unità di Apprendimento A1 1 1 Cosa è una base di dati In ogni modello di organizzazione della vita dell uomo vengono trattate informazioni Una volta individuate e raccolte devono

Dettagli

Novell ZENworks Configuration Management in ambiente Microsoft * Windows *

Novell ZENworks Configuration Management in ambiente Microsoft * Windows * Guida GESTIONE SISTEMI www.novell.com Novell ZENworks Configuration Management in ambiente Microsoft * Windows * Novell ZENworks Configuration Management in ambiente Microsoft Windows Indice: 2..... Benvenuti

Dettagli

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0

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

Dettagli

BASI DI DATI I Lezione n 2 25/09/2009

BASI DI DATI I Lezione n 2 25/09/2009 BASI DI DATI I Lezione n 2 25/09/2009 Fumarola Roberta, Galeano Antonio Andrea Linguaggio di modellazione Insieme di simboli e regole atto a descrivere la struttura e le funzionalità di un Database prima

Dettagli

Acronis License Server. Manuale utente

Acronis License Server. Manuale utente Acronis License Server Manuale utente INDICE 1. INTRODUZIONE... 3 1.1 Panoramica... 3 1.2 Politica della licenza... 3 2. SISTEMI OPERATIVI SUPPORTATI... 4 3. INSTALLAZIONE DI ACRONIS LICENSE SERVER...

Dettagli

Classificazione del software

Classificazione del software Classificazione del software Classificazione dei software Sulla base del loro utilizzo, i programmi si distinguono in: SOFTWARE Sistema operativo Software applicativo Sistema operativo: una definizione

Dettagli

SIAGAS Manuale Utente Utente non autenticato

SIAGAS Manuale Utente Utente non autenticato SIAGAS Manuale Utente Utente non autenticato 27 marzo 2007 v.1.7 SIAGAS: Manuale Utente: utente non autenticato 1/10 1 Introduzione 1.1 Destinatario del prodotto SIAGAS è uno Sportello Informativo per

Dettagli

Ministero dell Istruzione dell Università e della Ricerca M070 ESAME DI STATO DI ISTITUTO TECNICO INDUSTRIALE

Ministero dell Istruzione dell Università e della Ricerca M070 ESAME DI STATO DI ISTITUTO TECNICO INDUSTRIALE Pag. 1/1 Sessione ordinaria 2010 Seconda prova scritta Ministero dell Istruzione dell Università e della Ricerca M070 ESAME DI STATO DI ISTITUTO TECNICO INDUSTRIALE CORSO DI ORDINAMENTO Indirizzo: INFORMATICA

Dettagli

Manuale di riferimento di HP Web Jetadmin Database Connector Plug-in

Manuale di riferimento di HP Web Jetadmin Database Connector Plug-in Manuale di riferimento di HP Web Jetadmin Database Connector Plug-in Informazioni sul copyright 2004 Copyright Hewlett-Packard Development Company, L.P. Sono vietati la riproduzione, l'adattamento e la

Dettagli

SOLUTION BRIEF CA ERwin Modeling. Come gestire la complessità dei dati e aumentare l'agilità del business

SOLUTION BRIEF CA ERwin Modeling. Come gestire la complessità dei dati e aumentare l'agilità del business SOLUTION BRIEF CA ERwin Modeling Come gestire la complessità dei dati e aumentare l'agilità del business CA ERwin Modeling fornisce una visione centralizzata delle definizioni dei dati chiave per consentire

Dettagli

Relazione finale di Didattica e laboratorio di Programmazione

Relazione finale di Didattica e laboratorio di Programmazione Relazione finale di Didattica e laboratorio di Programmazione Prof.ssa Vallì Carando Tirocinante Maria Grazia Maffucci Classe di concorso A042 aprile 2013 Progettazione Web Applicazioni client-server La

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

Basi di dati. Corso di Laurea in Ingegneria Informatica Canale di Ingegneria delle Reti e dei Sistemi Informatici - Polo di Rieti

Basi di dati. Corso di Laurea in Ingegneria Informatica Canale di Ingegneria delle Reti e dei Sistemi Informatici - Polo di Rieti Basi di dati Corso di Laurea in Ingegneria Informatica Canale di Ingegneria delle Reti e dei Sistemi Informatici - Polo di Rieti Anno Accademico 2008/2009 Introduzione alle basi di dati Docente Pierangelo

Dettagli

COMPLETA SICUREZZA GRAZIE ALL ACCESSO PROTETTO E AI LIVELLI AUTORIZZATIVI

COMPLETA SICUREZZA GRAZIE ALL ACCESSO PROTETTO E AI LIVELLI AUTORIZZATIVI Consultazione prodotti e gestione ordini via internet SAM r-evolution La rivoluzione non è cambiare il software! SAM OW - Open Web Open-Web è l applicazione web per la consultazione online degli articoli

Dettagli

ALLEGATO B NOTA DESCRITTIVA DELLE INFRASTRUTTURE

ALLEGATO B NOTA DESCRITTIVA DELLE INFRASTRUTTURE ALLEGATO B NOTA DESCRITTIVA DELLE INFRASTRUTTURE INDICE 1 1. PREMESSA... 3 2. SCOPO DEL DOCUMENTO... 3 3. IL SOFTWARE APPLICATIVO GESTIONE CASI... 4 3.1 ARCHITETTURA... 4 3.2 DESCRIZIONE DELLE INFRASTRUTTURE

Dettagli

Università degli Studi "Roma Tre" Dipartimento di Informatica ed automazione. Facoltà di Ingegneria

Università degli Studi Roma Tre Dipartimento di Informatica ed automazione. Facoltà di Ingegneria Università degli Studi "Roma Tre" Dipartimento di Informatica ed automazione Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica Tesi di Laurea AUTENTICAZIONE PER APPLICAZIONI WEB Relatore

Dettagli

ANALISI DI UN CASO DI EVOLUZIONE NELL ADOZIONE DELLA SOLUZIONE PROJECT AND PORTFOLIO MANAGEMENT DI HP.

ANALISI DI UN CASO DI EVOLUZIONE NELL ADOZIONE DELLA SOLUZIONE PROJECT AND PORTFOLIO MANAGEMENT DI HP. INTERVISTA 13 settembre 2012 ANALISI DI UN CASO DI EVOLUZIONE NELL ADOZIONE DELLA SOLUZIONE PROJECT AND PORTFOLIO MANAGEMENT DI HP. Intervista ad Ermanno Pappalardo, Lead Solution Consultant HP Software

Dettagli

Programmazione Server Side e Database in rete

Programmazione Server Side e Database in rete Programmazione Server Side e Database in rete Prof. Massimo PALOMBO -IIS A. MEUCCI Casarano La programmazione Stand-Alone consente di costruire applicazioni, più o meno complesse, ma utilizzabili esclusivamente

Dettagli

COGITEK s.r.l. Via Fregene, 14 00183 ROMA Tel. 0689820236 Fax. 0689820213 Cod. Fisc. e Part. IVA 06012550015 Cap. Soc. 70.000 i.v.

COGITEK s.r.l. Via Fregene, 14 00183 ROMA Tel. 0689820236 Fax. 0689820213 Cod. Fisc. e Part. IVA 06012550015 Cap. Soc. 70.000 i.v. Sommario 1. I presupposti di GRAM AUDIT... 4 2. I vantaggi di GRAM AUDIT... 4 3. Aspetti metodologici alla base del Modello... 5 3.1. La gestione degli utenti... 5 3.2. La composizione del Piano di Audit

Dettagli

SVN server, per Florim, è installato su server di test, anche se la sua configurazione può avvenire in qualsiasi ambiente.

SVN server, per Florim, è installato su server di test, anche se la sua configurazione può avvenire in qualsiasi ambiente. Siti FLORIM SVN Subversion Il sistema di versioning viene illustrato nell immagine seguente: Sistema locale dello sviluppatore, si parla di working copy ( copia dei file dal server in produzione) SVN server,

Dettagli

Concetti base. Impianti Informatici. Web application

Concetti base. Impianti Informatici. Web application Concetti base Web application La diffusione del World Wide Web 2 Supporto ai ricercatori Organizzazione documentazione Condivisione informazioni Scambio di informazioni di qualsiasi natura Chat Forum Intranet

Dettagli

EXPLOit Content Management Data Base per documenti SGML/XML

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

Dettagli

Software. Definizione, tipologie, progettazione

Software. Definizione, tipologie, progettazione Software Definizione, tipologie, progettazione Definizione di software Dopo l hardware analizziamo l altra componente fondamentale di un sistema di elaborazione. La macchina come insieme di componenti

Dettagli

NetCrunch 6. Server per il controllo della rete aziendale. Controlla

NetCrunch 6. Server per il controllo della rete aziendale. Controlla AdRem NetCrunch 6 Server per il controllo della rete aziendale Con NetCrunch puoi tenere sotto controllo ogni applicazione, servizio, server e apparato critico della tua azienda. Documenta Esplora la topologia

Dettagli

PARAMETRI 2014 P.I. 2013. Guida all uso ed all installazione

PARAMETRI 2014 P.I. 2013. Guida all uso ed all installazione PARAMETRI 2014 P.I. 2013 Guida all uso ed all installazione 1 INTRODUZIONE Il prodotto PARAMETRI 2014 consente di stimare i ricavi o i compensi dei contribuenti esercenti attività d impresa o arti e professioni

Dettagli

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni)

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni) Progettazione di Sistemi Interattivi Struttura e supporti all implementazione di applicazioni in rete (cenni) Docente: Daniela Fogli Gli strati e la rete Stratificazione da un altro punto di vista: i calcolatori

Dettagli

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Il Sistema Operativo Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela Fogli Cos

Dettagli

Architetture per le applicazioni web-based. Mario Cannataro

Architetture per le applicazioni web-based. Mario Cannataro Architetture per le applicazioni web-based Mario Cannataro 1 Sommario Internet e le applicazioni web-based Caratteristiche delle applicazioni web-based Soluzioni per l architettura three-tier Livello utente

Dettagli

AREA SERVIZI ICT. Servizi di hosting offerti dall'area Servizi ICT. Estratto offerta. hosting.polimi.it

AREA SERVIZI ICT. Servizi di hosting offerti dall'area Servizi ICT. Estratto offerta. hosting.polimi.it AREA SERVIZI ICT Servizi di hosting offerti dall'area Servizi ICT Estratto offerta hosting.polimi.it Indice 1. Documentazione... 6 2. Glossario e convenzioni del documento... 6 3. Oggetto del servizio...

Dettagli

Verifica e Validazione (V & V) Software e difetti. Processo di V & V. Test

Verifica e Validazione (V & V) Software e difetti. Processo di V & V. Test Software e difetti Il software con difetti è un grande problema I difetti nel software sono comuni Come sappiamo che il software ha qualche difetto? Conosciamo tramite qualcosa, che non è il codice, cosa

Dettagli

Architetture Software

Architetture Software Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Ingegneria del Software Architetture Software Giulio Destri Ing. del Sw: Architettura - 1 Scopo del modulo

Dettagli

PARAMETRI 2012 P.I. 2011. Guida all installazione

PARAMETRI 2012 P.I. 2011. Guida all installazione PARAMETRI 2012 P.I. 2011 Guida all installazione 1 INTRODUZIONE Il prodotto PARAMETRI 2012 consente di stimare i ricavi o compensi realizzabili da parte dei contribuenti esercenti attività d impresa o

Dettagli

Architetture Web a tre livelli: CGI, SSI, ISAPI e codice mobile Architetture a 3 livelli (1)

Architetture Web a tre livelli: CGI, SSI, ISAPI e codice mobile Architetture a 3 livelli (1) Pagina 1 di 10 Architetture Web a tre livelli: CGI, SSI, ISAPI e codice mobile Architetture a 3 livelli (1) Nel corso della lezione precedente abbiamo analizzato le caratteristiche dell'architettura CGI.

Dettagli

MIXER: gestione trasmissioni DJ: governance di MIXER

MIXER: gestione trasmissioni DJ: governance di MIXER MIXER-DJ MIXER: gestione trasmissioni DJ: governance di MIXER MIXER Mixer è un ambiente applicativo di tipo Enterprise Service Bus (ESB) per la gestione delle trasmissioni di file su Linux. All'interno

Dettagli

Obiettivi d esame PHP Developer Fundamentals on MySQL Environment

Obiettivi d esame PHP Developer Fundamentals on MySQL Environment Obiettivi d esame PHP Developer Fundamentals on MySQL Environment 1.0 Ambiente di sviluppo 1.1 Web server e database MySQL Comprendere la definizione dei processi che si occupano di fornire i servizi web

Dettagli

GPL4i DMS-WEB. Copyright 2010 2014 JetLab S.r.l. Tutti i diritti riservati

GPL4i DMS-WEB. Copyright 2010 2014 JetLab S.r.l. Tutti i diritti riservati GPL4i DMS-WEB Copyright 2010 2014 JetLab S.r.l. Tutti i diritti riservati Copyright 2014 2015 JetLab S.r.l. Tutti i diritti riservati GPL4i è un marchio di JetLab S.r.l. Microsoft, Windows, Windows NT,

Dettagli

Sistemi Informativi Distribuiti

Sistemi Informativi Distribuiti Corso di Laurea Magistrale in Ingegneria Gestionale Corso di Sistemi Informativi Modulo II A. A. 2013-2014 SISTEMI INFORMATIVI MODULO II Sistemi Informativi Distribuiti 1 Sistemi informativi distribuiti

Dettagli

Aspetti applicativi e tecnologia

Aspetti applicativi e tecnologia Aspetti applicativi e tecnologia Premessa Architetture usate per i database Le prime applicazioni erano definite monolitiche, cioè un unico computer (mainframe) gestiva sia le applicazioni che i dati,

Dettagli

Corso di Web Programming

Corso di Web Programming Corso di Web Programming 1. Introduzione a Internet e al WWW Paolo Milazzo Dipartimento di Informatica, Università di Pisa http://www.di.unipi.it/ milazzo milazzo di.unipi.it Corso di Laurea in Informatica

Dettagli

Web Inserimento Rapporti Manuale amministratore versione 3.2.0

Web Inserimento Rapporti Manuale amministratore versione 3.2.0 Web Inserimento Rapporti Manuale amministratore versione 3.2.0 Premessa Indice 1. Premessa... 4 1.1. Descrizione del documento... 4 1.1.1. Scopo... 4 1.1.2. Destinatari... 4 1.2. Convenzioni utilizzate

Dettagli

Corso di Informatica Modulo T3 B1 Programmazione web

Corso di Informatica Modulo T3 B1 Programmazione web Corso di Informatica Modulo T3 B1 Programmazione web 1 Prerequisiti Architettura client/server Elementi del linguaggio HTML web server SQL server Concetti generali sulle basi di dati 2 1 Introduzione Lo

Dettagli

Introduzione alla Business Intelligence. E-mail: infobusiness@zucchetti.it

Introduzione alla Business Intelligence. E-mail: infobusiness@zucchetti.it Introduzione alla Business Intelligence E-mail: infobusiness@zucchetti.it Introduzione alla Business Intelligence Introduzione Definizione di Business Intelligence: insieme di processi per raccogliere

Dettagli

Basic Standard Suite WEB. Contatto. fidelizzare

Basic Standard Suite WEB. Contatto. fidelizzare Basic Standard Suite WEB organizzare collaborazione Memorizzare Comunicare CONDIVISIONE QuALSIASI Contatto fidelizzare Dovunque Gestione ricerca Attività File è la soluzione software di nuova concezione

Dettagli

Symantec Backup Exec 12.5 for Windows Servers. Guida rapida all'installazione

Symantec Backup Exec 12.5 for Windows Servers. Guida rapida all'installazione Symantec Backup Exec 12.5 for Windows Servers Guida rapida all'installazione 13897290 Installazione di Backup Exec Il documento contiene i seguenti argomenti: Requisiti di sistema Prima dell'installazione

Dettagli

Introduzione Ai Data Bases. Prof. Francesco Accarino IIS Altiero Spinelli Via Leopardi 132 Sesto San giovanni

Introduzione Ai Data Bases. Prof. Francesco Accarino IIS Altiero Spinelli Via Leopardi 132 Sesto San giovanni Introduzione Ai Data Bases Prof. Francesco Accarino IIS Altiero Spinelli Via Leopardi 132 Sesto San giovanni I Limiti Degli Archivi E Il Loro Superamento Le tecniche di gestione delle basi di dati nascono

Dettagli

Co.El.Da. Software S.r.l. Coelda.Ne Caratteristiche tecniche

Co.El.Da. Software S.r.l.  Coelda.Ne Caratteristiche tecniche Co..El. Da. Software S..r.l.. Coelda.Net Caratteristiche tecniche Co.El.Da. Software S.r.l.. Via Villini Svizzeri, Dir. D Gullì n. 33 89100 Reggio Calabria Tel. 0965/920584 Faxx 0965/920900 sito web: www.coelda.

Dettagli

Istituto Tecnico Industriale Statale Dionigi Scano Cagliari. Candidato: Medda Daniele Classe 5ª C Informatica Anno scolastico 2013/2014.

Istituto Tecnico Industriale Statale Dionigi Scano Cagliari. Candidato: Medda Daniele Classe 5ª C Informatica Anno scolastico 2013/2014. Istituto Tecnico Industriale Statale Dionigi Scano Cagliari Candidato: Medda Daniele Classe 5ª C Informatica Anno scolastico 2013/2014 relate Un esperimento di social networking open source 1 Introduzione

Dettagli

Indice REGIONE BASILICATA

Indice REGIONE BASILICATA DIPARTIMENTO PROGRAMMAZIONE UFFICIO SISTEMA INFORMATIVO REGIONALE E Via Vincenzo Verrastro n 4 fax 0971/668954 REGI ONE BASI UFFICIO S. I. LICA R. S. TA Piano dei Test Id Sistema APPROVAZIONI Redatto da:

Dettagli

Annuncio software IBM per Europa, Medio Oriente e Africa ZP09-0108, 5 maggio 2009

Annuncio software IBM per Europa, Medio Oriente e Africa ZP09-0108, 5 maggio 2009 ZP09-0108, 5 maggio 2009 I prodotti aggiuntivi IBM Tivoli Storage Manager 6.1 offrono una protezione dei dati e una gestione dello spazio migliorate per ambienti Microsoft Windows Indice 1 In sintesi 2

Dettagli

Content Management Systems

Content Management Systems Content Management Systems L o Guido Porruvecchio Tecnologia e Applicazioni della Rete Internet Definizione Un Content Management System (CMS) è letteralmente un sistema per la gestione dei contenuti Definisce

Dettagli

Introduzione al linguaggio Java: Servlet e JSP

Introduzione al linguaggio Java: Servlet e JSP Introduzione al linguaggio Java: Servlet e JSP Corso di Gestione della Conoscenza d Impresa A. A. 2006/2007 Dipartimento di Informatica Università degli Studi di Bari 1 Servlet e JSP: il contesto Un applicazione

Dettagli

Servizi di hosting offerti dall'area Servizi ICT Estratto offerta. Area Servizi ICT. Servizi hosting di Ateneo Estratto offerta Versione 1.

Servizi di hosting offerti dall'area Servizi ICT Estratto offerta. Area Servizi ICT. Servizi hosting di Ateneo Estratto offerta Versione 1. Area Servizi ICT Servizi hosting di Ateneo Estratto offerta Versione 1.5 http://hosting.polimi.it Servizi di hosting offerti dall'area Servizi ICT Estratto offerta Politecnico di Milano Area Servizi ICT

Dettagli

MANUALE www.logisticity.it. Copryright 2015 - All rights reserved Email: info@logisticity.it - P.IVA 04183950403

MANUALE www.logisticity.it. Copryright 2015 - All rights reserved Email: info@logisticity.it - P.IVA 04183950403 MANUALE www.logisticity.it Copryright 2015 - All rights reserved Email: info@logisticity.it - P.IVA 04183950403 INDICE Presentazione... pag. 02 Applicativo... pag. 03 Amministrazione...pag. 06 Licenza...pag.

Dettagli

Novità di Crystal Reports XI

Novità di Crystal Reports XI Introduzione Introduzione Questa sezione offre una panoramica di dettagliata dei componenti, delle funzioni e dei vantaggi forniti dalla versione più recente di Crystal Reports. Alcuni tra i più importanti

Dettagli

CORSO DI FORMAZIONE PER: TECNICO DELLE ATTIVITA' DI PROGETTAZIONE, SVILUPPO E AGGIORNAMENTO DI SITI WEB

CORSO DI FORMAZIONE PER: TECNICO DELLE ATTIVITA' DI PROGETTAZIONE, SVILUPPO E AGGIORNAMENTO DI SITI WEB Avviso Pubblico PROV-BR 02/2013 PO FSE 2007/2013 ASSE II OCCUPABILITA' Formazione per Inserimento-Reinserimento Lavorativo Approvato con D.D. n.85 del 24/01/2014, pubblicata sul BURP n. 17 del 06/02/2014

Dettagli

Gestione dello sviluppo software Modelli Agili

Gestione dello sviluppo software Modelli Agili Università di Bergamo Facoltà di Ingegneria GESTIONE DEI SISTEMI ICT Paolo Salvaneschi A4_3 V1.1 Gestione dello sviluppo software Modelli Agili Il contenuto del documento è liberamente utilizzabile dagli

Dettagli

Facoltà di Ingegneria

Facoltà di Ingegneria Facoltà di Ingegneria Corso di laurea in Ingegneria dell Informazione FONDAMENTI DI INFORMATICA PRIMA PARTE Manuale di Installazione dell ECMs SharePoint PROFESSORE: STUDENTE: Prof. Mario Bochicchio Paiano

Dettagli

Business Simulation in ambiente web

Business Simulation in ambiente web Business Simulation in ambiente web Da soluzione Stand Alone ad un ambiente condiviso Lecco, Novembre 2013 Documento riservato. Ogni riproduzione è vietata salvo autorizzazione scritta di MAS Consulting

Dettagli