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

Save this PDF as:
 WORD  PNG  TXT  JPG

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

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

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

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

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

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

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

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

Dettagli

TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE

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

Dettagli

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

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

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

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

Gruppo 4: Gelmi Martina, Morelato Francesca, Parisi Elisa. La mia scuola ha un sito Web

Gruppo 4: Gelmi Martina, Morelato Francesca, Parisi Elisa. La mia scuola ha un sito Web Gruppo 4: Gelmi Martina, Morelato Francesca, Parisi Elisa La mia scuola ha un sito Web Presentazione del corso Contenuti e obiettivi del corso Imparare a lavorare con le metodologie dell ingegneria del

Dettagli

UML e (R)UP (an overview)

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

Dettagli

INGEGNERIA DEL SOFTWARE. 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

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

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

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

TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE

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

Dettagli

TECNICO SUPERIORE PER LE TELECOMUNICAZIONI

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

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

Progettazione del Software A.A.2008/09

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

Dettagli

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

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

Dettagli

Verifica e Validazione del Simulatore

Verifica e Validazione del Simulatore Verifica e del Simulatore I 4 passi principali del processo simulativo Formulare ed analizzare il problema Sviluppare il Modello del Sistema Raccolta e/o Stima dati per caratterizzare l uso del Modello

Dettagli

Metodologia Classica di Progettazione delle Basi di Dati

Metodologia Classica di Progettazione delle Basi di Dati Metodologia Classica di Progettazione delle Basi di Dati Metodologia DB 1 Due Situazioni Estreme Realtà Descritta da un documento testuale che rappresenta un insieme di requisiti del software La maggiore

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

Sistemi Informativi Geografici

Sistemi Informativi Geografici Sistemi Informativi Geografici Introduzione ai dati geografici Alberto Belussi Anno accademico 2007-08 08 Sistemi Informativi Territoriali (SIT) o Geografici I Sistemi Informativi Territoriali (SIT) gestiscono

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

Principi dell ingegneria del software Relazioni fra

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

Dettagli

Corso di Informatica

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

Dettagli

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

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

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

Ciclo di Vita Evolutivo

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

Dettagli

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

Introduzione alla Progettazione per Componenti

Introduzione alla Progettazione per Componenti Introduzione alla Progettazione per Componenti Alessandro Martinelli 6 ottobre 2014 Obiettivo del Corso Il Progetto Software Reale Il Componente Software La Programmazione Ad Oggetti Fondamenti di Informatica

Dettagli

LA VALUTAZIONE DEL PERSONALE NEGLI ENTI LOCALI

LA VALUTAZIONE DEL PERSONALE NEGLI ENTI LOCALI LA VALUTAZIONE DEL PERSONALE NEGLI ENTI LOCALI Premesse e riferimenti normativi La valutazione del personale, che costituisce un processo centrale nell ambito del management pubblico, ha registrato negli

Dettagli

Gestione dei Progetti (2005-2006)

Gestione dei Progetti (2005-2006) Gestione dei Progetti (2005-2006) Alessandro Agnetis DII Università di Siena (Alcune delle illustrazioni contenute nella presentazione sono tratte da PMBOK, a guide to the Project Management Body of Knowledge,

Dettagli

Guida al livellamento delle risorse con logica Critical Chain (1^ parte)

Guida al livellamento delle risorse con logica Critical Chain (1^ parte) Paolo Mazzoni 2011. E' ammessa la riproduzione per scopi di ricerca e didattici se viene citata la fonte completa nella seguente formula: "di Paolo Mazzoni, www.paolomazzoni.it, (c) 2011". Non sono ammesse

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

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

Configuration of a distributed system as emerging behavior of autonomous agents

Configuration of a distributed system as emerging behavior of autonomous agents Configuration of a distributed system as emerging behavior of autonomous agents Configuration of a distributed system as emerging behavior of autonomous agents : Questo documento illustra la strategia

Dettagli

Linguaggi di programmazione

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

Dettagli

Introduzione alle basi di dati (prima parte)

Introduzione alle basi di dati (prima parte) Introduzione alle basi di dati (prima parte) Università degli Studi di Salerno Corso di Laurea in Scienze della Comunicazione Informatica generale (matr. Dispari) Docente: Angela Peduto A.A. 2007/2008

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

Valutazione del sistema di controllo interno: un'unica modalità di approccio per i processi di business e di IT Governance

Valutazione del sistema di controllo interno: un'unica modalità di approccio per i processi di business e di IT Governance Valutazione del sistema di controllo interno: un'unica modalità di approccio per i processi di business e di IT Governance Livorno 24-25 maggio 2007 Paolo Casati 1 Evoluzione delle attività di Internal

Dettagli

Facoltà di Farmacia - Corso di Informatica

Facoltà di Farmacia - Corso di Informatica Basi di dati Riferimenti: Curtin cap. 8 Versione: 13/03/2007 1 Basi di dati (Database, DB) Una delle applicazioni informatiche più utilizzate, ma meno conosciute dai non informatici Avete già interagito

Dettagli

Ingegneria del Software Requisiti e Specifiche

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

Dettagli

I Modelli della Ricerca Operativa

I Modelli della Ricerca Operativa Capitolo 1 I Modelli della Ricerca Operativa 1.1 L approccio modellistico Il termine modello è di solito usato per indicare una costruzione artificiale realizzata per evidenziare proprietà specifiche di

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

Sistema per il test dell impianto elettrico in linea di montaggio della vettura FERRARI 575 MM.

Sistema per il test dell impianto elettrico in linea di montaggio della vettura FERRARI 575 MM. Sistema per il test dell impianto elettrico in linea di montaggio della vettura FERRARI 575 MM. La sfida Certificare il corretto montaggio dell impianto elettrico, escludendo la presenza di cortocircuiti

Dettagli

INFORMATICA. Applicazioni WEB a tre livelli con approfondimento della loro manutenzione e memorizzazione dati e del DATABASE.

INFORMATICA. Applicazioni WEB a tre livelli con approfondimento della loro manutenzione e memorizzazione dati e del DATABASE. INFORMATICA Applicazioni WEB a tre livelli con approfondimento della loro manutenzione e memorizzazione dati e del DATABASE. APPLICAZIONI WEB L architettura di riferimento è quella ampiamente diffusa ed

Dettagli

Il Piano di comunicazione

Il Piano di comunicazione Il Piano di comunicazione 23 lezione 11 novembre 2011 Cosa è un piano di comunicazione Il piano di comunicazione è uno strumento utilizzato da un organizzazione per programmare le proprie azioni di comunicazione

Dettagli

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

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

Dettagli

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

Ingegneria del Software UML - Unified Modeling Language

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

Dettagli

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

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

Dettagli

Modelli matematici avanzati per l azienda a.a. 2010-2011

Modelli matematici avanzati per l azienda a.a. 2010-2011 Modelli matematici avanzati per l azienda a.a. 2010-2011 Docente: Pasquale L. De Angelis deangelis@uniparthenope.it tel. 081 5474557 http://www.economia.uniparthenope.it/siti_docenti P.L.DeAngelis Modelli

Dettagli

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

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

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

CAPITOLO 4 LA CREAZIONE DI TABELLE D ATTIVITÀ E SCHEDE DI SPESA

CAPITOLO 4 LA CREAZIONE DI TABELLE D ATTIVITÀ E SCHEDE DI SPESA CAPITOO 4 A CREAZIONE DI TABEE D ATTIVITÀ E SCHEDE DI SPESA 55 A CREAZIONE DI TABEE D ATTIVITÀ E SCHEDE DI SPESA 57 Questo capitolo descrive l uso del Q per sviluppare budget e piani di lavoro basati sul

Dettagli

Beatrice Benesperi acquisizione delle informazioni restituzione delle informazioni implementazione aggiornamento delle informazioni

Beatrice Benesperi acquisizione delle informazioni restituzione delle informazioni implementazione aggiornamento delle informazioni Beatrice Benesperi In quest'intervento parlerò della seconda fase del lavoro, cioè della conoscenza dello stato di fatto dei luoghi. Dopo la costituzione del laboratorio comunale per accessibilità si passa

Dettagli

LAVORO DI GRUPPO. Caratteristiche dei gruppi di lavoro transnazionali

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

Dettagli

SPECIFICHE TECNICHE DI SISTEMA TITOLO DOCUMENTO

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

Dettagli

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

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

6.A.1 Logistica interna ed esterna

6.A.1 Logistica interna ed esterna 6.A.1 Logistica interna ed esterna Il corso si propone di fornire un quadro chiaro di inquadramento della logistica e delle sue principali funzioni in azienda. Si vogliono altresì fornire gli strumenti

Dettagli

Corso di Amministrazione di Sistema Parte I ITIL 2

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

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

CLUSIT. Commissione di studio Certificazioni di Sicurezza Informatica. Linea guida per l analisi di rischio. Codice doc.

CLUSIT. Commissione di studio Certificazioni di Sicurezza Informatica. Linea guida per l analisi di rischio. Codice doc. CLUSIT Commissione di studio Certificazioni di Sicurezza Informatica Linea guida per l analisi di rischio Codice doc.to: CS_CERT/SC1/T3 Stato: Draft 1 2 INDICE 1. Introduzione....4 2. Scopo della presente

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

Il Controllo di gestione nella piccola impresa

Il Controllo di gestione nella piccola impresa Stampa Il Controllo di gestione nella piccola impresa admin in A cura di http://www.soluzionipercrescere.com La piccola impresa presenta generalmente un organizzazione molto snella dove l imprenditore

Dettagli

Metriche del software

Metriche del software Sviluppo di Software Applicativo Metriche del software Come misurare le diverse caratteristiche del software: dimensioni, qualità, impegno richiesto per lo sviluppo, ecc. Ercole Colonese IBM Global Services

Dettagli

Il diagramma dei casi d uso

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

Dettagli

InfoTecna ITCube Web

InfoTecna ITCube Web InfoTecna ITCubeWeb ITCubeWeb è un software avanzato per la consultazione tramite interfaccia Web di dati analitici organizzati in forma multidimensionale. L analisi multidimensionale è il sistema più

Dettagli

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

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

Dettagli

COME GESTIRE LA NUOVA IMPRESA: FORNIRE CONOSCENZE, METODI E SISTEMI DI DI LAVORO SULLE AREE DELLA GESTIONE AZIENDALE

COME GESTIRE LA NUOVA IMPRESA: FORNIRE CONOSCENZE, METODI E SISTEMI DI DI LAVORO SULLE AREE DELLA GESTIONE AZIENDALE COME GESTIRE LA NUOVA IMPRESA: FORNIRE CONOSCENZE, METODI E SISTEMI DI DI LAVORO SULLE AREE DELLA GESTIONE AZIENDALE PROF. VALTER CANTINO 1 L AZIENDA Soggetto unitario composto di più elementi diversi

Dettagli

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

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

Dettagli

Capitolo 20: Scelta Intertemporale

Capitolo 20: Scelta Intertemporale Capitolo 20: Scelta Intertemporale 20.1: Introduzione Gli elementi di teoria economica trattati finora possono essere applicati a vari contesti. Tra questi, due rivestono particolare importanza: la scelta

Dettagli

Tutorial. al Piano di Miglioramento

Tutorial. al Piano di Miglioramento Tutorial al Piano di Miglioramento Il presente documento è protetto ai sensi della vigente normativa sul diritto d'autore Legge 6 del 9 e ss.mm.ii. Come definito nell introduzione il Piano di Miglioramento

Dettagli

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

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

Dettagli

5. Requisiti del Software II

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

Dettagli

Progettazione del Software

Progettazione del Software L4.4 Progettazione del Software Emiliano Casalicchio Dipartimento di Informatica e Sistemistica SAPIENZA Università di Roma Sede di Rieti http://www.ce.uniroma2.it/courses/psw Seconda Parte La fase di

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

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

Modulo 1 Concetti di base della Qualità

Modulo 1 Concetti di base della Qualità Syllabus rev. 1.04 Modulo 1 Concetti di base della Qualità Il seguente Syllabus è relativo al Modulo 1, Concetti e approcci di base per la gestione della qualità in una organizzazione, e fornisce i fondamenti

Dettagli

disponibili nel pacchetto software.

disponibili nel pacchetto software. Modulo syllabus 4 00 000 00 0 000 000 0 Modulo syllabus 4 DATABASE 00 000 00 0 000 000 0 Richiede che il candidato dimostri di possedere la conoscenza relativa ad alcuni concetti fondamentali sui database

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

Software a supporto della Gestione amministrativa dello Sportello Unico Versione 2.1

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

Dettagli

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

Università di Venezia Corso di Laurea in Informatica. Marco Fusaro KPMG S.p.A.

Università di Venezia Corso di Laurea in Informatica. Marco Fusaro KPMG S.p.A. Università di Venezia Corso di Laurea in Informatica Laboratorio di Informatica Applicata Introduzione all IT Governance Lezione 4 Marco Fusaro KPMG S.p.A. 1 CobiT Obiettivi del CobiT (Control Objectives

Dettagli

MANUALE DELLA QUALITÀ Pag. 1 di 10

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

Dettagli

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

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

TECNICO SUPERIORE PER LA MOBILITÀ E IL TRASPORTO PUBBLICO LOCALE

TECNICO SUPERIORE PER LA MOBILITÀ E IL TRASPORTO PUBBLICO LOCALE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE TRASPORTI TECNICO SUPERIORE PER LA MOBILITÀ E IL TRASPORTO PUBBLICO LOCALE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI TECNICO SUPERIORE PER

Dettagli

Basi di Dati. Programmazione e gestione di sistemi telematici

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

Dettagli

Object Oriented Programming

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

Dettagli

LA NORMALIZZAZIONE. Introduzione

LA NORMALIZZAZIONE. Introduzione LA NORMALIZZAZIONE Introduzione La normalizzazione e' una tecnica di progettazione dei database, mediante la quale si elimina la rindondanza dei dati al fine di evitare anomalie nella loro consistenza

Dettagli

PROGETTO SOCIALE D INIZIATIVA WIN (WELLFARE DI INIZIATIVA).

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

Dettagli

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

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

Dettagli

Standard di documentazione Linee guida per la rappresentazione dei processi

Standard di documentazione Linee guida per la rappresentazione dei processi ALLEGATO B Standard Parte 2 Standard di documentazione Linee guida per la rappresentazione dei processi Pagina 1 di 11 SOMMARIO 1. INTRODUZIONE...3 1.1 SCOPO E CAMPO DI APPLICAZIONE...3 1.2 RIFERIMENTI...3

Dettagli