Tutte le pubblicazioni e le monografie che possono essere scaricate mediante i link di questa pagina, possono essere pubblicamente utilizzate, purchè ne venga indicata chiaramente la fonte. Ciascun link dell'elenco sotto riportato rimanda ad un paragrafo che contiene una breve introduzione della corrispondente pubblicazione o monografia, seguito da uno o più link per il download dei relativi file.
Le organizzazioni industriali per la progettazione del software
La produzione industriale del software per rispettare gli obiettivi economici, di qualità e di time to market deve essere realizzata secondo modelli che indicano il “cosa deve essere fatto” ed altri modelli che indicano il “come deve essere fatto”. I primi modelli comportano per l’ente che produce il software l’adozione di una ben precisa organizzazione a livello aziendale. Questo fatto non è immediatamente evidente, ma può essere dimostrato. I secondi modelli indicano invece esplicitamente quale deve essere l’organizzazione a livello dei team di progettazioni. L’uso combinato di un modello del tipo “cosa deve essere fatto” e di un altro del tipo “come deve essere fatto” determina in modo preciso l’organizzazione che l’ente produttore del software si deve dare sia a livello aziendale che a livello di team di progettazione.
Questo articolo è stato presentato al congresso AICA tenuto a Taormina il 27-30 Settembre 2000 e successivamente è stato pubblicato sulla Rivista di Informatica AICA nel Volume XXXI n.3 settembre-dicembre 2001. Dal momento della sua pubblicazione ad oggi i modelli a cui l'articolo fa riferimento hanno ovviamente subito delle sostanziali evoluzioni, ma, malgrado ciò, la tesi di fondo dell'articolo, relativa al fatto che gli enti che producono software si devono dare un'organizzazione che non può essere una qualsiasi, magari stabilita dalla storia in precedenza vissuta dall'ente, ma deve essere necessariamente ridefinita in base ai modelli che vengono prescelti per il "cosa deve essere fatto" e per il "come deve essere fatto", rimane sostanzialmente valida.
L’Ingegneria del Software raccoglie un insieme di modelli, metodologie e tecniche che supportano i progettisti nel realizzare la produzione e la manutenzione del software, secondo processi che sono stati studiati per essere pianificabili, controllabili, ripetibili, misurabili, migliorabili, …ecc. Da questo punto di vista l’Ingegneria del Software non si discosta dalle Ingegnerie relative ad altri tipi di progettazione (edile, meccanica, elettronica, ..ecc.), ma la pratica applicazione delle sue metodiche rileva spesso delle notevoli discordanze tra i risultati attesi e quelli effettivi. Questo è da imputare innegabilmente alla particolare natura del prodotto, il Software, che l’Ingegneria del Software supporta per la progettazione e la manutenzione.
Ovviamente i fondamentali passi avanti dell’Ingegneria del Software, effettuati, ad esempio, nella ricerca di metodologie di progettazione efficaci (che hanno portato dapprima alla Structured Analysis and Design e, più recentemente, alla Object Oriented Analysis and Design) o di migliori processi di progettazione/manutenzione (come la definizione del Rational Unified Process e poi dei numerosi processi agili, come Extreme Programming, Scrum, ecc.), sono stati realizzati tenendo conto della natura del prodotto Software, ma ciò non è stato fatto in modo sistematico, ma solo in un modo sostanzialmente intuitivo. Ossia in ciascuno di questi tentativi si è cercato di definire “cosa era meglio per il Software”, e poi, a posteriori, si è cercato di verificare se quello che si era definito era veramente quanto di meglio per il Software. Ognuno di questi tentativi ha in realtà poco curata la ricerca relativa alla caratterizzazione dell’oggetto che si vuole progettare, ossia alla caratterizzazione del Software stesso, e, di conseguenza, allo studio degli impatti devianti che le sue intrinseche caratteristiche possono provocare al processo di progettazione/manutenzione.
In questi ultimi anni Philip Glen Armour, curatore della rubrica “The Business of Software” sulla rivista ACM Communications, si è distinto in una particolare ricerca sulla natura del Software e nell’analizzare le conseguenze che questa sua natura ha sulla relativa progettazione. L’analisi di Armour ha portato alla conclusione che il Software altro non è che “conoscenza”, il cui supporto è costituito dalle istruzioni di un calcolatore. In altre parole questo concetto, con un cambio di visuale ardimentoso, ma concretamente dimostrabile, può anche essere espresso dicendo che il prodotto finale di un progettista software non è costituito dalle istruzioni del calcolatore, ma dalla conoscenza che esse supportano. In particolare, inoltre, la conoscenza che il progettista software incorpora nel supporto costituito dalle istruzioni ha, rispetto ad altri tipi di conoscenza incorporati in altri tipi di supporti (libri, dischi, ecc.), il grosso vantaggio di essere una conoscenza non statica, ma, bensì, come facilmente comprensibile, una conoscenza “eseguibile”.
Armour ha poi stabilito una graduatoria di tipi di conoscenza, così come essa esiste prima di essere incorporata nel progetto Software e, quindi, ha analizzato le difficoltà che si presentano ad un Progettista Software per attuare le attività dell’incorporazione della conoscenza nelle istruzioni (cioè, in altre parole, per attuare la progettazione del software) a seconda del particolare tipo di conoscenza. Nell’articolo che qui si propone viene ripercorso il cammino che ha condotto Armour alla determinazione della natura del software e alla tipizzazione della conoscenza, prima della sua incorporazione nelle istruzioni, in una scala di cinque possibili tipi.
Come già detto, sia la natura del software, assegnabile direttamente alla conoscenza, sia l’esistenza dei vari tipi di conoscenza, influenzano le attività di progettazione del Software e quindi, in pratica, permettono di dare delle spiegazioni relativamente a particolari comportamenti che si osservano nel campo della progettazione del Software e possono costituire inoltre la base per una definizione più realistica dei modelli, metodi e tecniche che compongono l’Ingegneria del Software. In base a ciò Armour ha portato avanti un’analisi su molti aspetti del ciclo di vita del software, con risultati interessanti e condivisibili. L'articolo allegato precisa le idee di Armour e fa vedere come esse siano efficaci nello spiegare alcuni aspetti dell'ingegneria del software come, ad esempio, la difficoltà della preventivazione dei progetti software e l'efficacia delle metodologie agili.
I testi che seguono derivano dall’esperienza fatta dal sottoscritto nell’insegnamento dell’informatica a giovani laureati neo assunti presso strutture industriali. Questi giovani erano generalmente laureati in discipline tecniche (matematica, fisica, economia, ..ecc.), ma nessuno con indirizzamento informatico. Il loro impiego immediato, a valle del programma di addestramento, sarebbe stato quello di essere inseriti in team di progettazione software da produrre per terzi. Inoltre, poiché non era generalmente prevedibile a priori il preciso campo di applicazione del software che loro sarebbero andati a progettare ed anche per evitare una formazione lacunosa, si è cercato di orientare il loro insegnamento in modo da privilegiare i concetti base della progettazione industriale del software contemplando, alle volte senza approfondire, tutte le possibili implicazioni progettuali derivanti dai sistemi su cui il software avrebbe dovuto operare.
La cultura dell’uso del calcolatore elettronico, specialmente nella sua forma più nota che è quella del Personal Computer, è ormai diffusa in tutti gli ambienti di studio e di lavoro, anche molto lontani da quello tecnico – ingegneristico. L’apprendimento dell’uso del Personal Computer è facile e spesso capita che, dopo poche ore spese in compagnia di qualcuno che ne sa un po’ di più, il resto dell’apprendimento venga fatto senza altri supporti esterni, ma direttamente sul computer sfruttando la sua capacità di fornire su richiesta gli aiuti desiderati oppure ricorrendo a meccanismi di prova e riprova. Tranne rarissime eccezioni quindi, un giovane laureato, qualsiasi sia stato il suo indirizzo di studi, ha appreso l’uso delle applicazioni di base del Personal Computer, ossia è capace di gestire file, di produrre file di documenti di testo con una applicazione Word Processor, alle volte di fare calcoli con un’applicazione Spread Sheet e, nella maggioranza dei casi, anche di accedere, per mezzo di una applicazione Internet Browser, alla rete internet per reperire informazione, partecipare a gruppi di discussione, spedire e ricevere messaggi, ecc. Ovviamente tutto questo viene fatto avendo scarsissime conoscenze del modo in cui il computer opera, ossia di come il computer è internamente strutturato, sia fisicamente che logicamente.
Tutto ciò è abbastanza normale poiché il Personal Computer è uno strumento per il supporto all’esecuzione di determinate attività ed è stato pensato e realizzato proprio per rendere il più semplice possibile il suo uso come strumento. Secondo me però le cose cambiano quando si deve invece affrontare la progettazione del software. La conoscenza del computer solo come strumento non è più sufficiente, ossia è necessario, per poter lavorare con la coscienza di quello che si sta producendo, in modo da produrlo con la dovuta qualità ed efficienza, avere delle conoscenze, anche se non approfondite, dei meccanismi che stanno alla base del funzionamento del computer.
I Link che seguono permettono di acquisire i file delle slide utilizzate dal sottoscritto come supporto alle lezioni del corso di Fondamenti di Informatica 2 per Ingegneri Gestionali, tenuto nell'anno accademico 2001-2002 presso la Seconda Università di Roma "Tor Vergata". Gli obiettivi del corso erano quelli di fornire le basi per:
A tale scopo è stato utilizzato il linguaggio di programmazione C++. In particolare il programma del corso ha compreso i seguenti argomenti:
Le slide qui messe a disposizione potranno essere utilizzate come supporto per corsi analoghi, ma anche come strumento mnemonico per riacquisire alla mente nozioni che possono essersi sbiadite con il passare del tempo. Nella lettura delle slide c'è da notare che l’introduzione dei costrutti C++ di volta in volta utilizzati è stata fatta per mezzo di notazioni non formali che descrivono la struttura del costrutto in modo intuitivo. Questa notazione è normalmente poi seguita da uno o più esempi chiarificatori. La suddetta notazione non formale è costituita dai simboli e parole riservate C++ scritti così come devono apparire nel costrutto, mentre tutti gli altri elementi (costanti, variabili, etichette di qualsiasi tipo, ecc.) sono sostituiti da una definizione di poche parole legate l’una all’altra dal simbolo: _ (underscore) Ad esempio nel caso dell’assegnazione ad una variabile intera del valore restituito da una funzione, la notazione suddetta sarà: