Sviluppo e implementazione

Dalla specifica all'integrazione: OTOKO® sviluppa applicazioni e le collega ai vostri sistemi e processi esistenti.

Che si tratti di un'applicazione specialistica, di un prodotto digitale o di uno strumento interno: sviluppiamo software per i processi che non si possono rappresentare in modo sensato con i sistemi esistenti.

Analisi dei requisiti con l'area di business, modello delle minacce e architettura target secondo il modello C4 Modello di dominio, modello dei dati e contratti di interfaccia prima della prima riga di codice Sviluppo in iterazioni brevi con code review e collaudi da parte dell'area di business Sviluppo sicuro secondo OWASP ASVS, dipendenze verificate e build firmati Passaggio di consegne con codice sorgente, documentazione di architettura e manuale operativo

Applicazione funzionante con codice sorgente e pipeline di build Documentazione di architettura con modello delle minacce Manuale operativo con runbook e piano di emergenza

Esempi dei flussi di lavoro attuali e delle eccezioni Responsabili per le decisioni di business Sistemi esistenti, fonti di dati e requisiti di gestione operativa

La pianificazione della manutenzione è finora gestita in fogli di calcolo. Un'applicazione specialistica riunisce impianti, scadenze, responsabilità e approvazioni. La prima fase di ampliamento copre un sito; gli altri siti seguiranno solo dopo una verifica funzionale del processo.

.NET C# Go Rust TypeScript PostgreSQL

Si parte dal flusso di lavoro in cui l'investimento deve ripagarsi. Modelliamo termini, stati e regole di business insieme alle persone che poi ci lavoreranno. Un'approvazione, ad esempio, non è solo un pulsante: delega, autorizzazioni, scadenze e revoca di una decisione devono essere coerenti tra loro. Queste regole diventano parte del modello dei dati e dei test. La prima versione si concentra su un processo completo e utilizzabile. Aggiungiamo ulteriori funzionalità in base ai riscontri derivanti dall'uso reale. Ne nasce così un prodotto con un beneficio verificabile, e non una grande raccolta di schermate incomplete.

Per backend, interfaccia utente e gestione dei dati scegliamo le tecnologie in base al vostro panorama esistente e all'evoluzione prevista. Competenze già presenti, interfacce e requisiti di gestione operativa pesano più di una tendenza tecnologica a breve termine. L'offerta attuale comprende tra l'altro .NET, Go e TypeScript; i componenti a basso livello vengono valutati separatamente. Definiamo i confini dei moduli e le responsabilità in modo che le modifiche restino tracciabili. Le credenziali di accesso non vanno nel codice sorgente, le regole di business non solo nell'interfaccia. Review, controlli automatizzati e modifiche versionate del database accompagnano la realizzazione dall'inizio.

Ogni iterazione mostra funzionalità utilizzabili con limitazioni note. Il collaudo funzionale e l'approvazione tecnica vengono considerati separatamente: un ordine calcolato correttamente può essere giusto nel merito, mentre il comportamento sotto carico o la gestione degli errori non sono ancora pronti per la produzione. Definiamo insieme quali evidenze siano necessarie per ciascuna fase di ampliamento. L'ambito di fornitura concordato comprende codice sorgente, build riproducibili e documentazione. Per l'avvio in produzione chiariamo migrazione dei dati, formazione, responsabilità e gestione dei malfunzionamenti. Diritti di utilizzo, componenti di terzi e manutenzione futura li regoliamo prima del passaggio di consegne.

Un'applicazione deve funzionare correttamente anche quando più persone modificano contemporaneamente le stesse giacenze. Due prenotazioni non devono assegnare, senza che nessuno se ne accorga, lo stesso ultimo articolo. Determiniamo quindi quali modifiche devono avere successo insieme e quali conflitti richiedono un riscontro funzionale. Vincoli di database, transazioni e controlli di versione possono risolvere parti diverse di questo compito; l'interfaccia da sola non può garantire queste regole. I processi di business più lunghi, invece, spesso non rientrano in un'unica transazione. Un ordine, un servizio di pagamento esterno e un'autorizzazione alla spedizione hanno propri stati di errore. Modelliamo il processo con stati tracciabili e transizioni consentite. Le richieste ripetute ricevono un identificativo dell'operazione adeguato, affinché un'interruzione di connessione non provochi automaticamente un'azione duplicata. In caso di errori parziali serve una correzione definita sul piano funzionale, ad esempio la revoca di un'autorizzazione, invece di un riavvio tecnico generico.

Per prodotti SaaS e piattaforme interne distinguiamo l'identità di un utente dai suoi diritti su un determinato record di dati. Un dipendente autenticato non è automaticamente autorizzato a leggere ogni fattura o ogni ordine. Verifichiamo gli accessi nel backend a livello di organizzazione, ruolo e processo. Anche esportazioni, indici di ricerca, attività in background e risultati memorizzati nella cache devono rispettare questi limiti. Tabelle condivise con identificativo di tenant, schemi di database separati o database propri comportano requisiti diversi in termini di isolamento, migrazione e ripristino. Scegliamo il modello in base alla separazione necessaria e alla vostra organizzazione operativa. I test con più tenant verificano in particolare gli accessi non autorizzati. Un registro di audit documenta le modifiche rilevanti per il business con il contesto adeguato; quali dati contenga e per quanto tempo restino disponibili viene stabilito espressamente.

La struttura dei dati segue le query e le regole di business. Analizziamo filtri, ordinamenti, analisi e operazioni di scrittura tipici prima di introdurre tecnologie di memorizzazione aggiuntive. Elenchi di risultati illimitati, query singole ripetute e trasferimenti di dati di grandi dimensioni possono rallentare un'applicazione, anche se il server appare poco caricato. Misurazioni con volumi di dati realistici mostrano se indici, modifiche alle query, paginazione o un'altra suddivisione dei compiti siano d'aiuto. Il caching è una decisione consapevole sull'aggiornamento dei dati: deve essere stabilito quando un risultato memorizzato diventa non valido e quali utenti possano vederlo. Calcoli estesi possono essere eseguiti come attività in background, ma richiedono allora un indicatore di avanzamento, il riavvio e stati di errore. Per le estensioni separiamo le regole di business dagli adattatori tecnici. Test automatizzati e modifiche versionate del database proteggono questi confini, affinché un nuovo canale o il passaggio a un altro fornitore non richieda modifiche a ogni modulo.

Panorama applicativo, requisiti, rischi Area di business, IT, sicurezza delle informazioni, architetto software OTOKO® Iniziative valutate, analisi dello stato attuale, requisiti di sicurezza e di esercizio

Architettura, tecnologia, modello operativo Area di business, architettura, protezione dei dati, sicurezza delle informazioni Architettura target, modello delle minacce, strategia di test, modello operativo, milestone