Questo sito utilizza cookie di terze parti per inviarti pubblicità in linea con le tue preferenze. Se vuoi saperne di più clicca QUI 
Chiudendo questo banner, scorrendo questa pagina, cliccando su un link o proseguendo la navigazione in altra maniera, acconsenti all'uso dei cookie. OK

Valutazione dei costi di migrazione tramite metriche di complessità del codice

La traduzione automatica del software è un processo gestito da elaboratori che si occupa della traduzione di codice sorgente da un linguaggio di programmazione d’origine a uno di destinazione, rispettando nel programma di destinazione le stesse funzionalità del programma d’origine. La problematica della migrazione, nel contesto moderno dove l’evoluzione delle tecnologie informatiche è in continuo aggiornamento, assume sempre maggior importanza. Le imprese, soprattutto in Italia, soffrono di un’arretratezza tecnologica che preclude la dinamicità dei processi aziendali e diventa quindi importante l’aggiornamento dei propri sistemi al fine di cercare di ottenere un vantaggio sulla concorrenza, mantenendo, allo stesso tempo, la spesa da sostenere nei limiti del budget disponibile. L’adozione di soluzioni di migrazione automatica può esser di grande aiuto alle imprese poiché, se utilizzate in maniera intelligente, sarà possibile avere un prodotto di buona qualità a costi notevolmente ridotti.
Si possono individuare tre tipi di migrazioni:
L’evoluzione dell’hardware da sistemi legacy a sistemi distribuiti
L’evoluzione dal paradigma di programmazione da linguaggi logico/procedurali all’object oriented
L’introduzione di framework di sviluppo applicativo
Il terzo punto rappresenta la migrazione più complessa perché dà origine a problematiche legate alla migrazione di funzioni native del linguaggio; Il framework incorpora funzionalità specifiche che saranno differenti tra il linguaggio d’origine e quello di destinazione; viene introdotta la problematica della migrabilità del codice, non come processo di passaggio da un codice scritto in un certo linguaggio ad un codice scritto in un linguaggio differente, quanto piuttosto, da un codice scritto per supportare un framework (che incorpora una serie di funzionalità native), ad un codice di destinazione che necessariamente deve essere eseguito su un framework target e che potrebbe non supportare nativamente le funzionalità d’origine. È in questo contesto che si colloca il tool di migrazione su cui ho lavorato durante il mio stage in Avanade. Questi è stato realizzato con il fine di poter portare in maniera semi-automatica applicazioni scritte in LotusNotes a piattaforme più recenti e funzionali quali C# e Silverlight (utilizzato per la parte front-end). Il sistema LotusNotes, inventato nel 1973 da Don Bitzer, professore universitario, ha l’intento di poter utilizzare una rete di computer per l’apprendimento automatizzato, mediante l’utilizzo di funzionalità collaborative simili alle moderne chat, e-mail e condivisione file. Successivamente è evoluto in un software commerciale dedicato alla gestione interna di grandi aziende. Di anno in anno sono state rilasciate nuove release con relativi aggiornamenti e nuove funzionalità fino ad arrivare alla versione odierna, tutt’oggi in commercio, che seppur perfettamente integrata con il web e tutte le altre tecnologie non esistenti negli anni 80’ si può considerare obsoleta, almeno dal mio punto di vista, in quanto nata da un’idea vecchia di quarant’anni. Si parla quindi di conversione semi-automatica per l’inevitabile differenza tra i framework dei due linguaggi; ci sarà quindi una parte del codice del programma sorgente da convertire in modo automatico ed un’altra dovrà essere gestita manualmente da un capace programmatore. Il compito assegnatomi nello stage, è stato quello di identificare quest’ultima parte, dandole un peso utile a capirne la complessità e quindi il relativo costo in termini di risorse umane per la sua traduzione. Per fare questo mi sono dovuto documentare sulle varie metriche di misura del codice, come ad esempio quella di Albrecht, COCOMO e infine McCabe, che è stata la metrica che ho implementato all’interno del tool per il suo compromesso trà affidabilità e semplicità; (viene costruito il grafo equivalente di un programma formato dai cammini indipendenti che si creano al suo interno, per poi trovare il valore rappresentante il numero ciclomatico V(G)= e – n + 2p dove e= # archi, n=# nodi mentre p rappresenta il numero di componenti connesse). Una volta identificato e pesato un token di codice non migrabile in automatico dovrò generare un issue contenente tutte le informazioni disponibili tra cui la causa della mancata conversione che può essere dovuta a:
Il tool non può riconoscere la funzione che sta analizzando poiché non è ancora stata implementata
La funzione non ha equivalente nella piattaforma di destinazione (per le caratteristiche della piattaforma di destinazione tale funzione non ha significato).

Mostra/Nascondi contenuto.
4 Introduzione Nello scenario economico odierno, le imprese si trovano sempre più spesso a confrontare le opportunità presentate dalle nuove tecnologie e il parco applicativo esistente in rapida obsolescenza. Il costo dell’adeguamento dai sistemi informativi in dotazione alle nuove piattaforme, imposto dall’evoluzione tecnologica, spesso può assumere entità rilevante e pertanto deve essere continuamente sottoposto a revisioni che ne giustifichino la fattibilità. La mancanza di tecniche universalmente accettate per valutare costi e benefici nell’adeguamento fa si che tale sforzo sia spesso visto più come una voce di costo, che non come un investimento generante valore aggiunto, frenando in questo modo gli sforzi d’innovazione richiesti alle imprese italiane, che in questi ultimi anni hanno ridotto sempre più il budget a esso dedicato (si parla di un 5% in meno ogni anno), causando conseguentemente un notevole divario tecnologico rispetto alle concorrenti americane. In questo contesto, assumono sempre più valore e importanza le piattaforme che permettono di evolvere il codice applicativo esistente in maniera semi automatica garantendo un risparmio di costi rispetto alla completa riscrittura, ma soprattutto permettendo di stilare in maniera relativamente semplice e veloce lo sforzo necessario ad una migrazione completa: infatti con questi sistemi è possibile identificare subito le parti che non possono essere migrate automaticamente. Queste piattaforme permettono in generale un risparmio dei costi e un’evoluzione del parco applicativo in uno stato tale da poter permettere l’innovazione dei sistemi ad un costo sensibilmente ridotto, riducendo considerevolmente il lavoro necessario all’adeguamento. C’è inoltre da considerare che, se anche questi tool non aggiungono direttamente funzionalità alle applicazioni esistenti, tuttavia, nel corso degli anni, i framework applicativi hanno avuto forti evoluzioni dal punto di vista dell’interoperabilità, della facilità di scrittura di codice e dell’integrazione tra vari componenti. Ad esempio la migrazione di applicazioni da Visual Basic 6.0 al framework .Net permette di beneficiare delle evoluzioni intervenute negli ultimi anni nei linguaggi full object oriented e degli IDE ad esso associati (visual studio); VB 6.0 infatti non si configura come linguaggio full object oriented, risultando invece un’evoluzione, ancorchè solida, di un linguaggio tipicamente procedurale con supporto agli oggetti che, per molte funzionalità,

Laurea liv.I

Facoltà: Scienze Matematiche, Fisiche e Naturali

Autore: Luca Locatelli Contatta »

Composta da 56 pagine.

 

Questa tesi ha raggiunto 273 click dal 13/10/2010.

Disponibile in PDF, la consultazione è esclusivamente in formato digitale.