X

Esempi di inserimento dei termini di ricerca


milano roma: deve essere presente uno dei due termini
+milano +roma: devono essere presenti entrambi i termini
+milano roma: deve essere presente milano ed eventualmente roma
+milano -roma: deve essere presente milano ma non roma
+milano +( venezia): devono essere presenti o milano e roma o milano e venezia, ma i record con milano e venezia hanno rilevanza maggiore.
('<' indica minore rilevanza, '>' indica maggiore rilevanza)
"milano roma": deve essere presente l'esatta sequenza milano roma

Ricerche in: Ingegneria Informatica
Architettura e Ingegneria dei Sistemi Software
Ingegneria dei requisiti (Requirements Engineering)
In questa attività di ricerca, fra il 2011 e il 2013, abbiamo verificato che, con riferimento ai requisiti di sistema di una data azienda che lavora sul mercato internazionale in un dominio critico, le tecniche NLP identificanti requisiti equivalenti manifestano, sul dato insieme di dati (dataset), prestazioni  che sono in accordo sia con l'abilità, sia con  le disparità nel produrre corrette identificazioni. Per esempio, quando le differenze nel cercare la giusta categoria sono molto alte allora è ragionevole aspettarsi che le tecniche NLP esporranno delle buone prestazioni. La ricerca ha altresì già proposto un nuovo approccio alla misura di un fattore casuale associato al (/ai) dataset specifico (/specifici) in uso e al conseguente aggiustamento delle prestazioni osservate.  L'approccio migliora la validità esterna dei risultati perché le prestazioni osservate sono indipendenti dalla difficoltà del dataset in uso.  Il contesto della applicazione corrente è la valutazione delle tecniche NLP per la identificazione di requisiti equivalenti, Comunque, l'approccio sembra essere indipendente dal tipo di estimatore (e.g., testo del requisito) e metodo di stima (e.g., tecniche  NLP) fintanto che il metodo di stima supporta una decisione binaria,con la stima nell'intervallo rele [0;1],come di fatto la similarità misurata, appunto, dalle tecniche NLP.
Decision Making Technique in Software Architecture and Engineering
Decision Making Technique in Software Architecture Design The architecture of a software-intensive system can be defined as the set of relevant design decisions that affect the qualities of the overall system functionality; therefore, architectural decisions are eventually crucial to the success of a software project. The software engineering literature describes several techniques to choose among architectural alternatives, but it gives no clear guidance on which technique is more suitable than another, and in which circumstances. As such, there is no systematic way for software engineers to choose among decision-making techniques for resolving tradeoffs in architecture design. In this research line, we provide a comparison of existing decision-making techniques, aimed to guide architects in their selection. The results show that there is no “best” decision-making technique; however, some techniques are more susceptible to specific difficulties. Hence software architects should choose a decision-making technique based on the difficulties that they wish to avoid. Our researc line provides a first attempt to reason on meta-decision-making, that is, the issue of deciding how to decide.   Evaluating Decision Making Techniques for Software Architecture and Engineering This reseasrch line has been supported in part by Selex Sistemi Integrati SpA, Italy, from 2007 up to 2012.   Evaluating Decision Making Tecniques for Mobile. This research line aims to answert the following question: What is the best development technology to utilize for developing given (non dunctional) requirements for sofware mobile apps.
Processo software
Modelli di processo. Sono stati sviluppati esperimenti volti a comparare, a parità di requisiti funzionali e non, i seguenti modelli di processo in termini di tempo di rilascio, costo (effort), qualità (errori al rilascio e loro tipi): Ad hoc vs. Basic-RUP. Qui i soggetti sperimentali, ricevuti i requisiti di utente (“user needs”) sviluppano il prodotto o liberamente oppure producendo la specifica dei requisiti (con Requisite-Pro™), analisi e progettazione (con IBM-RSA™) e codice (con Eclipse), raccogliendo metriche di prodotto e di processo per tipologia di attività. Agile vs. Basic-RUP.  Qui i soggetti di ciascuno degli “agile team” incontrano il product-owner e il team master una volta a settimana e sviluppano il prodotto come applicazione web a partire dalle storie, con Trello™, impiegando framework vari, e codificando in Eclipse.   Modellamento a fini di miglioramento/reingegnerizzazione di processi. Le trasformazioni di processi di ingegneria di sistemi, eventualmente software, devono di norma avvenire sotto vincoli ben definiti. Ad esempio, è possibile che un cambiamenti venga richiesto a parità di costi o di tempo di rilascio ovvero che un miglioramento di qualità venga richiesto in termini di maggiore efficacia (nuove tecniche devono lasciare un minor numero di errori nel prodotto) piuttosto che in termini di efficienza (nuove tecniche devono individuare un maggior numero di errori presenti nel prodotto per unità di tempo). D'altro canto, il miglioramento del processo secondo una o più dimensioni (e.g., qualità in termini di maggiore efficacia) potrebbe impattare su altre dimensioni che influenzano il processo. Conseguentemente, non tutti i processi di miglioramento o reingegnerizzazione sono fattibili, compatibili con assegnati vincoli o, infine, fra loro “equivalenti”. Per una investigazione del cambiamento in termini quantitativi si pone allora l'esigenza di definire gli attributi del cambiamento, di associare a questi delle misure possibilmente quantitative, di sintetizzare il tutto nelle dimensioni delle variabili indipendenti che descrivono il miglioramento desiderato, il che, date le complessità in gioco, non può che avvenire a partire da approcci di tipo empirico. In tale quadro, stiamo lavorando da qualche anno per lo sviluppo di un metodo di analisi e sintesi dei processi  di cambiamento basato sul cosiddetto Vettore d'impatto. Tale approccio è stato finora applicato a vari casi, fra cui uno di Ingegneria dei sistemi, uno di Adeguamento delle tecnologie di sviluppo per Mobile e, in collaborazione con il Fraunhofer Center ESE, MS, USA, al controllo di qualità di sistemi spaziali.   Processo Agile. Il coordinatore del gruppo e' co-Program Chair di XP2014, the Agile Conderence.  
Qualita' del software
Miglioramento continuo. Il gruppo ha lavorato sul Quality Improvement Paradigm e, in particolare, su Component Factory fin dalla fine degli anni '80 del secolo scorso. Attualmente è attivo con il gruppo internazionale di Goal Question Metrics plus Strategies per il quale ha, peraltro, già sviluppato uno strumento a supporto, in varie versioni e secondo diverse architetture software; il coordinatore svolge il ruolo di opponent di tesi di dottorato presso università straniere. Classificazione di difetti software. Scopo di questa linea di ricerca è investigare se, i diversi modi di classificare i difetti software presenti in letteratura, sono perseguibili con sufficiente oggettività da parte di personale software. Un  risultato di tali ricerche è stato premiato come best paper da parte della conferenza ESCOM.  Testing e ispezione di prodotti software. Scopo di questa linea di ricerca è investigare le prestazioni delle diverse tecniche di test e, rispettivamente, di ispezione dei diversi prodotti del ciclo di vita del software.  E' stata finanziata dalla Comunità Europea nell'ambito del progetto ESERNET. Delle attività sviluppate, una prima ha riguardato la sperimentazione di tecniche di lettura per la verifica di software espresso in linguaggi di documentazione altro livello (e.g., UML). L'obiettivo finale della attività era comparare vantaggi e svantaggi dello gestire i cambi di configurazione. Il lavoro ha incluso tre esperimenti controllati - uno di base e due repliche con minori variazioni – da noi condotti per valutare la applicazione di due tecniche di lettura a documenti software di alto livello. In particolare, le tecniche comparate sono: Checklists Based Reading (CBR) and Use-cases Based Reading (UBR). Altri aspetti considerati includono l'Apprendimento on the job di tecnologia e dominio applicativo, rispettivamente, tramite l'impiego di CBR e/o UBR. Una ulteriore attività ha riguardato la comparazione sperimentale di test funzionale e ispezione per lettura di codice, con particolare riferimento a software concorrente OO per la gestione di eventi. Un esperimento è stato condotto è replicato con diverse categorie di studenti,inclusi laureati, e diverse sedi universitarie. Infine, la validazione di tecniche di ispezione su artefatti UML sono state investigate sperimentalmente con studenti di Roma Tor Vergata in collaborazione con ldocenti della a Universita' spagnola di Castilla La Mancha.
Misura del software
Conteggio dei Function Point per Progetti UML. Questa linea di ricerca ha inizialmente esaminato comparativamente modelli e tecnologie per il conteggio dei “Function Point” di progetti descritti in UML (Unified Modeling Language). Ha poi sviluppato, in modo completo, un prototipo di analizzatore e convertitore semi-automatico, basato su alcuni dei modelli esaminati, implementandolo come “wizard” all'interno di IBM-Rational. I risultati di casi di studio registrano conteggi proposti dal supporto semiautomatico prossimi a quelli indicati da un esperto. I risultati sono stati pubblicati in parte da IEEE ACM Software Metrics Symposium e, a cura di GUFPI-IFPUG, in volume di editore nazionale. Modelli per la misura del software: dalla teoria alla produzione. In questa linea di ricerca, la teoria classica delle misure viene prima ripresa e poi applicata alla misurazione software, descrivendone i tipi, le aree applicative e i metodi più comuni di identificazione. Viene definita, quindi, un ciclo di vita per i modelli di misura del software. I risultati sono stati pubblicati a cura di GUFPI-IFPUG in volume di editore nazionale.  
Informatica sperimentale: Sperimentazioni di Ingegneria del Software (Experimental Software Engineering)
Con il titolo Experimental Software Engineering (ESE) ci si riferisce al sotto-dominio della Ingegneria dei sistemi software che si focalizza sulla sperimentazione controllata di architetture e sistemi software: prodotti, processi e/o risorse. La ESE è interessata a teorie, metodi e tecniche sperimentali per il software, allo sviluppo dei relativi modelli di processo sperimentale, alla produzione e raccolta di dati sperimentali, alla analisi di tali dati, alla verifica di ipotesi sperimentali, alla eventuale formulazioni di leggi e teorie. La prima settimana internazionale di ESE si è tenuta a Roma Tor Vergata nel 2003 (ESEIW 2003), coordinata da questo gruppo di ricerca, e da allora si è sempre ripetuta, anno dopo anno, in differenti paesi del mondo, includendo la maggiore conferenza internazionale del settore di ACM IEEE, prima denominata ISESE poi ESEM. L'approccio sperimentale è alla base di tutte le altre attività di ricerca del gruppo, come descritte nella presente pagina. Attività in parte finanziata dal 2001 al 20013 dal progetto europeo ESERNET e successivamente da Fraunhofer IESE, Kaiserkauter (Germany), ospitando laureandi e dottorandi di Roma Tor Vergata. Il coordinatore del gruppo e' stato membro del Comitato di Programma di ESEM2013 e dello Steering Committee di ISERN2013.