Architettura ed effort
Architettura proposta: inferenza client-side
Il principio: l'immagine non lascia il dispositivo. Al backend arrivano soltanto i valori derivati — coordinate dei landmark e angoli calcolati — mai il fotogramma.
Vantaggi:
- il dato più sensibile (immagine del corpo) non viene mai trasmesso né conservato, il che semplifica radicalmente gli adempimenti privacy;
- nessun costo di inferenza e nessuna GPU da gestire: il carico è sul dispositivo dell'utente;
- latenza nulla, quindi feedback in tempo reale durante il posizionamento;
- funziona anche offline dopo il primo caricamento del modello.
Il backend serve solo per: storico delle misurazioni, confronto tra sessioni, generazione di report ed eventuale condivisione con un professionista.
Ha senso solo se un professionista deve poterle rivedere. In quel caso cambia la natura del trattamento e servono base giuridica, retention definita e probabilmente una DPIA — vedi Rischi e validazione. Va trattata come una feature a sé, non come un dettaglio implementativo.
Ripartizione dell'effort
Stime in giorni/uomo per uno sviluppatore senior già operativo sul progetto. Sono ordini di grandezza per dimensionare la decisione, non impegni.
Facile — le librerie fanno il lavoro
| Attività | Effort |
|---|---|
| Integrazione PoseLandmarker, gestione camera e permessi | 2–3 gg |
| Overlay scheletro su canvas, linee di riferimento | 1–2 gg |
| Calcolo angoli e asimmetrie | 1–2 gg |
| Filtro temporale e aggregazione multi-frame | 1–2 gg |
| Totale PoC dimostrabile | 5–9 gg |
Al termine si ha una demo che funziona e sembra convincente. È il punto in cui è più facile sottovalutare tutto il resto.
Medio — rendere la misura ripetibile
| Attività | Effort |
|---|---|
| UX di posizionamento: silhouette guida, countdown, feedback correttivo | 5–8 gg |
| Controlli automatici di qualità dell'acquisizione (soggetto intero nel frame, confidenza minima, rotazione, livella) | 4–6 gg |
| Protocollo multi-vista (fronte / lato / retro) con gestione della sequenza | 3–5 gg |
| Persistenza, storico e confronto tra sessioni | 4–6 gg |
| Presentazione risultati: score, deviazioni, incertezza, report | 5–8 gg |
| Totale verso un MVP usabile | 21–33 gg |
Difficile — non è lavoro da sviluppatore
| Attività | Effort | Chi |
|---|---|---|
| Definizione di angoli rilevanti e soglie di normalità | Settimane | Fisioterapista / ortopedico |
| Protocollo di acquisizione standardizzato e validato | Settimane | Professionista + sviluppo |
| Misura sperimentale della ripetibilità del sistema | 5–8 gg | Sviluppo |
| Validazione contro un riferimento (motion capture o valutazione clinica) | Mesi | Esterno / partner |
| Revisione legale dei claim e inquadramento regolatorio | Da definire | Legale |
Sommando: circa 30–45 giorni/uomo portano a un prodotto tecnicamente completo e gradevole. Ma un prodotto tecnicamente completo che mostra soglie non validate è esattamente il modo in cui questa categoria di funzionalità genera danni reputazionali. La colonna "Chi" della tabella difficile è la parte che non si può risolvere assumendo un altro sviluppatore.
Considerazioni implementative
Peso del modello. I modelli MediaPipe esistono in varianti di dimensione crescente (lite / full / heavy). Il download iniziale va gestito con una schermata di caricamento esplicita e caching, altrimenti la prima esperienza utente è un'attesa senza spiegazione. La variante più pesante ha senso solo se lo spike dimostra che migliora effettivamente la ripetibilità.
Foto vs video. Il video è preferibile anche per un'analisi statica: consente di aggregare su più frame e di scartare quelli in cui il soggetto si muove o la confidenza cala. L'utente percepisce comunque "uno scatto", ma la misura è mediata su una finestra temporale.
Dispositivi eterogenei. La stessa persona misurata con telefoni diversi ottiene risultati diversi (ottica, campo visivo, distorsione, risoluzione). Se lo storico deve essere confrontabile nel tempo, va registrato il contesto dell'acquisizione e segnalato all'utente quando cambia — oppure il confronto tra dispositivi diversi va disabilitato.
Accessibilità. I modelli sono addestrati prevalentemente su persone in piedi e abbigliamento aderente. Utenti in carrozzina, con arti amputati o con abbigliamento ampio producono risultati inaffidabili senza che il sistema se ne accorga. Serve almeno un percorso di uscita esplicito ("non riusciamo a rilevare correttamente la postura") invece di un numero inventato.