Requisiti, architettura, dati e test
Nel Project Work L-31 ogni scelta tecnica dovrebbe essere riconducibile a un requisito della traccia. Il nostro intervento è finalizzato a migliorare la chiarezza tra problema, funzionalità, modello dei dati e criteri di verifica, distinguendo un prototipo dimostrativo da un sistema effettivamente sviluppato.
Requisiti verificabili
Controlliamo ruoli, flussi, vincoli e criteri con cui valutare ogni funzionalità.
Architettura e dati
Rivediamo diagrammi, componenti, modello informativo e motivazioni tecniche.
Test e documentazione
Verifichiamo che test dichiarati, schermate e risultati siano coerenti con quanto realizzato.
Per il corso di Informatica per le Aziende Digitali (L-31), il project work va costruito a partire dalla traccia effettivamente disponibile e dal modello che l’ateneo richiede per la tua carriera. Questa pagina illustra i controlli utili per la qualità del lavoro, non rappresenta un template universale. Consulta anche la guida generale Pegaso.
Identificare il bisogno e i requisiti
Prima di scegliere framework o linguaggio, descrivi chi utilizzerà la soluzione, quale processo deve essere migliorato e come riconoscerai il risultato. Se la traccia prevede una piattaforma per prenotazioni, per esempio, occorre distinguere esigenze degli utenti, ruoli, vincoli di accesso e dati trattati. Un requisito come «il sistema è intuitivo» è troppo vago; può essere utile precisare quali operazioni debbano essere completabili e con quali condizioni. Se il progetto è simulato, rendi espliciti scenari e assunzioni.
Dall’architettura al flusso dei dati
Uno schema architetturale è utile quando mostra componenti, dipendenze e responsabilità, non soltanto nomi di servizi. Descrivi come i dati vengono acquisiti, validati, elaborati e conservati, distinguendo livelli applicativi e eventuali integrazioni esterne. Se proponi un database, chiarisci almeno entità principali, relazioni e criteri di accesso pertinenti. La presenza di una tecnologia diffusa non costituisce di per sé una motivazione progettuale: confronta alternative in base ai requisiti effettivi della traccia e ai limiti delle risorse disponibili.
Esempio: prenotazioni con gestione dei ruoli
In un esempio didattico di gestione delle prenotazioni si potrebbero distinguere utente, amministratore e operatore, con operazioni e permessi diversi. Un flusso di inserimento dovrebbe verificare campi obbligatori, possibili conflitti e risposta in caso di errore. La descrizione può includere diagramma dei casi d’uso, pseudocodice o prototipo, quando previsti dalla consegna. Non chiamare «software realizzato» un modello che esiste soltanto su carta; un progetto concettuale e una implementazione verificata sono risultati di natura diversa.
Progettare verifiche e test significativi
Un test deve collegarsi a un requisito e produrre un esito osservabile. Oltre al caso atteso, considera input non validi, dati mancanti, conflitti e autorizzazioni insufficienti. Per ogni prova registra condizioni iniziali, azione, risultato atteso e risultato effettivo se il test è stato eseguito. Se non hai sviluppato il sistema, puoi proporre un piano di test senza inventare screenshot o risultati. Le metriche di prestazione richiedono configurazioni e carichi documentati: numeri privi di contesto tecnico sono poco interpretabili.
Privacy, manutenzione e verifica finale
Quando un’applicazione tratta informazioni personali, il progetto deve considerare minimizzazione dei dati, accessi, conservazione e gestione degli errori in modo proporzionato alla traccia. In revisione controlla coerenza fra requisiti, diagrammi, codice eventualmente prodotto, test e conclusioni. Un elenco di funzionalità non basta a documentare la qualità del lavoro. Per richiedere supporto indica architettura prevista, tecnologie scelte, materiali disponibili e aspetti da chiarire, senza inviare password o credenziali di accesso.
Regole e fonti ufficiali da controllare
Il regolamento della prova finale triennale rimanda alle tracce selezionabili e alle linee guida del Project Work in piattaforma. Per la denominazione e l’inquadramento dei corsi sono consultabili i documenti SUA 2026–2027; i calendari dell’ateneo forniscono ulteriori riferimenti. Verifica sempre quale versione di regolamento e template si applichi alla tua sessione.
Domande frequenti per L-31
Devo scrivere codice per forza?
Dipende dalla traccia: un progetto concettuale e una realizzazione software hanno consegne differenti.
Come descrivere correttamente un test?
Indica requisito, dati di partenza, operazione, risultato atteso e, se eseguito, quello osservato.
Posso inserire screenshot dimostrativi?
Sì, ma vanno etichettati correttamente; schermate simulate non devono apparire come test realmente svolti.
Come descrivo un requisito funzionale?
Specifica chi compie l’azione, che cosa deve poter fare il sistema e quali condizioni rendono verificabile l’esito.
Un mockup può essere presentato come software funzionante?
No. Un mockup va identificato come rappresentazione progettuale e non come prova di implementazione o di test effettuati.
È obbligatorio usare un determinato linguaggio?
Dipende dalla traccia. La scelta tecnologica va motivata dai requisiti, senza presumere che un framework sia richiesto in tutti i progetti.
Come documentare un caso di test?
Indica requisito, dati iniziali, passi, comportamento atteso e risultato osservato soltanto quando la prova è stata effettivamente eseguita.
Che cosa inviare per il controllo L-31?
Traccia, requisiti, diagrammi, descrizione delle tecnologie, screenshot non sensibili e documentazione dei test; non inviare credenziali o chiavi API.
Approfondimenti
- Scheda ufficiale del corso Informatica per le Aziende Digitali — UniPegaso
- Project Work Pegaso rifiutato: valutare le osservazioni e le correzioni
- Prezzi e criteri per il preventivo
La nostra consulenza è indipendente dall’università. Regole e scadenze ufficiali devono essere verificate nella piattaforma di Ateneo.