Portale web su misura

Le fasi

1. 1

   Analisi dei requisiti

   settimane 1–4
   • Contratto firmato
   • Riunione di avvio con il committente e i referenti dei repartiDopo «Contratto firmato».
   • Interviste ai referenti e agli utenti del portaleDopo «Riunione di avvio con il committente e i referenti dei reparti».
   • Processi attuali: moduli, email e fogli di calcolo che il portale sostituisceDopo «Riunione di avvio con il committente e i referenti dei reparti».
   • Ruoli e permessi: chi vede e chi fa che cosaDopo «Interviste ai referenti e agli utenti del portale», «Processi attuali: moduli, email e fogli di calcolo che il portale sostituisce».
   • Requisiti funzionali scritti come storie con i criteri di accettazioneDopo «Interviste ai referenti e agli utenti del portale», «Processi attuali: moduli, email e fogli di calcolo che il portale sostituisce».
   • Requisiti non funzionali: utenti contemporanei, disponibilità, tempi di risposta, conservazioneDopo «Interviste ai referenti e agli utenti del portale».
   • Sistemi da collegare: accesso unico, gestionale, archivio documentaleDopo «Processi attuali: moduli, email e fogli di calcolo che il portale sostituisce».
   • Documento dei requisiti e piano dei rilasci per sprintDopo «Ruoli e permessi: chi vede e chi fa che cosa», «Requisiti funzionali scritti come storie con i criteri di accettazione», «Requisiti non funzionali: utenti contemporanei, disponibilità, tempi di risposta, conservazione», «Sistemi da collegare: accesso unico, gestionale, archivio documentale».
   • Revisione dei requisiti con il committenteDopo «Documento dei requisiti e piano dei rilasci per sprint».
   • Requisiti approvatiDopo «Revisione dei requisiti con il committente».
2. 2

   Esperienza utente e design

   settimane 4–8
   • Mappa delle funzioni e navigazione per ruoloDopo «Requisiti approvati».
   • Prototipo navigabile dei percorsi principaliDopo «Mappa delle funzioni e navigazione per ruolo».
   • Libreria di componenti accessibile: contrasti, focus, moduli, messaggi d'erroreDopo «Mappa delle funzioni e navigazione per ruolo».
   • Prova del prototipo con cinque utenti veriDopo «Prototipo navigabile dei percorsi principali».
   • Schermate definitive di tutte le funzioniDopo «Prova del prototipo con cinque utenti veri», «Libreria di componenti accessibile: contrasti, focus, moduli, messaggi d'errore».
   • Design approvato dal committenteDopo «Schermate definitive di tutte le funzioni».
3. 3

   Architettura

   settimane 4–7
   • Architettura applicativa: stack, API, hosting nell'Unione europeaDopo «Requisiti approvati».
   • Accesso unico con il sistema aziendale e doppio fattoreDopo «Architettura applicativa: stack, API, hosting nell'Unione europea».
   • Modello dei dati e regole di conservazioneDopo «Architettura applicativa: stack, API, hosting nell'Unione europea».
   • Analisi dei rischi per i dati personali e misure di sicurezzaDopo «Architettura applicativa: stack, API, hosting nell'Unione europea».
   • Ambienti, rilascio automatico e copie di sicurezzaDopo «Architettura applicativa: stack, API, hosting nell'Unione europea».
   • Contratti delle API verso il gestionale e l'archivio documentaleDopo «Modello dei dati e regole di conservazione».
   • Architettura approvata dal reparto informatico del committenteDopo «Accesso unico con il sistema aziendale e doppio fattore», «Contratti delle API verso il gestionale e l'archivio documentale», «Analisi dei rischi per i dati personali e misure di sicurezza», «Ambienti, rilascio automatico e copie di sicurezza».
4. 4

   Sviluppo

   settimane 9–17
   • Il reparto informatico del committente apre gli accessi ai sistemi di provaDopo «Architettura approvata dal reparto informatico del committente».
   • Sprint 1: accesso, profili, ruoli e permessiDopo «Design approvato dal committente», «Architettura approvata dal reparto informatico del committente».
   • Demo dello sprint 1 al committenteDopo «Sprint 1: accesso, profili, ruoli e permessi».
   • Sprint 2: richieste e pratiche con il loro flusso di approvazioneDopo «Demo dello sprint 1 al committente».
   • Demo dello sprint 2 al committenteDopo «Sprint 2: richieste e pratiche con il loro flusso di approvazione».
   • Sprint 3: documenti, notifiche e ricercaDopo «Demo dello sprint 2 al committente», «Il reparto informatico del committente apre gli accessi ai sistemi di prova».
   • Demo dello sprint 3 al committenteDopo «Sprint 3: documenti, notifiche e ricerca».
   • Sprint 4: integrazione con il gestionale, cruscotti e pannello di amministrazioneDopo «Demo dello sprint 3 al committente».
   • Demo dello sprint 4 al committenteDopo «Sprint 4: integrazione con il gestionale, cruscotti e pannello di amministrazione».
   • Manuale d'uso per ruolo e documentazione tecnicaDopo «Demo dello sprint 3 al committente».
   • Portale completo nell'ambiente di collaudoDopo «Demo dello sprint 4 al committente», «Manuale d'uso per ruolo e documentazione tecnica».
5. 5

   Collaudo

   settimane 17–20
   • Prove funzionali e di regressione su tutte le storieDopo «Portale completo nell'ambiente di collaudo».
   • Verifica di accessibilità WCAG 2.1 livello AADopo «Portale completo nell'ambiente di collaudo».
   • Prove di carico sugli utenti contemporanei dei requisitiDopo «Portale completo nell'ambiente di collaudo».
   • Prova di intrusione da parte di un esperto esternoDopo «Portale completo nell'ambiente di collaudo».
   • Correzioni dalle prove e dalla prova di intrusioneDopo «Prove funzionali e di regressione su tutte le storie», «Verifica di accessibilità WCAG 2.1 livello AA», «Prove di carico sugli utenti contemporanei dei requisiti», «Prova di intrusione da parte di un esperto esterno».
   • Collaudo del committente con gli utenti pilotaDopo «Correzioni dalle prove e dalla prova di intrusione».
   • Verbale di collaudo firmatoDopo «Collaudo del committente con gli utenti pilota».
6. 6

   Avvio in esercizio

   settimane 20–23
   • Formazione degli amministratori e dei referentiDopo «Verbale di collaudo firmato».
   • Caricamento dei dati iniziali e degli utentiDopo «Verbale di collaudo firmato».
   • Messa in esercizio in produzioneDopo «Formazione degli amministratori e dei referenti», «Caricamento dei dati iniziali e degli utenti».
   • Portale in esercizioDopo «Messa in esercizio in produzione».
   • Presidio delle prime due settimaneDopo «Messa in esercizio in produzione».
   • Consegna del codice sorgente, delle credenziali e della documentazioneDopo «Messa in esercizio in produzione».
   • Riunione di chiusura e avvio della garanziaDopo «Presidio delle prime due settimane», «Consegna del codice sorgente, delle credenziali e della documentazione».
   • Fine del progetto e inizio della garanziaDopo «Riunione di chiusura e avvio della garanzia».

I rischi tipici

• Requisiti che cambiano durante gli sprint

  Critico · 16

  Le demo fanno venire idee nuove: le storie si riscrivono a sprint avviato e le ore vendute finiscono prima del collaudo.

  Mitigare: Requisiti approvati prima dello sviluppo; ogni richiesta nuova stimata e decisa dal referente del committente: entra al posto di una storia di peso simile o come variante a parte.

• Accessi ai sistemi del committente in ritardo

  Alto · 12

  Il reparto informatico del committente ha altre priorità: le integrazioni si sviluppano su dati finti e si scoprono i problemi in collaudo.

  Mitigare: Elenco degli accessi consegnato all'approvazione dell'architettura, con la data in cui servono; le integrazioni nell'ultimo sprint, non nel primo.

• Gestore delle identità aziendale non pronto

  Alto · 12

  Gruppi non definiti o configurazione dell'accesso unico affidata a un fornitore esterno del committente: gli utenti non entrano.

  Mitigare: Accesso unico nel primo sprint, provato con utenze vere di ogni ruolo; accesso locale per gli amministratori come riserva.

• Vulnerabilità gravi scoperte a fine progetto

  Alto · 12

  La prova di intrusione trova un controllo dei permessi mancante: correggerlo tocca molte funzioni a una settimana dal collaudo.

  Mitigare: Permessi sul server per ogni chiamata, con test automatici per ruolo dallo sprint 1; revisione del codice con la sicurezza fra i criteri.

• Utenti che restano su email e fogli di calcolo

  Alto · 12

  Il portale funziona ma nessuno cambia abitudini: i processi vecchi restano in piedi accanto a quello nuovo.

  Mitigare: Utenti veri nelle interviste e nella prova del prototipo; data concordata con il committente da cui il vecchio canale non si usa più.

La commessa

A corpo, fatturata a rate alle milestone · 6 voci. Importi e tariffe li metti tu.

• Analisi dei requisiti
• Esperienza utente e design
• Architettura
• Sviluppo
• Collaudo
• Avvio in esercizio

Le rate

• Anticipo alla firma del contratto: 20 %, alla milestone «Contratto firmato»
• Approvazione dei requisiti: 15 %, alla milestone «Requisiti approvati»
• Approvazione del design: 15 %, alla milestone «Design approvato dal committente»
• Portale completo in collaudo: 25 %, alla milestone «Portale completo nell'ambiente di collaudo»
• Verbale di collaudo firmato: 15 %, alla milestone «Verbale di collaudo firmato»
• Fine del progetto: 10 %, alla milestone «Fine del progetto e inizio della garanzia»

Le pagine dei documenti

• Scheda di una storia utente
• Verbale di collaudo