02 · Ciclo di Vita

Attività Centrali del Software

Indipendentemente dal modello di ciclo di vita scelto, lo sviluppo del software ruota sempre attorno a quattro attività fondamentali, che ora andiamo a dettagliare:

1. Specifica (Requisiti)

Questa fase si suddivide in tre sotto-attività:

Elicitazione: Scoprire cosa si aspetta realmente il cliente (interviste, analisi).
Specifica: Definire in dettaglio e formalizzare i requisiti raccolti.
Convalida: Verificare con il cliente che i requisiti specificati siano corretti e completi.

2. Sviluppo (Design e Codice)

La progettazione si articola su quattro livelli (Architettura, Dati, Interfacce, Componenti), a cui segue l'implementazione vera e propria (programmazione e debugging).

3. Convalida (V&V e Testing)

Dimostra che il sistema fa ciò che il cliente vuole. La fase principale è il Testing (V-model):

Test di sviluppo (unitari/componenti).
Test di sistema (integrazione).
Test di release/utente (accettazione).

4. Evoluzione

Modifica del software per adattarsi ai cambiamenti. Oggi, la linea di separazione netta tra "nuovo sviluppo" e "manutenzione" è irrilevante: il software è in continua iterazione.

Modelli di Processo: Waterfall vs Agile

I processi software possono essere strutturati in diversi modi. Il modello Waterfall (a cascata) è un approccio lineare sequenziale dove ogni fase deve essere completata prima che inizi la successiva. Sebbene facile da gestire, è molto rigido verso i cambiamenti.

Al contrario, l'approccio Agile è basato su cicli iterativi e incrementali. Il prodotto viene costruito e rilasciato in piccoli incrementi, permettendo al team di adattarsi rapidamente ai cambiamenti e di ottenere feedback continuo.

Modello Waterfall

Ogni fase orizzontale blocca la successiva. Nessun task funziona finché non finisce tutto.

TASK 1

TASK 2

TASK 3

Modello Agile (Sprints)

Ogni slot (Sprint) elabora un intero pacchetto di Task (non tutto!), riempiendosi completamente e diventando subito operativo.

SPRINT 1

SPRINT 2

SPRINT 3

Requisiti

Design

Sviluppo

Test & Release

È fondamentale non confondere i termini Task e Sprint. Vediamoli nel contesto dello sviluppo di un videogioco (es. un clone di Super Mario):

Le Task (o User Story): Rappresentano il "Cosa". Sono le singole funzionalità da costruire.
Esempio: "Far saltare Mario", "Disegnare il fungo", "Programmare la musica".
Lo Sprint: Rappresenta il "Quando". È semplicemente una scatola di tempo fisso (es. 2 settimane) in cui il team decide di inserire un certo numero di Task.

Nel diagramma in alto, lo Sprint 1 dell'Agile racchiude al suo interno tante piccole Task (es. far muovere il personaggio). In quelle 2 settimane, il team scrive i requisiti, disegna, programma e testa tutte quelle Task. Risultato: dopo 14 giorni hai un prototipo funzionante giocabile (Release).

Nel Waterfall, invece, le Task sono i singoli componenti hardware (RAM) che si riempiono orizzontalmente. Passeresti 6 mesi interi (Requisiti e Design) solo a scrivere documenti per tutte le 10.000 Task del gioco, senza avere in mano nulla di effettivamente giocabile fino all'ultimo mese di Sviluppo.

Questo modello non crea il software da zero, ma assembla componenti esistenti sul mercato (COTS - Commercial Off-The-Shelf).

Fasi chiave: Specifica (valutazione componenti sul mercato), Progettazione (configurazione e adattamento dei moduli), Convalida e Manutenzione.
Pro: Drastica riduzione dei costi, dei rischi e dei tempi di consegna.
Contro: Compromessi inevitabili sui requisiti (ci si deve adattare a ciò che fa il componente) e perdita di controllo sull'evoluzione futura del modulo riutilizzato.

Elementi e Gestione del Processo

Un processo software non si limita a elencare le attività da svolgere. Per descriverlo compiutamente bisogna definire:

Prodotti (Products)

I risultati concreti di un'attività (es. un documento dei requisiti, un diagramma o un eseguibile).

Ruoli (Roles)

Le responsabilità delle persone coinvolte nel processo (es. Project Manager, Sviluppatore, Tester).

Pre e Post-condizioni

Le dichiarazioni che devono essere vere prima di iniziare un'attività e dopo averla conclusa con successo.

Un esempio pratico perfetto di questi tre concetti si trova nella stesura e gestione di una User Story (metodologia Agile):

Il Prodotto È la User Story scritta (es. "Come giocatore, voglio poter salvare la partita...").
I Ruoli Il Product Owner scrive la storia, lo Sviluppatore la implementa, il Tester la verifica.
Pre-condizione Cosa deve essere vero prima di iniziare? (es. "Il sistema di login cloud deve essere già funzionante").
Post-condizione Sono i famosi Acceptance Criteria (Criteri di Accettazione). Affinché la task sia considerata finita, il sistema deve trovarsi in un nuovo stato "Il file di salvataggio è generato sul cloud e il menu mostra il tasto 'Continua'".

Il cambiamento nei grandi progetti è inevitabile (nuove regole di business, nuove tecnologie) e porta sempre a costi aggiuntivi. Per gestirlo si usa lo Sviluppo e Consegna Incrementale:

Il sistema viene diviso in incrementi, dando priorità ai requisiti di maggior valore per il cliente.
Una volta iniziato lo sviluppo di un incremento, i suoi requisiti vengono "congelati", mentre quelli successivi possono evolvere.
Problemi dell'approccio: È difficile identificare all'inizio le basic facilities (strutture base) che serviranno a tutti gli incrementi. Inoltre, l'approccio iterativo entra spesso in conflitto con i modelli di appalto contrattuale aziendali classici, che richiedono specifiche complete e rigide prima di iniziare i lavori.

Metodologia Agile, Scrum e XP

Il Manifesto Agile pone l'accento sugli individui e le interazioni, sul software funzionante, sulla collaborazione con il cliente e sulla risposta al cambiamento. Scrum è il framework Agile più diffuso per implementare questi principi, strutturando il lavoro in iterazioni a tempo fisso dette Sprint (solitamente 2-4 settimane).

block-beta
  columns 7
  
  block:PBBlock:1
    columns 1
    PTitle("Product Backlog
(PO)")
    P1[" "]
    P2[" "]
    P3[" "]
    P4[" "]
  end

  space:1

  block:SBBlock:1
    columns 1
    STitle("Sprint Backlog
(Dev Team)")
    S1[" "]
    S2[" "]
  end

  space:1

  block:SprintBlock:1
    columns 1
    S(("SPRINT
1-4 Settimane"))
    D(("Daily 24h"))
  end

  space:1

  block:IncBlock:1
    columns 1
    ITitle("Valore Rilasciato")
    INC["Incremento"]
  end

  PBBlock -- "Sprint Planning" --> SBBlock
  SBBlock --> SprintBlock
  SprintBlock -- "Review & Retro" --> IncBlock

  classDef transparent fill:transparent,stroke:none,color:#fff
  classDef slot fill:#475569,stroke:none
  classDef slotSprint fill:#7c5cfc,stroke:none
  classDef circleSprint fill:transparent,stroke:#7c5cfc,stroke-width:4px,color:#fff
  classDef circleDaily fill:transparent,stroke:#10b981,stroke-width:4px,color:#fff
  classDef inc fill:#10b981,stroke:none,color:#000
  classDef container fill:#334155,stroke:#475569,stroke-width:2px
  
  class PTitle,STitle,ITitle transparent
  class P1,P2,P3,P4 slot
  class S1,S2 slotSprint
  class S circleSprint
  class D circleDaily
  class INC inc
  class PBBlock,SBBlock container
  class SprintBlock,IncBlock transparent

Scrum si basa su tre pilastri fondamentali: trasparenza, ispezione e adattamento. Per garantire che il framework funzioni, sono definiti ruoli, eventi e artefatti specifici:

Product Owner (PO): Massimizza il valore del prodotto. È l'unico responsabile della gestione del Product Backlog (aggiunta, rimozione, prioritizzazione).
Scrum Master: È un "servant leader". Si assicura che il team comprenda e applichi correttamente Scrum e rimuove gli ostacoli (impediments) che frenano il team.
Development Team: Un team autorganizzato e cross-funzionale. Nessuno dice loro *come* trasformare il Backlog in Incrementi funzionanti.

Sprint: Il contenitore di tutti gli altri eventi. Una time-box fissa in cui viene creato un incremento "Done".
Sprint Planning: Si pianifica il lavoro. Il PO spiega gli obiettivi, il Team seleziona gli elementi e definisce *come* li realizzerà.
Daily Scrum: Un meeting giornaliero di 15 minuti del Dev Team per ispezionare il progresso verso l'obiettivo dello sprint e adattare il piano per le 24 ore successive.
Sprint Review: Si mostra l'incremento agli stakeholder per ottenere feedback e si adatta il Product Backlog se necessario.
Sprint Retrospective: Il team ispeziona se stesso, identificando cosa è andato bene e cosa può essere migliorato nel processo per lo Sprint successivo.

I 3 Artefatti

Product Backlog

La lista infinita e ordinata per priorità di tutto ciò che serve al sistema. Il suo scopo finale è raggiungere il Product Goal (l'obiettivo a lungo termine).

Sprint Backlog

Un "pacchetto" estratto dal Product Backlog, su cui il team si impegna a lavorare nello Sprint corrente. Ha un suo Sprint Goal chiaro e fisso.

Incremento

Il risultato tangibile e funzionante rilasciato a fine Sprint. Per essere rilasciato, deve rispettare severamente la Definition of Done (DoD).

Extreme Programming (XP)

L'Extreme Programming è un'altra metodologia Agile fortemente orientata alla qualità del codice sorgente e al team working.

Pratiche fondamentali includono:

Test-Driven Development (TDD): Scrivere i test automatici prima di scrivere il codice di produzione.
Refactoring continuo: Migliorare costantemente la struttura del codice senza alterarne il comportamento esterno.
Pair Programming: Due programmatori lavorano insieme su un singolo computer, uno scrive (Driver) e l'altro revisiona (Observer), riducendo drasticamente il numero di bug.

L'Impatto dell'Intelligenza Artificiale nel Ciclo di Sviluppo

Un focus critico nello sviluppo moderno è come l'AI stia agendo da "assistente" in ogni fase del ciclo di vita. Il cambio di paradigma è totale: l'enfasi si sposta dalla scrittura della sintassi (eseguita dall'AI) alla semantica e alla verifica (eseguite dall'umano).

Requirements Engineering: L'AI funge da simulatore di stakeholder: analizza trascrizioni di meeting per generare User Stories, rileva requisiti ambigui e scrive automaticamente i criteri di accettazione (es. in sintassi Gherkin).
Design & Architettura: Converte descrizioni testuali in diagrammi (Text-to-UML), suggerisce Design Pattern e valuta i pro/contro architetturali.
Coding: Agisce come un Junior Pair Programmer, traducendo la logica di business in sintassi complesse (come regex e SQL) e generando documentazione al volo.
Testing & QA: Genera unit test (metodo white-box), crea dati sintetici per testare i casi limite ed esegue analisi statiche predittive per scovare bug prima della compilazione.
Maintenance & Evolution: Agisce come agente di refactoring: spiega il codice legacy obsoleto, lo traduce in stack moderni (es. da Java 8 a Java 21) e aiuta a ridurre il debito tecnico.

Process Improvement e Modello CMM

Le aziende cercano continuamente di migliorare i propri processi per aumentare la qualità e ridurre tempi e costi, affidandosi a Metriche di processo (come il tempo impiegato o il numero di difetti scoperti).

Per misurare la maturità di un'azienda nello sviluppo software, viene utilizzato il modello CMM, strutturato in 5 livelli incrementali:

1. Initial: Il processo è essenzialmente incontrollato e caotico.
2. Repeatable: Esistono e vengono usate procedure base di gestione del prodotto.
3. Defined: Le procedure e strategie di gestione del processo sono definite e usate in tutta l'organizzazione.
4. Managed: Vengono utilizzate strategie misurabili per la gestione della qualità.
5. Optimising: L'azienda usa strategie definite per il miglioramento continuo del processo.