PROCESSO DI SVILUPPO DI UNA APPLICAZIONE CUSTOM

PREVENTIVO

Quando un cliente ci chiede di sviluppare un progetto custom, come prima cosa valutiamo insieme al cliente se esiste un documento di analisi.

Un documento di analisi è un documento estremamente dettagliato che segue una serie di specifiche che andremo a vedere nel dettaglio in seguito.

Se questo documento di analisi non esiste, si fa un’intervista preliminare durante la quale si cerca di capire quali sono gli obiettivi del progetto.

Da questa intervista nasce una prima quotation, ovvero una quotazione di massima, spesso anche con una forbice di range che definisce in qualche modo lo scopo del progetto: i tempi e, appunto, un ordine di grandezza di budget.

Se invece esiste un documento di analisi, si procede per un’altra strada. Si valuta prima il livello di analisi che il documento ha raggiunto.

Noi dividiamo i documenti di analisi in tre livelli:

Il documento di livello 1 si definisce come una prima quotazione di massima e una serie di task da svolgere, tra i quali c’è la definizione del documento di analisi di livello due e tre.

Se esiste già un documento di livello 2, si fa una quotazione, un elenco di task e si definisce, fra questi task, la realizzazione del dettaglio di documento di analisi di livello 3.

Se invece decidi di partire da una *quotation* senza documento di analisi, il cliente, se decide di accettare la *quotation*, che in genere prevede una prima quotazione anche per la stesura del documento di analisi, firma un contratto.

Si parte con una fattura di inizio lavori e si realizza un primo livello di analisi; in conseguenza, si procede con il secondo e il terzo livello.

Quando si ha un documento completo con tutti e tre i livelli, si ha di fatto una lista di attività dettagliate, un preventivo preciso, un capitolato preciso, un Gantt e una serie di azioni definite.

In generale, si dispone anche di un prototipo funzionante con schemi e, diciamo, funzionalità cliccabili dell’interfaccia che permettono di capire quanto ed effettivamente si andrà a sviluppare.

A questo punto, si può redigere un preventivo di spesa, una tabella di lavoro, un Gantt e, di fatto, un elenco di feature. Si è quindi pronti alla firma di questo secondo contratto e ad avviare la fase di sviluppo software.

FASE DISCOVERY & DESIGN

Le fasi di **Design and Discovery**, o meglio **Discovery and Design**, sono fondamentalmente tre:
1. La fase di design a livello 1,
2. La fase di design a livello 2,
3. La fase di **Design System**, o meglio di **System Design**, e la fase di output, che è la fase di prototipazione.
Come detto, nella prima fase si proviene da una quotazione di soluzioni. La Quotation prevede un documento di pre-analisi che, di fatto, è un’intervista al cliente riportata nel documento.
Inoltre, include un project charter, che è una risposta ai documenti di pre-analisi con un elenco di funzionalità, affici o obiettivi.
È previsto anche un budget massimo, che può essere espresso sotto forma di forbice, e un time frame di lavoro con le tempistiche previste per lo sviluppo del progetto. La fase di design livello 1, che potremmo chiamare **Discovery**,

LA FASE DI DESIGN DI LIVELLO 1 È DEFINITA FASE DI DISCOVERY & DESIGN (D&D).

Qui si eseguono attività come:
– Analisi della UX research
– Sviluppo di wireframes della soluzione
– User flow dei vari casi
– Analisi delle user personas
– Elenco dei vari use cases
– Differenziazione delle varie business logic dell’applicazione
– Elenco di output previsti (expected output)
– Elenco delle integrazioni richieste (integration needed)
– Area di information architecture, quando è prevista
– – Elenco di security privacy requirements del progetto.
L’Information Architecture, o IA, è sicuramente un aspetto importante per tutte le applicazioni custom.
In particolare, assume un rilievo fondamentale per le applicazioni di tipo website, quindi progetti che hanno come primario obiettivo la comunicazione e la gestione di informazioni.
Information Architecture
L’architettura dell’informazione (IA, acronimo dell’inglese Information Architecture) è l’organizzazione logica e semantica dell’informazione all’interno di qualunque spazio informativo complesso, sia fisico sia digitale. In altre parole, l’architettura dell’informazione riguarda il modo in cui informazioni, documenti, beni e servizi sono organizzati all’interno di spazi complessi per favorire il wayfinding (“orientamento”), la findability (lett. trovabilità dell’informazione), l’usabilità e la comprensibilità dell’informazione stessa.

LA FASE DI DESIGN DI LIVELLO 2: FUNCTIONAL DESIGN

La fase due di design prevede una maggiore definizione degli aspetti tecnici e informatici della soluzione e prevede:
– modellazione delle tabelle del database
– relazione tra i record
– eventuali integrazioni con API esterne con dettagli
– eventuali esposizione di API interne con specifiche
– altre integrazioni con software e sistemi esterni
– un Gantt dettagliato di progetto
– lo sviluppo della UI di interfaccia e la componentistica ed il Design System

LA FASE DI DESIGN DI LIVELLO 3: SYSTEM DESIGN

Nella fase tre del progetto, entriamo ancora più nel dettaglio con la tecnologia e con l’architettura software.
– Dettaglio dei campi presenti nelle tabelle del db
– Scelta dello stack tecnologico
– Specifiche di hosting
– Specifiche di sicurezza per DRP (RTO e RPO richiesti)
– SLA di supporto richieste

OUTPUT FINALE DELLA FASE D&D

Al termine di questa fase, che, come detto, può durare da uno a tre mesi, si ottiene come output:

– un prototipo funzionante,
– un project plan dettagliato in tutti i particolari, sia dal punto di vista economico, quindi un preventivo preciso,
– che dal punto di vista descrittivo delle funzionalità,
– il project Gantt completo finale,
– e un prototipo cliccabile in Figma.

Sviluppo

Dopo la fase D&D, il cliente riceve un preventivo dettagliato e un piano di lavoro dettagliato.
A questo punto, è ancora in grado di bloccare il progetto pagando la fase D&D, ma non proseguire; oppure può scegliere di proseguire secondo una delle due metodologie offerte, ovvero metodologia agile e metodologia watefall.
Il preventivo verrà formulato con un sistema di fatturazione a stati di avanzamento (SAL) mensili.
Lo sviluppo avviene comunque per sprint di due settimane, con un rilascio periodico in stage fino al rilascio della versione finale, che deve essere poi collaudata e autorizzata. Solo alla firma del collaudo viene emessa la fattura di saldo.
Il prodotto viene rilasciato con una garanzia di 90 giorni da difetti.
Il codice sorgente viene rilasciato solo al saldo della fattura, quindi dopo il collaudo. Per tutto il tempo dello sviluppo, il software risulta di proprietà della software house, che può rilasciarne codice sorgente anticipatamente al cliente, solo in caso di recesso anticipato del contratto e saldo di quanto dovuto delle SAL già svolte.
In caso di insolvenza di una delle fattore di SAL, il processo di sviluppo si ferma e può essere receduto o sospeso fino a venuto saldo.

METODO WATERFALL

Il metodo waterfall, più adatto per progetti a bando e a cifra chiusa, richiede normalmente più tempo per rilasciare dei risultati e non prevede modifiche rilevanti nel corso dello sviluppo.
Offre però un maggiore controllo sul budget e la certezza dei costi finali.

METODO FULL-AGILE

Il metodo di sviluppo full agile si basa invece su una definizione progressiva degli scopi e, di conseguenza, su un controllo del costo totale del progetto inferiore e comunque meno prevedibile.
Offre però il vantaggio di un rilascio più veloce e la capacità di poter cambiare lo scopo del progetto in corso d’opera.