Come nasce il software

Viaggio tra specifiche e modelli di sviluppo, dall'idea al rilascio.

Come nasce un software? Come si organizza il lavoro? Quali buone pratiche si mettono in atto?

Che si tratti di un nuovo programma costruito da zero o dell’integrazione di un prodotto, lo sviluppo software è un lavoro complesso che prevede un’azione sistemica e corale di diverse figure, materie e competenze. In ambito IT  spesso ci si sofferma sugli aspetti tecnici: le scelte tecnologiche, gli ambienti di deploy o l’integrazione di device sono sicuramente una parte fondamentale della soluzione, ma non l’unica.

E’ necessario infatti orchestrare risorse, capacità, requisiti, vincoli al fine di generare un software che porti un reale valore all’interno delle aziende.

Il software: una questione sistemica

Facciamo un passo indietro e, per spiegare come nasce e evolve un programma, proviamo ad avvalerci di un esempio del mondo reale: la costruzione di una casa.

Da dove si comincia? Dall’architetto che realizza un progetto tenendo conto di desideri, necessità, vincoli ambientali e chiaramente budget. L’esempio è calzante: nelle fasi iniziali, infatti, siamo focalizzati sui processi di design. Analisi dei requisiti, documenti funzionali, costruzione di prototipi sono fondamentali per arrivare ad una consapevolezza profonda del contesto dei nostri clienti e proporre soluzioni efficaci.

Come per l’architetto, che mette nero su bianco perimetri, muri, finestre, stanze, anche noi nelle fasi preliminari del processo, andiamo a punteggiare le necessità, parlando un linguaggio comune e assicurandoci che design model e user model coincidano.

La metafora della casa è adatta anche sotto l’aspetto delle competenze: l’architetto non basta, servono (solo per citare alcuni esempi) ingegneri civili,  muratori, supervisori, idraulici, elettricisti, imbianchini, responsabili della sicurezza e in generale figure differenti con conoscenze verticali su un singolo aspetto di realizzazione dell’edificio. E’ facile immaginare in un cantiere le varie figure che si avvicendano: anche in questo caso la trasposizione con il nostro “cantiere del software” è facile. In un contesto sempre più complesso come l’Information Technology è fondamentale affidarsi a team multidisciplinari che trattino l’intero progetto in maniera sistemica e competente, senza tralasciare alcun aspetto.

Il processo: meno cascate, più modelli circolari

Se l’esempio del cantiere è perfettamente calzante per descrivere l’intero sistema, diventa meno pertinente quando ci addentriamo nei dettagli dello sviluppo. La costruzione di una casa è, infatti un tipico modello waterfall: le fasi si susseguono in maniera precisa dalle fondamenta alla posa degli infissi, ed è impossibile, per il cliente, sperimentare come si vivrà all’interno di quella casa, fino a che i lavori saranno ultimati.

Storicamente i modelli a cascata sono stati applicati alla produzione del software per molti anni. Ciascuna unità di esperti lavorava parte del problema e passava un semilavorato all’unità successiva, in stile catena di montaggio. Le fasi di testing venivano delegate alle parti finali del progetto e il cliente veniva a contatto con il software solo a lavori ultimati.

I modelli waterfall hanno un innegabile vantaggio: sono semplici da capire e da spiegare.
Ma questa semplicità determina due side effect disfunzionali:

  • non sono resistenti al cambiamento: quando le necessità cambiano è complesso e costoso gestire le modifiche (nella metafora della casa, provate a pensare quando può essere oneroso spostare un muro a lavori ultimati).
  • non sono verificabili  fino alla fine del processo: è difficile capire se il software prodotto sia effettivamente di valore per l’azienda e i suoi utenti

Per questo motivo oggi si parla di modelli circolari (iterativi, agili o incrementali a seconda delle necessità) dove lo sviluppo viene suddiviso in cicli che terminano con un delivery funzionante. Il software diviene quindi una soluzione in continua evoluzione, che l’azienda cliente può testare da subito e migliorare all’iterazione successiva.

Il software: una questione di cambiamento “ecologico”

C’è infine un ultimo aspetto da considerare: il cambiamento.

Ogni strumento nuovo, necessità di una fase di on-boarding da parte dell’azienda, modificando procedure e abitudini agli utenti.  Lavorando con realtà enterprise siamo molto attenti e gestire il ciclo di sviluppo in modo che il software sia “ecologico” per il sistema azienda.

Il riferimento all’ecologia si ispira al significato intrinseco del termine: così come un elemento ecologico non va a turbare l’equilibrio della natura, il software deve conservare la capacità di una azienda di essere produttiva anche nel momento di transizione da uno strumento ad un altro. Per questo i nostri prodotti, in ottica incrementale, sono pensati per adattarsi a piccole situazioni e scalare seguendo la naturale evoluzione delle necessità dell’azienda.

Ne è un tipico esempio Klan.IT EBR, la nostra soluzione per la tracciatura del Lotto (Batch Record) , che garantisce un approccio graduale, tenendo conto delle necessità delle aziende che vogliono innovare, minimizzando tempi e rischi. Un approccio flessibile alla costruzione del software ci permette di consegnare valore, rapidamente, distribuendo investimenti e funzionalità tra le iterazioni. 

Per conoscere in dettaglio le nostre soluzioni, scoprite la nostra Business Unit Enterprise e la nostra raccolta di Case History.

Newsletter

Lascia l’email: le nostre BU ti invieranno periodicamente news, attività e pillole tecnologiche per rimanere sempre aggiornato!