Prova generale della presentazione

Questa lezione appartiene al Modulo 23 — Preparazione della consegna finale estesa.

Perché fare una prova generale

La prova generale non è una ripetizione per sentirsi sicuri — è un test con feedback reale. Serve a trovare tre tipi di problemi prima del giorno della valutazione:

1. Problemi tecnici: la demo si blocca, localStorage è vuoto, un link non funziona
2. Problemi di tempo: la presentazione è troppo lunga o troppo corta
3. Problemi di chiarezza: il revisore non capisce un passaggio, una spiegazione è troppo tecnica

Ogni problema trovato in prova è un problema evitato in valutazione.

Come strutturare la prova generale

La prova deve simulare le condizioni reali della presentazione:

• Cronometro attivo — non pausare mai
• Revisore reale — un compagno, non tu stesso
• Ambiente pulito — localStorage svuotato prima di iniziare
• Nessuna interruzione — il revisore prende note e parla solo alla fine

Struttura temporale consigliata (15 minuti totali)

[0:00 - 3:00]  Apertura: il problema, cosa fa il Registro, i quattro livelli
[3:00 - 8:00]  Demo live: ciclo completo (registra → presta → errore → chiudi)
[8:00 - 11:00] Architettura: tre punti nel codice con spiegazione
[11:00 - 13:00] Test e documentazione: un test dimostrato, README aperto
[13:00 - 15:00] Retrospettiva: cosa funziona, cosa cambieresti, limiti dichiarati

La scheda del revisore

Il revisore compila questa scheda durante la prova — non interrompe, prende note:

## Scheda revisore — Prova generale

**Studente presentato:** 
**Data prova:** 

### Comprensione

Il problema del laboratorio era chiaro prima della soluzione? (sì/no)
Spiegazione:

La distinzione tra dominio e infrastruttura era comprensibile? (sì/no)
Spiegazione:

I punti dimostrativi nel codice erano convincenti? (sì/no — quali mancavano?)

### Tecnica

La demo ha funzionato senza blocchi? (sì/no)
Cosa non ha funzionato:

Il localStorage era svuotato all'inizio? (sì/no)

### Tempo

Durata totale: _____ minuti
Parte più lunga: _____
Parte più corta: _____

### Domande emerse durante la prova

1.
2.
3.

### Tre cose da correggere prima della valutazione

1.
2.
3.

Cosa controllare prima di iniziare la prova

Checklist pre-prova:
[ ] localStorage svuotato (DevTools → Application → Clear storage)
[ ] Il progetto parte correttamente dall'index.html
[ ] I dati di esempio sono pronti (lista strumenti precaricati o procedura per inserirli)
[ ] Il file README è aperto e visibile
[ ] Il file di test è pronto da eseguire
[ ] Il cronometro è sul telefono o sul monitor
[ ] Il revisore ha la scheda stampata o aperta

Scenario demo da eseguire durante la prova

Il ciclo completo deve essere dimostrabile in 5 minuti:

1. Avvia il progetto da localStorage vuoto
2. Registra uno strumento: "Trapano elettrico", categoria "Elettrico"
3. Registra un secondo strumento: "Multimetro", categoria "Misura"
4. Cerca per categoria "Elettrico" — mostra il filtro funzionante
5. Apri un prestito per "Trapano elettrico" — assegna a "Luca 3A"
6. Prova a prestare lo stesso strumento di nuovo → mostra l'errore
7. Segnala "Multimetro" come guasto
8. Prova a prestare "Multimetro" → mostra l'errore
9. Chiudi il prestito del "Trapano elettrico"
10. Verifica che il Trapano torni disponibile

Questo scenario copre: registrazione, ricerca, prestito, errori di dominio, chiusura.

I tre punti dimostrativi nel codice

Durante la prova, apri questi tre file e spiega una frase per ognuno:

Punto 1 — domain/strumento.js
  → "Nessun import esterno. Questa è la prova che il dominio non conosce localStorage."

Punto 2 — application/registraPrestito.js (funzione creaRegistraPrestito)
  → "Riceve archivioStrumenti come parametro. Nei test usiamo un archivio in memoria."

Punto 3 — [file di test]
  → "Questo test verifica la regola sullo strumento guasto. Gira senza browser."

Procedura della prova

1. Il revisore imposta il cronometro.
2. Lo studente presenta senza interruzioni — 15 minuti.
3. Il revisore compila la scheda durante la prova.
4. Dopo 15 minuti: 10 minuti di feedback strutturato dal revisore.
5. Lo studente prende nota delle tre cose da correggere.
6. Correggi i problemi tecnici prima di fare la seconda prova (facoltativa).

Attività in classe

## Prova generale — risultati

Data e ora della prova:

Revisore:

Durata totale: _____ minuti

Problemi tecnici trovati:

Passaggi poco chiari segnalati dal revisore:

Tempo fuori range (troppo lungo/corto):

Tre correzioni da fare prima della valutazione:
  1.
  2.
  3.

Seconda prova programmata (sì/no/non necessaria):

Spiegazione guidata per studiare

La prova generale è un controllo di qualità, non una ripetizione. Senza un revisore esterno, è impossibile sapere se la spiegazione è comprensibile — chi presenta conosce il progetto troppo bene per accorgersi dei salti logici.

Il punto centrale è: il revisore trova i problemi che lo studente non vede. Una spiegazione che sembra ovvia per chi ha costruito il progetto può essere incomprensibile per chi la sente per la prima volta.

Il rischio tipico è fare la prova “da soli nella testa” invece che con un revisore vero. Non vale. La prova serve proprio a scoprire cosa non funziona quando qualcuno ascolta davvero.

Passo per passo nel progetto

1. Trova un revisore — un compagno che non ha lavorato sul tuo progetto.
2. Svuota localStorage e verifica che il progetto parta correttamente.
3. Esegui la prova completa con cronometro — no pause, no correzioni in corso.
4. Ricevi il feedback dalla scheda del revisore.
5. Correggi i tre problemi segnalati prima della valutazione.

Esempio da leggere lentamente

Feedback tipico del revisore dopo una prova:

"Non ho capito la differenza tra dominio e caso d'uso.
 Hai detto 'il dominio verifica' e poi 'il caso d'uso verifica' — sembravano la stessa cosa."

→ Correzione: prepara una frase che distingue i due:
  "Il dominio contiene la regola — strumento guasto = non prestabile.
   Il caso d'uso usa quella regola mentre coordina l'operazione completa."

"La demo si è bloccata perché localStorage era già pieno di test precedenti."

→ Correzione: svuota localStorage prima di ogni prova nella checklist pre-prova.

"Non ho capito perché i test funzionano senza browser."

→ Correzione: mostra fisicamente il test girare — apri il terminale, esegui il test,
  fai vedere che la finestra del browser non è aperta.

Prova di comprensione

• Il revisore ha capito il problema del laboratorio prima di vedere il codice?
• La demo ha completato il ciclo completo senza blocchi?
• I tre punti dimostrativi nel codice erano nel posto giusto e pronti?

Errori da evitare

• fare la prova senza cronometro — il tempo è una dimensione critica della presentazione;
• interrompere la prova per correggere durante — simula le condizioni reali;
• scegliere come revisore qualcuno che conosce già il progetto — non è un feedback utile;
• non correggere i problemi trovati prima della valutazione.

Prodotto da consegnare

Può essere:

• la scheda del revisore compilata con i tre problemi trovati;
• la lista delle tre correzioni applicate dopo la prova;
• la conferma che la seconda prova (se necessaria) è stata eseguita.

Checklist di chiusura

• Ho fatto la prova con un revisore reale, con cronometro
• Il revisore ha compilato la scheda
• Ho ricevuto almeno tre punti di feedback specifici
• Ho corretto i problemi tecnici trovati (localStorage, link, file mancanti)
• Ho rivisto i passaggi poco chiari segnalati dal revisore

Domande per la revisione

• Quanti minuti è durata la prova? Era nel range di 15 minuti?
• Quale parte della presentazione era meno chiara per il revisore?
• I tre punti dimostrativi nel codice erano pronti o hai dovuto cercarli durante la prova?

Risultato atteso

Alla fine lo studente deve saper dire:

Ho fatto la prova generale il [data] con [revisore].
Durata: [X] minuti.
Problemi trovati: [lista].
Ho corretto: [lista].
Sono pronto per la valutazione / ho bisogno di una seconda prova perché [motivo].

Se questa spiegazione non è possibile, la lezione non è ancora davvero conclusa.