Sviluppo Software

simulazione
di una realtà
migliore

Riflesso della tua esperienza,
che trova nell’ordine e nella precisione 
un processo di sviluppo di successo

Sviluppo Software

simulazione
di una realtà
migliore

Riflesso della tua esperienza,
che trova nell’ordine e nella precisione 
un processo di sviluppo di successo

Sviluppo Software

simulazione
di una realtà
migliore

Riflesso della tua esperienza,
che trova nell’ordine e nella precisione 
un processo di sviluppo di successo

Il tuo modo di organizzare il lavoro è il riflesso della tua esperienza, sia lavorativa che culturale. Vale lo stesso per le tue relazioni con i clienti o con i colleghi: ognuno di noi ha un proprio processo di sviluppo e spesso riesce a trovare ordine e precisione soltanto seguendo il suo istinto.

La nostra storia cambia il processo di sviluppo

La struttura di un processo di sviluppo viene influenzata da vari fattori, come ad esempio le relazioni tra fornitore e committente, il sistema IT e quello di gestione delle risorse umane.
Questo significa che la modifica o innovazione di un processo deve tenere conto di questi aspetti, migliorando le situazioni critiche e senza stravolgere le parti più solide.

In informatica un modello di sviluppo software è il principio teorico che indica il metodo da seguire nel progettare e nello scrivere un programma. Il modello è alla base di una metodologia di sviluppo.
I modelli di sviluppo software simulano la realtà per vedere cosa accadrebbe e al fine di ridurre gli errori e ottimizzare prestazioni e risultati.

Sviluppo Software: il Modello a cascata e la struttura del processo

Le fasi principali del modello di sviluppo nascono tra gli anni ’60 e ’70, anche se con costi di manutenzione troppo elevati, dovuti alla rigidità dei processi.

In questo caso parliamo del modello a cascata, il ciclo di vita del software più tradizionale.

Il modello o ciclo di vita a cascata (waterfall model in inglese o waterfall lifecycle) è il primo modello di ciclo di vita del software: per la prima volta lo sviluppo viene visto come processo industriale, abbandonando quello “artigianale” che prevedeva una programmazione basata su tentativi ed errori. Il ciclo di vita a cascata, grazie al suo successo negli anni ’70, viene associato ancora oggi alla programmazione procedurale e strutturata.

Il “waterfall model” prevede un processo strutturato in sequenze lineari, composto da:

Analisi dei requisiti: viene deciso cosa farà il sistema secondo uno studio di fattibilità, dove vengono analizzati costi tecnici ed economici per capire se valga la pena realizzare il sistema con i suoi requisiti.

Progettazione: dopo aver stabilito (nella prima fase) lo scopo del sistema, si progetta la sua suddivisione in moduli, relazioni tra moduli comprese.

Sviluppo (o codifica): creazione dei moduli con un linguaggio di programmazione.

Collaudo: vengono fatte delle prove per verificare che i singoli moduli implementati funzionino.

Manutenzione: comprende le attività volte a migliorare, estendere e correggere il sistema nel tempo.

Un’organizzazione può formalizzare ulteriormente il processo imponendo vincoli sulla natura, sul formato e sulla struttura dei documenti prodotti nelle varie fasi, per poter analizzare meglio lo stato di avanzamento del progetto e la qualità del lavoro svolto.

Il modello a cascata è stato poi abbandonato dall’industria del software: negli anni 80 il software stesso si è evoluto, dando vita a nuovi linguaggi di programmazione, critiche e revisioni.

Questi cambiamenti hanno trasformato il modello a cascata in modello evolutivo, che prevede una prima fase più ridotta in grado di ottenere migliori requisiti, chiamata prototipazione.
Si è poi passati al modello trasformazionale, che approfondisce e migliora l’analisi dei requisiti per produrre alla fine un prototipo funzionale.

Sviluppo Software: analisi, svolgimento e attori coinvolti

Le varie fasi di un processo di sviluppo sono caratterizzate da ulteriori processi svolti all’interno; la prima fase prevede lo studio di fattibilità, che ha lo scopo di decidere se intraprendere il nuovo sviluppo.

Cliente e organizzazione aziendale sono gli attori coinvolti, coloro che producono il primo output.

Gli attori ricercano le soluzioni esistenti e individuano i problemi principali:

  • Analisi frettolose o fatte sotto pressione;
  • Analisi dei costi imprecisa per i continui rifacimenti
  • Decisioni premature che ostacolano lo sviluppo successivo
  • Analisi dei requisiti

Superati questi ostacoli, viene scritto un documento con diversi scenari e soluzioni, accompagnato da una discussione dei compromessi in termini di costi previsti e benefici: il documento di studio di fattibilità.

Con lo scopo di identificare e descrivere i requisiti (le caratteristiche del sistema), al cliente e all’organizzazione aziendale si aggiungono gli sviluppatori.

Gli attori coinvolti emettono un documento che descrive le caratteristiche del sistema, le esigenze dell’utente e la fattibilità per il progettista. Documento che deve essere preciso, completo, coerente e modificabile.

Successivamente viene definita la struttura di massima (architettura di alto livello), così come le caratteristiche dei singoli componenti (moduli).

L’individuazione dei componenti necessari e delle loro caratteristiche spesso comporta problemi riguardanti le numerose decisioni da prendere, le strutture diverse, le scelte non chiare e i test di modulo.

Una volta ottenuto un sistema funzionante, si passa all’Alpha test per la verifica e la validazione del processo.

I problemi tipici riguardano:

  • Analisi dei requisiti imprecisa
  • Manutenzione
  • Tutto ciò che accade dalla consegna del sistema alla sua dismissione

Il beta test viene svolto dagli utenti, che verificano il software. È un ciclo lungo che può essere suddiviso in:

Sviluppo Software: vantaggi e criticità del processo di sviluppo

Lo sviluppo di un software è cambiato rispetto a quello “a tentativi”, stabilendo due concetti principali:

  • Il processo di sviluppo del software deve essere soggetto a disciplina e pianificazione
  • L’implementazione del prodotto deve iniziare soltanto quando gli obiettivi sono perfettamente chiari

A semplificazione del controllo dell’andamento del progetto grazie a un ciclo di vita in fasi, rappresenta il vantaggio principale di questo metodo di lavoro.

Per ottimizzare il ciclo di vita, la scomposizione delle fasi ha due obiettivi:

  • Assegnare a ciascuna fase la soluzione di problematiche specifiche
  • Rendere le fasi indipendenti per parallelizzare le attività

Il modello è una semplificazione della realtà che deve però rispettare tre principi:

Linearità: spesso si hanno cicli di feedback per la correzione degli errori che devono essere lineari. Non si può saltare all’indietro per correggere, è necessario seguire la linea sequenziale.

Rigidità: quando si passa alla fase successiva, la fase precedente viene ufficialmente “superata”, motivo per cui clienti e sviluppatori non possono interagire dopo la parte iniziale;

Monoliticità: siccome il modello è orientato alla data di rilascio che spesso si pone a mesi o anni dopo l’inizio della prima fase, gli eventuali errori commessi o i cambiamenti  dei requisiti verranno corretti dopo la fase di consegna, rendendo il software già obsoleto con le modifiche che andranno fatte.

Un processo come questo comporta vari problemi, come ad esempio:

  • La difficoltà nella stima delle risorse e dei costi fino alla prima fase di analisi
  • La completezza del documento dei requisiti. L’utente spesso non può conoscere tutti i requisiti dell’applicazione, motivo per cui alla fase successiva si ha una documentazione poco chiara
  • Il modello obbliga a usare standard di documentazione in determinati momenti, burocratizzando il lavoro

Tutto questo riesce a spiegare gli alti costi del software, con le specifiche poco complete e i troppi interventi successivi per introdurre funzionalità non previste in partenza.

Per migliorare questo modello, sempre più aziende si stanno orientando verso il lavoro Agile.

Il processo Agile e lo sviluppo di software

Negli ultimi anni la produzione si è dovuta adattare a nuovi fattori, vedi la competizione elevata e le continue richieste di qualità e velocità. Fattori che hanno cambiato la natura dei progetti, rendendo insufficiente il management tradizionale.

Per aiutare le realtà meno forti a sopravvivere, sono state inventate tecniche evolute di project management: il metodo AGILE e SCRUM.

Il metodo Agile (Lightweight methodologies) nasce nell’IT a metà degli anni ’90 per mostrare un’evoluzione rispetto al tradizionale metodo Heavyweight.

I principi fondamentali di un processo Agile sono: 

  1. Persone e interazioni più che i processi e gli strumenti
  2. Il software funzionante più che la documentazione esaustiva
  3. La collaborazione col cliente più che la negoziazione dei contratti
  4. Rispondere al cambiamento più che seguire un piano

L’idea del Metodo Agile si basa sulla possibilità di realizzare un progetto per fasi, chiamate “sprint”. Ogni sprint corrisponde a un output, con l’introduzione di una nuova funzionalità verificata dal cliente, che vede il lavoro svolto fino a quel punto.
Questo sistema consente di modificare facilmente il progettoabbattendo i costi di produzione ed evitando il fallimento del progetto.

Scrum è il metodo Agile più diffuso, soprattutto nei progetti complessi. Il processo di gestione di un progetto in sprint viene diviso per poter coordinare il processo di sviluppo del prodotto insieme al cliente. Solitamente gli sprint durano da 2 a 4 settimane.

Questo metodo nasce per controllare i processi dove la conoscenza deriva dall’esperienza e le decisioni vengono prese seguendo ciò che si conosce. Sprint dopo sprint, il metodo Scrum aumenta la prevedibilità ed il controllo del rischio.

Le componenti principali di SCRUM si dividono in: ruoli, artefatti ed eventi.

In uno Scrum Team ci sono tre ruoli, che lavorano insieme per un continuo e veloce flusso di informazioni.

SCRUM MASTER: il responsabile del processo, deve garantire che il processo venga eseguito con successo. Il team deve lavorare in maniera coerente eliminando ostacoli esterni.

PRODUCT OWNER: conosce tutti i requisiti del prodotto e porta avanti gli interessi del processo. Deve massimizzare il valore del prodotto e del Team di Sviluppo.

TEAM DI SVILUPPO: il gruppo di professionisti che si occupa dello sviluppo del prodotto e del testing delle funzionalità, organizzando le priorità per portare a termine un determinato sprint.

Gli artefatti sono 3, progettati per avare più informazioni chiave e monitorare il processo.

PRODUCT BACKLOG: documento con i requisiti necessari per la realizzazione del progetto. Il Product Owner è responsabile del contenuto e della disponibilità.

SPRINT BACKLOG: documento con le task da completare negli sprint. Viene definito il lavoro necessario per raggiungere gli obiettivi dello sprint.

INCREMENTO: la somma degli elementi del Product Backlog completati durante uno sprint e quelli precedenti. L’incremento, in base agli accordi col team di Sviluppo, dovrà garantire un prodotto utilizzabile.

Gli eventi principali in Scrum sono 4, creati per sincronizzare le attività e ridurre al minimole difficoltà. L’obiettivo è quello di monitorare l’andamento del progetto in modo chiaro e preciso.

SPRINT PLANNING: il Product Owner stila il Product Backlog e, insieme al Team di Sviluppo e allo Scrum Master, individua l’obiettivo da raggiungere nello sprint seguente. Al termine della riunione lo Scrum Master può compilare lo Sprint Backlog.

DAILY SCRUM: un breve “Stand up meeting”, un confronto giornaliero (della durata di 15 min) fra il Team di Sviluppo e lo Scrum Master, nel quale si analizzano le attività del giorno precedente e si espongono le attività imminenti della giornata, compresi problemi o difficoltà.

SPRINT REVIEW: una revisione dopo ogni sprint per capire se e come è stato raggiunto l’obiettivo. Partecipa tutto lo Scrum Team e il committente del prodotto, che analizzerà il lavoro svolto fino a quello sprint.

SPRINT RETROSPECTIVE: un’ulteriore analisi di tutto lo Scrum Team per valutare cosa continuare, cosa smettere di fare e cosa migliorare nello sprint successivo.

Queste metodologie, applicate alla produzione di software, diventano vantaggiose per ogni sistema aziendale che deve gestire progetti innovativi e complessi.

Ancora una volta, prima delle macchine, dei processi e degli strumenti, ci sono le persone.

Partner Tecnologico

logo Microsoft - Sviluppo Software