Ogni progetto avrebbe bisogno di una fase di inizializzazione in cui pianificare le risorse necessarie, selezionare le tecnologie e le metodologie, ecc.; fra queste scelte riveste un ruolo non secondario anche il modello di sviluppo da adottare.
L’esperienza personale e le letture (frutto dell’esperienza altrui) possono aiutare ad impostare correttamente tale aspetto cruciale di ogni progetto.
Circa tre anni fa, con altri due amici, abbiamo dato vita ad un progetto in pieno stile web 2.0: un aggregatore semantico di flussi informativi (feed RSS e non solo) con un sistema di ranking basato essenzialmente sulla taggatura dei contenuti.
Fra le nottate, i sabati e le domeniche passate a scrivere codice, gli interminabili brainstorming fra pizze e birre, gli scazzi e i momenti di esaltazione, quella esperienza è stata caratterizzata da una straordinaria intensità umana e professionale che ha travalicato anche i confini del progetto stesso.
L’architettura del sistema prevedeva tre diverse componenti inter-operanti. Sul piano tecnologico è stato facile individuare come soluzione ottimale per disaccoppiare le componenti realizzate da ciascuno, la definizione delle interfacce di comunicazione fra i tre sotto-sistemi; mentre una delle principali difficoltà affrontate è consistita nella condivisione di un modello di sviluppo e di organizzazione del ciclo di vita del progetto.
Le esigenze di sperimentazione legate all’elevato livello di innovazione caratteristico del progetto suggerivano un approccio di tipo agile che consentisse una continua verifica delle scelte adottate; d’altro canto l’inevitabile a-sincronicità con cui venivano portati avanti gli sviluppi richiedeva la definizione di un disegno progettuale comune (per quanto soggetto a radicali e frequenti cambiamenti) che fosse da guida nella realizzazione delle singole parti e garantisse l’unità di intenti. Come nelle migliori tradizioni della filosofia orientale, il caos creativo e l’ordine produttivo hanno continuato a fronteggiarsi e (s)bilanciarsi per tutto l’arco del progetto.
Il quesito, sopravvissuto al progetto, è se tali esigenze siano intrinsecamente inconciliabili o se esistano strumenti e modelli produttivi in grado di garantire la velocità di esecuzione e la frequente rimodulazione di un disegno progettuale definito.
Non credo esista una risposta universale a tale quesito, tuttavia è possibile identificare alcune classi di soluzione.
Le risposte “classiche” della software engineering si chiamano modello iterativo/prototipale e sviluppo basato su componenti. Tali approcci però si prestano bene a risolvere istanze specifiche di problemi già noti con soluzioni che sono in gran parte preconfezionate (sia nelle componenti di interfaccia che negli algoritmi adottati). Per quanto riguarda la velocità realizzativa, questa dipende molto dalla disponibilità e dalla qualità dei componenti riusabili; mentre per quanto riguarda la flessibilità nella rimodulazione del disegno progettuale, questa dipende molto dalle tecnologie scelte (dal loro uso corretto) e dall’IDE utilizzato per assemblare i componenti. Il risultato di tale modello produttivo finisce per assomigliare molto alla realizzazione di un prototipo (che diventa definitivo nella sua seconda o terza versione, ma non necessariamente esaustivo nei suoi requisiti iniziali) incentrato sui componenti che è stato possibile assemblare.
Un approccio alternativo che offre maggiore flessibilità è quello del Model Driven Engineering (o sue varianti come il Model Driven Architecture di OMG) in cui al centro del processo realizzativo viene posto il disegno progettuale (modello) del sistema definito in funzione del requisito di business espresso. Il sistema viene realizzato attraverso l’adozione di una serie di scelte implementative applicate alle diverse componenti del modello disegnato: tale processo realizzativo può essere concepito come una catena di trasformazioni del modello iniziale che integrano e raffinano il requisito di business fino a realizzare il sistema software (Business Driven Development). La velocità esecutiva consiste nella generazione automatica o semi-automatica dell’implementazione del modello, mentre la flessibilità è data dalla facilità di manipolazione del modello del sistema rispetto alla sua implementazione (che viene adeguata in maniera automatica o semi-automatica) in modo da assecondare agevolmente le rimodulazioni dei requisiti.
Una delle tecniche più semplici per implementare tale processo di trasformazione consiste nell’utilizzo di template di codice applicati ai metadati che descrivono formalmente il modello del sistema. Molti case UML (ex. StarUML, Enterprise Architect, ecc.) consentono di definire tali template all’interno del prodotto, così come di estendere il proprio metamodello per integrare le informazioni necessarie alla generazione automatica del codice.
L’automazione del processo di trasformazione del modello, oltre a ridurre drasticamente i tempi di codifica lasciando più spazio alla modellazione del sistema e all’individuazione delle soluzioni implementative più adatte, garantisce l’apllicazione coerente delle medesime soluzioni implementative nell’arco dell’intero progetto. A parità di funzionalità implementate il carico di lavoro (così come le professionalità richieste) si sposta nelle fasi alte del ciclo di sviluppo (analisi e progettazione); le track di sviluppo si scaricano delle attività di codifica più ripetitiva (applicazione stereotipata di patttern) a favore dello studio di soluzioni tecnologiche adeguate e dell’implementazione degli algoritmi e delle componenti per cui non è possibile o conveniente prevedere una generazione automatica del codice.
L’applicazione di tale modello produttivo risulta di grande utilità anche nell’ambito della realizzazione, in tempi ristretti, di prototipi funzionanti, nel momento in cui si dispone già di template e strumenti di analisi e progettazione collaudati. Con un ambiente di dimostrazione preconfigurato e gli strumenti adeguati si può condurre in pochi giorni (o ore) un intera iterazione progettuale dalla formulazione di un semplice requisito alla realizzazione di un sistema che ne implementi le principali funzionalità. Attività dimostrative di questo tipo possono essere condotte anche da un’unica figura professionale in grado di modellare un requisito e seguire le fasi di auto-generazione del sistema che lo implementa.