Analisi e Progettazione Software
Prima di scrivere codice, definiamo cosa serve davvero, con te e non al posto tuo
A monte di qualunque riga di codice, la prima cosa che facciamo è ascoltare: entriamo nel merito dei processi, dei dati e delle informazioni che devono restituire, capiamo l’operatività reale delle persone coinvolte, il carico delle utenze e i diversi gradi di accesso alle informazioni. È fondamentale che emergano obiettivi, processi, dipendenze e strumenti con cui il nuovo software dovrà dialogare. La raccolta dei requisiti è sempre a quattro mani con il cliente, così come l’analisi dell’architettura dati che ne consegue. Il risultato è un progetto condiviso, con tempi e costi stimati prima di partire — non dopo.
Perché saltare l'analisi costa più che farla
La fase di analisi ha un difetto: non produce niente di visibile. Non ci sono schermate da mostrare, non c’è codice che gira. Per questo è la prima voce che si prova a tagliare quando il budget è stretto.
Nella nostra esperienza è anche il taglio che costa di più. I progetti software raramente falliscono per limiti tecnici: falliscono perché a metà strada si scopre che il flusso reale è diverso da quello immaginato, che un sistema di terze parti non espone i dati che servono, o che due reparti si aspettavano due cose diverse dalla stessa funzione. A quel punto la modifica non è più una riga di codice: è una riprogettazione.
Una fase di analisi fatta bene serve a far emergere questi punti quando correggerli costa una riunione, non tre settimane di sviluppo e revisione delle integrazioni.
Chiamaci per una una valutazione del tuo nuovo progetto IT
Una call conoscitiva di trenta minuti basta per capire se il progetto è fattibile, quali sono i punti critici e come conviene affrontarlo. Siamo a Milano, in via Bernardo Quaranta 45, se vuoi passare a trovarci.
Lavoriamo con aziende Enterprise, PMI e Pubblica Amministrazione da oltre quindici anni sviluppando soluzioni per la digitalizzazione dei processi.
Vuoi scoprire qualcosa di più su Antha e i suoi servizi? Scarica la brochure.
strategia
Come lavoriamo: dalle quattro fasi dell’analisi al prototipo
Raccolta dei requisiti, verifica di fattibilità e inquadramento tecnologico
Partiamo da chi il software lo userà tutti i giorni. Mappiamo i processi così come funzionano oggi, non come dovrebbero funzionare sulla carta, e individuiamo i vincoli: normativi, infrastrutturali, di budget, di competenze interne. Da qui esce la verifica di fattibilità – cioè la risposta onesta alla domanda “questa cosa si può fare, con quali tecnologie e a quali condizioni”. Se la risposta è che serve un percorso diverso da quello immaginato, lo diciamo in questa fase.
Studio dell'architettura dati e delle integrazioni con sistemi terzi
Il dato è la parte che sopravvive a ogni riscrittura del software, quindi va progettata per prima. Definiamo il modello dati, le entità e le relazioni, i livelli di accesso per ruolo e le politiche di storicizzazione. In parallelo verifichiamo cosa deve dialogare con cosa: ERP, CRM, gestionali, macchinari, sistemi legacy. Verifichiamo davvero le API disponibili, i formati di scambio e i limiti di ciascun sistema, perché è qui che si nascondono la maggior parte delle sorprese.
Analisi funzionale e progettazione delle interfacce
Traduciamo i requisiti in funzioni: casi d’uso, ruoli, permessi, stati, eccezioni. Su questa base progettiamo le interfacce partendo dai wireframe e arrivando al design UX/UI. L’obiettivo non è l’effetto grafico ma il numero di passaggi: se un operatore ripete un’operazione duecento volte al giorno, ogni click risparmiato è tempo di lavoro recuperato.
Realizzazione del prototipo dinamico
Chiudiamo con un prototipo navigabile: non uno screenshot, ma un modello in cui si clicca e si passa da una schermata all’altra seguendo i flussi reali. È il momento in cui il progetto smette di essere un documento e diventa un modello che gli utenti possono navigare e testare. Le correzioni raccolte in questa fase sono un reale e concreto valore aggiunto da parte degli operatori che useranno l’applicativo quotidianamente.
Cosa ricevi a fine analisi
Ogni analisi viene sempre restituita al cliente. Non è una formalità: è il documento su cui si prendono le decisioni di budget e di priorità, e resta valido anche se poi il progetto viene sviluppato da qualcun altro.
Proof of Concept, prototipo o MVP: cosa serve al tuo progetto
I tre termini vengono usati come sinonimi, ma rispondono a domande diverse e costano cifre diverse. Prima di preventivare, chiariamo quale delle tre ti serve davvero.
- Proof of Concept (PoC) – risponde alla domanda “quello che ho in mente è tecnicamente fattibile?”
Si concentra su un singolo aspetto critico, di solito il più rischioso, e serve a decidere se proseguire. È circoscritto e non è destinato agli utenti finali. - Prototipo – risponde alla domanda “l’esperienza d’uso funziona?”
Riproduce i flussi e le interfacce senza logica applicativa reale, e serve a validare l’usabilità con le persone che dovranno usarlo. - MVP – risponde alla domanda “il prodotto regge sul campo?”
È software funzionante, ridotto alle funzioni essenziali, rilasciato a utenti reali per raccogliere dati d’uso.
Non servono sempre tutti e tre: su un progetto con tecnologia consolidata e processo chiaro il PoC è spesso superfluo; su un progetto IoT o con componenti di intelligenza artificiale è quasi sempre il passaggio che evita l’investimento sbagliato.
metodo di lavoro
Un metodo chiaro, concreto e condiviso
Ogni analisi viene sempre restituita al cliente allo scopo di condividere obiettivi, strumenti, priorità e punti di attenzione.
Sulla base dell'analisi svolta vengono pianificate le attività e condivisi tempi e scadenze. Ciò consente di mantenere una forte consapevolezza sul piano stabilito e sulle diverse fasi di lavoro.
Approcciamo il progetto con pragmatismo, basandoci spesso su un principio di parsimonia (o rasoio di Occam): a parità di risultati, la progettazione più semplice è sempre da preferire, evitando di introdurre elementi o cause superflue. Non suggeriamo tecnologie fini a sé stesse, ma andiamo a digitalizzare i processi reali con tutto il necessario e nulla più di ciò che realmente occorre.
Sfruttiamo i principi base della metodologia agile, proponendo un approccio agile già dalla fase di analisi. Pianifichiamo cicli di sviluppo del software iterativi e progressivi, prevedendo già in fase di progettazione un processo incrementale, che va ad aggregare, integrare o estendere funzioni progressivamente, consolidando e incrementando mano a mano che si procede con i rilasci e garantendo in questo modo una verifica continuativa dell'applicativo e un'ottima sostenibilità e scalabilità di progetto.
Su gran parte dei progetti l'analisi tiene già conto di ASKA, il nostro framework di sviluppo. Non è un pacchetto chiuso: mette a disposizione moduli nativi già consolidati - dalla gestione delle identità e degli accessi all'API Gateway - che in fase di analisi e progettazione permettono di stimare tempi e costi su basi reali invece che teoriche.
Domande frequenti su analisi e progettazione software
Dipende dall'ampiezza del perimetro e dal numero di sistemi coinvolti. Su un applicativo verticale con pochi attori si tratta in genere di due o tre settimane; su un progetto che tocca più reparti e richiede integrazioni con ERP o gestionali esistenti si arriva a sei o otto. Il primo incontro serve proprio a stimare questo, prima di qualunque preventivo.
Sì. L'analisi viene sempre restituita al cliente in forma di documento completo e resta di sua proprietà. Diversi clienti la usano per confrontare fornitori, per costruire un business case interno o per presentare il progetto a un finanziatore. Se poi lo sviluppo lo fa qualcun altro, il documento è comunque utilizzabile.
L'analisi dei requisiti stabilisce cosa il software deve ottenere: obiettivi, vincoli, esigenze delle persone coinvolte. L'analisi funzionale definisce come lo ottiene: funzioni, ruoli, permessi, casi d'uso, comportamento del sistema nelle eccezioni. La prima risponde al perché, la seconda al come.
No, ed è normale non averle. Nella maggior parte dei casi il cliente arriva con un problema operativo — un processo lento, dati sparsi su più fogli di calcolo, un gestionale che non parla con il resto — e non con una specifica funzionale. Trasformare il problema in requisiti è esattamente il nostro lavoro in questa fase.
Viene quotata sul perimetro effettivo, che definiamo insieme nel primo incontro conoscitivo. Come ordine di grandezza incide di norma fra il 10% e il 20% del valore complessivo del progetto. È la quota che riduce il rischio sul restante 80%.