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

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

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

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

Ciclo di vita del software

Ciclo di vita del software Ciclo di vita del software Da Wikipedia, l'enciclopedia libera. L'espressione ciclo di vita del software si riferisce al modo in cui una metodologia di sviluppo o un modello di processo scompongono l'attività

Dettagli

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma Unified Process Prof. Agostino Poggi Unified Process Unified Software Development Process (USDP), comunemente chiamato

Dettagli

Corso di Progettazione di sistemi multimediali

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

Dettagli

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

Il ciclo di vita del software

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

Dettagli

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

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 PER LA QUALITA

CONCETTI DI BASE PER LA QUALITA CONCETTI DI BASE PER LA QUALITA Misura: è una funzione m: A -> B che associa ad ogni attributo A di un osservabile nel mondo reale o empirico (dominio) un oggetto formale B nel mondo matematico (range);

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

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

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

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

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

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

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

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

KNOWLEDGE MANAGEMENT. Knowledge Management. Knowledge: : cos è. Dispense del corso di Gestione della Conoscenza d Impresa

KNOWLEDGE MANAGEMENT. Knowledge Management. Knowledge: : cos è. Dispense del corso di Gestione della Conoscenza d Impresa KNOWLEDGE MANAGEMENT Pasquale Lops Giovanni Semeraro Dispense del corso di Gestione della Conoscenza d Impresa 1/23 Knowledge Management La complessità crescente della società, l esubero di informazioni

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

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 / 42 Sommario 1 Generalità

Dettagli

Architettura SW Definizione e Notazioni

Architettura SW Definizione e Notazioni Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Stili Architetturali E. TINELLI Architettura SW Definizione e Notazioni Definizione ANSI/IEEE Std Std1471-2000

Dettagli

Relazione Pinakes3 Analisi modello di business (BOZZA) di Valeriano Sandrucci 08/09/07

Relazione Pinakes3 Analisi modello di business (BOZZA) di Valeriano Sandrucci 08/09/07 Relazione Pinakes3 Analisi modello di business (BOZZA) di Valeriano Sandrucci 08/09/07 1. Introduzione...3 1.2. Application vs Tool... 3 2. Componenti logiche di un modello... 6 3. Ontologie e Semantic

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

Il software: natura e qualità

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

Dettagli

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0

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

Dettagli

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

Glossario Project Cycle Management

Glossario Project Cycle Management Glossario Project Cycle Management Albero degli obiettivi Diagramma, utilizzato nell ambito dell Approccio del Quadro Logico, che permette di rappresentare, in un quadro unitario, ciò che si potrebbe osservare

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

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 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

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

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

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

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

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

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

Cos è l Ingegneria del Software?

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

Dettagli

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

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

The Zachman Framework for Enterprise Architecture

The Zachman Framework for Enterprise Architecture The Zachman Framework for Enterprise Architecture Introduzione Una delle sfide più importanti che un impresa moderna deve affrontare è quella del cambiamento. Considerando la necessità di cambiamento dal

Dettagli

RUP (Rational Unified Process)

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

Dettagli

TECNOLOGIE DELL INFORMAZIONE E DELLA COMUNICAZIONE PER LE AZIENDE

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

Dettagli

Ingegneria dei Requisiti

Ingegneria dei Requisiti Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Ingegneria dei Requisiti E. TINELLI Contenuti I requisiti del software Documento dei requisiti I processi

Dettagli

FONDAMENTI di INFORMATICA Prof. Lorenzo Mezzalira

FONDAMENTI di INFORMATICA Prof. Lorenzo Mezzalira FONDAMENTI di INFORMATICA Prof. Lorenzo Mezzalira Appunti del corso 1 Introduzione all informatica: algoritmi, linguaggi e programmi Indice 1. Introduzione 2. Risoluzione automatica di problemi - Algoritmi

Dettagli

Software project management. www.vincenzocalabro.it

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

Dettagli

Introduzione a UML. Iolanda Salinari

Introduzione a UML. Iolanda Salinari Introduzione a UML Iolanda Salinari Perché modelliamo Un modello è una semplificazione della realtà I modelli ci aiutano a visualizzare un sistema come è o come vorremmo che fosse ci permettono di specificare

Dettagli

CAPITOLO 1: SOFTWARE MAINTENANCE E LEGACY SYSTEM

CAPITOLO 1: SOFTWARE MAINTENANCE E LEGACY SYSTEM IS2 -> Capitolo 1 CAPITOLO 1: SOFTWARE MAINTENANCE E LEGACY SYSTEM MANUTENZIONE DEL SOFTWARE La predizione della manutenzione consiste nel verificare quali componenti possono causare problemi e a quali

Dettagli

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

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

Dettagli

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

Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI. Obiettivi Specifica dei Requisiti Assembly Lines Esercizi

Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI. Obiettivi Specifica dei Requisiti Assembly Lines Esercizi Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI Obiettivi Specifica dei Requisiti Assembly Lines Esercizi Obiettivi Nelle lezioni precedenti abbiamo descritto come modellare i requisiti funzionali

Dettagli

Studio di fattibilità (2) Identificazione ed analisi dei requisiti

Studio di fattibilità (2) Identificazione ed analisi dei requisiti Prime fasi nella produzione del software &RUVR GL,QJHJQHULD GHO 6RIWZDUH Capitolato d appalto o doc. formale di richiesta prodotto Incontri con il committente e/o interviste Esercitazione Studio del dominio

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

Processi di Business e Sistemi di Gestione di Workflow: concetti di base. Prof. Giancarlo Fortino g.fortino@unical.it

Processi di Business e Sistemi di Gestione di Workflow: concetti di base. Prof. Giancarlo Fortino g.fortino@unical.it Processi di Business e Sistemi di Gestione di Workflow: concetti di base Prof. Giancarlo Fortino g.fortino@unical.it Introduzione Le aziende devono modificare la loro organizzazione per cogliere le nuove

Dettagli

2. Ciclo di Vita e Processi di Sviluppo

2. Ciclo di Vita e Processi di Sviluppo 2. Ciclo di Vita e Processi di Sviluppo come posso procedere nello sviluppo? Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 2. Ciclo di Vita e Processi di

Dettagli

Work World WORK WORLD PROGETTO INGEGNERIA DEL SOFTWARE. Alessandro Spinelli

Work World WORK WORLD PROGETTO INGEGNERIA DEL SOFTWARE. Alessandro Spinelli WORK WORLD PROGETTO INGEGNERIA DEL SOFTWARE di Alessandro Spinelli Indice 1 - Introduzione 2 - Descrizione del problema 2.1 Requisiti funzionali 2.2 Requisiti non funzionali 3 - Analisi 3.1 Dizionario

Dettagli

La disciplina che cura un approccio sistematico, disciplinato e quantificabile allo sviluppo, all operatività ed alla manutenzione del software

La disciplina che cura un approccio sistematico, disciplinato e quantificabile allo sviluppo, all operatività ed alla manutenzione del software Ingegneria del software (software engineering) La branca dell'ingegneria che si occupa della realizzazione di sistemi software. La disciplina che cura un approccio sistematico, disciplinato e quantificabile

Dettagli

ARCHIVI CLASSICI. Concetti di base

ARCHIVI CLASSICI. Concetti di base ARCHIVI CLASSICI Concetti di base Per svolgere una qualsiasi attività gestionale, amministrativa, o statistica è necessario utilizzare grandi quantità di dati e scegliere per essi una opportuna organizzazione,

Dettagli

Processo parte III. Modello Code and fix. Modello a cascata. Modello a cascata (waterfall) Leggere Sez. 7.4 Ghezzi et al.

Processo parte III. Modello Code and fix. Modello a cascata. Modello a cascata (waterfall) Leggere Sez. 7.4 Ghezzi et al. Modello Code and fix Processo parte III Leggere Sez. 7.4 Ghezzi et al. Modello iniziale Iterazione di due passi scrittura del codice correzione degli errori Problemi: dopo una serie di cambiamenti, la

Dettagli

Introduzione. è uguale a 0, spostamento di dati da una parte della memoria del calcolatore ad un altra.

Introduzione. è uguale a 0, spostamento di dati da una parte della memoria del calcolatore ad un altra. Appunti di Calcolatori Elettronici Modello di macchina multilivello Introduzione... 1 Linguaggi, livelli e macchine virtuali... 3 La struttura a livelli delle macchine odierne... 4 Evoluzione delle macchine

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

Agent and Object Technology Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Fondamenti di Informatica

Agent and Object Technology Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Fondamenti di Informatica Agent and Object Technology Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma Fondamenti di Informatica Linguaggi di Programmazione Michele Tomaiuolo Linguaggi macchina I

Dettagli

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

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

Dettagli

Laboratorio di Progettazione di Sistemi Software Introduzione

Laboratorio di Progettazione di Sistemi Software Introduzione Laboratorio di Progettazione di Sistemi Software Introduzione Valentina Presutti (A-L) Riccardo Solmi (M-Z) Indice degli argomenti Introduzione all Ingegneria del Software UML Design Patterns Refactoring

Dettagli

Realizzazione di un prototipo di un software web based per la gestione di un inventario comunale

Realizzazione di un prototipo di un software web based per la gestione di un inventario comunale tesi di laurea inventario comunale Anno Accademico 2009/2010 relatore Ch.mo prof. Porfirio Tramontana correlatore Ch.mo Ing. Luigi Pontillo candidato Michele Vitelli Matr. 534 2170 Redazione dell Inventario

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

Quality gate. Sono eventi programmati regolarmente e condotti seguendo una procedura standard

Quality gate. Sono eventi programmati regolarmente e condotti seguendo una procedura standard Quality gate Nei punti chiave del processo di sviluppo del software, viene integrato un insieme di quality gate per monitorare la qualità del prodotto intermedio prima che quest ultimo possa passare al

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

Architettura del software: dai Casi d Uso al Modello

Architettura del software: dai Casi d Uso al Modello Architettura del software: dai Casi d Uso al Modello Lorenzo Barbieri Sono un Senior Trainer/Consultant in ObjectWay SpA (www.objectway.it), specializzato in architetture Microsoft.NET, Windows, SQL Server,

Dettagli

Alberi Decisionali di Vito Madaio

Alberi Decisionali di Vito Madaio Tecnica degli Alberi Decisionali Cosa è un albero decisionale Un albero decisionale è la dimostrazione grafica di una scelta effettuata o proposta. Non sempre ciò che istintivamente ci appare più interessante

Dettagli

Progettazione orientata agli oggetti Introduzione a UML

Progettazione orientata agli oggetti Introduzione a UML Progettazione orientata agli oggetti Introduzione a UML Claudia Raibulet raibulet@disco.unimib.it Il processo di sviluppo software Rappresenta un insieme di attività per la specifica, progettazione, implementazione,

Dettagli

L ottimizzazione dei processi con Microsoft Office System: come generare e misurare il valore per le aziende

L ottimizzazione dei processi con Microsoft Office System: come generare e misurare il valore per le aziende MICROSOFT BUSINESS DESKTOP MICROSOFT ENTERPRISE CLUB Disponibile anche sul sito: www.microsoft.com/italy/eclub/ L ottimizzazione dei processi con Microsoft Office System: come generare e misurare il valore

Dettagli

Il paradigma OO e le relative metodologie di progettazione. Programmazione orientata agli oggetti

Il paradigma OO e le relative metodologie di progettazione. Programmazione orientata agli oggetti Alessio Bechini - Corso di - Il paradigma OO e le relative metodologie di progettazione Metodologie OO Programmazione orientata agli oggetti La programmazione ad oggetti (OOP) è un paradigma di programmazione

Dettagli

PROGETTO - Ingegneria del Software. Università degli Studi di Milano Polo di Crema. Corso di laurea in Scienze Matematiche, Fisiche e Naturali

PROGETTO - Ingegneria del Software. Università degli Studi di Milano Polo di Crema. Corso di laurea in Scienze Matematiche, Fisiche e Naturali Università degli Studi di Milano Polo di Crema Corso di laurea in Scienze Matematiche, Fisiche e Naturali INFORMATICA Corso di Ingegneria del Software progetto IL SISTEMA CALENDAR Presentato al dott. Paolo

Dettagli

SISTEMI INFORMATIVI AZIENDALI

SISTEMI INFORMATIVI AZIENDALI SISTEMI INFORMATIVI AZIENDALI Prof. Andrea Borghesan venus.unive.it/borg borg@unive.it Ricevimento: Alla fine di ogni lezione Modalità esame: scritto 1 Sistema informativo. Prima definizione Un sistema

Dettagli

Sistemi Informativi e WWW

Sistemi Informativi e WWW Premesse Sistemi Informativi e WWW WWW: introduce un nuovo paradigma di diffusione (per i fornitori) e acquisizione (per gli utilizzatori) delle informazioni, con facilità d uso, flessibilità ed economicità

Dettagli

SCADA: struttura modulare

SCADA: struttura modulare Sistemi per il controllo di supervisione e l acquisizione dati o (Supervisory Control And Data Acquisition) Sistema informatico di misura e controllo distribuito per il monitoraggio di processi fisici

Dettagli

5 Gestione dei progetti software. 5.1 Attività gestionale. Sistemi Informativi I Lezioni di Ingegneria del Software

5 Gestione dei progetti software. 5.1 Attività gestionale. Sistemi Informativi I Lezioni di Ingegneria del Software 5 Gestione dei progetti software. Dopo aver completato lo studio del ciclo di vita del software, in questa parte vengono discussi gli aspetti gestionali della produzione del software. Vengono esaminate

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

Dedico questo lavoro alla vita, a ciò che mi ha dato, agli insegnamenti ricevuti da ciò che non ho più, ai miei grandi amori, alle speranze e alle

Dedico questo lavoro alla vita, a ciò che mi ha dato, agli insegnamenti ricevuti da ciò che non ho più, ai miei grandi amori, alle speranze e alle Dedico questo lavoro alla vita, a ciò che mi ha dato, agli insegnamenti ricevuti da ciò che non ho più, ai miei grandi amori, alle speranze e alle paure di ciò che sarà, perché in fondo senza questo non

Dettagli

Testing. Definizioni. incomprensione umana nel tentativo di comprendere o risolvere un problema, o nell uso di strumenti

Testing. Definizioni. incomprensione umana nel tentativo di comprendere o risolvere un problema, o nell uso di strumenti Definizioni Problemi del testing:criterio di selezione dei casi di test Test Funzionale: suddivisione in classi di equivalenza e analisi dei valori limite Test Strutturale: basato sul flusso di controllo

Dettagli

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

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

Dettagli

Guida al controllo di gestione nelle piccole e medie imprese

Guida al controllo di gestione nelle piccole e medie imprese j l k l d o ^ c f b S o c i e t à Laura Broccardo Guida al controllo di gestione nelle piccole e medie imprese Pianificazione e controllo nelle PMI Costruzione del budget Reporting Aziende che operano

Dettagli

Indice generale. Nota dell editore...xiii. Parte I Antipattern nella progettazione logica di database 11

Indice generale. Nota dell editore...xiii. Parte I Antipattern nella progettazione logica di database 11 Indice generale Nota dell editore...xiii Capitolo 1 Introduzione...1 1.1 A chi si rivolge questo libro... 2 1.2 Contenuto del libro... 3 Struttura del libro... 3 Anatomia di un antipattern... 4 1.3 Che

Dettagli

ISO/IEC 27001 Versioni a confronto: 2005 vs 2013

ISO/IEC 27001 Versioni a confronto: 2005 vs 2013 ISO/IEC 27001 Versioni a confronto: 2005 vs 2013 Introduzione Il primo ottobre 2015 la normativa ISO/IEC 27001: 2005 verrà definitivamente sostituita dalla più recente versione del 2013: il periodo di

Dettagli

in questo numero: A proposito di Granaio n. 43/2011 novembre CONSORZIO AGRARIO DEL PIEMONTE ORIENTALE CONSORZIO AGRARIO DELLA MAREMMA TOSCANA

in questo numero: A proposito di Granaio n. 43/2011 novembre CONSORZIO AGRARIO DEL PIEMONTE ORIENTALE CONSORZIO AGRARIO DELLA MAREMMA TOSCANA n. 43/2011 novembre in questo numero: A proposito di Granaio CONSORZIO AGRARIO DEL PIEMONTE ORIENTALE CONSORZIO AGRARIO DELLA MAREMMA TOSCANA Regioni coinvolte: Piemonte, Lombardia, Veneto, Friuli Venezia

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

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

Linee guida per lo sviluppo e la gestione di un sito Web

Linee guida per lo sviluppo e la gestione di un sito Web Linee guida per lo sviluppo e la gestione di un sito Web Paolo Atzeni Università Roma Tre Dipartimento di Informatica e Automazione atzeni@dia.uniroma3.it http://www.dia.uniroma3.it/ atzeni/ Roma, 25 settembre

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

La progettazione del software nelle piccole o micro imprese

La progettazione del software nelle piccole o micro imprese La progettazione del software nelle piccole o micro imprese Il contenuto di questo documento è strettamente confidenziale, la visione dello stesso è consentita solo al personale di FadeOut Snc e della

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

Data Warehouse: una sola lingua. Iolanda Salinari

Data Warehouse: una sola lingua. Iolanda Salinari Data Warehouse: una sola lingua Iolanda Salinari 2 Il Glossario: uno strumento prezioso Uno dei fattori critici per la realizzazione del data warehouse è costituito dalle difficoltà che si incontrano per

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

BOZZA 2.1. 7 Febbraio 2008 LA CARTA DI LONDRA PER LA VISUALIZZAZIONE DIGITALE DEI BENI CULTURALI. Introduzione. Obiettivi.

BOZZA 2.1. 7 Febbraio 2008 LA CARTA DI LONDRA PER LA VISUALIZZAZIONE DIGITALE DEI BENI CULTURALI. Introduzione. Obiettivi. BOZZA 2.1 7 Febbraio 2008 LA CARTA DI LONDRA PER LA VISUALIZZAZIONE DIGITALE DEI BENI CULTURALI Introduzione Obiettivi Principi Principio 1: Implementazione Principio 2: Scopi e metodi Principio 3: Fonti

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. B - Caratteristiche essenziali e modalità applicative del Sistema di Gestione Responsible Care

1. B - Caratteristiche essenziali e modalità applicative del Sistema di Gestione Responsible Care 1. B - Caratteristiche essenziali e modalità applicative del Sistema di Gestione Responsible Care 20 gennaio 2009 INDICE Sezione Contenuto 1. Il programma Responsible Care: scopo e campo di applicazione

Dettagli

Ingegneria del Software Progettazione

Ingegneria del Software Progettazione Ingegneria del Software Progettazione Obiettivi. Approfondire la fase di progettazione dettagliata che precede la fase di realizzazione e codifica. Definire il concetto di qualità del software. Presentare

Dettagli

TEORIA sulle BASI DI DATI

TEORIA sulle BASI DI DATI TEORIA sulle BASI DI DATI A cura del Prof. Enea Ferri Cos è un DATA BASE E un insieme di archivi legati tra loro da relazioni. Vengono memorizzati su memorie di massa come un unico insieme, e possono essere

Dettagli