Rapporti tecnici

L'obiettivo olistico che ha l'iniziativa AURIGA 2020 si può esprimere sinteticamente come: diminuzione dei costi di produzione, eliminando gli sprechi, aumentando la qualità della stessa produzione. Per qualità della produzione si intende la proposizione dei valori richiesti da tutti gli stakeholders. Pertanto, la parte centrale della qualità è senza dubbio quella del software ma a questa si devono affiancare tutti gli altri parametri di qualità avvertiti dagli utilizzatori dei prodotti e dei servizi erogati da AURIGA.

Tutto ciò premesso, i pilastri fondamentali dell'infrastruttura che deve essere costituita in AURIGA sono:

• Strumenti per la gestione dei processi. Questi costituiscono il nucleo centrale della produzione in AURIGA quindi in essi si annidano molti degli sprechi che si devono individuare ed eliminare. La eliminazione di questi richiede che i processi posano essere monitorati e controllati sistematicamente, di qui la necessità di questi strumenti;
• Piattaforma per l'automazione dei test di sistema. I software che produce AURIGA sono in gran parte nel dominio applicativo delle transazioni di pagamento che utilizzano gli ATM. Questo dominio applicativo richiede che quando si devono fare i test di sistema dei software da consegnare ai clienti si deve avere la disponibilità degli ATM che il cliente specifico ha in esercizio. Questo implica che AURIGA deve avere un enorme parco di ATM considerato che: i produttori di queste macchine sono molti; i tipi di macchine che produce ogni fornitore sono molti; gli sportelli delle banche sono attrezzate con svariati tipi di ATM. Questo implica due problemi che impattano fortemente sull'economia della produzione e sulla qualità dei servizi: il primo problema è che servono molti spazi per mantenere in azienda tutti i tipi di macchine, il secondo problema è che ogni tipo di macchina fa da collo di bottiglia nei processi di test che si devono eseguire parallelamente per servire clienti diversi, ciò ha come conseguenza che i processi di test hanno forti rischi di dover essere rischedulati per mancanza della risorsa ATM, ovvero ritardi sulla consegna del prodotto. Inoltre, i casi di test di regressione devono essere ridigitati tutte le volte che si deve eseguire un test su uno specifico ATM; questo comporta alti costi. Se ne deduce che è necessario avere una piattaforma che fornisca ATM virtuali che emulano gli ATM fisici di tutti i tipi e che gestisca l'esecuzione di test di sistema che la stessa piattaforma accumula incrementalmente;
• Piattaforma per la verifica del codice. Questa piattaforma deve assicurare da un lato che il codice prodotto abbia le caratteristiche di qualità e di sicurezza che sono necessarie a rendere competitivi i prodotti messi sul mercato da AURIGA; dall'altro deve assicurare che la gestione e la manutenibilità dei prodotti siano tali da rendere più economici i processi di sviluppo che comprendono produzione e manutenzione del software; infine essi devono promuovere l'acquisizione on job delle buone pratiche di programmazione da parte dei programmatori.
• Tra i tool citati lo ALM (Application Lifecycle Management) è certamente il più radicato e diffuso nel mercato e nella letteratura, perciò per questo si è reso necessaria una preliminare analisi dello stato dell'arte.

Questo rapporto continua, quindi, con l'analisi eseguita per decidere quali tool acquisire per essere successivamente validati empiricamente e quindi sperimentati intensivamente su progetti e prodotti sperimentali così che si possa creare la necessaria conoscenza utile per la disseminazione degli stessi in tutta l'impresa AURIGA.

Approfondisci il concetto »

Selezionati gli elementi essenziali dell’infrastruttura per supportare l’iniziativa AURIGA 2020, è necessario verificare che essi siano adeguati agli obiettivi assegnatili nel contesto di AURIGA.

Per tale scopo devono essere sperimentati preliminarmente in campo. In particolare:

• Il TFS richiede almeno un progetto campione da gestire che deve seguire uno specificato processo. Deve essere verificato che le feature dello strumento consentano di disciplinare l’esecuzione dei processi e di rilevare le misure che serviranno a valutare la qualità dei progetti e dei processi. Rispetto ad AURIGA 2020, esso deve facilitare la eliminazione di attività che sprechino risorse nella esecuzione dei progetti e consentire la rilevazione degli indicatori di qualità che esprimano taluni aspetti della qualità da conferire agli stakeholders.
• FIS deve contribuire a risolvere due problemi cruciali per l’economia dei progetti e la qualità dei prodotti. Da un lato esso deve rendere virtuali macchine ATM (Automatic Teller Machine) e CSA (Casse Self Assistite), dall’altro deve consentire di eseguire automaticamente piani di test di sistema con numerosi casi di test. Nell’ottica di AURIGA 2020, il primo aspetto elimina per un verso la necessitò di dover avere macchine fisiche per la esecuzione dei test; trattasi di avere molte decine di macchine fisiche a disposizione. Considerata la numerosità dei tipi di macchine che sono sul mercato e considerata la occupazione del mercato (più che il 70% degli ATM in Italia ed il 3% degli ATM nel globo), in AURIGA si possono avere solo pochi esemplari (uno o due dipendentemente dal tipo) per tipo (fornitore e modello) di macchina. Questo comporta che su ogni macchina si accodino più attività di test inerenti diversi progetti in esecuzione e ciò comporta tempi di attesa che creano disvalori per i rispettivi progetti; pertanto FIS ha anche l’obiettivo di eliminare questi ultimi conferendo così ulteriori valori ai progetti. D’altronde, FIS deve consentire di accumulare incrementalmente casi di test che devono servire a verificare la regressione dei sistemi software che si consegnano ai clienti dopo aver realizzato le modifiche chieste da questi ultimi e di eseguirli automaticamente senza l’impiego di persone. Questo crea valore per i clienti a cui si consegnano prodotti con meno difetti residui e per gli sviluppatori a cui si evita l’esecuzione di attività molto noiose quali quella dell’esecuzione dei casi di test e di verifica della correttezza dei risultati.
• KIUWAN deve assicurare che rilevi i difetti nei programmi appena questi siano iniettati dai programmatori. Questo ha due grandi vantaggi, il primo è che la eliminazione dei difetti rilevati tempestivamente costano meno; il secondo l’addestramento on job dei programmatori all’uso delle buone pratiche di programmazione così che essi iniettino sempre meno difetti nei programmi.
• Fortify ha ruolo e vantaggi analoghi a KIUWAN ma per gli aspetti della sicurezza in cui, nell’analisi dello stato dell’arte, ha dimostrato di avere un punto di forza corrispondente al punto di debolezza di KIUWN nella verifica dello stesso aspetto della qualità.

Per dovere di chiarezza, è opportuno evidenziare che queste verifiche dovranno dimostrare l’adeguatezza degli strumenti ma rileveranno anche la necessità di miglioramenti necessari che dovranno essere realizzati o chiedendo modifiche ai fornitori dei tool o acquisendo, anche realizzandoli in casa, degli strumenti addizionali che completino le loro features. In quest’ultimo caso, la verifica deve assicurare che la qualità degli strumenti è tale da rendere ragionevolmente economica e tempestiva l’acquisizione di tali strumenti aggiuntivi. Una volta verificata la adeguatezza degli strumenti ai loro obiettivi questi saranno utilizzati nei cantieri sperimentali che AURIGA 2020 deve provvedere per i suoi obiettivi ed in tali cantieri saranno ulteriormente sperimentati e quindi raffinate le loro valutazione e le conseguenti modalità d’uso.

Inoltre, durante l’esecuzione di AURIGA 2020 questi strumenti saranno migliorati dai loro fornitori, com’è naturale per tutti i sistemi software; quindi, i cantieri sperimentali aperti serviranno a verificare come questi miglioramenti possano far coprire meglio gli scopi relativi di ognuno degli strumenti. Anche dopo il completamento di AURIGA 2020 saranno realizzati miglioramenti su ognuno dei tool in questione; pertanto essi continueranno ad essere considerati sotto sperimentazione anche quando il loro uso ed i loro servizi saranno stati industrializzati, ovvero disseminati in tutti i progetti ad uso di tutti gli sviluppatori di AURIGA.

È evidente che AURIGA 2020 dovrà prevedere che anche dopo l’industrializzazione dei suoi risultati si dovrà instaurare, per quanto detto prima, una continua sperimentazione e miglioramento di processi, progetti e prodotti. Questo è compito degli altri obiettivi realizzativi dell’iniziativa AURIGA 2020.

Questo rapporto continua dedicando un capitolo per ognuno degli strumenti da verificare.

Approfondisci il concetto »

Nel presente documento riferito alla sola attività di progetto “2.1 - Analisi dello stato dell’arte”, in linea con la visione generale dell’obiettivo realizzativo “Analisi del fabbisogno” si riporta la trattazione dei risultati ottenuti dal censimento degli attuali metodi e tecniche annoverati in letteratura ed utili alla formalizzazione ed esecuzione di Lean Thinking in ambito di Software Development dal punto di vista sia dei contenuti che delle tecnologie.

In particolare, sono descritte le metodologie e tecnologie dei seguenti ambiti:

• Processi lean. È l’insieme dei processi che sottendono la gestione snella dell’azienda, ottenuta tramite l’applicazione dei principi del Lean Thinking e del Toyota Production System. Un miglioramento continuo per creare valore al cliente interno ed esterno aumentando la competitività, attraverso la gestione dei processi aziendali e la riduzione degli sprechi.
• GQM (Goal, Question, Metric). È un approccio che identifica metriche significative, utili alla misurazione di alcune proprietà del software o delle sue specifiche, per ogni parte del processo di sviluppo software. Evidenzia la necessità di: stabilire un obiettivo di misurazione esplicito, specifico delle attività del processo o delle caratteristiche del prodotto che deve essere valutato; definire un insieme di domande cui occorre rispondere per ottenere l’obiettivo; identificare metriche ben formulate per aiutare a rispondere a queste domande.
  • QIP. QIP è uno strumento completo di miglioramento della qualità dei progetti di prevenzione e promozione della salute. Verifica la qualità di programmi, progetti, campagne e interventi basati sul contesto, oltre che delle iniziative di formazione ed educazione sanitaria. Fornisce feedback e suggerimenti per dei miglioramenti. QIP può essere utilizzato per migliorare la qualità in qualsiasi fase del ciclo del progetto, come strumento di pianificazione per massimizzare la qualità durante l’implementazione, nonché per migliorare la progettazione e i processi di valutazione.
• Big data. Con il termine Big Data ci si riferisce alla capacità di usare enormi volumi di dati eterogenei per fonte e formato, per trovare riscontri oggettivi, in tempo reale, su diverse tematiche analizzabili. L’analisi di una mole così elevata di dati richiede competenze specifiche, e tecnologie avanzate in grado di supportare l’elaborazione di file di dimensioni così grandi, per poterne estrarre informazioni utili, nascoste. Così come è avvenuto per innovazioni quali internet, data center o cellulari, anche i Big Data sono uno step verso un modo diverso di gestire il business e la società.
• Formazione continua. La formazione continua (in inglese “continuing vocational training”) ha come obiettivo principale quello di riqualificare e donare una nuova professionalità al personale di aziende e organizzazioni attraverso la partecipazione a specifici corsi "dedicati". Nel contesto lavorativo attuale, il mondo del lavoro è in continuo cambiamento a causa di brevi periodi a cui sono soggette le economie, il lavoratore è soggetto costantemente a cambi lavorativi e questo ha fatto nascere la necessità di riqualificare il personale per poterlo inserire in nuovi impieghi o mansioni più consoni al cambiamento in atto.
• Trasferimento della conoscenza. il termine "knowdlege sharing", partendo dall'assunto secondo cui la conoscenza se fatta confluire in un "fondo condiviso" caratterizzato da apporti diversificati, possa essere il reale valore competitivo dei nostri tempi. Siamo in presenza di una grande rivoluzione di pensiero. Ad oggi le competenze sono considerate un valore da "difendere" e la ragione reale di un vantaggio competitivo.

Approfondisci il concetto »

Nel prosieguo del presente rapporto tecnico si riporta quanto rilevato nello stato dell’arte in relazione all’applicazione delle metodologie e delle tecniche identificate nel procedente rapporto tecnico.

Approfondisci il concetto »

Dopo aver fatto lo stato dell’arte che consente di raccogliere metodi e strumenti utili per gli obiettivi della presente iniziativa è necessario analizzare cosa bisogna implementare perché i metodi anzidetti possano essere applicati durante il miglioramento continuo che si innescherà, non solo durante l’iniziativa, ma anche dopo la fine della stessa e durante la industrializzazione dei risultati (cfr Figura 5.29).

Gli aspetti considerati più rilevanti che devono essere implementati in AURIGA 2020 sono: Learning, Application Lifecycle Management; la Base di Conoscenza ed Esperienza. In questo capitolo si rileva che per il Learning lo strumento che risponde meglio alle esigenze della presente iniziativa è Moodle. Per quanto riguarda lo ALM si conferma che il TFS, scelto come strumenti infrastrutturale, è una buona scelta rispetto a quelli concorrenti. Infine per quanto riguarda la KEB ci sono solo informazioni su come deve essere organizzata oltre a cosa deve contenere, ma non ci sono strumenti che possano essere presi in considerazione. Pertanto la progettazione e la realizzazione della KEB deve essere completamente a carico di questa iniziativa.

A partire da quanto rilevato circa gli aspetti detti, si analizza come si vuole implementare la trasformazione dell’impresa secondo il Lean Thinking e per ognuno degli aspetti coinvolti in questa trasformazione sono inventariate le implementazioni più critiche in termini di processi, di valori che devono essere presi in considerazione per riconoscere gli sprechi e gli approcci adottati per la trasformazione, sfruttando quanto disponibile ed inventariato precedentemente.

Il capitolo è strutturato come segue:

• Learning, per lo stato dell’arte circa la formazione on line;
• ALM, per la valutazione degli strumenti ALM più accreditati sul mercato;
• Base di conoscenza, per analizzare quanto è conosciuto nella pratica cirac la patrimonializzazione della conoscenza e della esperienza empirica;
• Analisi per AURIGA che rappresenta lo spirito con cui AURIGA 2020 affronta la trasformazione secondo il Lean Thinking adeguato agli obiettivi di business ed al contesto attuale di AURIGA.

Approfondisci il concetto »

Secondo la teoria dei sistemi, il sistema di processi dell’Ingegneria del software è dinamico, discreto, distribuito e non deterministico. In rapporto con un tale complicato sistema, un modello di processi software può essere empirico o formale dal punto di vista delle tecniche e descrittivo o prescrittivo dal punto di vista dell’organizzazione. Attualmente i modelli di processi normalmente utilizzati sono empirici-descrittivi: catturano le migliori pratiche derivate dall’esperienza industriale e le organizzano in modelli di processi che descrivono cosa fare. Si tende a descrivere il modello in modo rigoroso per eliminare ogni ambiguità circa il “cosa” si deve fare nell’esecuzione di ogni attività; gradualmente, attraverso l’automazione delle attività di base si rendere prescrittivo il modello perché gli strumenti vincolano anche il “come” eseguire le attività.

Gli attuali modelli empirici-descrittivi sono designati per contribuire a rispondere alle seguenti questioni:

• Quali sono le migliori pratiche dell’ingegneria del software?
• Quali sono le esperienze empiriche di successo nei processi delle organizzazioni di sviluppo software?
• Come sono impiantati i processi di ingegneria del software?
• Come sono controllati lo stato e le prestazioni di un sistema di processi?
• Com’è possibile migliorare un sistema di processi software esistente?

L’Impianto dei processi software è una procedura sistematica per selezionare e implementare un sistema di processi ritagliandolo, estendendolo o adattandolo da un sistema di riferimento di processi che sia ben stabilizzato. Poiché questa procedura è una costosa reingegnerizzazione organizzativa è opportuno che in cima all’agenda della sua realizzazione ci sia l’indagine della usabilità e convenienza del modello dei processi candidati.

Una volta selezionato il modello di riferimento, il passo successivo è di ritagliare e adattare i modelli di processi da adottare perché essi si adeguino al meglio all’ambiente e alla cultura dell’organizzazione che li deve adottare. E’ comunque evidente che raramente il sistema di riferimento si adegui al 100% ad un’organizzazione; quindi, c’è da prevedere comunque una reingegnerizzazione dei processi dell’organizzazione.

Approfondisci il concetto »

Questo documento descrive come definire e implementare un programma di misurazione per supportare i fabbisogni di informazione dell’impresa quando produce, fornisce o acquisisce sistemi software. Poiché questo documento vuole raccogliere le esperienze già disponibili in letteratura e vuole essere esso stesso un mezzo per raccogliere esperienza esplicita di AURIGA in questo delicato settore, si ispira al “Practical Software and Systems Measurement (PSM)” del Department of Defense and US Army.

Questo documento è rivolto a:

• Manager Tecnici e di Progetto – per conseguire una migliore comprensione (capire e saper applicare) dell’uso della misurazione per la gestione dei progetti software e di sistema;
• Personale Tecnico di progetto- per aiutarli ad implementare la misurazione durante l’esecuzione di un progetto;
• Manager del Business dell’Impresa – per comprendere I requisiti associate alla implementazione delle misurazioni nell’Impresa.

TR3.2 si focalizza sui progetti perché questi sono alla base del business di AURIGA. Nonostante la focalizzazione sui progetti, i problemi trattati e le soluzioni proposte possono essere agevolmente generalizzati per aspetti inerenti i prodotti software, i dati e le prestazioni richiesti a livello dell’intera organizzazione dell’impresa.

Gli aspetti quantitativi del Project Management includono la misurazione e la gestione dei rischi e delle prestazioni finanziarie. TR3.2 è focalizzato sul processo di misurazione ma discute anche le relazioni chiavi con la gestione del rischio e finanziaria. Esso indirizza quattro maggiori temi del processo di misurazione:

• Adattamento delle misure software per rispondere a specifiche questioni;
• Applicazione delle misure software per convertire le misure rilevate in informazioni utilizzabili;
• Implementazione della misurazione per ogni misura necessaria;
• Valutazione della misurazione.

Il rapporto 3.2 prosegue con i seguenti sette capitoli che dettagliano incrementalmente i quattro temi anzidetti:

1. Misurazione spiega ciò che serve per implementare un processo di misura su un progetto, descrivendo la misurazione ad un livello sintetico esponendo una sintesi dei quattro temi citati.
2. Adattamento delle Misure, descrive come identificare I problemi del progetto, selezionare le misure più appropriate e definire il piano di misurazione del progetto.
3. Selezione e Specifiche delle Misure che attraverso un insieme di tavole supportano l’utilizzatore a selezionare le misure che indirizzano meglio il problema del progetto; tali tavole dettagliano meglio la guida all’adattamento delle misure di cui al capitolo precedente.
4. Applicazione delle Misure, descrive come raccogliere e processare dati rilevati attraverso la misurazione e usare le informazioni ricavate per prendere decisioni informate durante l’esecuzione del progetto.
5. Analisi di Misurazione e Esempi di Indicatori, fornisce esempi di Indicatori derivati dalle misure e le relative interpretazioni. Questo è un approfondimento del precedente capitolo precedente.
6. Processi di Implementazione descrive I compiti che compongono la misurazione in un’organizzazione.
7. Valutazione della Misurazione identifica le attività di valutazione e di miglioramento della misurazione.

Per facilitare la lettura: si consiglia di leggere prima il capitolo di “Misurazione”, dopo di esso è agevole leggere in sequenza i capitoli “Adattamento delle Misure”, “Applicazione delle Misure”, “Processi di Implementazione”, “Valutazione delle misurazioni”; “Selezione e Specifiche delle Misure” è opportuno leggerlo dopo e per approfondire “Adattamento delle Misure”; “Analisi di Misurazione e esempi di Indicatori” dopo aver letto e per approfondire “Applicazione delle Misure”.

Approfondisci il concetto »

La Ingegneria del Software è stata definita come “l’applicazione disciplinata dei principi, metodi e tools ingegneristici, scientifici e matematici alla produzione del software”.  Le sue attività comprendono la pianificazione, la stima, l’analisi, la progettazione, l’implementazione, il test, la manutenzione e la gestione.

Le prospettive per il successo nell'esecuzione e nel miglioramento di queste attività aumentano in modo significativo quando le decisioni possono essere prese basandosi su informazioni quantitative e su conoscenze che possono essere ottenute solo dall’osservazione e misurazione di prodotti, processi e risorse coinvolte. Ma uno dei rischi in imprese complesse che abbiano come scopo lo sviluppo e il supporto del software è che ci sono potenzialmente così tante cose da misurare che si è facilmente sopraffatti dai dati. Affinché la misurazione sia redditizia, deve essere progettata e mirata per supportare gli obiettivi aziendali dell'organizzazione.

Perciò è necessario utilizzare un processo che aiuti a trovare e definire le misure software che supportano direttamente gli obiettivi aziendali. A tale scopo, questo rapporto mostra come identificare e definire le misure software per supportare gli obiettivi aziendali in modo che le attività di raccolta dei dati siano focalizzati sugli obiettivi prefissati. Questo approccio è denominato misurazione guidata dagli obiettivi. In questo approccio la domanda primaria non è "Quali misure dovrei usare?", ma "Cosa voglio sapere o imparare?".  Poiché le risposte dipendono dagli obiettivi, non vi è alcuna serie fissa di misure universalmente appropriato. Quindi, invece di tentare di sviluppare o utilizzare liste generiche e per tutti gli usi di misure discutibilmente utili, è opportuno disporre di un processo di adattamento che ogni persona o gruppo di lavoro possa utilizzare per identificare e definire le misure che forniscono approfondimenti sui propri problemi gestionali. Tutto ciò è coerente con il Lean Thinking che è il perno su cui ruota l’iniziativa AURIGA 2020. Le tecniche che si illustrano sono elementi di un processo molto pratico che favorisce la organizzazione dell’impegno delle persone implicate nella pianificazione e nella gestione della misurazione.

Il rapporto è strutturato come segue: prima di tutto si espongono i fondamenti a cui farà riferimento l’intero rapporto, il capitolo successivo parla dei modelli mentali alla base dei processi in esercizio in una organizzazione, si passa così alla descrizione dettagliata dei modelli guidati dagli obiettivi che formalizzano i modelli mentali e per concludere con i modelli metrici alcune raccomandazioni utili per poter definire e gestire correttamente i modelli metrici; il capitolo 6 introduce uno strumento pratico per rilevare i bisogni di misurazione di una organizzazione che consente la progettazione partecipata dei modelli metrici, il capitolo seguente tratta un metodo che struttura, meglio di come non sia stato fatto precedentemente, la relazione tra obiettivi di business, strategia e obiettivi di misurazione così che si colleghino i risultati di quest’ultimo ai problemi di tutti i livelli organizzativi ( strategico, esecutivo, operativo); infine il Quality Improvement Paradigm che si collega ai modelli metrici per il miglioramento continuo dei risultati rilevati da questi ultimi.

Approfondisci il concetto »

Il software è un prodotto immateriale e può essere difficile avere una panoramica completa di un sistema software che normalmente comprende milioni di linee di codice per identificare tutti i possibili difetti disseminati in esso. Inoltre i processi di sviluppo (produzione e manutenzione) sono creativi e quindi difficili da controllare per poter individuare ed eliminare tutte le possibili sorgenti di errori. Altre sorgenti di problemi possono trovarsi nella comunicazione tra utenti finali e sviluppatori.

Da tutto questo deriva che piccoli difetti creano grandi conseguenze nel software e richiedono molto tempo e molto impegno-persona per essere eliminati. Numerosi esempi di problemi nello sviluppo software sono esposti in [T. Collins and D. Bicknell, 1997], [R.L. Glass, 1998].

Molte discussioni sono state fatte negli anni nell’ambito della Ingegneria del Software (I.S.) per ridurre l’impatto di tali problemi. Molte soluzioni sono state proposte per migliorare lo sviluppo del software con l’obiettivo, in generale, di migliorare la produttività e la qualità del software prodotto. Differenti tecnologie sono state introdotte, quali, per esempio:

• Tecniche strutturate- usano la strutturazione nell’analisi, progettazione e programmazione.
• Linguaggi di quarta generazione.
• Computer Aided Software Engineering- strumenti di support alla ingegneria del software.
• Metodi formali- specifica e validazione formale del software.
• Metodologie Cleanroom-metodo per rimuovere difetti dal software.
• Modelli di processo- descrizione di processi appropriati nella ingegneria del software.
• Tecnologie Object Oriented- per trovare “oggetti” nel problema da risolvere ed usare questi nel generare soluzioni software.
• Framework- schemi per produrre software più rapidamente e con maggiore qualità.

Col tempo la lista di tecnologie utilizzabili aumentano, qualcuna diventa obsoleta, tutte sono promettenti nei risultati della loro applicazione ma vi sono, ancora oggi, pochi articoli di ricerca che consentono di valutare l’efficacia di ognuna di esse e di confrontare l’efficacia di tecnologie concorrenti. Pertanto c’è bisogno di maggiore ricerca, di rilevazione di dati empirici e di analisi di questi ultimi per validare l’efficacia di ogni tecnologia e le condizioni di applicazione delle stesse che consentono di misurare l’efficacia. Solo questa conoscenza rende possibile prendere decisioni informate circa l’introduzione di una nuova tecnologia in un contesto di sviluppo software.

Recentemente, molto interesse è stato posto sul riuso della conoscenza ricavata da progetti precedentemente sviluppati per aumentare la qualità dei nuovi sviluppi. Di conseguenza è anche stato dato molto interesse alla “gestione della conoscenza” che è stata applicata con successo in molti altri settori diversi dallo sviluppo software e che quindi può dare risultati soddisfacenti anche nel software.

Prima di discutere della gestione della conoscenza è opportuno analizzare qualche concetto di base per eliminare ambiguità e fraintendimenti.

• I dati sono direttamente rilevati dalle entità osservate, essi sono grezzi, non sintetizzati e esprimono fatti non analizzati, in sintesi non hanno significato e sono l’input al processo di interpretazione che è il passo inziale al processo decisionale. Esempi di dati sono casi di test, dati di test, misure di impegno-persona o di complessità, errori.
• L’informazione è il significato che un umano o un sistema intelligente associa ai dati significativamente processati ed opportunamente rappresentati, per mezzo di convenzioni [Lehner, 2001]. La raccolta dei dati in una memoria, richiede una certa struttura e questa consente la trasformazione automatica di dati in informazione; per esempio la distribuzione dell’impegno-persona nelle fasi di un processo può essere raccolta automaticamente. Spesso l’informazione è creata dalle persone; per esempio il modello di un prodotto o di un processo ricavato dai dati estratti da progetti eseguiti, oppure la raccolta di casi di test standard.
• La conoscenza è definita in [Oxford Dictionary and Thesaurus, 1995] come la consapevolezza o familiarità guadagnata da una persona o da fatti o da cose attraverso l’informazione. La conoscenza deriva da un processo di apprendimento basato sull’informazione che dipende dall’ambiente reale in cui è stata prodotta l’informazione ed eseguito il processo di apprendimento [Lehner, 2001]. Pertanto, quando si esprime un elemento di conoscenza è importante registrare anche l’ambiente in cui essa è stata creata. Per esempio un modello di processo può essere riusato efficacemente solo quando il contesto (dominio applicativo, numero di persone nel gruppo di progetto, competenze delle persone, ecc.) in cui è già stato usato con successo è conosciuto. Pertanto per evitare errori nell’uso della conoscenza è necessario che la struttura di questa sia una parte integrale dell’archivio in cui essa è depositata.
• L’esperienza è guadagnata dalle persone attraverso l’utilizzazione ripetuta dell’informazione o della conoscenza. Essa non può essere trovata su libri o articoli, bensì è acquisita solo dalle persone, mai da sistemi automatici. Una persona fa uso dell’informazione e della conoscenza e produce esperienza che se opportunamente espressa e memorizzata può essere usata come conoscenza da altre persone che non l’hanno prodotta. La validità dell’esperienza è legata al contesto degli eventi e delle attività i cui è stata guadagnata. Perciò, nella registrazione dell’esperienza è necessario che sia registrato, oltre al contesto, anche l’ambiente (per esempio: il progetto) in cui è stata ricavata [Tautz, 2000].

Una più approfondita analisi rileva due tipi di conoscenza: tacita ed esplicita. La conoscenza tacita è quella che un umano ha nella sua mente e che non ha esplicitato, molto spesso non la sa esplicitare; per esempio saper andare in bicicletta. La conoscenza esplicita è quella descritta in rapporti, libri o qualsiasi altro strumento formale e informale di comunicazione. In letteratura [Nonaka, 1995] si sostiene che: la esternalizzazione è la trasformazione di conoscenza tacita in esplicita; la internalizzazione trasforma la esplicita in tacita; la socializzazione da tacita di una persona a tacita di una o più persone; la combinazione da esplicita ad esplicita.

In questo report si discute sia di come migliorare lo sviluppo del software ed i processi di acquisizione sia di come aumentare la qualità del software e la ripetibilità del successo, sia di come riusare la conoscenza di progetti precedenti per migliorare quelli futuri e come creare un ambiente di apprendimento tra gli sviluppatori.

Per rendere più chiaro quanto esposto di seguito è opportuno definire alcuni termini chiave:

• La tecnica è un algoritmo di base, o una serie di passi da seguire nella costruzione o valutazione del software. Ad esempio, la lettura del codice per astrazione graduale è una tecnica per valutare il codice.
• Il metodo è un approccio organizzato basato sull'applicazione di alcune tecniche. Un metodo ha associato ad esso una o più tecniche, così come una serie di linee guida su come e quando applicare ogni singola tecnica, quando smettere di applicarla, quando la tecnica è appropriata e come si possa valutarlo. Ad esempio, un metodo avrà un associato un insieme di criteri di ingresso e di uscita e una serie di supporti di gestione. L’ispezione del codice è un metodo, basato su una tecnica di lettura, che ha a insieme ben definito di criteri di ingresso e uscita e un insieme di funzioni di gestione che definiscono come manipolare la tecnica.
• Processo di sviluppo o processo, come insieme integrato e coordinato di metodi che coprono l'intero ciclo di produzione di un prodotto software o di un servizio.
• Tecnologia come uno dei precedenti elementi applicati in un sistema produttivo per creare valore.

Questo report continua come segue:

• Il capitolo 2 introduce nei concetti fondanti della conoscenza ed e esperienza e come si producono, stante la letteratura;
• Il capitolo 3 fa un elenco delle basi di esperienza in ambiente industriale che si conoscono attraverso la letteratura; per ognuna delle basi di esperienza presa in esame si rileva anche l’efficacia del loro uso; purtroppo i dati empirici, quando sono noti, non sono confrontabili perché ogni impresa interpreta e misura l’efficacia secondo il proprio punto di vista.
• Il capitolo 4 sono esaminati alcuni aspetti che generalizzano le lezioni apprese dall’uso e dalla produzione della conoscenza e della esperienza.
• Il capitolo 5 espone i fondamenti della “teoria” nella I.S., come è utilizzata in Auriga nella formulazione dei Pacchetti di Conoscenza ed Esperienza; infatti, l’innovazione più rilevante nella Base di Esperienza e Conoscenza concepita in Auriga è la composizione dei Pacchetti di Conoscenza ed Esperienza focalizzati su una “teoria” che con il loro uso è confermata, modificata o confutata.
• Il capitolo 6 descrive le caratteristiche della Base di Conoscenza ed Esperienza di Auriga che prende il nome di ARUBAKEB.
• Il capitolo 7 analizza l’empirismo ed il suo valore nella validazione delle teorie; questo rende autoconsistente il rapporto, visto che ARUBAKEB usa molto i concetti inerenti l’empirismo.
• Il capitolo 8 espone come la Base di Conoscenza ed Esperienza è essa stessa un mezzo di formazione continua e come si collega agli strumenti di formazione di cui essa ha bisogno.

Approfondisci il concetto »

Implementazione processi organizzativi (TFS) e non TFS.

Approfondisci il concetto »

I modelli metrici servono a monitorare l’andamento del progetto secondo le esigenze di AURIGA.

I modelli metrici saranno aggiornati nel tempo sia per soddisfare i cambiamenti di esigenze dell’impresa sia per le misure che saranno rilevabili a causa della maggiore strumentazione dei processi e della riorganizzazione degli stessi.

Tutti i modelli metrici sono definiti con il paradigma Goal Question Metrics (GQM).

Il presente documento descrive i meccanismi per la rilevazione dei dati per alimentare automaticamente il GQM in modo tale da essere certi della loro correttezza e da economizzare la gestione dei modelli di qualità.

Approfondisci il concetto »

Produzione o installazione del tool per la gestione dei modelli di qualità (GQM, QIP, etc.)

 Produzione o installazione del tool per il MINING DEI DATI.

Approfondisci il concetto »

Produzione e installazione del tool per la gestione della base di conoscenza

 Produzione e installazione del tool per la formazione continua.

Approfondisci il concetto »

Le indagini empiriche sono servite a sperimentare l’efficacia delle innovazioni introdotte in AURIGA.

Esse sono state eseguite sempre con i Minimum Viable Product (MVP) per evitare sprechi nel produrre prototipi operativi (prodotto da sperimentare) che evidenziano carenze di efficacia e quindi devono essere modificati. In altri termini, si spende il minimo possibile per arrivare ad un prototipo che possa essere verificato, testato o sperimentato così che se il risultato della validazione dovesse essere negativo si è speso poco e, comunque, si è compreso prima se e cosa debba essere modificato.

Le indagini sono condotte con il paradigma della Ricerca-Azione. La comunità di destinatari dell’innovazione riconosce come “proprio e valido” il problema per cui si sta sviluppando l’innovazione e si fa promotrice delle ipotesi di soluzione. Così che se dopo la sperimentazione i risultati non sono valutati, dalla stessa comunità, soddisfacenti si decidono le iniziative di miglioramento con un processo di progettazione partecipata. I ricercatori di AURIGA promuovo e facilitano il processo mentre i veri attori dell’innovazione e delle indagini correlate sono gli stakeholders.

Le indagini empiriche sono condotte con l’approccio costruttivista ed essenzialmente con il caso di studio come tipo di indagine. L’approccio consente di produrre teorie locali che sono valide per AURIGA e che possono essere modificate nel tempo man mano che i progetti che si eseguono nell’azienda, anche se non sono sperimentali, producono nuova conoscenza. Il tipo di indagine preminente è il caso di studio essenzialmente per due ragioni: la sperimentazione deve avvenire nel contesto reale; i risultati della sperimentazione richiedono l’esecuzione di attività incluse nei progetti sperimentali ma non implicate nella sperimentazione.

Spesso i dati di controllo sono ricavati da progetti eseguiti in AURIGA senza l’innovazione che si sta sperimentando. In tal caso è necessario associare ad un caso di studio anche la revisione di dati storici.

Gli sprechi, ovvero attività che non creano valore, sono disseminati nei processi di AURIGA e sono rilevati gradualmente pertanto sono necessari diversi cantieri sperimentali. Alcuni di questi sono attivati in parallelo, altri sono attivati in sequenza perché la risoluzione o la moderazione di un problema, spesso, ne fa emergere altri.

I cantieri sperimentali aperti hanno caratteristiche diverse, dipendentemente dagli obiettivi dell’innovazione da sperimentare. Pertanto ogni cantiere sperimentale ha un suo processo di sperimentazione che è adeguato agli obiettivi dell’innovazione.

Nel seguito di questo report si descrivono, per completezza, il paradigma di ricerca-azione e il caso di studio. Per i concetti di teoria locale e di costruttivismo si rimanda al TR 3.4.  Dopo la descrizione di questi concetti si descrivono i cantieri sperimentali attivati e per ognuno di essi si riporta il progetto dell’indagine sperimentale.

Approfondisci il concetto »