Ponti, edifici e software

2 febbraio 2012 § 6 commenti

Fonte: rebaz007

Le metafore sono uno strumento eccezionale per comprendere rapidamente un concetto, creando una corrispondenza tra quello che conosciamo e quello che vogliamo conoscere. Nell’informatica si fa un grande uso di metafore, ma come talvolta accade, non sempre sono del tutto calzanti. Una di queste, in verità molto abusata, accosta lo sviluppo del software alla costruzione di ponti o edifici.
Probabilmente a primo acchito questa metafora rende l’idea a chi è proprio all’oscuro dellle problematiche di sviluppo del software, ma ad una attenta analisi essa risulta del tutto inadeguata e fuorviante.

Un edificio è qualcosa di fisico, tangibile, rigido per natura. Una volta costruito non è facile apportarvi modifiche strutturali, spostare un muro, costruirvi un altro piano sopra o un parcheggio sotto le fondamenta. Una volta definito il progetto, certe modifiche in corso d’opera risultano impossibili o troppo costose. Dopo la realizzazione non è possibile intervenire sui materiali usati, sulle tecniche di costruzione per migliorarlo o per adeguarlo a nuove esigenze.

Un software invece è un sistema flessibile, malleabile, adattabile, in evoluzione continua per esigenze dell’utente e/o dello sviluppatore. Proprio questo aspetto soft è allo stesso tempo il pregio e il difetto (in senso lato) del software.

Qualcuno ha suggerito metafore alternative per catturare questa natura evolutiva del software associandolo all’urbanistica o al giardinaggio o ad altre discipline. In ogni caso, ogni metafora lascia sempre, per sua natura, qualcosa di non definito.

Ma riflettiamo un attimo. Se vado da un ingegnere perchè voglio che mi progetti una casa, io sto chiedendo di fare qualcosa che lui sa fare bene. Lui sa come progettare edifici. Conosce le leggi della fisica e la normativa edilizia.

Se vado da uno sviluppatore e gli chiedo di realizzare un software per la gestione della contabilità di un ente pubblico, lo sviluppatore può anche essere preparatissimo da un punto di vista tecnico, ma deve in ogni caso avvicinarsi alla conoscenza della contabilità degli enti pubblici. In altre parole, alle variabili tipiche della propria attività si aggiungono le variabili legate alla conoscenza del dominio del problema.

Se volessimo mantenere in qualche modo l’analogia con l’edilizia, sarebbe come se un ingegnere volesse costruire un edificio senza conoscere a fondo le leggi della fisica. Sarebbe costretto a sperimentare soluzioni senza poter dare un adeguata garanzia di successo.

Lo sviluppo del software è più simile alla sperimentazione, alla ricerca di una soluzione in mancanza di una conoscenza completa del dominio del problema. Mentre l’ingegnere edile ha sotto controllo tutte le variabili del problema, l’ingegnere del software deve colmare la lacuna della conoscenza approfondita del problema che deve gestire.

Alla mancanza di conoscenza si aggiunge il problema della comunicazione con l’utente, non sempre chiara e trasparente, e la mutevolezza delle specifiche iniziali, talvolta nemmeno chiare all’utente stesso.

Il tutto si traduce in un alto grado di incertezza, un po’ come nella ricerca scientifica. Incertezza da gestire accuratamente e tempestivamente mettendo al centro dell’attività di sviluppo la comunicazione.

D’altronde tutto nel software ruota intorno alla comunicazione, a partire dal linguaggio di programmazione.

Annunci

Tag:, , , , , , , , ,

§ 6 risposte a Ponti, edifici e software

  • tenstepit ha detto:

    Mi permetto di dissentire dalla frase sopra: “Un software invece è un sistema flessibile, malleabile, adattabile, in evoluzione continua per esigenze dell’utente e/o dello sviluppatore.”
    Concordo che un software non è una costruzione, mentre sono paragonabili le rispettive progettazioni e documentazione di progetto. Però, non direi mai che “un software è sistema flessibile, malleabile, adattabile”. Quando il codice software entra nel sistema ne diventa parte integrante come il cemento o la calce nelle costruzioni. Un modulo software, in produzione, è intoccabile, pena il crollo del sistema stesso, proprio come una trave in una costruzione. Quando un software è stato collaudato, consegnato e reso operativo è simile al cemento armato.
    Il software deve garantire quello che ha promesso e ci riesce solo se è protetto, qunidi intoccabile. Eventuali esigenze manutentive producono un nuovo software, da collaudare nuovamente e rimettere in produzione. Pensiamo al software die conti correnti e immaginiamo cosa accadrebbe se lo sviluppatore ci mettesse le mani a suo piacimento.
    Forse corriamo troppo! Una volta, nell’era dell’elaborazione dati, i sistemi software di produzione erano logicamente e fisicamente separati dai sistemi di sviluppo. Dovrebbe valere anche nell’era informatica, o no?
    Dopo anni di attenzione all’integrità ed alla riservatezza dei dati, sarei preoccupato se il software fosse un sistema adattabile alle esigenze di utente e/o sviluppatore.
    Vito Madaio, PMP
    TenStep Italia

    • Andrea Chiarelli ha detto:

      Probabilmente abbiamo esperienze diverse o forse abbiamo un modo differente di intendere l’evoluzione di un software.

      Dal mio punto di vista la manutenzione di un software, correttiva o evolutiva che sia, rappresenta l’evoluzione dello stesso software, non un nuovo software.

      Non mi è chiaro poi cosa intendi con “Un modulo software, in produzione, è intoccabile, pena il crollo del sistema stesso”.
      Vuol dire che una volta realizzato quel modulo non è più possibile apportarvi modifiche?!? Mi sembra una cosa più unica che rara… 🙂

  • Vito Madaio ha detto:

    Gentile Andrea,
    Non volevo essere invadente, ma sicuramente abbiamo esperienze diverse, compreso il linguaggio se non ti risulta il concetto di “modulo software”: uno o più programmi gestiti insieme.
    A parte questo, ciò che volevo evidenziare è che un software in produzione ha la responsabilità di funzionare sempre esattamente come un muro portante o un tramezzo in un edificio, quindi non può essere adattabile o flessibile.
    L’esigenza di manutenzione, sarà una richiesta di modifica assoggettata ai processi di change management dell’ambiente. La realizzazione darà luogo ad una nuova versione di qeul software che sostituirà la versione in produzione solo dopo il collaudo e l’accettazione. Se tutto ciò ti sembra strano, stiamo parlando di cose diverse. Purtroppo, spesso questi passi vengono saltati o ignorati, agendo direttamente sul software in produzione con evidenti rischi per l’integrità dei dati e dell’affidabilità dei sistemi. Spero di essere stato più chiaro adesso.

  • Andrea Chiarelli ha detto:

    Vito, il concetto di modulo software mi è abbastanza chiaro (almeno credo…:-)).
    Da quello che scrivi mi sembra che ci sia un misunderstanding sulle modalità di gestione del software.
    Io non ho mai detto che le modifiche vadano fatte direttamente sull’istanza del software in produzione. Ci mancherebbe altro. Anche perchè se il software è compilato non vedo come intervenire direttamente, a meno di non volersi fare proprio del male…

    Come software intendo (e non credo di essere il solo) l’intero progetto costituito da codice sorgente, documentazione tecnica, test unitari, di integrazione, di accettazione, ecc.
    Ecco, questo materiale lo considero molto più “flessibile, malleabile, adattabile” di un edificio o un ponte.
    Fare una modifica o un’integrazione a questo materiale (compresi i test) e generare il prodotto che andrà in produzione credo sia molto più agevole che apportare modifiche ad un edificio o ad un ponte.
    Mi sbaglio?

  • Vito Madaio ha detto:

    Andrea, non ti sbagli affatto. E’ a questo che volevo arrivare. Il tutto è nato dal voler fare analogie tra sistemi software e ponti, edifici, etc.
    La mia provocazione se vuoi è che non bisogna ritenere flessibile o adattabile un software solo perchè ha meno fisicità di un edificio.
    Toccare un software senza le dovute precauzioni può causare dei danni immensi. Pensa ai disservizi di alcuni enti pubblici fermi per intere giornate perchè qualcuno aveva modificato (ricompilato) qualcosa direttamente in produzione senza passare per i test ed il collaudo. Purtroppo, oggi ci sono molti più garibaldini dal mouse facile e i risultati si vedono.
    Saluti.
    Vito

    • Andrea Chiarelli ha detto:

      Sinceramente davo per scontato che la gestione del software sia di tipo professionale.
      Il mio ragionamento era più incentrato sulla natura stessa del software che si presta ad una evoluzione più dinamica rispetto a quella delle costruzioni di ingegneria civile.
      E’ naturale che se non applichi alcun accorgimento per tenere sotto controllo quello che stai facendo rischia di crollare tutto…
      Grazie per il tuo contributo.

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

Che cos'è?

Stai leggendo Ponti, edifici e software su Andrea Chiarelli.

Meta

%d blogger hanno fatto clic su Mi Piace per questo: