Written by L’ingegneria è una disciplina che vuole applicare le conoscenze ed i risultati di altre discipline tecnico-scientifiche (principalmente le scienze matematiche, la fisica, la chimica e così via), per produrre sistemi e soluzioni in grado di soddisfare esigenze tecniche attraverso norme e metodologie di progettazione, realizzazione e gestione. Tali norme e metodologie fanno sempre riferimento in primo luogo alla creazione di un modello che costituisce la versione astratta ma razionalizzata del sistema da realizzare, facendo attenzione a mantenerne quegli aspetti caratteristici che consentano di studiarne prestazioni, affidabilità, comportamento e così via. E’ quindi chiaro come i modelli siano fondamentali nella loro funzione di descrivere in maniera semplificata ciò che si intende realizzare, ovvero sistemi generalmente complessi. Nel secolo scorso ha visto la luce una nuova disciplina ingegneristica: L’Ingegneria del Software. Essa si occupa dei processi produttivi e delle metodologie di sviluppo finalizzate alla realizzazione di sistemi software di qualità ottimizzando i costi. Si differenzia dall’Ingegneria dei Sistemi, in quanto quest’ultima si occupa in modo complessivo dello sviluppo di Sistemi Informatici, includendo quindi l’hardware, il software e il processo, mentre l’Ingegneria del Software si occupa della parte di questo processo di sviluppo riguardante lo sviluppo di software di qualità. Quindi laddove l’Informatica considera principalmente aspetti teorici, l’Ingegneria del Software si occupa dell’applicazione di tali principi teorici alla pratica dello sviluppo del software, non trascurando vincoli organizzativi e finanziari. Al fine di definire i requisiti del sistema in modo preciso e quanto più rigoroso possibile, questa disciplina ha iniziato a studiare come elaborare modelli che soddisfino questa esigenza e consentano di razionalizzare ed organizzare il processo di sviluppo per governare i team di lavoro. I tentativi in questo senso sono stati molteplici e sempre più orientati a facilitare la comunicazione tra i membri del team e tra il committente ed il team. In quest’ultimo senso, la difficoltà di comprensione tra il cliente che si aspetta la realizzazione un sistema con determinate caratteristiche ed il fornitore, che nella maggioranza dei casi riesce a produrre qualcosa di distanza siderale da tali aspettative, è divenuta oggetto di aneddoti e storie mitiche che potrebbero costituire il canovaccio per la sceneggiatura di film comici di sicuro successo al botteghino. Un po’ tutti in informatica ricordiamo la vignetta del progetto di realizzazione dell’altalena appesa al ramo dell’albero, che a seconda del punto di vista di chi era coinvolto nel processo produttivo, dal cliente al venditore, dall’analista al programmatore, veniva concepita in modi dall’improponibile al grottesco. Un bel giorno (del 1996 per la precisione), Grady Booch, Jim Rambaugh e Ivar Jacobson unificarono tutti gli approcci degli anni precedenti per la realizzazione di linguaggi di modellazione. Nasce così un linguaggio di modellazione unificato: lo UML (Unified Modeling Language), il cui standard è gestito da un consorzio di centinaia di aziende del settore, tra cui HP, Microsoft, SUN, Digital e OSF. UML, con la sua organizzazione in viste, tenta di fornire ai membri di un team di sviluppo software la possibilità di concentrarsi di volta in volta su particolari aspetti del sistema, in modo da essere più aderente possibile alle esigenze della data fase di sviluppo.
Ciò che spesso sfugge dell’UML è che anche se raccoglie in sé le migliore prassi adottabili per la modellazione, la funzione principale che svolge è quello di lingua franca nella comunità di progettazione e programmazione secondo il paradigma ad oggetti. Il tentativo è quello di dare descrizione delle soluzioni progettuali mediante un mezzo comunicativo che risulti più sintetico e comprensibile possibile. Nelle aziende però la carenza di conoscenza dell’UML da parte di molti membri dei team tecnici, siano essi dell’azienda committente o dell’azienda fornitrice, ne vanifica il ruolo e lo rende quasi osteggiato nei processi di qualità aziendali. L’UML non dovrebbe essere utilizzato in quanto standard industriale unificato o perché “trendy”, ma perché utile. E’ un valido aiuto, non una prassi consolidata a cui uniformarsi. Negli ultimi anni a causa del rastremarsi sempre più pronunciato dei margini di guadagno per le aziende di produzione del software (sì, sì, la crisi, la crisi…) l’approccio è sempre più orientato a cercare di produrre subito qualcosa che possa stare in piedi (in qualsiasi modo), saltando spesso a piè pari l’intero processo di modellazione ed iniziando immediatamente a scrivere codice. Nei casi più estremi si giunge addirittura a scrivere la documentazione (incluse le specifiche tecniche!) alla fine del progetto, quando ormai il sistema (se così si può chiamare ciò che è stato prodotto…) è in esercizio. E’ chiaro quindi che con questo approccio, quella dell’ingegnere del software specializzato nella modellazione dei sistemi tramite il Linguaggio di Modellazione Unificato, è vista come una figura superflua. Ovviamente la qualità del prodotto fornito al cliente degrada costantemente ed è solo a questo punto che ci si rende conto di quanto siano fondamentali la modellazione, la progettazione, la pianificazione…Si direbbe allora che la speranza sia da riporsi nella catastrofe, che opera di per sé una sorta di “selezione naturale” in grado di far emergere le eccellenze. In realtà però con ottimismo potremmo riporre tale speranza nel semplice buonsenso e negli insegnamenti dell’esperienza. Insomma, forse andrà tutto bene…