Quanto tempo occorre per modernizzare una applicazione gestionale? E’ una delle domande cruciali che si pone l’azienda che intende affrontare un progetto di modernizzazione: tempo significa costi, e significa anche “quando saremo pronti”. Le variabili sono diverse. Molto dipende dallo strumento di modernizzazione che si va ad utilizzare.
Obbiettivo dell’esercizio, è valutare la modernizzazione completa di una applicazione gestionale, implementando le caratteristiche maggiormente diffuse su interfacce “visual” quali tabelle, bottoni, icone, boxes, checks etc.
La prima domanda è: lo strumento richiede necessariamente di modificare il codice sorgente dell’applicazione originale per implementare comportamenti “visuali” (tabelle, icone, check box, combo box etc)? Questo aspetto introduce un primo impatto di tempi non indifferente; peraltro è facilmente misurabile : una volta acquisita la conoscenza dello strumento si riesce a stimare un tempo medio di intervento, ad esempio, se vengono richiesti ca. 30/45 minuti per la modifica del codice sorgente di un programma (modifica/compilazione/test), significa che preparare alla conversione una applicazione con 1500 display file richiede per questa sola fase ca. 5/7 mesi/uomo.
La seconda domanda è: quanto lo strumento si può adattare alla mancanza di standard ben definiti nell’applicazione originale? Questo aspetto è molto importante. Più lo strumento si può adattare a standard diversi, meno sarà il tempo destinato a modificare le applicazioni originali ad assumere un unico standard. I tempi da destinare a questa fase si possono già ricavare da uno studio delle caratteristiche dello strumento di modernizzazione, unito ad un censimento delle tipologie di display file e delle differenze di standard implementate; ad esempio: la posizione delle descrizioni dei tasti funzione, la posizione e tipologia delle intestazioni dei subfile (su una o piu righe, costante unica, costanti separate, etc), delle opzioni di subfile, dei possibili contenuti di un campo opzione ( i tipici campi S/N e simili); inoltre può essere utile un censimento dei formati record “piatti” (tipo anagrafiche), dei formati con subfile, delle window, o dei formati di impostazione parametri (le cosiddette guide iniziali), delle schermate con più formati e così via, i tempi da destinare ai singoli tipi di formato può variare notevolmente
La terza domanda è: quanto tempo è necessario dedicare all’ “abbellimento” dei pannelli convertiti? In molti casi il risultato della conversione può non essere eccellente, o può risultare necessario un abbellimento, come incolonnare o spostare campi, cambiare colori o font, introdurre “frames” (i rettangolini di contorno a campi omogenei), o modificare costanti “criptiche” dovute dai limiti di caratteri del verde nero ( “cd.cl.”, “dt.ul.pag” e così via), limiti non più presenti su una interfaccia “visual”. Anche in questo caso alcuni strumenti richiedono di modificare il sorgente originale con piccoli “trucchi”, altri consentono la modifica direttamente sul pannello convertito. I tempi di preparazione variano dalla quantità di schermate da abbellire e dai tempi richiesti dallo strumento per i singoli interventi
La quarta domanda è: i tre precedenti punti richiedono il ciclo modifica/ compilazione/ test/ modifica? È evidente che se si tratta di modifiche ai sorgenti dell’applicazione originale la risposta è affermativa, ma è anche importante sapere se è così anche per le modifiche fatte con lo strumento; minore è il ciclo di modifica più breve sarà il tempo di intervento
La quinta domanda è: quanto tempo occorre per le verifiche finali? Questo tempo è legato direttamente all’applicazione, alla quantità di display file e alla complessità di variabili di visualizzazione e navigazione, ed è sicuramente misurabile indipendentemente dallo strumento di modernizzazione; mediamente servono dai due ai tre giri completi (secondo una media fatta sommando i pannelli verificati più volte con quelli per cui è sufficiente una sola verifica).
La sesta domanda è: quanto tempo è richiesto per le impostazioni e configurazioni di ambiente? Questi tempi includono la preparazione dei comandi di lancio nel nuovo ambiente applicativo grafico, i menu applicativi, il caricamento e gestione dei repository grafici etc. Non sono tra i tempi più significativi, ma è comunque importante comprendere quanto elastico sia il prodotto, se gestisce i dati di ambiente su AS400, su server Windows, su server HTTP; più è complessa la gestione dell’ambiente maggiore sarà il tempo di gestione, non solo all’avviamento, ma anche negli ordinari cicli di manutenzione.
ultima domanda : quanto tempo serve allo studio grafico e alla preparazione degli elementi visuali necessari? Questo aspetto è tipico di ambienti visuali e del web, quindi poco conosciuto in ambiente gestionale AS400, e per questo molto spesso sottostimato. È il tempo da dedicare alle prove di font, colori etc ma anche alla realizzazione di icone ed immagini a completamento; è strettamente legato alla qualità del risultato che si vuole ottenere. Ad es. diverse giornate per lo studio e la scelta grafica, da alcune giornate a settimane per i grafici nel caso si volessero disegnare sfondi o icone originali e univoche.
A questo punto, una volta individuate la/le applicazioni da convertire, ed una volta acquisita la conoscenza panoramica di alcuni strumenti di modernizzazione, sarete in grado di poter valutare una stima indicativa dei tempi di modernizzazione che, uniti agli obbiettivi che vi ponete come modernizzazione, vi permetteranno di individuare lo strumento più adatto a voi.
A proposito di TOUCH400:
- non richiede alcuna modifica preparatoria al codice sorgente dell’applicazione originale
- ha un suo sofisticato sistema di regole di conversione completamente configurabile dall’ utente, il quale consente un adattamento pressochè totale agli standard 5250 più disparati.
- consente di intervenire direttamente su attributi globali (colori font bordi sfondi etc) attraverso un potente sistema di stili paragonabile ai CSS; consente inoltre modifiche dirette ai pannelli convertiti, conservandole ad ogni successiva compilazione del display file originale; la modifica ai campi costanti è estremamente veloce: basta cliccare l costante e riscriverla direttamente. Uno dei punti di forza è una serie di contenitori per formati record con algoritmi di impaginazione dei dati che consentono di trasformare in modo radicale il posizionamento dei campi del formato.
- lavora direttamente sull’applicazione in esecuzione, si puo dunque modificare uno stile (colori, sfondi, fonts etc) e vederne immediatamente l’effetto, così come per modifiche a layout e incolonnamenti, e per limpostazione di regole ad effetto immediato, abbattendo quasi totalmente i tempi di impostazione del look visuale e di schermate particolari
- consente la verifica dell’applicazione contestualmente alla modifica di stili ed impostazioni regole, riducendo quindi i tempi.
- L’ambiente TOUCH400 risiede completamente su AS400, non utilizza database, l’ambiente viene gestito tramite comandi OS400 o comandi e tools proprietari di facile utilizzo per il sistemista/programmatore AS400
- TOUCH400 viene fornito con alcuni set di impostazione visuale preconfigurati; Prodigyt fornisce studio grafico e asset personalizzati su richiesta.
In sintesi TOUCH400 consente un impatto minimo nei tempi di conversione, minimo nei tempi di impostazione visuale, un impatto molto contenuto in fase di analisi degli standard e preparazione delle regole, strettamente legato alle peculiarità applicative; tali tempi possono variare in base all’ aggressività della modernizzazione, ovvero a quanto si desidera innovare la parte visuale e funzionale dell’applicazione. Si può affermare che TOUCH400 richiede tempi di modernizzazione fino a cinque volte inferiori rispetto a prodotti competitor.