Una storia affascinante - Perché il software AEP è sempre migliore I protagonisti raccontano come siamo passati dalla programmazione in assembler ...
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Una storia affascinante Perché il software AEP è sempre migliore I protagonisti raccontano come siamo passati dalla programmazione in assembler dei primordi al Devops, oggi stato dell'arte delle tecnologie per lo sviluppo del software
La qualità delle lavorazioni Per il software valgono regole molto simili a quelle della meccanica: le sue qualità sono strettamente legate anche alle tecniche impiegate per la sua lavorazione. In AEP abbiamo i migliori tecnici della bigliettazione elettronica e una lunga esperienza nello scrivere il software: ai venti anni della nostra storia si sommano infatti quasi altrettanti del Ramo Monetica che AEP ha acquistato nel 2016 da Finmeccanica Leonardo. Ma il software è oggi sempre più complesso e non bastano più semplicemente la creatività e la capacità dei singoli. E' indispensabile una solida organizzazione che, proprio come nella meccanica, riduca al minimo le tolleranze della lavorazione, verifichi i risultati della produzione e non permetta a quelle componenti che non rispondessero completamente ai criteri di qualità prestabiliti di arrivare dai Clienti. In questa piccola pubblicazione abbiamo voluto illustrarvi sinteticamente e con parole semplici l'evoluzione del nostro sistema per la qualità del software attraverso gli anni, partendo addirittura dalle origini, fino ad arrivare alle ultime tecnologie, per rendervi partecipi della cura che mettiamo nel realizzare i nostri applicativi.
Sviluppo &
implementazione
Anni Assembler
80 Linguaggio "difficile" e riservato
agli esperti. Sviluppo lento e con
molti errori.
Due facce della stessa medaglia
Siamo del tutto coscienti che ogni bug del nostro software potrebbe Linguaggio C/C++ Anni
provocare problemi ai nostri Clienti: biglietterie che si fermano, validatrici che
non convalidano, emettitrici self-service che non vendono, passeggeri che Un linguaggio molto più vicino a 90
noi umani ma che consente un
non entrano in metropolitana sono solo alcuni esempi dei possibili problemi pieno controllo dell'hardware.
che un software imperfetto può provocare.
Il software deve essere quindi robusto, sicuro, efficiente e deve richiedere
costi contenuti per la sua manutenzione ed evoluzione. Sistema operativo
Anni
Il processo della qualità non deve però limitarsi allo sviluppo del
software (Development) ma deve coinvolgere anche tutti i processi di
00 Un salto di qualità importante.
Mxm, il s.o. degli apparati AEP resta
in servizio fino ai giorni nostri.
implementazione (Operation), in pratica l'installazione e la configurazione
per un certo Cliente. Sviluppo e implementazione devono cioè andare a
braccetto, tendendo alla completa integrazione e automazione, così da
minimizzare la soggettività degli operatori e quindi la possibilità di errori. Controllo versioni Anni
La tecnologia che combina Development e Operation prende il nome di Il software non si sviluppa più da soli
ma in team. Si diffondono strumenti di
10
DevOps. Con essa i team di sviluppo e delle operazioni collaborano per controllo e collaborazione. Il test diventa
parte integrante del ciclo di sviluppo.
creare, sottoporre a test, distribuire e monitorare applicazioni con velocità,
qualità e controllo.
La nostra rincorsa alla qualità del software dura da oltre di 20 anni. Il
diagramma a lato riporta le tappe più importanti di questo percorso, che ha
Anni DevOps
subito una forte accelerazione negli ultimi anni e che abbiamo cercato di 20 I vecchi strumenti non bastano più per
la crescente complessità del software.
illustrarvi più in dettaglio nel seguito di questo documento. Un altro grande salto nella logica dello
sviluppo e dell'implementazione.
Dinosauri e
sacerdoti
Negli anni 70 la terra era ancora popolata dai dinosauri
dell'informatica. Si chiamavano mainframe ed erano delle
grandi infrastrutture, spesso realizzate in edifici dedicati da
IBM o altre grandi compagnie dell'informatica.
Essi fornivano i loro servizi in time sharing, attraverso
telescriventi, o in batch processing, portando pacchi di
schede perforate agli operatori e attendendo pazientemente i
tabulati prodotti da stampanti che a volte erano grandi come
il banco dei surgelati di un supermercato.
Erano proprio le stampanti che producevano quel particolare
odore, in quelle segrete stanze ove solo i "sacerdoti" della
Dea Informatica potevano accedere; un incenso tecnologico.
L'informatica era più che elitaria: anche il solo accesso
ai terminali andava conquistato, con il merito o con l'oro.
Talvolta servivano entrambi.
Noi siamo la rivoluzione "Non eravamo in tanti," racconta Giovanni Becattini, fondatore ed oggi AD di AEP, "ma già nei primi anni '70 ad alcuni di noi saltò in testa l'improbabile ghiribizzo di costruirsi un computer in casa, per rompere lo strapotere dei Centri di Elaborazione dei Dati (CED). A quell'epoca non ce ne rendevamo conto, ma eravamo semplicemente i precursori di quella rivoluzione dell'informatica personale che sarebbe diventata, da lì a pochi anni, una vera e propria onda incontenibile." Nel mentre che le obliteratrici meccaniche dormivano sonni tranquilli e non si presagivano niente, costruire un computer personale che rompesse la dipendenza dai templi e dai sacerdoti non era a quei tempi certamente facile. Se un computer di allora costava tantissimi milioni di lire, una ragione c'era: la tecnologia non offriva ancora strumenti adeguati per realizzare unità di elaborazione e memorizzazione di ragionevole semplicità.
Il mondo non sarà più lo stesso Nel 1973 la Intel presenta il microprocessor (l'italianizzazione "microprocessore" arrivò diversi anni dopo) che sconvolge completamente il mondo dell'elettronica e dell'informatica. In un solo chip una completa CPU, con prestazioni pari o anche superiori ai minicomputer dell'epoca, ma con un prezzo di soli pochi dollari. "Questo per noi fu un vero intervento quasi divino," continua Becattini, "tanto che potemmo, non solo coronare il nostro sogno di progettarci il nostro computer casalingo, ma anche di iniziare a produrre nel 1975 la serie Child di computer personali". In realtà, l'impatto di questa novità fu immenso, non solo per l'informatica personale, ma anche perché consentì di portare la capacità di elaborazione in ogni sorta di apparato: lavatrici, televisori, macchine fotografiche e tantissimi altri oggetti di uso quotidiano, tra cui quelli ...della bigliettazione!
Codice macchina: incomprensibile! La capacità di elaborazione si porta dietro ovviamente il software, che oggi sappiamo benissimo cos'è ma che all'epoca risultava abbastanza difficile da spiegare ai "non iniziati". Ma come lo si sviluppava allora, abbiamo chiesto a Becattini? "Beh, all'inizio era ...duretta! Usavamo semplicemente i codici macchina, di fatto dei numeri corrispondenti alle varie operazioni da eseguire. Sui minicomputer si potevano inserire usando una fila di interruttori presenti sul loro pannello, ma sui microprocessori dovremmo crearci "alla cieca" un programma chiamato Debugger, capace di dialogare con una telescrivente. Fu difficile ma ci riuscimmo. Scrivevamo il programma su fogli di carta usando codici mnemonici e poi lo traducevamo manualmente nei codici macchina. Solo dopo alcuni anni riuscimmo a far girare sui nostri trabiccoli dei programmi, gli assemblatori, capaci di tradurre il codice sorgente in codici macchina. Ci sembrò un progresso straordinario!"
Migliorare il dialogo Dialogare con un computer attraverso i codici macchina o il linguaggio assembler non era però alla portata di tutti. Una semplice operazione come la somma di due numeri poteva richiedere anche una giornata di lavoro. La prima necessità da superare per poter allargare il mercato degli utilizzatori fu quindi portare sui microcomputer personali dei linguaggi di programmazione più simili al linguaggio umano. Becattini, quando foste in condizioni di offrire questa forma di programmazione ai clienti dei vostri venerandi computer? "La corsa era partita, ed è proprio dal Microsoft BASIC per i microcomputer che partì la fortuna di Bill Gates. Ma all'epoca ancora non c'era e dovemmo arrangiarci. Noi non avevamo i genitori che affittarono a Bill un minicomputer per lo sviluppo e dovemmo scriverci il primo interprete di un linguaggio ad alto livello in codice macchina. Si chiamava RPN-8 ed era davvero molto primitivo. Ad esempio non riusciva ad interpretare le espressioni numeriche ed usava quindi la notazione polacca inversa. Però funzionò: un nostro cliente commercialista arrivò perfino a scriverci un programma di contabilità".
Arrivano i sistemi operativi "Nel 1975, ci mettemmo a progettare quel Modello T che molti storici ritengono essere stato il primo personal computer italiano, nell'accezione moderma del termine, e che diversi appassionati oggi raccolgono e restaurano", aggiunge Becattini. "Ebbe per l'epoca un notevole successo, pur costando quanto un'auto di media cilindrata, e arrivammo a produrne uno al giorno. La sua carta vincente fu di avere un sistema operativo a bordo. Gli utilizzatori non dovevano più scrivere tutto il codice da zero: le funzioni principali erano svolte dal SO, che essendo un prodotto standardizzato, permetteva di acquistare linguaggi di programmazione, elaboratori di testi, programmi di contabilità e tutto quello che l'industria mondiale cominciava a mettere a disposizione dell'informatica personale." Non stupisce quindi che, molti anni più tardi, si sia pensato di mettere un sistema operativo anche in una validatrice.
Gli apparati della bigliettazione Gli apparati della bigliettazione sono tra quelli che dalla rivoluzione del microprocessore hanno potuto trarre immensi benefici. Grazie ad esso possono diventare dei sistemi embedded, ossia incorporati, perché in essi la parte di elaborazione è letteralmente immersa nell'apparato stesso. Gli apparati elettromeccanici avevano, come ovvio, poche funzioni e fisse, ma neppure le prime macchine elettroniche erano facilmente aggiornabili. Essendo realizzate, come si dice, in logica cablata, non avevano software. Qualunque modifica richiedeva la modifica dei circuiti fisici. Con la concezione embedded, tutto cambia, grazie a quel magico componente detto software che permette loro di variare le proprie funzionalità entro ampi limiti senza necessità di dover procedere a modifiche della loro struttura. Per gli apparati di bordo, la strada è ancora lunga, ma è tracciata!
Il linguaggio C Gli sviluppatori software dei sistemi embedded seguono storicamente tecniche ben diverse da quelle dell'informatica tradizionale, più simili a quelle dei microcomputer che non dei PC. La "paura" è sempre quella di perdere il contatto diretto con l'hardware e con le singole operazioni del processore. Un sistema operativo aggiunge infinite possibilità, è vero, ma viene visto dai più come riparare un orologio con i guantoni da boxe. Lo sviluppo in linguaggio assembler, che offre il controllo più completo della piattaforma, presenta però dei grossi inconvenienti: richiede molto più tempo per lo sviluppo, dà molte possibilità di commettere errori ma soprattutto è legato a un processore specifico: cambiando processore, tutto il lavoro fatto non è riutilizzabile. Il linguaggio C fu sviluppato nei primi anni '70, ma gli sviluppatori dei sistemi embedded se ne erano tenuti lontani, un po' per i timori di cui sopra, un po' perché non disponibile per i microprocessori. Ma agli inizi degli anni '90, il software dei sistemi embedded aveva ormai cominciato a raggiungere livelli di complessità notevoli e gestirlo con l'assembler stava ormai diventando impossibile. La scelta di molti cadde proprio su questo linguaggio, e del suo successore C++, che negli anni diventerà patrimonio di tutti.
Mxm, il sistema operativo di AEP Abbiamo detto che un sistema operativo tradizionale in un apparato embedded era visto dagli sviluppatori come l'elefante nel negozio dei cristalli. Ma i benefici di un sistema operativo sono immensi. Semplicemente, agli inizi degli anni '90 non esistevano molti SO adatti ad operare su sistemi embedded. "Nel 1994 ero appena uscito dalla scuola", racconta Luca Coppolaro, responsabile del reparto Sistemi Operativi Embedded di AEP, "e conobbi Becattini e il suo famoso cane Otto. Stavano sviluppando un sistema operativo per impieghi industriali denominato Mxm e accettai con entusiasmo la loro proposta di collaborare. Dopo quasi 25 anni posso dire che non avrei mai immaginato, in quel momento, quanta parte della mia vita avrebbero avuto Mxm e l'AEP che sarebbe poco dopo nata." Sotto la guida di Coppolaro, Mxm divento un prodotto davvero eccezionale: compatto, stabile, veloce e potente, equipaggiò un gran numero di progetti industriali. Permetteva di realizzare un sistema minimo con soli tre chip e velocizzava moltissimo lo sviluppo delle applicazioni.
Tutti possono programmarmi! Mxm ha equipaggiato tutti gli apparati AEP fino al 2012, quando ha iniziato ad essere sostituito da Linux e sono ancora parecchie migliaia quelli che sono ancora in servizio con questo piccolo-grande sistema operativo. La validatrice AEP Futura 4/MX raffigurata qui a lato era nel 2006 un prodotto assolutamente innovativo. Non solo aveva il sistema operativo Mxm ed era programmabile in C/C++, ma introduceva un'altra importantissima novità, rimasta in uso in qualche posto fino ai giorni nostri. Era infatti dotata di un linguaggio di configurazione, denominato VCL (Validator Configuration Language) che permetteva di definire il comportamento della macchina in modo molto facile e intuitivo: parametri di funzionamento, titoli di viaggio, formati di stampa, formati dei file ecc. senza necessità di conoscere alcun linguaggio di programmazione.
Arriva Linux!
Nel 2006 AEP vince una importante gara estera e
decide di rinnovare la sua unità multifunzione, basata
su Mxm, dando vita al progetto CDB-6 PLUS, una
unità multifunzione che ha raccolto negli anni
molti successi e che, continuamente aggiornata,
rimane oggi ancora molto attuale.
"Negli ultimi anni", è ancora Luca Coppolaro
che parla, "le aspettative del mercato erano
cresciute non poco, mentre cominciava
a diventare possibile la realizzazione di
hardware molto potenti anche nei limitati
spazi che avevamo a disposizione.
Decidemmo quindi di saltare il fosso ed
utilizzare Linux, il sistema operativo open
source di tipo Unix-like, una scelta che si
rivelò poi del tutto vincente."Ma non basta dire Linux Nei sistemi embedded mission critical, come validatrici e computer di bordo, dove hardware e software sono fortemente interconnessi, non è possibile però adottare come sono le normali distribuzioni dei sistemi operativi. Molti dei problemi che un utente home o office non trova drammatici, risultano invece del tutto inaccettabili su apparati destinati ad operare fino a 24 ore al giorno e che svolgono compiti di rilevanza economica. AEP ha quindi creato un reparto, detto Embedded Operating System (EOS), dove operano tecnici di altissima specializzazione, competenti sia in materia di software che di hardware, che sviluppano e supportano le distribuzioni del sistema operativo Linux per renderlo adatto a equipaggiare gli apparati AEP. Essi sono costantemente al lavoro per eseguire test, sviluppare driver, risolvere problemi, studiare i componenti elettronici e garantire ai Clienti negli anni la continuità di servizio degli apparati.
La torre di Babele? Nel 1975, i primi microcomputer iniziavano la loro vita del tutto privi di software e chi lo sviluppava operava a diretto contatto dell'hardware, conoscendo ogni singolo bit. In quasi mezzo secolo, l'umanità ha continuato a sviluppare programmi sulla base di quelli sviluppati in precedenza, fino ad arrivare a livelli di complessità in un tempo inimmaginabili e difficili da gestire. "Nel passaggio dalla fase artigianale a quella industriale di AEP", continua Luca Coppolaro, "ci siamo trovati ben presto di fronte alle conseguenze di questa complessità, e già molti anni or sono abbiamo introdotto il sistema di controllo versioni (CSV) nel nostro ciclo di sviluppo, come strumento indispensabile dei team collaborativi, oltre al reparto dedicato esclusivamente al test". Grazie al CSV, ogni modifica al codice sorgente è tracciata da un sistema informatico ed è sempre possibile, in caso di necessità, ritornare a uno stato precedente del progetto.
Ci vuole metodo "Senza una metodologia chiara", afferma Andrea Mizzoni responsabile
delle tecnologie di sviluppo del software di AEP, "si rischia di dotarsi di
Un prodotto software ha un obiettivo semplice: conferire ai suoi strumenti, figure professionali e processi non utili al raggiungimento di
utilizzatori valore ed efficienza. Nel realizzarlo, l'obiettivo è di arrivare al quel "semplice" obiettivo. Senza un'adeguata strategia, si rischierebbe di
risultato che soddisfa i requisiti, attraverso un processo che coinvolga il aggiungere impropriamente persone e strumenti ai progetti, con l'unico
minor numero possibile di operazioni manuali. Ma raggiungere questo effetto di amplificare un possibile effetto caotico, finendo per realizzare
obiettivo è una missione molto complessa che necessita di adeguate un processo in cui tutti fanno qualcosa ma non la cosa giusta".
strategie e tecnologie.DevOps, la scelta di AEP "E' per questa ragione", continua Mizzoni, "che in AEP ci siamo oramai da tempo orientati verso la metodologia DevOps" DevOps nasce dalla contrazione di development e operations ed è un metodologia di sviluppo del software che punta alla messa in produzione del software attraverso una migliore comunicazione, collaborazione e integrazione tra gli sviluppatori e gli addetti al deployment. DevOps prende in considerazione l’intero ciclo di vita del prodotto software, dalla definizione dei requisiti alla messa in esercizio e punta su pochi, fondamentali strumenti, quali la gestione del progetto, il controllo versione, il build server, il package manager, arrivando a consentire il rilascio automatico delle applicazioni, supportando le varie figure professionali nel lavoro quotidiano, attraverso l’automazione e la misura delle prestazioni.
La user story: cosa vuole il Cliente? Premesso che il Cliente siamo spesso noi stessi, quando definiamo i requisiti che un nuovo modulo deve possedere, come viene descritto cosa il Cliente desidera? In AEP usiamo le User Story. Le User Story sono delle specifiche da condividere con il team di sviluppo, per stabilire cosa deve essere sviluppato. Perché non chiamarle semplicemente Specifiche Tecniche oppure Requisiti Funzionali? Il concetto più interessante che introducono le User Story è quello di mettere l’utilizzatore del nostro prodotto al centro dell’attenzione durante il processo di sviluppo. Pari importanza è data anche all’identificazione del bisogno, la "storia", che ogni funzionalità promette di soddisfare.
Gli inevitabili difetti In AEP usiamo suddividerli in bug, termine oramai di uso comune, e rework. • rework: è una non conformità rilevata internamente durante una delle fasi interne di validazione. Non ha impatti sulla operatività del campo in quanto la correzione dello stesso avviene solitamente entro la fase di validazione interna. • bug: è una difformità rilevata sul campo dall’assistenza interna AEP o dal cliente. User story, bug e rework (generalmente denominati task) vengono assegnati ai singoli sviluppatori e lavorati secondo un criterio di priorità. Lo stato di avanzamento dei task viene monitorato in uno strumento agile di gestione dei progetti software. Attraverso l’uso di dashboard è possibile monitorare quali e quanti task si trovino in uno stato di attesa, in corso di lavorazione oppure sono già stati completati.
Produrre solo codice di qualità il codice sorgente è quello scritto dal programmatore nel linguaggio di programmazione prescelto. E' facile intuire come un codice sorgente di bassa qualità, ossia non scritto nel severo rispetto di tutte le buone regole, possa dare origine a un'applicazione apparentemente completa e funzionante, ma porta ineluttabilmente a gravi problemi in fase di test o, peggio ancora, quando portato in campo. Uno degli scopi fondamentali dell’ingegneria del software è diventato quindi quello dell’analisi della qualità del codice sorgente. Grazie anche ad algoritmi di intelligenza artificiale, la tecnologia offre oggi validi strumenti da utilizzare durante la stesura del software, durante la fase di testing e anche dopo il completamento del prodotto, che permettono di prevenire moltissimi difetti o instabilità. "Grazie all'analisi di qualità", continua Mizzoni, "abbiamo ridotto drasticamente la difettosità delle nostre applicazioni ed accresciuto in misura rilevante la soddisfazione dei Clienti".
Costruire le applicazioni Per build (costruire) si intende il processo partendo dal codice sorgente, quello scritto dal programmatore nel linguaggio di programmazione prescelto, costruisce l'applicazione installabile. Con il build server, che non è un server fisico ma una collezione di processi, in AEP abbiamo reso possibile eseguire questo processo in modo completamente automatizzato, garantendo al tempo stesso l’esecuzione di test e l'analisi del codice sorgente per escludere eventuali vulnerabilità. Il build server non richiede intervento umano, pertanto gli sviluppatori possono concentrarsi nella parte creativa del lavoro, senza occuparsi delle fasi più tediose e ripetitive. L'automazione garantisce la riproducibilità del processo di build anche senza supervisione, estendendo la giornata lavorativa a 24 ore. Ad esempio, il build server può operare anche nottetempo, eseguendo dei test che possono protrarsi per tempi molto lunghi. "Abbiamo di conseguenza introdotto un vincolo importante: se il codice sorgente non supera tutte le fasi previste non verrà prodotta una applicazione installabile e pertanto un codice di qualità non accettabile non arriverà in esercizio."
Gestire i pacchetti Giornalmente, il build server produce moltissime versioni per
ciascuna delle applicazioni installabili. La domanda pertanto
diventa: chi gestisce questo vasto archivio?
Il build server trasforma il codice sorgente in una applicazione Il package manager (o artifact repository) è lo strumento che
installabile e le assegna un numero di versione. archivia tutte le diverse versioni di ciascuna applicazione
installabile.
Ogni cambiamento nel codice corgente produce un incremento nel
numero di versione, così da rendere rintracciabile la modifica. Mentre il build server dimentica cosa ha fatto nei giorni precedenti,
il package manager, come un buon bibliotecario, archivia tutto,
offrendo molte possibilità per ricercare efficacemente le diverse
applicazioni in una enorme mole di dati e tiene traccia sia delle
versioni ufficiali che delle release candidate, in quest’ultimo caso
archiviandole solo per un periodo ragionevolmente breve.
Risulta pertanto evidente come il package manager sia il perfetto
assistente per il rilascio automatico. Solo esso può esporre l’intero
catalogo delle applicazioni e delle versioni che un Cliente potrebbe
voler installare sul proprio sistema.User
Story
Ci basta un click! 1
Sviluppo
Produzione
2
Il software moderno è modulare. Una suite completa come ET, Controllo 6
The Easy Ticketing non potrebbe mai essere sviluppata come versioni
un’unica applicazione. ET è una sinergia di diverse applicazioni Test
software, ciascuna con proprie responsabilità e missione. Ma sono
tante: decine e decine…e, fortunatamente, molti Clienti desiderano
averle tutte o quasi! La domanda pertanto diventa: come installare
DevOps
decine di applicazioni software, ciascuna con la propria versione, Ciclo dello sviluppo
3
sui sistemi del Cliente? L’implementazione di AEP
Qualità 5
del codice
AEP offre oggi il rilascio automatico, ovvero una modalità
Rilascio
operativa che permette di svolgere il suddetto compito con un automatico
semplice gesto: un click!
4
"Siamo consapevoli", afferma Mizzoni, "che l’unico modo per Build
installare numerose applicazioni software sia mediante una
sequenza di operazioni definita, predicibile e idempotente. Grazie al
rilascio automatico, siamo in grado di assicurare ai nostri clienti
un sistema di bigliettazione installato e configurato in maniera
Tempo impiegato con il rilascio automatico
corretta e completa, mentre, dal canto nostro vogliamo usare rispetto a quello manuale:
bene il nostro tempo per progettare le applicazioni di domani. • -70% per il primo rilascio;
Non possiamo permetterci di perderlo con operazioni manuali • -85% per i successivi.
tediose, ripetitive e... fonte di possibili errori!" La complessità del rilascio automatico resta
costante al crescere del numero di Clienti.
Il rilascio automatico viene utilizzato dall’am-
biente di sviluppo a quelli di produzione al
fine di assicurare standard di qualità elevati.4
Passi per entrare
rapidamente in servizio
Conclusioni grazie a Devops
Vi ringraziamo per averci seguito fino in fondo. Speriamo di avervi
comunicato quanto AEP sia impegnata con l'obiettivo di rendere
sempre migliori e più fruibili i suoi prodotti. Grazie al nostro
progetto Devops si ottengono infatti:
• accelerazione del ciclo di sviluppo; Messa
• riduzione dei costi; in servizio
• maggiore aderenza alle specifiche;
Rilascio
• minori tempi di entrata in servizio; Sviluppo
varianti Messa in servizio
• minimizzazione dei fermi dovuti a difettosità del software. Grazie all'organizzazione
Progetto di AEP, è possibile
Nei nostri prodotti sono concentrati centinaia di anni uomo di esecutivo raggiungere in tempi più
brevi la fase di esercizio,
Rilascio automatizzato con un minor numero di
lavoro. Ci rendiamo conto che non è possibile in delle semplici Come è stato indicato in inconvenienti e quindi con
brochure informative trasmettere quanto know-how abbiamo Sviluppo delle varianti questo documento, la fase
del rilascio è molto delicata,
grandi benefici per il Cliente
e anche , ovviamente, per
accumulato in tutti questi anni, grazie anche all'acquisizione del I moduli software AEP sono
progettati per tener conto di
in quanto spesso si tratta
di installare parecchie
la stessa AEP.
Ramo Monetica di Finmeccanica/Leonardo. Project Management
L’avviamento di un nuovo sistema
moltissime condizioni di utilizzo
e richiedono, nella maggior
decine di moduli. Il rilascio
automatizzato del Devops
di bigliettazione elettronica è un parte dei casi, solo operazioni di rende incredibilmente più
Saremo quindi lieti di aprirvi le nostre porte, mostrarvi i nostri processo complesso che coinvolge
tutte le aree della Compagnia. Il
configurazione. Qualche variante è
però spesso indispensabile. Ecco
semplice questa fase,
permettendo di risparmiare
stabilimenti e le nostre sale prova, mettervi in contatto con i Project Management AEP permette quindi che i benefici della tecnologia
Devops diventano importanti e
tempo, costi e problemi.
di definire e raggiungere gli obiettivi
nostri Clienti e di accogliere i vostri suggerimenti. del progetto, rispettando i costi permettono di ridurre notevolmente il
numero dei possibili problemi.
e i tempi previsti, ottimizzando
l’allocazione delle risorse, mitigando
Vi aspettiamo. i rischi e risolvendo i problemi che
via via si manifestano.
Dal progetto all’esercizio
Presto e benePoland Italy Romania
France Turkey
Spain Israel
Canada Kazakhstan
Portugal Egypt
Mexico India
Martinica Algeria
(Francia)
Ecuador Senegal
Ticketing solutions
AEP Ticketing Solutions
Via dei Colli, 240
50058 Signa (Firenze, Italia) Doc. P/N 740559.E00.IT
+39/055.87.32.606 10/2020
www.aep-italia.itPuoi anche leggere
