Tecniche e strumenti per l Analisi di Impatto di una modifica nei processi di manutenzione Software

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Tecniche e strumenti per l Analisi di Impatto di una modifica nei processi di manutenzione Software"

Transcript

1 Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Elaborato finale in Ingegneria del Software Tecniche e strumenti per l Analisi di Impatto di una modifica nei processi di manutenzione Software Anno Accademico 2011/2012 Candidato: Borriello Michele matr. N46/576

2 A tutte le persone che mi sono state accanto in questi tre anni A mia madre e a mio padre, che mi hanno sempre sostenuto anche quando non hanno condiviso le mie scelte A Tom e ad Ale, perché se non ci fossero loro forse non avrei nemmeno scritto queste parole

3 Indice Introduzione 4 Capitolo 1. Manutenzione dei sistemi Software Modelli di manutenzione del software Integrazione dell'analisi di Impatto nel processo di modifica 9 Capitolo 2. Analisi di Impatto Tipologie di IA Rappresentazione degli impatti Classi di algoritmi di ricerca Tecniche per la determinazione degli impatti 18 Capitolo 3. Tracciabilità Livelli ed approcci di tracciabilità Analisi di tracciabilità orizzontale Analisi di tracciabilità verticale Tracciabilità dei requisiti Ipotizzazione delle tracce 27 Capitolo 4. Supporto automatizzato per l'analisi di Impatto Analisi automatica dei diagrammi UML Analisi automatica del codice sorgente 33 Conclusioni 36 Bibliografia 37

4 Introduzione Quando si realizza un sistema software la maggior parte delle risorse umane ed economiche viene solitamente impiegata nella fase di manutenzione del prodotto, ovvero quella parte del processo che inizia con il rilascio del prodotto stesso e che si protrae poi per tutto il suo ciclo di vita. L'obiettivo della manutenzione, il cui impatto sui costi complessivi per lo sviluppo di un software è stimato tra il 60% e l'80% [4], è quello di introdurre modifiche riguardanti: correzione di errori (manutenzione Correttiva) adattamento all'ambiente operativo (manutenzione Adattativa) miglioramento delle prestazioni (manutenzione Perfettiva) al fine di prolungare il periodo di utilizzo del prodotto da parte dei clienti. È dunque nell'interesse di chi produce i sistemi software fare in modo che l'evoluzione delle proprie creazioni avvenga col minor sforzo possibile e senza perdite considerevoli di qualità. Questo ambito di lavoro dell'ingegneria del Software presenta tuttavia ancora oggi una serie di problematiche molto delicate: la modifica di un sistema senza un'adeguata conoscenza della sua struttura interna può portare alla pianificazione di interventi inefficaci e potenzialmente dannosi la complessità e le dimensioni sempre crescenti dei prodotti software rendono particolarmente onerose e lente le operazioni di manutenzione la documentazione di sistema risulta spesso incompleta e/o non aggiornata, impedendo a chi non ha seguito interamente il ciclo di vita del prodotto di ottenere una conoscenza sufficiente del contesto operativo Varie ricerche hanno dimostrato che tali difficoltà sono legate principalmente ad una cattiva progettazione e ad una gestione troppo grossolana e sbrigativa delle attività di manutenzione, la cui importanza viene ancora oggi sottovalutata. Un altro fattore determinante è l'assenza di un approccio comune alla risoluzione dei problemi appena citati. La letteratura del settore presenta attualmente diverse metodologie per controllare le operazioni di modifica del software, ma ancora non esiste una trattazione completa e sistematica dell'argomento e dunque i progettisti tendono ad usare approcci basati sulla propria esperienza 4

5 lavorativa (con risultati spesso discutibili). Vi è però una caratteristica comune a tutti i metodi proposti, ossia l'utilizzo della Tracciabilità e dell'analisi di impatto. L'Impact Analysis (IA), o anche Analisi di Impatto, è l'argomento centrale del seguente lavoro. Essa è la pratica dell'ingegneria del Software che consente di stabilire quali parti della struttura di un sistema saranno influenzate da una determinata modifica tramite un attento esame della documentazione e/o del codice sorgente. I vantaggi dovuti al suo utilizzo nel processo di manutenzione sono molteplici: individuando i componenti che vanno modificati per cambiare una determinata funzionalità del prodotto si possono velocizzare considerevolmente gli interventi di modifica (con una conseguente riduzione di costi) il collegamento tra i requisiti del sistema ed i moduli che li implementano consente di verificare la conformità delle modifiche che si vogliono introdurre alle specifiche del progetto originario la conoscenza dei componenti interessati da una modifica permette di velocizzare il retesting del sistema poiché il campo delle funzionalità da testare viene notevolmente ridotto determinando gli effetti ripple causati da una modifica si riducono gli interventi di manutenzione correttiva dovuti ad errori introdotti dalle nuove modifiche i risultati ottenuti dalla fase di analisi consentono di fare stime più accurate sui costi e sui tempi di ciascun intervento modificare un sistema di cui si conosce la struttura interna comporta il rilascio di un prodotto finale qualitativamente migliore L'Analisi di Impatto si configura quindi come un metodo che permette di effettuare una manutenzione efficiente e al contempo estremamente efficace, poiché consente di scegliere il tipo di intervento più adeguato per il sistema in esame. La Tracciabilità di un sistema è invece legata alla comprensibilità delle sue relazioni strutturali ed è un requisito fondamentale per poter realizzare un'analisi di Impatto completa. Lo studio di Tracciabilità precede dunque l'impact Analysis e le fornisce il materiale grezzo su cui lavorare. Questo documento costituisce un primo tentativo di presentare una trattazione integrata e sistematica dell'analisi di Impatto e della sua applicazione ai processi di manutenzione del software. In esso si andrà prima di tutto a studiare la natura degli interventi di manutenzione e le modalità di integrazione dell'analisi di Impatto all'interno di tale fase. Si approfondirà poi la teoria 5

6 alla base dell'impact Analysis, descrivendo le tecniche principali impiegate per realizzarla. Successivamente verrà chiarito il concetto di Tracciabilità e saranno presentate le procedure adoperate per lo studio di tracciabilità di un sistema. Saranno infine elencate alcune tipologie di strumenti automatizzati in grado di supportare le suddette attività. 6

7 Capitolo 1 Manutenzione dei sistemi Software Un prodotto software rilasciato sul mercato ha la necessità di evolvere in base alle esigenze di chi lo utilizza ed in base all ambiente reale in cui opera. Tale evoluzione segue solitamente le Leggi empiriche di Lehman [24]: 1. Cambiamento continuo Un programma utilizzato in un ambiente reale deve necessariamente cambiare o diventerà progressivamente meno utile 2. Entropia crescente Quando un sistema viene modificato la sua struttura tende a deteriorarsi, quindi per preservarla e semplificarla sono necessarie risorse aggiuntive 3. Evoluzione dei grandi sistemi I grandi sistemi hanno una propria dinamica evolutiva, caratterizzata da un andamento sostanzialmente regolare. In particolare la dimensione, il tempo fra due release successive, il numero di errori rilevati sono valori approssimativamente invarianti per ciascuna release. La Manutenzione è la fase del ciclo di vita di un sistema software finalizzata alla sua evoluzione. Esistono attualmente cinque classi di manutenzione del software [29]: Manutenzione per correggere gli errori nel software (Correttiva): gli errori di programmazione sono solitamente semplici da correggere, mentre quelli di progettazione e quelli nei requisiti sono più costosi da riparare perché possono richiedere la riscrittura di diversi componenti del sistema Manutenzione per adattare il software ai cambiamenti dell'ambiente operativo (Adattativa): richiesta quando aspetti del sistema come l hardware, il Sistema Operativo o altri componenti esterni di supporto cambiano Manutenzione per migliorare le funzionalità del sistema (Perfettiva): necessaria quando i requisiti di sistema cambiano a causa di variazioni organizzative e di business Manutenzione per semplificare gli interventi futuri (Preventiva): 7

8 introduce modifiche che facilitano le correzioni, gli adattamenti e le migliorie all'interno del sistema Manutenzione per rimediare a guasti improvvisi (di Emergenza): manutenzione correttiva non programmata necessaria a rendere nuovamente operativo nel minor tempo possibile un sistema non funzionante Qualunque sia il tipo di manutenzione che si va ad effettuare, però, bisogna adottare un approccio strutturato al fine di poter gestire la complessità del sistema. 1.1 Modelli di manutenzione del software Un modello molto usato nella pratica per gestire i processi di modifica all'interno di un sistema è il Quick Fix Model. Esso è pensato esclusivamente per effettuare piccole riparazioni e consiste in un insieme di modifiche al codice in termini di Patch (trad. pezze ). Quando invece si devono realizzare modifiche più estensive alla struttura del sistema è necessario uno studio preventivo dei possibili interventi e delle loro conseguenze, ottenuto con l'iterative Enhancement Model. Questo secondo metodo, a differenza del primo, consente di modificare il prodotto senza deteriorarne la struttura ma richiede una maggiore quantità di tempo e di risorse. Generalmente un qualsiasi approccio strutturato per la manutenzione del software deve essere composto da tre stadi fondamentali: [25] 1. comprensione del software dal punto di vista del cambiamento richiesto 2. realizzazione della modifica nel sistema esistente 3. ripetizione dei test sul sistema modificato La letteratura ha proposto nel corso degli anni numerosi modelli di manutenzione concepiti a partire dallo schema di principio appena visto, tra cui: modello di Boehm [BOE76] che si articola in Comprensione del software, Modifica del software e Rivalidazione del software modello di Martin McClure [MAR83] sostanzialmente analogo al precedente modello di Parikh [PAR82] composto da Identificazione degli obiettivi, Comprensione del software, Modifica del codice e Rivalidazione del prodotto modello di Sharpley [SHA77] che si articola in Problem verification, Problem diagnosis, Riprogrammazione e Baseline reverification 8

9 modello di Yau [YAU80] composto da Determinazione degli obiettivi, Comprensione del programma, Stesura proposta di cambiamento, Valutazione effetti ripple e Test di regressione modello di Patkow [PAT83] che si articola in Diagnosi della modifica, Localizzazione della modifica, Realizzazione della modifica e Rivalidazione del prodotto modello di Moreton [MOR90] composto da Change management, Analisi degli effetti, Pianificazione rilascio del sistema, Progettazione delle modifiche, Implementazione delle modifiche e Testing Il problema principale di questi approcci sta però nel ricavare le informazioni strutturali del sistema, qualora assenti o incomplete, e nel saperle adoperare per prevedere gli effetti delle modifiche e scegliere la strategia di intervento più efficace. Tali compiti possono essere svolti tramite l'utilizzo dell'impact Analysis all'interno del processo di manutenzione. Quando vengono effettuate modifiche sul codice, infatti, vi saranno inevitabilmente effetti imprevisti sul programma che possono essere rilevati tramite le tecniche di analisi di impatto. Prima della realizzazione dei cambiamenti si può usare l'impact analysis per migliorare la comprensione del programma e fare previsioni sull'impatto della modifica e sui costi di modifica. Dopo la realizzazione delle modifiche invece l'impact analysis guida la scelta dei casi di test da ripetere nei test di regressione [26]. 1.2 Integrazione dell'analisi di Impatto nel processo di modifica La procedura di manutenzione del software presentata di seguito, proposta da Shawn A. Bohner nel 1996 [25], nasce con lo specifico intento di integrare le tecniche di analisi di impatto nell'intero processo di modifica. Il fulcro di tale approccio non sta nei singoli passaggi, non molto differenti rispetto a quelli degli altri metodi elencati finora, ma nelle metriche di manutenibilità usate per quantificare i risultati di ogni fase del processo e per farsi un'idea delle condizioni del sistema, nonché per misurare la bontà degli interventi proposti/realizzati. Grazie a questo accorgimento ogni passo della procedura può essere ripetuto iterativamente qualora gli indicatori definiti a partire da tali metriche evidenzino dei risultati insoddisfacenti: in questo modo il processo di manutenzione risulta molto più flessibile ed efficace. Il seguente schema SADT (Structured Analysis and Design Technique) [MAR93] mostra il contesto operativo dei processi di modifica: 9

10 Esso evidenzia i dati necessari ad avviare il processo di manutenzione (richieste di modifica e sistema attuale) e mostra le fasi durante le quali è possibile individuare ulteriori difetti e malfunzionamenti (manutenzione ed esecuzione). Lo schema successivo illustra invece in maniera semplificata le fasi del processo di manutenzione, descritte singolarmente nel seguito: Gestione modifica del software Questa fase dirige e coordina tutte le altre operazioni di manutenzione, determinando le azioni più appropriate da compiere in base agli obiettivi e ai vincoli stabiliti. Le numerose decisioni prese nel corso di questa attività riguardo alla realizzazione dell'intervento sono influenzate in gran parte dagli indicatori di gestione restituiti dalle altre attività nel corso del processo. In questo stadio si 10

11 vanno a determinare gli obiettivi di qualità del software, si stabiliscono i rischi connessi alla modifica, si producono le stime di cambiamento, si pianifica il rilascio degli aggiornamenti, si tiene traccia dello stato attuale delle modifiche e si assegnano di conseguenza ad ogni attività le risorse necessarie. Comprensione della modifica e Determinazione dell'impatto Questa attività consiste nell'analizzare le richieste di cambiamento, tradurle in una forma comprensibile che non sia ambigua e valutare i possibili effetti di tali modifiche. Essa inoltre serve a memorizzare informazioni sulla storia delle modifiche utili per agevolare gli interventi futuri. I passi previsti in questa fase sono la revisione della documentazione software, la chiarificazione delle richieste di modifica, l'identificazione degli impatti della modifica, la registrazione degli impatti individuati e la valutazione della stabilità del sistema. Oltre alle richieste chiarificate e all'insieme degli impatti rilevati vengono forniti come risultato gli indicatori relativi al grado di Tracciabilità e di Stabilità del sistema. L'identificazione degli impatti della modifica riveste un ruolo fondamentale nel procedimento appena visto, in quanto è al suo interno che avviene l'analisi di Impatto vera e propria. Lo schema adottato per realizzare l'impact Analysis è il seguente: Si può osservare facilmente come tale analisi vada ad integrare le informazioni di alto livello e quelle di basso livello al fine di garantire la completezza dei risultati. Può tuttavia accadere che ulteriori effetti collaterali dovuti alle modifiche emergano nel corso delle attività successive: in tal 11

12 caso è sufficiente registrarli ed eventualmente ripetere l'identificazione degli impatti della modifica tenendo conto della loro esistenza. Specifica e progettazione della modifica In questa fase le richieste di modifica chiarificate vengono adoperate per generare le nuove specifiche dei requisiti e del design. Viene inoltre fornita una misura della comprensibilità del design del sistema tramite gli indicatori relativi alla Complessità, alla Modularità e alla Qualità della documentazione. Anche le relazioni tra Software Life-cycle Objects (SLO) vengono analizzate per stabilire se la modifica andrà a migliorare o peggiorare la manutenibilità del sistema e, nel caso vi sia il rischio di raggiungere un livello di peggioramento non accettabile, si può tornare alle fasi precedenti del processo per rivalutare il metodo di realizzazione della modifica o addirittura la sua effettiva necessità. Questo stadio del processo include l'analisi dei requisiti di modifica, la valutazione delle variazioni nell'architettura, la derivazione dei requisiti di modifica correlati e la progettazione delle modifiche da realizzare. Implementazione dei cambiamenti A partire dalle specifiche di progetto appena delineate vengono a questo punto realizzati gli interventi di modifica pianificati, aggiornando di conseguenza la relativa documentazione di sistema e ripetendo il testing di unità sui moduli interessati dalle variazioni. La realizzazione delle modifiche prevede la ricerca dei moduli da modificare, l'identificazione dei cambiamenti al livello di statement, l'applicazione delle modifiche al codice sorgente ed il testing di unità sui componenti interessati dall'intervento. Queste attività consentono tra le altre cose di estrarre dal codice sorgente gli indicatori di Adattabilità ed Autodescrittività del software. Testing del software modificato Una volta ultimati gli interventi sul codice sorgente è necessario ripetere i test per verificare il funzionamento del sistema e per assicurarsi che esso operi conformemente ai nuovi requisiti. Un'ulteriore indicazione sulla bontà del prodotto appena ultimato viene poi ottenuta in questa fase ricavando dai test effettuati gli indicatori di Testabilità, Completezza e Verificabilità. Per prima cosa in questo stadio si verifica se è necessario generare casi di test supplementari per coprire eventuali funzionalità aggiunte con la modifica, dopodiché si aggiorna l'insieme dei casi di test e si effettuano i test di integrazione, il testing globale di sistema ed il testing di accettazione. Ora che le attività del processo di manutenzione sono state formalizzate adeguatamente resta da capire come si fa a realizzare l'analisi di Impatto di un sistema software. 12

13 Capitolo 2 Analisi di Impatto Anche se da molti anni ormai viene utilizzata nella pratica ingegneristica, l'impact Analysis (IA) è tuttora priva di una definizione univoca. Bohner e Arnold la indicano come "l'identificazione delle potenziali conseguenze di un cambiamento, o la stima di ciò che è necessario modificare per portare a termine un cambiamento [5]. Pfleeger e Atlee definiscono invece l'ia come "la valutazione dei molteplici rischi associati al cambiamento, incluse le stime degli effetti su risorse, sforzi e programmi di lavoro [27]. Ibrahim e Munro sottolineano inoltre che essa fornisce visibilità ai potenziali effetti delle modifiche prima che tali modifiche vengano effettivamente implementate [2]. Esistono anche altre definizioni nella letteratura del settore, ma tutte delineano in maniera più o meno esplicita lo scopo primario di questa attività: individuare le relazioni e le dipendenze esistenti tra i diversi componenti di un sistema software per stabilire i possibili effetti di una modifica. Tale conoscenza è finalizzata al confronto delle diverse metodologie di intervento utilizzabili in fase di manutenzione, in modo da scegliere quella più adatta alle esigenze del caso specifico. 2.1 Tipologie di IA A seconda del livello di astrazione adottato per cercare le relazioni tra componenti si può parlare di: Traceability Impact Analysis (approccio di alto livello), finalizzata alla ricerca delle relazioni tra i moduli del software tramite i modelli, i diagrammi ed i documenti di specifica prodotti nel corso della progettazione. Se, ad esempio, per realizzare un certo requisito di sistema è stato progettato un apposito componente di design, allora quel componente dipende dal requisito di origine. Dependency Impact Analysis (approccio di basso livello), finalizzata alla ricerca delle dipendenze tra variabili, classi, flussi di controllo e funzioni all'interno del codice sorgente. Questa ricerca può essere realizzata sia con approccio statico, interpretando struttura e contenuto del codice sorgente, sia con approccio dinamico, osservando il comportamento in esecuzione del sistema. Se, ad esempio, il comportamento di una classe cambia in base al valore di una certa variabile, allora la classe dipende da quella variabile. 13

14 Il primo metodo permette di ottenere una visione d'insieme del sistema da modificare, delineando i legami tra requisiti, componenti del design, moduli software e casi di test. Qualora la conoscenza dei suddetti legami non sia già disponibile, essa va ottenuta effettuando lo Studio di Tracciabilità del prodotto software. Le dipendenze tra i SLO prodotti nelle varie fasi del ciclo di vita del software non vanno assolutamente trascurate (a differenza di quanto fanno molti progettisti), in quanto permettono di stabilire anche per sistemi molto complessi il modo in cui una modifica in un livello di astrazione si propaga sugli altri livelli. Il secondo metodo, molto più diffuso del primo nella pratica, si limita invece ad analizzare il codice del software per estrarne la struttura della soluzione implementativa utilizzata. Tale operazione può essere fatta con l'ausilio di diverse tecniche di analisi del codice [25]: Data Flow Analysis [TAH88], che prevede per ciascuna variabile contenuta nel codice la ricerca dei punti del programma che utilizzano il valore di tale variabile. A seconda della direzione lungo la quale avviene l'analisi si può parlare di Forward Analysis o di Backward Analysis Control Flow Analysis, che consiste nello studio del flusso di esecuzione del programma in termini di procedure e funzioni invocate per ciascun insieme di valori forniti in ingresso. I risultati di questa analisi vengono solitamente espressi tramite un Control Flow Graph (CFG) Dependency Analysis [WIL87], che integra la Data Flow Analysis e la Control Flow Analysis al fine di ricavare i vincoli relativi all'ordine di esecuzione dei singoli statement. Tali vincoli permettono, tra le altre cose, di determinare i punti del programma in cui è possibile eseguire più statement in parallelo senza rischi di fallimento dell'esecuzione Program Slicing [GAL91], che consente di isolare all'interno del codice gli statement relativi ad un singolo comportamento dell'eseguibile, in quanto dipendenti dal contenuto di uno statement di partenza (detto Criterio di Slicing) Le informazioni estratte tramite queste procedure possono essere divise in tre classi principali [5]: Data Dependencies dipendenze dei flussi di dati dipendenze di invocazione dipendenze di definizione dipendenze funzionali 14

15 Control Dependencies chiamate a funzione strutture di controllo decisionali (IF/ELSE) strutture di controllo cicliche (LOOP) Component Dependencies dipendenze per riferimenti incrociati dipendenze da analisi di copertura dei test dipendenze da comparazione del codice sorgente Esse permettono di capire quali sono le classi, le variabili, le funzioni ed i moduli che devono essere ricontrollati quando si va a cambiare qualcosa in un metodo da essi invocato o in una classe da essi utilizzata/ereditata. 2.2 Rappresentazione degli impatti Le relazioni ricavate tramite la Dependency IA possono essere rappresentate efficacemente adottando strumenti standard come i Class Diagram in UML o i Control Flow Graph. Per una rappresentazione più generica, adatta anche ai risultati della Traceability IA, si possono usare invece i grafi orientati dei SLO, le matrici di connettività o le matrici di raggiungibilità [5]. Nei Grafi Orientati ciascun componente, ciascun modulo o ciascun SLO generico viene raffigurato come un nodo, mentre le relazioni tra gli oggetti vengono indicate tramite archi orientati. Un arco parte dal nodo dell'oggetto modificato ed arriva al nodo dell'oggetto influenzato dalla modifica, quindi si ha che i nodi di arrivo dipendono dai rispettivi nodi di partenza. Le relazioni così rappresentate costituiscono gli Impatti diretti (detti anche First Order Impacts), mentre un percorso formato da più archi denota la presenza di un Impatto indiretto (detto anche N-Order Impact). In uno stesso grafo si può inoltre decidere di inserire SLO appartenenti a diversi stadi dello sviluppo del software: in questo caso ogni stadio viene rappresentato come un rettangolo contenente i nodi corrispondenti ai propri componenti. Di seguito viene mostrato un esempio di grafo orientato per dimostrare quanto questa forma rappresentativa possa risultare complessa anche per un numero limitato di nodi. 15

16 Una rappresentazione meno confusa e più congeniale alle esigenze degli ingegneri del software è quella tramite Matrici di Connettività. In esse si hanno un numero di righe ed un numero di colonne pari al numero di nodi, e il valore della singola cella indica se tra la coppia Nodo Riga > Nodo Colonna vi è un impatto diretto o no. Le Matrici di Raggiungibilità sono la naturale estensione delle matrici di connettività al caso di dipendenze indirette. Il valore della singola cella indica stavolta l'ordine di impatto della coppia Nodo Riga > Nodo Colonna: esso è pari a zero nel caso non vi siano dipendenze, è pari ad uno nel caso di dipendenze dirette o è maggiore di uno nel caso di dipendenze indirette. La matrice di raggiungibilità può essere calcolata a partire proprio dalla matrice di connettività applicando un algoritmo di Chiusura Transitiva opportunamente adattato. Usando una matrice di raggiungibilità si può capire quali oggetti potrebbero essere influenzati dalla modifica di un particolare SLO e, nel caso vi siano più alternative, si può scegliere di intervenire sul SLO la cui modifica innesca il minor numero di effetti ripple. Il seguente è un esempio di matrice di raggiungibilità: SLO1 SLO2 SLO3 SLO4 SLO5 SLO SLO SLO SLO SLO

17 L'utilizzo di questa modalità di rappresentazione, alla luce di quanto detto in precedenza, risulta di particolare aiuto per assistere l'analisi del software e per supportare le attività decisionali. L'utilizzo dei grafi orientati, d'altra parte, fornisce una visione più intuitiva ed immediata della struttura del sistema ma non è particolarmente agevole per gli studi di tipo ingegneristico. 2.3 Classi di algoritmi di ricerca Per effettuare l'analisi di impatto possono essere impiegati svariati algoritmi di ricerca delle dipendenze. Tali metodi sono raggruppati in cinque categorie [28]: 1. Algoritmi su base Semantica L'Impact Analysis è guidata da una semantica di oggetti e relazioni predeterminata, derivabile tramite algoritmi di reti semantiche o tramite database di confronto. Tale semantica viene usata per estrarre dalle informazioni disponibili ulteriori informazioni implicite. 2. Algoritmi su base Euristica L'identificazione degli impatti è diretta in base ad un insieme di regole prestabilite o in base a particolari euristiche, concepite in modo da distinguere i possibili percorsi da verificare e quelli non necessari ai fini della modifica. 3. Algoritmi su base Stocastica L'Analisi di Impatto si fonda su uno studio probabilistico del comportamento dei singoli SLO e degli eventi che caratterizzano la fase di esecuzione. In questo modo è possibile stimare con precisione i rischi collegati ad una modifica. 4. Algoritmi Ibridi La ricerca degli impatti viene fatta combinando due o più metodi tra quelli appena elencati. 5. Algoritmi Esaustivi Si individuano gli impatti tramite un approccio brute force, elaborando le sole informazioni di tracciabilità esplicitamente disponibili. La scelta della tipologia di algoritmo da adottare è strettamente legata all'ambito di applicazione del sistema in esame: ciascun approccio, infatti, può risultare più o meno efficace a seconda del contesto operativo e delle informazioni disponibili. 17

18 2.4 Tecniche per la determinazione degli impatti I vari algoritmi esistenti per la determinazione degli impatti, pur essendo molto diversi tra loro, lavorano sempre basandosi su modelli più o meno dettagliati del sistema e ricercano i componenti influenzati da una certa modifica tramite l'elaborazione dei SLO e delle loro relazioni. Tali procedure dipendono ovviamente dalla rappresentazione adottata per il modello in esame e sono alla base dei principali approcci di Analisi di Impatto automatica. Gli algoritmi più conosciuti in quest'ambito sono quelli di Chiusura Transitiva, Inferenze e Program Slicing [5] Chiusura transitiva A partire da un modello grafico o matriciale delle dipendenze dirette tra i componenti del sistema si ricavano le dipendenze indirette, considerando tutti i possibili percorsi da un oggetto ad un altro: A B C D E A B C D E A A B B C C D D E E Tale approccio è molto intuitivo ma risulta privo di euristiche di ricerca dipendenti dal dominio applicativo, quindi la precisione dei suoi risultati può essere talvolta insoddisfacente. L'algoritmo è di implementazione molto semplice, ma ha lo svantaggio di diventare estremamente lento al crescere degli elementi da elaborare Inferenze Un insieme di regole predeterminate guida la descrizione formale delle relazioni tra i singoli oggetti e consente la loro elaborazione per estrarne ulteriori relazioni implicite. 18

19 Il formalismo adottato in questo approccio permette di memorizzare le dipendenze individuate in un database e consente di dimensionare adeguatamente lo spazio di ricerca in base al problema affrontato. I sistemi deduttivi che implementano questa tipologia di algoritmo sono composti generalmente da un database di assunzioni, da una procedura per dedurre nuove assunzioni da quelle disponibili e da strumenti per gestire la ricerca nel database. La valutazione degli impatti può essere realizzata a questo punto tramite Truth maintenance constraint systems, ovvero strutture in grado di verificare la consistenza di un modello mediante una serie di vincoli, o tramite Semantic Inferencing, ovvero reti semantiche che definiscono meccanismi di reasoning automatizzato Program Slicing Tramite meccanismi basati su uno o più criteri di slicing questo approccio permette di restringere il campo dell'analisi agli elementi caratterizzanti un singolo comportamento dell'eseguibile. Nel contesto dell'impact Analysis si può quindi isolare la parte di codice sorgente che potrebbe risentire delle modifiche, tralasciando i moduli software non essenziali. Gli algoritmi di questo tipo usano tecniche di data flow analysis e di control flow analysis per estrarre dal codice le informazioni strutturali, dopodiché i risultati ottenuti vengono filtrati applicando i criteri di slicing adottati. int x = 0; int b = 0; int c = 2; for(int i=0;i<max;i++) = program slice estratto { k[i] = (a*i+c)/100; cout << k[i]; } int var = b + d; x = x * c; float result = compute_function( b, x ); 19

20 Capitolo 3 Tracciabilità La tracciabilità viene definita come l'abilità di individuare gli oggetti dipendenti all'interno di un modello e l'abilità di individuare gli oggetti corrispondenti negli altri modelli [1]. Con il termine modello viene qui indicata una rappresentazione sintetica del sistema in esame ad un livello di astrazione più o meno dettagliato, riportata con modalità grafico/testuale oppure tabellare. Il termine oggetto delinea invece un generico Software Life-cycle Object (SLO) prodotto nel corso dell'attività di sviluppo e costituisce l'unità base per la costruzione di un modello. Si può anche identificare il concetto di tracciabilità come l'abilità di risalire alle relazioni tra gli artefatti software generati e modificati durante il ciclo di vita del prodotto software [5]. Ad ogni modo la tracciabilità è una caratteristica molto importante di un sistema, in quanto consente di ricavare le relazioni strutturali che lo costituiscono e di ricostruire le varie fasi del suo sviluppo. 3.1 Livelli ed approcci di tracciabilità La prima definizione fornita permette di stabilire una distinzione preliminare tra due tipologie di tracciabilità [3]: Tracciabilità verticale riguarda le relazioni di dipendenza tra oggetti appartenenti ad uno stesso modello Tracciabilità orizzontale riguarda le relazioni di corrispondenza tra oggetti appartenenti a due modelli diversi A seconda del livello di dettaglio si distinguono poi quattro tipi di modello [2]: requisiti modello relativo ai singoli requisiti funzionali del sistema. La specifica di ciascun requisito costituisce il singolo SLO adoperato in questo stadio design modello relativo alla progettazione dell'architettura del software. A seconda del grado di astrazione scelto si può parlare di: 1. design di alto livello, rappresentabile ad esempio tramite un Collaboration Design Model 2. design di basso livello, rappresentabile ad esempio tramite un Class Diagram in UML 20

Indice generale. OOA Analisi Orientata agli Oggetti. Introduzione. Analisi

Indice generale. OOA Analisi Orientata agli Oggetti. Introduzione. Analisi Indice generale OOA Analisi Orientata agli Oggetti Introduzione Analisi Metodi d' analisi Analisi funzionale Analisi del flusso dei dati Analisi delle informazioni Analisi Orientata agli Oggetti (OOA)

Dettagli

Automazione Industriale (scheduling+mms) scheduling+mms. adacher@dia.uniroma3.it

Automazione Industriale (scheduling+mms) scheduling+mms. adacher@dia.uniroma3.it Automazione Industriale (scheduling+mms) scheduling+mms adacher@dia.uniroma3.it Introduzione Sistemi e Modelli Lo studio e l analisi di sistemi tramite una rappresentazione astratta o una sua formalizzazione

Dettagli

11. Evoluzione del Software

11. Evoluzione del Software 11. Evoluzione del Software Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 11. Evoluzione del Software 1 / 21 Evoluzione del Software - generalità Cosa,

Dettagli

Concetti di base di ingegneria del software

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

Dettagli

12. Evoluzione del Software

12. Evoluzione del Software 12. Evoluzione del Software Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 12. Evoluzione del Software 1 / 21 Evoluzione del Software - generalità Cosa,

Dettagli

Ciclo di vita dimensionale

Ciclo di vita dimensionale aprile 2012 1 Il ciclo di vita dimensionale Business Dimensional Lifecycle, chiamato anche Kimball Lifecycle descrive il framework complessivo che lega le diverse attività dello sviluppo di un sistema

Dettagli

Piano di gestione della qualità

Piano di gestione della qualità Piano di gestione della qualità Pianificazione della qualità Politica ed obiettivi della qualità Riferimento ad un eventuale modello di qualità adottato Controllo della qualità Procedure di controllo.

Dettagli

Database. Si ringrazia Marco Bertini per le slides

Database. Si ringrazia Marco Bertini per le slides Database Si ringrazia Marco Bertini per le slides Obiettivo Concetti base dati e informazioni cos è un database terminologia Modelli organizzativi flat file database relazionali Principi e linee guida

Dettagli

Strumenti di modellazione. Gabriella Trucco

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

Dettagli

Generazione Automatica di Asserzioni da Modelli di Specifica

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

Dettagli

Project Cycle Management La programmazione della fase di progettazione esecutiva. La condivisione dell idea progettuale.

Project Cycle Management La programmazione della fase di progettazione esecutiva. La condivisione dell idea progettuale. Project Cycle Management La programmazione della fase di progettazione esecutiva. La condivisione dell idea progettuale. Il presente materiale didattico costituisce parte integrante del percorso formativo

Dettagli

La Metodologia adottata nel Corso

La Metodologia adottata nel Corso La Metodologia adottata nel Corso 1 Mission Statement + Glossario + Lista Funzionalià 3 Descrizione 6 Funzionalità 2 Schema 4 Schema 5 concettuale Logico EA Relazionale Codice Transazioni In PL/SQL Schema

Dettagli

Project Cycle Management

Project Cycle Management Project Cycle Management Tre momenti centrali della fase di analisi: analisi dei problemi, analisi degli obiettivi e identificazione degli ambiti di intervento Il presente materiale didattico costituisce

Dettagli

La gestione manageriale dei progetti

La gestione manageriale dei progetti PROGETTAZIONE Pianificazione, programmazione temporale, gestione delle risorse umane: l organizzazione generale del progetto Dimitri Grigoriadis La gestione manageriale dei progetti Per organizzare il

Dettagli

Progettaz. e sviluppo Data Base

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

Dettagli

Business Process Management

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

Dettagli

Analisi e diagramma di Pareto

Analisi e diagramma di Pareto Analisi e diagramma di Pareto L'analisi di Pareto è una metodologia statistica utilizzata per individuare i problemi più rilevanti nella situazione in esame e quindi le priorità di intervento. L'obiettivo

Dettagli

Project Management. Modulo: Introduzione. prof. ing. Guido Guizzi

Project Management. Modulo: Introduzione. prof. ing. Guido Guizzi Project Management Modulo: Introduzione prof. ing. Guido Guizzi Definizione di Project Management Processo unico consistente in un insieme di attività coordinate con scadenze iniziali e finali, intraprese

Dettagli

Configuration Management

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

Dettagli

La norma ISO 9001:08 ha apportato modifiche alla normativa precedente in

La norma ISO 9001:08 ha apportato modifiche alla normativa precedente in La norma ISO 9001:08 ha apportato modifiche alla normativa precedente in base alle necessità di chiarezza emerse nell utilizzo della precedente versione e per meglio armonizzarla con la ISO 14001:04. Elemento

Dettagli

Progettaz. e sviluppo Data Base

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

Dettagli

Trasformazione dei Processi in Progetti DIB 1

Trasformazione dei Processi in Progetti DIB 1 Trasformazione dei Processi in Progetti DIB 1 Generalità DIB 2 Progetto PROGETTO: esecuzione di un insieme di attività in un tempo e con risorse limitati per raggiungere uno specifico scopo. A causa dell

Dettagli

Gestione del workflow

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

Dettagli

Comune di San Martino Buon Albergo

Comune di San Martino Buon Albergo Comune di San Martino Buon Albergo Provincia di Verona - C.A.P. 37036 SISTEMA DI VALUTAZIONE DELLE POSIZIONI DIRIGENZIALI Approvato dalla Giunta Comunale il 31.07.2012 INDICE PREMESSA A) LA VALUTAZIONE

Dettagli

Ciclo di vita del progetto

Ciclo di vita del progetto IT Project Management Lezione 2 Ciclo di vita del progetto Federica Spiga A.A. 2009-2010 1 Ciclo di vita del progetto Il ciclo di vita del progetto definisce le fasi che collegano l inizio e la fine del

Dettagli

BASI DI DATI per la gestione dell informazione. Angelo Chianese Vincenzo Moscato Antonio Picariello Lucio Sansone

BASI DI DATI per la gestione dell informazione. Angelo Chianese Vincenzo Moscato Antonio Picariello Lucio Sansone BASI DI DATI per la gestione dell informazione Angelo Chianese Vincenzo Moscato Antonio Picariello Lucio Sansone Libro di Testo 22 Chianese, Moscato, Picariello e Sansone BASI DI DATI per la Gestione dell

Dettagli

Il database management system Access

Il database management system Access Il database management system Access Corso di autoistruzione http://www.manualipc.it/manuali/ corso/manuali.php? idcap=00&idman=17&size=12&sid= INTRODUZIONE Il concetto di base di dati, database o archivio

Dettagli

Norme per l organizzazione - ISO serie 9000

Norme per l organizzazione - ISO serie 9000 Norme per l organizzazione - ISO serie 9000 Le norme cosiddette organizzative definiscono le caratteristiche ed i requisiti che sono stati definiti come necessari e qualificanti per le organizzazioni al

Dettagli

Strutturazione logica dei dati: i file

Strutturazione logica dei dati: i file Strutturazione logica dei dati: i file Informazioni più complesse possono essere composte a partire da informazioni elementari Esempio di una banca: supponiamo di voler mantenere all'interno di un computer

Dettagli

Light CRM. Documento Tecnico. Descrizione delle funzionalità del servizio

Light CRM. Documento Tecnico. Descrizione delle funzionalità del servizio Documento Tecnico Light CRM Descrizione delle funzionalità del servizio Prosa S.r.l. - www.prosa.com Versione documento: 1, del 11 Luglio 2006. Redatto da: Michela Michielan, michielan@prosa.com Revisionato

Dettagli

ISTITUTO TECNICO ECONOMICO MOSSOTTI

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

Dettagli

Telerilevamento e GIS Prof. Ing. Giuseppe Mussumeci

Telerilevamento e GIS Prof. Ing. Giuseppe Mussumeci Corso di Laurea Magistrale in Ingegneria per l Ambiente e il Territorio A.A. 2014-2015 Telerilevamento e GIS Prof. Ing. Giuseppe Mussumeci Strutture di dati: DB e DBMS DATO E INFORMAZIONE Dato: insieme

Dettagli

QUESTIONARIO 1: PROCESSO DI AUTOVALUTAZIONE

QUESTIONARIO 1: PROCESSO DI AUTOVALUTAZIONE QUESTIONARIO 1: PROCESSO DI AUTOVALUTAZIONE Step 1 - Decidere come organizzare e pianificare l autovalutazione (AV) 1.1. Assicurare l impegno e il governo del management per avviare il processo. 1.2. Assicurare

Dettagli

Base di dati e sistemi informativi

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

Dettagli

Fasi di creazione di un programma

Fasi di creazione di un programma Fasi di creazione di un programma 1. Studio Preliminare 2. Analisi del Sistema 6. Manutenzione e Test 3. Progettazione 5. Implementazione 4. Sviluppo 41 Sviluppo di programmi Per la costruzione di un programma

Dettagli

Progettazione di Basi di Dati

Progettazione di Basi di Dati Progettazione di Basi di Dati Prof. Nicoletta D Alpaos & Prof. Andrea Borghesan Entità-Relazione Progettazione Logica 2 E il modo attraverso il quale i dati sono rappresentati : fa riferimento al modello

Dettagli

Capitolo 4 - Teoria della manutenzione: la gestione del personale

Capitolo 4 - Teoria della manutenzione: la gestione del personale Capitolo 4 - Teoria della manutenzione: la gestione del personale Con il presente capitolo si chiude la presentazione delle basi teoriche della manutenzione. Si vogliono qui evidenziare alcune problematiche

Dettagli

Strumenti per la gestione della configurazione del software

Strumenti per la gestione della configurazione del software tesi di laurea Anno Accademico 2005/2006 relatore Ch.mo prof. Porfirio Tramontana correlatore Ch.mo ing. Luigi Suarato candidato Pasquale Palumbo Matr. 534/000021 MANUTENZIONE DEL SOFTWARE Il Configuration

Dettagli

INGEGNERIA DEL SOFTWARE. Prof. Paolo Salvaneschi

INGEGNERIA DEL SOFTWARE. Prof. Paolo Salvaneschi Università di Bergamo Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica INGEGNERIA DEL SOFTWARE Prof. Paolo Salvaneschi 1 Obiettivi Scopi del corso: - Fornire gli elementi di base della disciplina,

Dettagli

Organizzazione degli archivi

Organizzazione degli archivi COSA E UN DATA-BASE (DB)? è l insieme di dati relativo ad un sistema informativo COSA CARATTERIZZA UN DB? la struttura dei dati le relazioni fra i dati I REQUISITI DI UN DB SONO: la ridondanza minima i

Dettagli

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

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

Dettagli

della manutenzione, includa i requisiti relativi ai sottosistemi strutturali all interno del loro contesto operativo.

della manutenzione, includa i requisiti relativi ai sottosistemi strutturali all interno del loro contesto operativo. L 320/8 Gazzetta ufficiale dell Unione europea IT 17.11.2012 REGOLAMENTO (UE) N. 1078/2012 DELLA COMMISSIONE del 16 novembre 2012 relativo a un metodo di sicurezza comune per il monitoraggio che devono

Dettagli

S i s t e m a d i v a l u t a z i o n e d e l l e p r e s t a z i o n i d e i d i p e n d e n t i

S i s t e m a d i v a l u t a z i o n e d e l l e p r e s t a z i o n i d e i d i p e n d e n t i S i s t e m a d i v a l u t a z i o n e d e l l e p r e s t a z i o n i d e i d i p e n d e n t i P r o d o t t o d a A l b e r t o P a o l i n i G r o s s e t o P a r c h e g g i s r l V e n g o n o p

Dettagli

ALLINEARSI: IL DRIVER PER UNA INNOVAZIONE DI SUCCESSO!

ALLINEARSI: IL DRIVER PER UNA INNOVAZIONE DI SUCCESSO! ALLINEARSI: IL DRIVER PER UNA INNOVAZIONE DI SUCCESSO! L allineamento del team esecutivo è definibile come l accordo dei membri del team in merito a: 1. Allineamento personale -consapevolezza dell impatto

Dettagli

MODULO 5 Appunti ACCESS - Basi di dati

MODULO 5 Appunti ACCESS - Basi di dati MODULO 5 Appunti ACCESS - Basi di dati Lezione 1 www.mondopcnet.com Modulo 5 basi di dati Richiede che il candidato dimostri di possedere la conoscenza relativa ad alcuni concetti fondamentali sui database.

Dettagli

Funzioni funzione dominio codominio legge argomento variabile indipendente variabile dipendente

Funzioni funzione dominio codominio legge argomento variabile indipendente variabile dipendente Funzioni In matematica, una funzione f da X in Y consiste in: 1. un insieme X detto dominio di f 2. un insieme Y detto codominio di f 3. una legge che ad ogni elemento x in X associa uno ed un solo elemento

Dettagli

Modellazione di sistema

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

Dettagli

Soluzione dell esercizio del 2 Febbraio 2004

Soluzione dell esercizio del 2 Febbraio 2004 Soluzione dell esercizio del 2 Febbraio 2004 1. Casi d uso I casi d uso sono riportati in Figura 1. Figura 1: Diagramma dei casi d uso. E evidenziato un sotto caso di uso. 2. Modello concettuale Osserviamo

Dettagli

Introduzione all Information Retrieval

Introduzione all Information Retrieval Introduzione all Information Retrieval Argomenti della lezione Definizione di Information Retrieval. Information Retrieval vs Data Retrieval. Indicizzazione di collezioni e ricerca. Modelli per Information

Dettagli

IL CICLO DI VITA DEL PROGETTO. Elementi essenziali di progetto. Fasi e tappe Gli Approcci

IL CICLO DI VITA DEL PROGETTO. Elementi essenziali di progetto. Fasi e tappe Gli Approcci UNIVERSITA MILANO BICOCCA Corso di laurea di primo livello in servizio sociale anno accademico 2009-2010 Progettare il sociale Prof. Dario A. Colombo IL CICLO DI VITA DEL PROGETTO Elementi essenziali di

Dettagli

IL SISTEMA INFORMATIVO

IL SISTEMA INFORMATIVO IL SISTEMA INFORMATIVO In un organizzazione l informazione è una risorsa importante al pari di altri tipi di risorse: umane, materiali, finanziarie, (con il termine organizzazione intendiamo un insieme

Dettagli

Brochure Internet. Versione 2010.1 The Keyrules Company s.r.l. Pagina 2 di 8

Brochure Internet. Versione 2010.1 The Keyrules Company s.r.l. Pagina 2 di 8 Ogni organizzazione possiede un sistema di regole che la caratterizzano e che ne assicurano il funzionamento. Le regole sono l insieme coordinato delle norme che stabiliscono come deve o dovrebbe funzionare

Dettagli

Alessandra Raffaetà. Basi di Dati

Alessandra Raffaetà. Basi di Dati Lezione 2 S.I.T. PER LA VALUTAZIONE E GESTIONE DEL TERRITORIO Corso di Laurea Magistrale in Scienze Ambientali Alessandra Raffaetà Dipartimento di Informatica Università Ca Foscari Venezia Basi di Dati

Dettagli

1. BASI DI DATI: GENERALITÀ

1. BASI DI DATI: GENERALITÀ 1. BASI DI DATI: GENERALITÀ BASE DI DATI (DATABASE, DB) Raccolta di informazioni o dati strutturati, correlati tra loro in modo da risultare fruibili in maniera ottimale. Una base di dati è usualmente

Dettagli

PROJECT MANAGEMENT SERVIZI DI PROJECT MANAGEMENT DI ELEVATA PROFESSIONALITÀ

PROJECT MANAGEMENT SERVIZI DI PROJECT MANAGEMENT DI ELEVATA PROFESSIONALITÀ PROJECT MANAGEMENT SERVIZI DI PROJECT MANAGEMENT DI ELEVATA PROFESSIONALITÀ SERVIZI DI PROJECT MANAGEMENT CENTRATE I VOSTRI OBIETTIVI LA MISSIONE In qualità di clienti Rockwell Automation, potete contare

Dettagli

ControlloCosti. Cubi OLAP. Controllo Costi Manuale Cubi

ControlloCosti. Cubi OLAP. Controllo Costi Manuale Cubi ControlloCosti Cubi OLAP I cubi OLAP Un Cubo (OLAP, acronimo di On-Line Analytical Processing) è una struttura per la memorizzazione e la gestione dei dati che permette di eseguire analisi in tempi rapidi,

Dettagli

LA REVISIONE LEGALE DEI CONTI La comprensione

LA REVISIONE LEGALE DEI CONTI La comprensione LA REVISIONE LEGALE DEI CONTI La comprensione dell impresa e del suo contesto e la valutazione dei rischi di errori significativi Ottobre 2013 Indice 1. La comprensione dell impresa e del suo contesto

Dettagli

Gestione parte IIC. Diagrammi di Gantt. Esempio. Schemi di scomposizione delle attività

Gestione parte IIC. Diagrammi di Gantt. Esempio. Schemi di scomposizione delle attività Schemi di scomposizione delle attività Gestione parte IIC Work Breakdown Structures (WBS) Struttura ad albero: radice: attività principale i nodi figli rappresentano la scomposizione del nodo padre le

Dettagli

I casi d uso corrispondono ai compiti che l attore (che può essere una persona fisica e non) può svolgere.

I casi d uso corrispondono ai compiti che l attore (che può essere una persona fisica e non) può svolgere. UML e i Casi d USO I casi d uso specificano una sequenza di azioni che producono un risultato visibile agli attori del sistema. Essi nascono per fornire descrizioni delle capacità del sistema. I casi d

Dettagli

MANUALE DELLA QUALITÀ SIF CAPITOLO 08 (ED. 01) MISURAZIONI, ANALISI E MIGLIORAMENTO

MANUALE DELLA QUALITÀ SIF CAPITOLO 08 (ED. 01) MISURAZIONI, ANALISI E MIGLIORAMENTO INDICE 8.1 Generalità 8.2 Monitoraggi e Misurazione 8.2.1 Soddisfazione del cliente 8.2.2 Verifiche Ispettive Interne 8.2.3 Monitoraggio e misurazione dei processi 8.2.4 Monitoraggio e misurazione dei

Dettagli

lem logic enterprise manager

lem logic enterprise manager logic enterprise manager lem lem Logic Enterprise Manager Grazie all esperienza decennale in sistemi gestionali, Logic offre una soluzione modulare altamente configurabile pensata per la gestione delle

Dettagli

Il sapere tende oggi a caratterizzarsi non più come un insieme di contenuti ma come un insieme di metodi e di strategie per risolvere problemi.

Il sapere tende oggi a caratterizzarsi non più come un insieme di contenuti ma come un insieme di metodi e di strategie per risolvere problemi. E. Calabrese: Fondamenti di Informatica Problemi-1 Il sapere tende oggi a caratterizzarsi non più come un insieme di contenuti ma come un insieme di metodi e di strategie per risolvere problemi. L'informatica

Dettagli

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

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

Dettagli

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

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

Dettagli

VALORE DELLE MERCI SEQUESTRATE

VALORE DELLE MERCI SEQUESTRATE La contraffazione in cifre: NUOVA METODOLOGIA PER LA STIMA DEL VALORE DELLE MERCI SEQUESTRATE Roma, Giugno 2013 Giugno 2013-1 Il valore economico dei sequestri In questo Focus si approfondiscono alcune

Dettagli

Laboratorio di Pedagogia Sperimentale. Indice

Laboratorio di Pedagogia Sperimentale. Indice INSEGNAMENTO DI LABORATORIO DI PEDAGOGIA SPERIMENTALE LEZIONE III INTRODUZIONE ALLA RICERCA SPERIMENTALE (PARTE III) PROF. VINCENZO BONAZZA Indice 1 L ipotesi -----------------------------------------------------------

Dettagli

SVILUPPO, CERTIFICAZIONE E MIGLIORAMENTO DEL SISTEMA DI GESTIONE PER LA SICUREZZA SECONDO LA NORMA BS OHSAS 18001:2007

SVILUPPO, CERTIFICAZIONE E MIGLIORAMENTO DEL SISTEMA DI GESTIONE PER LA SICUREZZA SECONDO LA NORMA BS OHSAS 18001:2007 Progettazione ed erogazione di servizi di consulenza e formazione M&IT Consulting s.r.l. Via Longhi 14/a 40128 Bologna tel. 051 6313773 - fax. 051 4154298 www.mitconsulting.it info@mitconsulting.it SVILUPPO,

Dettagli

UML - Unified Modeling Language

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

Dettagli

Appendice III. Competenza e definizione della competenza

Appendice III. Competenza e definizione della competenza Appendice III. Competenza e definizione della competenza Competenze degli psicologi Lo scopo complessivo dell esercizio della professione di psicologo è di sviluppare e applicare i principi, le conoscenze,

Dettagli

Artifact Centric Business Processes (I)

Artifact Centric Business Processes (I) Introduzione Autore: Docente: Prof. Giuseppe De Giacomo Dipartimento di Informatica e Sistemistica SAPIENZA - Universitá di Roma 16 Novembre 2008 Una visione assiomatica La modellazione dei processi di

Dettagli

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

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

Dettagli

Sistemi di misurazione e valutazione delle performance

Sistemi di misurazione e valutazione delle performance Sistemi di misurazione e valutazione delle performance 1 SVILUPPO DELL'INTERVENTO Cos è la misurazione e valutazione delle performance e a cosa serve? Efficienza Efficacia Outcome Requisiti minimi Indicatori

Dettagli

Tecnologie dell informazione e della comunicazione per le aziende

Tecnologie dell informazione e della comunicazione per le aziende ! "#%&"'(&)*++,%#,"'"(&("##&-"! "!#!. /##&('"*#,0"1&,2)*',%3"2&11"1&,2& 4 "3'&"22&5 "3'&"22&6 "3'&"22&7 "0#8"22&9! "0#8"22&9 ",33& : '&&0+"##&)*''";,%,!,00"%&, Obiettivo del presente capitolo è presentare

Dettagli

I Sistemi di Gestione Integrata Qualità, Ambiente e Sicurezza alla luce delle novità delle nuove edizioni delle norme ISO 9001 e 14001

I Sistemi di Gestione Integrata Qualità, Ambiente e Sicurezza alla luce delle novità delle nuove edizioni delle norme ISO 9001 e 14001 I Sistemi di Gestione Integrata Qualità, Ambiente e Sicurezza alla luce delle novità delle nuove edizioni delle norme ISO 9001 e 14001 Percorsi di ampliamento dei campi di applicazione gestiti in modo

Dettagli

LA GESTIONE DELLE INFORMAZIONI IN AZIENDA: LA FUNZIONE SISTEMI INFORMATIVI 173 7/001.0

LA GESTIONE DELLE INFORMAZIONI IN AZIENDA: LA FUNZIONE SISTEMI INFORMATIVI 173 7/001.0 LA GESTIONE DELLE INFORMAZIONI IN AZIENDA: LA FUNZIONE SISTEMI INFORMATIVI 173 7/001.0 LA GESTIONE DELLE INFORMAZIONI IN AZIENDA: LA FUNZIONE SISTEMI INFORMATIVI PIANIFICAZIONE STRATEGICA NELL ELABORAZIONE

Dettagli

ISA 610 e ISA 620 L'utilizzo durante la revisione dei revisori interni e degli esperti. Corso di revisione legale dei conti progredito

ISA 610 e ISA 620 L'utilizzo durante la revisione dei revisori interni e degli esperti. Corso di revisione legale dei conti progredito ISA 610 e ISA 620 L'utilizzo durante la revisione dei revisori interni e degli esperti. Corso di revisione legale dei conti progredito 1 ISA 610 USING THE WORK OF INTERNAL AUDITORS Questo principio tratta

Dettagli

IL PROCESSO DI FABBRICAZIONE (sviluppo nuovo prodotto)

IL PROCESSO DI FABBRICAZIONE (sviluppo nuovo prodotto) CORSO DI Gestione aziendale Facoltà di Ingegneria IL PROCESSO DI FABBRICAZIONE (sviluppo nuovo prodotto) Carlo Noè Università Carlo Cattaneo Istituto di Tecnologie e-mail: cnoe@liuc.it 1 Il processo di

Dettagli

Schema metodologico per la valutazione del personale del comparto addetto agli uffici di diretta collaborazione

Schema metodologico per la valutazione del personale del comparto addetto agli uffici di diretta collaborazione Schema metodologico per la valutazione del personale del comparto addetto agli uffici di diretta collaborazione Sommario Premessa... 2 1. Introduzione... 3 2. Criteri generali della metodologia di valutazione...

Dettagli

Corso di. Dott.ssa Donatella Cocca

Corso di. Dott.ssa Donatella Cocca Corso di Statistica medica e applicata Dott.ssa Donatella Cocca 1 a Lezione Cos'è la statistica? Come in tutta la ricerca scientifica sperimentale, anche nelle scienze mediche e biologiche è indispensabile

Dettagli

La progettazione centrata sull utente nei bandi di gara

La progettazione centrata sull utente nei bandi di gara Progetto PerformancePA Ambito A - Linea 1 - Una rete per la riforma della PA La progettazione centrata sull utente nei bandi di gara Autore: Maurizio Boscarol Creatore: Formez PA, Progetto Performance

Dettagli

Stefania Marrara - Esercitazioni di Tecnologie dei Sistemi Informativi. Integrazione di dati di sorgenti diverse

Stefania Marrara - Esercitazioni di Tecnologie dei Sistemi Informativi. Integrazione di dati di sorgenti diverse Politecnico di Milano View integration 1 Integrazione di dati di sorgenti diverse Al giorno d oggi d la mole di informazioni che viene gestita in molti contesti applicativi è enorme. In alcuni casi le

Dettagli

TECNICO SUPERIORE PER L AUTOMAZIONE INDUSTRIALE

TECNICO SUPERIORE PER L AUTOMAZIONE INDUSTRIALE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE INDUSTRIA E ARTIGIANATO TECNICO SUPERIORE PER L AUTOMAZIONE INDUSTRIALE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI DESCRIZIONE DELLA FIGURA

Dettagli

Creare diagrammi di Gantt con Visio 2003

Creare diagrammi di Gantt con Visio 2003 Creare diagrammi di Gantt con Visio 2003 La fase di pianificazione di un progetto è sicuramente molto delicata e alquanto complessa, in quanto bisogna riuscire a definire una scomposizione del progetto

Dettagli

SOFTWARE A SUPPORTO DELLA GESTIONE AMMINISTRATIVA DELLO SPORTELLO UNICO SPECIFICA DEI REQUISITI UTENTE

SOFTWARE A SUPPORTO DELLA GESTIONE AMMINISTRATIVA DELLO SPORTELLO UNICO SPECIFICA DEI REQUISITI UTENTE Pag. 1 di 16 SOFTWARE A SUPPORTO DELLA (VERS. 3.1) Specifica dei Requisiti Utente Funzionalità di associazione di più Richiedenti ad un procedimento Codice Identificativo VERIFICHE ED APPROVAZIONI CONTROLLO

Dettagli

Archivi e database. Prof. Michele Batocchi A.S. 2013/2014

Archivi e database. Prof. Michele Batocchi A.S. 2013/2014 Archivi e database Prof. Michele Batocchi A.S. 2013/2014 Introduzione L esigenza di archiviare (conservare documenti, immagini, ricordi, ecc.) è un attività senza tempo che è insita nell animo umano Primi

Dettagli

Modulo: Scarsità e scelta

Modulo: Scarsità e scelta In queste pagine è presentato un primo modello di conversione di concetti, schemi e argomentazioni di natura teorica relativi all argomento le scelte di consumo (presentato preliminarmente in aula e inserito

Dettagli

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

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

Dettagli

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

1- Corso di IT Strategy

1- Corso di IT Strategy Descrizione dei Corsi del Master Universitario di 1 livello in IT Governance & Compliance INPDAP Certificated III Edizione A. A. 2011/12 1- Corso di IT Strategy Gli analisti di settore riportano spesso

Dettagli

MODELLO ORGANIZZATIVO REGIONALE PER LA GESTIONE DEL RISCHIO CLINICO.

MODELLO ORGANIZZATIVO REGIONALE PER LA GESTIONE DEL RISCHIO CLINICO. ALLEGATO A MODELLO ORGANIZZATIVO REGIONALE PER LA GESTIONE DEL RISCHIO CLINICO. il sistema organizzativo che governa le modalità di erogazione delle cure non è ancora rivolto al controllo in modo sistemico

Dettagli

UN GRUPPO DI LAVORO EVOLVE

UN GRUPPO DI LAVORO EVOLVE GRUPPI DI LAVORO GRUPPO DI LAVORO Un gruppo di lavoro è costituito da un insieme di individui che interagiscono tra loro con una certa regolarità, nella consapevolezza di dipendere l uno dall altro e di

Dettagli

REALIZZARE UN BUSINESS PLAN

REALIZZARE UN BUSINESS PLAN Idee e metodologie per la direzione d impresa Ottobre 2003 Inserto di Missione Impresa dedicato allo sviluppo pratico di progetti finalizzati ad aumentare la competitività delle imprese. REALIZZARE UN

Dettagli

Gestione Turni. Introduzione

Gestione Turni. Introduzione Gestione Turni Introduzione La gestione dei turni di lavoro si rende necessaria quando, per garantire la continuità del servizio di una determinata struttura, è necessario che tutto il personale afferente

Dettagli

TECNICO SUPERIORE DEI TRASPORTI E DELL INTERMODALITÀ

TECNICO SUPERIORE DEI TRASPORTI E DELL INTERMODALITÀ ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE TRASPORTI TECNICO SUPERIORE DEI TRASPORTI E DELL INTERMODALITÀ STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI TECNICO SUPERIORE DEI TRASPORTI E

Dettagli

Appunti sulla Macchina di Turing. Macchina di Turing

Appunti sulla Macchina di Turing. Macchina di Turing Macchina di Turing Una macchina di Turing è costituita dai seguenti elementi (vedi fig. 1): a) una unità di memoria, detta memoria esterna, consistente in un nastro illimitato in entrambi i sensi e suddiviso

Dettagli

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

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

Dettagli

FONDAMENTI di INFORMATICA L. Mezzalira

FONDAMENTI di INFORMATICA L. Mezzalira FONDAMENTI di INFORMATICA L. Mezzalira Possibili domande 1 --- Caratteristiche delle macchine tipiche dell informatica Componenti hardware del modello funzionale di sistema informatico Componenti software

Dettagli

CORSO BUSINESS CONTINUITY AND DISASTER RECOVERY MANAGEMENT LE 10 PROFESSIONAL PRACTICES

CORSO BUSINESS CONTINUITY AND DISASTER RECOVERY MANAGEMENT LE 10 PROFESSIONAL PRACTICES 1 CORSO BUSINESS CONTINUITY AND DISASTER RECOVERY MANAGEMENT Il corso è finalizzato a illustrare in dettaglio le competenze richieste al Business Continuity Manager per guidare un progetto BCM e/o gestire

Dettagli

Rational Unified Process Introduzione

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

Dettagli

UniRoma2 - Ingegneria del Software 1 1

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

Dettagli