L'approccio allo sviluppo del software

Lo sviluppo del software dovrebbe essere un'attività attentamente progettata e program-mata. Non si dovrebbe concentrare l'attenzione solamente sul problema e sulla sua solu-zione, ma anche su come raggiungere la comprensione di questi due aspetti. Bisogna in sostanza pensare a quello che si sta facendo. Lo scopo di questo paragrafo è quello di de-scrivere una serie di concetti che forniscono un aiuto per pensare in modo cosciente alle azioni che solitamente si compiono nello sviluppo del software, spesso anche solo per da-re dei nomi per dei concetti utilizzati non in modo articolato e consapevole.

Approccio ingegneristico allo sviluppo del software

Lo sviluppo del software può essere visto come la costruzione di una macchina. Non si costruisce fisicamente una macchina, ma si descrive e si costruisce il comportamento e le proprietà che la renderanno utile per alcuni scopi particolari. Un computer general-purpose prende questa descrizione - il codice del programma - e trasforma se stesso nella macchina special-purpose descritta.
Per tale ragione lo sviluppo del software può essere visto come un processo ingegneristico, cioè un'attività il cui scopo è quello di costruire "cose" che servono per un obiettivo chiaramente identificabile.
Ad un livello generale, la relazione tra il sistema software e il suo ambiente è chiara: il sistema è la macchina introdotta nel mondo e ha effetti su una parte di questo. Quella par-te del mondo sulla quale il sistema ha effetti è chiamata dominio dell'applicazione o dominio del problema, ed è costituito dai concetti comuni agli utenti dell'applicativo (occorre distinguere tra dominio dell'applicazione e ambiente, che indica ciò che fisicamente circonda la macchina). E' tramite i concetti espressi in tale dominio che committente e progettista software possono comunicare per chiarire gli scopi della macchina e le sue interazioni con il mondo. La descrizione della macchina e dei suoi effetti sono compiuti in termini di quello che è chiamato dominio della soluzione.
La distinzione tra macchina e dominio dell'applicazione è la chiave della distinzione tra il pluricitato "what and how": what indica quello che il sistema fa nel dominio dell'applicazione, how indica come dovrebbe essere fatta la macchina.
Il problema è nel dominio dell'applicazione, la macchina è la soluzione. Occorre quindi identificare e conoscere chiaramente il dominio dell'applicazione e su questo cercare di comprendere a fondo il problema (what?). Il passo successivo è quello di costruire la macchina (how?) che consente di risolvere tale problema.

Mettere a fuoco i problemi

L'incapacità dei progettisti software a discutere esplicitamente e chiaramente i problemi è forse una delle più gravi cause dell'attuale crisi del software. Il pericolo è quello di svi-luppare un sistema software lasciando il problema poco esplorato e poco chiarito. Una domanda molto semplice che è possibile porsi durante il processo di sviluppo del sistema è la seguente: se questa è la soluzione, qual è il problema? Purtroppo la tendenza umana è quella di focalizzare l'attenzione sulla soluzione; molti progetti falliscono perché i requisi-ti non sono stati attentamente esplorati: occorre tenere presente che i requisiti sono loca-lizzati nel dominio dell'applicazione (come il problema).
La tendenza a focalizzare l'attenzione sulla soluzione ha conseguenze ancora più gravi quando né il dominio dell'applicazione né il problema sono chiari alla stessa committen-za; e questo è stato l'aspetto più critico del progetto VAMP. Compito ulteriore del progettista software è allora quello di cercare di indirizzare i committenti nella preliminare esplorazione del problema, anche mediante interventi propositivi di alcuni particolari aspetti del dominio dell'applicazione e del problema (di sua competenza), così come descritto nei capitoli che seguono. Per rendere più efficace l'azione del progettista in queste situazioni critiche, è necessario che questi abbia chiari i concetti di requisito, specifica e programma.

I requisiti, le specifiche e il programma

I requisiti sono una descrizione del problema in termini di relazioni tra i fenomeni del dominio dell'applicazione, quindi utilizzando espressioni comprensibili dagli utenti dell'applicativo (tralasciando i termini del mondo dell'informatica). Ad esempio, volendo descrivere un ascensore (il dominio dell'applicazione è quindi quello del mondo degli a-scensori), se un utente sale al terzo piano per spostarsi al settimo, preme il relativo tasto e durante il movimento si dovranno accendere le luci dei piani intermedi, oltre alla luce di una freccia che indica la direzione. L'ascensore dovrà inoltre fermarsi alla giusta altezza, in modo da consentire una confortevole discesa dei passeggeri, e la porta dovrà rimanere aperta un tempo sufficiente. Ma la macchina può assicurare che i requisiti siano soddisfatti perché condivide alcuni fenomeni (eventi o stati) con il dominio dell'applicazione. Ad esempio, la pressione del tasto "sette" implica anche l'attivazione di una particolare linea della macchina. Tuttavia, non tutti i fenomeni sono condivisi (ad esempio, non è necessario che la macchina registri la salita o la discesa dei passeggeri): questo apre un gap tra i requisiti e quello che la mac-china può fare, poiché i requisiti non sono limitati dai fenomeni condivisi con la macchi-na, come mostrato in Figura 1.

Figura 1: i requisiti, le specifiche e il programma

A è l'insieme di tutti i fenomeni del dominio dell'applicazione, M è l'insieme dei fenome-ni della macchina. A intersect M sono i fenomeni condivisi. I requisiti sono quindi descritti in termini di A (e potrebbero quindi coinvolgere anche fenomeni non condivisi con la macchina). Il programma è scritto in termini di M (che presenta anche fenomeni solo interni alla macchina).
E' possibile pensare la progressione dai requisiti al programma come un modo per colmare il gap presente tra la macchina e il dominio dell'applicazione. Infatti, dai requisiti (espressi in termini di A) è possibile derivare un insieme di specifiche, espresse in termini di A intersect M. Il programma è quindi derivato da tali specifiche.

Il punto di vista

Perché è utile la distinzione tra requisiti, specifiche e programma precedentemente introdotta? Una delle maggiori difficoltà che un progettista software può incontrare nella gestione e sviluppo di sistemi complessi è il continuo cambiamento di punto di vista che egli deve operare. Infatti, nel rapporto con la committenza egli dovrà ragionare in modo da stabilire una comunicazione con questa (e quindi utilizzare termini specifici del dominio dell'applicazione, cioè in termini di requisiti), mentre nella realizzazione della macchina, dovrà utilizzare i concetti dell'informatica. Il punto d'incontro tra i due punti di vista è costituito dalle specifiche.
Lavorando all'interno del progetto VAMP si è comunque visto che limitare i punti di vista a quelli appena citati è sicuramente limitativo. Infatti, vista la particolare complessità del problema e la non chiarezza di dominio dell'applicazione e del problema, per mettere a fuoco i problemi è stato anche necessario adottare il punto di vista del progetto: se si considera il progetto VAMP come un'entità autonoma, esso dispone di propri obiettivi, molto chiari, e descritti nei rapporti tecnici (e lo staff del progetto può essere visto come il veico-lo per la realizzazione di tali obiettivi). In base all'esperienza fatta si è visto che l'utilizzo di questo punto di vista nelle discussioni con la committenza ha portato in molti casi alla realizzazione di risultati condivisi e accettati dall'intero staff.

Un altro punto di vista molto importante per il successo del progetto è quello degli utenti del sistema VAMP. Per utente s'intende un qualunque soggetto economico (come imprese edili e di demolizione) che ha interesse a partecipare al progetto. La capacità dell'Ingegnere Informatico di adottare anche questo punto di vista (e quindi di "mettersi dalla parte" di chi deve utilizzare il software) è molto importante per il successo di un qualsiasi progetto, mentre spesso questo aspetto è trascurato. L'Ingegnere Informatico dovrebbe quindi essere abbastanza flessibile da cambiare conti-nuamente punto di vista, a seconda dell'interlocutore e dello scopo prefisso. Deve quindi avere sempre chiaro lo scopo del lavoro che sta svolgendo.

Oltre l'approccio ingegneristico

Sulla base delle discussioni precedenti, è immediato dedurre che il giusto approccio allo sviluppo del software non può essere semplicemente ingegneristico. Tale approccio è necessario (in questo modo è possibile identificare e descrivere dominio dell'applicazione, problema e macchina), ma non sufficiente per lo sviluppo di un sistema software con adeguati standard qualitativi. Un giusto approccio deve anche curare la comunicazione con la committenza e con tutti gli individui che, a qualunque titolo, entrano a far parte del progetto e del processo di sviluppo del sistema informatico. Ad esempio, il rapporto di comunicazione con la committenza non deve riguardare solo i protocolli di comunicazione e l'utilizzo di terminologia del dominio dell'applicazione, ma deve anche riguardare gli aspetti psicologici: occorre in sostanza cercare di capire chi si ha di fronte, altrimenti nessun modo di comunicazione potrà permettere di superare le inevitabili barriere che si verrebbero a creare tra committenza e informatici; e la mancata o errata comunicazione è il primo passo verso l'insuccesso del progetto.
Di fatto, le considerazioni qui presentate evidenziano che lo sviluppo del software è più un'attività intellettuale che industriale; la ripetibilità del processo è molto importante, ma il prodotto software si migliora prima intervenendo sulle persone che concorrono alla sua definizione e sviluppo, e poi sul processo. Occorre rilevare che questa visione è abbastanza diversa da quella oggi predominante che vede nel miglioramento continuo del processo la chiave di volta per la produzione di software di qualità.

© 2001 Andrea Bulgarelli

[ Successiva ]