Prima di sviluppare un software: cosa verificare

Partire dal risultato che serve

Una richiesta di software nasce spesso da un’attività che richiede troppo tempo, da informazioni disperse o da un sistema che non accompagna più il lavoro. “Ci serve un’applicazione” è un punto di partenza: per scegliere cosa costruire occorre descrivere il risultato atteso e le condizioni in cui dovrà funzionare.

Un obiettivo utile è osservabile. Per esempio: consentire a un tecnico di registrare un intervento dal luogo in cui lavora, rendendo disponibili al coordinatore stato e materiali utilizzati. Restano da definire utenti, dispositivi, connessione e controlli. Queste domande rendono confrontabili le proposte tecniche.

Cinque verifiche da fare insieme

• Persone e attività: chi userà la soluzione, chi approverà il lavoro e chi la manterrà? Osservare un’attività reale può far emergere passaggi non descritti nelle procedure.

• Dati: quali informazioni servono, dove si trovano e chi può modificarle? Un campo chiamato “cliente” in due sistemi può avere significati diversi.

• Sistemi esistenti: quali strumenti devono restare, quali interfacce sono disponibili e quali vincoli impongono i fornitori?

• Condizioni d’uso: dispositivi, volumi, connessioni intermittenti, permessi e continuità operativa vanno descritti prima di scegliere l’architettura.

• Risorse: tempo delle persone, budget, licenze, gestione e manutenzione fanno parte della decisione, oltre allo sviluppo iniziale.

Confrontare alternative concrete

La scelta può riguardare un adattamento del software già disponibile, un’integrazione fra strumenti o una nuova applicazione. Il confronto è più utile quando ogni alternativa risponde allo stesso problema e rende espliciti costi, dipendenze e limiti.

Trasformare i dubbi in prove

Le incertezze decisive meritano una verifica circoscritta. Se il problema è la qualità dei dati, una piccola estrazione può essere più utile di un’interfaccia completa. Se il dubbio riguarda l’uso sul campo, si può provare un flusso con le persone interessate. Se dipende da un’integrazione, conviene verificare prima l’accesso ai sistemi.

Per ciascuna prova si definiscono domanda, materiali disponibili, risultato osservabile e criterio con cui decidere il passo successivo. I requisiti dovrebbero essere comprensibili, coerenti e verificabili: è un principio presente anche nelle indicazioni NASA sulla validazione dei requisiti software, da adattare alla complessità del progetto.

Uno scenario illustrativo

Un’impresa riceve rapportini via email e li ricopia nel gestionale. Prima di progettare un portale si esaminano alcuni rapportini, si segue il lavoro di un coordinatore e si verifica se il gestionale offre un’interfaccia di importazione. Potrebbe emergere che il primo intervento utile è uniformare i dati e automatizzarne il trasferimento. Oppure che occorre un’applicazione per raccoglierli sul campo. La decisione dipende dalle prove.

Scenario illustrativo di un possibile intervento. Non descrive un progetto cliente né risultati già ottenuti.

Cosa dovrebbe restare alla fine dell’analisi

Una descrizione condivisa del problema, le alternative considerate, i principali vincoli e un primo perimetro verificabile. Per ogni attività devono essere chiari responsabile, informazioni necessarie e criterio di completamento. Anche decidere di fermarsi o di usare meglio uno strumento esistente può essere un esito utile.

SoftGen può affiancare questa fase con analisi del contesto, confronto delle opzioni e verifiche di fattibilità. Il percorso successivo viene concordato sulla base di ciò che emerge.

Riferimenti

NASA Software Engineering Handbook — Requirements Validation

Una scheda pratica per il primo confronto

Puoi raccogliere queste informazioni anche in forma provvisoria. Le risposte mancanti indicano cosa approfondire, non sono un motivo per rimandare il confronto.

Da questa scheda può nascere un confronto tra alternative oppure una prova mirata. Il livello di dettaglio va commisurato alla decisione da prendere.