Cerca
Close this search box.
Cerca
Close this search box.

Low-Code e gli standard ISO 15288 e 12207: dal foglio bianco a soluzioni digitali di qualità 

Come coniugare velocità e flessibilità nello sviluppo software con le esigenze strategiche aziendali 

Il low-code offre velocità e flessibilità nello sviluppo di applicazioni, ma per sfruttarlo appieno è necessario adottare un approccio strutturato basato sulle ISO/IEC 15288 e 12207. Nell’approfondimento, spieghiamo le ragioni della nostra scelta del low-code come strumento per lo sviluppo software e i criteri per massimizzarne il valore.

Non si scappa: la domanda digitale è in aumento.

An comunicato stampa dell’Osservatorio Digital Transformation Academy del Politecnico di Milano prevede un aumento dell’1,5% dei budget in ICT delle aziende italiane, confermando un trend positivo negli ultimi nove anni e superando le previsioni di crescita del PIL nazionale. 

Questi dati evidenziano una crescente domanda di prodotti e servizi digitali da parte delle aziende italiane, spinte dalla necessità di migliorare l’efficienza operativa, l’adattabilità al mercato , and l’esperienza del cliente. 

Un esempio concreto dell’aumento dell’efficienza operativa potrebbe essere legato all’eliminazione di tutti quei processi aziendali ancora basati su fogli Excel, spesso usati come collante o elemento di connessione tra due sistemi aziendali strutturati. I limiti di Excel sono evidenti soprattutto nella gestione individuale di grandi volumi di dati in quanto un foglio Excel manca di uniformità: ognuno organizza i dati a suo modo ed è difficile mettere i diversi file a fattor comune. La stessa mancanza di automazione è un limite, con errori manuali, perdita di dati e rallentamenti operativi. Inoltre, il replacement di sistemi legacy rappresenta un altro aspetto chiave: questi sistemi risultano costosi da aggiornare, difficili da integrare e limitanti per l’innovazione. 

Quando si tratta di rispondere alla domanda di soluzioni digitali, le aziende hanno due alternative principali: MAKE o BUY. Se sul mercato esiste già una soluzione che soddisfa pienamente le esigenze aziendali, la scelta più logica è BUY, ovvero acquistarla, poiché consente di risparmiare tempo e risorse. Questo approccio include l’utilizzo di soluzioni già pronte sul mercato, conosciute come COTS (Commercial Off-The-Shelf Software), che sono prodotti standard progettati per soddisfare bisogni comuni e disponibili per un’implementazione immediata.  

La scelta del BUY è la migliore a prescindere perché offre un ottimo TCO: va a ridurre nel massimo il costo di manutenzione e supporto della soluzione nel tempo, una voce di spesa che molto spesso viene erroneamente ignorata durante la fase decisionale. 

Tuttavia, quando la soluzione desiderata non è disponibile (e lo scenario non è così raro avendo le aziende processi e integrazioni interne molto complesse), l’opzione è MAKE, ovvero sviluppare in proprio. 

Le opzioni per sviluppare in proprio 

Se le aziende optano per la strada del MAKE, possono esplorare diverse opzioni che vanno dalla scrittura tradizionale del codice fino all’utilizzo di soluzioni più o meno avanzate che semplificano e automatizzano la generazione stessa di questo 

Per garantire la personalizzazione totale, i team IT di solito si appoggiano a team interni o esterni di sviluppatori e ingegneri del software, con tutti i limiti legati al fatto che non si lavora a risorse infinite e i tempi spesso non sposano le richieste del business 

Per accelerare i tempi di sviluppo ci sono delle strategie: gli sviluppatori possono sfruttare risorse online , and librerie di snippet di codice come Stack Overflow o altri database dove è possibile trovare risposte dettagliate e testate a problemi comuni. Oppure possono ricorrere all’Intelligenza Artificiale per automatizzare parte dello sviluppo. I modelli di AI, infatti, possono essere addestrati con dati di repository come GitHub, che è uno dei repository più grandi e completi per progetti software open source ed essere sfruttati come assistenti nello sviluppo with suggerimenti di ottimizzazioni, identificazione di bug , and completamenti automatici del codice. Ovviamente si tenga presente che questi modelli sono validi prevalentemente per applicazioni standard, quando si parla di soluzioni complesse o altamente personalizzate i loro limiti sono evidenti.  

Esistono poi sul mercato anche piattaforme specializzate per lo sviluppo e l’integrazione di app verticali come SAP, Salesforce o ServiceNow, ma anche qui le personalizzazioni sono limitate alle specifiche dell’ecosistema in cui si trovano. Nel caso di piccole modifiche possono andare bene, ma diviene sempre più difficile gestire sviluppi che si allontanino molto dallo standard di prodotto. 

Per poter avere una tecnologia che garantisca allo stesso tempo flessibilità di personalizzazione e velocità, la scelta più indicata è appoggiarsi alle tecnologie low-code e no-code perché grazie a strumenti visuali e intuitivi queste permettono di generare rapidamente codice mantenendo allo stesso tempo elevati livelli di adattabilità alle esigenze aziendali. 

Aspetti peculiari del low-code  

At WEGG riteniamo che queste tecnologie siano la migliore opzione per soddisfare la richiesta di soluzioni digitali in azienda perché permettono di: 

  • focalizzarsi non solo sullo sviluppo ma anche sulla manutenzione, in quanto il low-code consente di gestire centralmente modifiche e aggiornamenti senza interventi complessi. Questo può concretizzarsi in scenari molto frequenti nell’aggiornamento e nella manutenzione delle applicazioni, come la gestione dei bug, le migrazioni e i cambiamenti di specifiche. Il fatto che queste soluzioni integrino controlli di sicurezza preimpostati va già a ridurre la probabilità di avere bug ed errori di trascrizione. Consideriamo poi che la generazione automatica di codice segue standard di sicurezza predefiniti, riducendo di default il rischio di errori manuali. La natura modulare del low-code ha inoltre il vantaggio di semplificare la transizione a nuove piattaforme e infrastrutture e se ci sono cambiamenti, come l’aggiornamento dei sistemi operativi, possono essere affrontati centralmente aggiornando i connettori, rendendo queste piattaforme estremamente flessibili. 
  • essere agnostici nella scelta del target dove far girare l’applicazione: dato ensure quando si scrive codice manualmente è necessario decidere in anticipo l’ambiente di destinazione (scrivere codice per una applicazione web è completamente diverso dallo scrivere una app nativa iOS, ad esempio) ed eventualmente ri-fattorizzarla a posteriori se si sceglie diversamente, con il low-code questa flessibilità è intrinseca. Ne abbiamo parlato anche in questo articolo.  
  • essere più efficaci nella progettazione di flussi: nel low-code abbiamo uno sviluppo visuale (visual development), quindi essendo tutto visivo nei vari flussi e integrazioni rispetto a milioni di righe di codice, è più facile identificare e correggere errori logici, rendendo il processo di sviluppo più intuitivo e collaborativo. 
  • sostituire le librerie utilizzate alla versione aggiornata con un click: il solo aggiornamento della piattaforma di low-code e la semplice ri-compliazione delle app permette la sostituzione delle librerie con la loro versione aggiornata e quindi permette di rimuovere i bug, anche di sicurezza, presenti in queste. Tutto senza che ci si debba preoccupare di un eventuale cambio di interfaccia, problema che rimane in gestione alla piattaforma di low-code. 

 

Nella scelta della tecnologia low-code abbiamo optato per Mendix technology., perché è riconosciuta come leader nel Quadrante Magico di Gartner per lo sviluppo di applicazioni enterprise. Mendix, oltre a supportare i requisiti di velocità e personalizzazione richiesti a queste tecnologie, ha il vantaggio di integrarsi profondamente con le infrastrutture IT aziendali esistenti, supportando il principio delle architetture componibili.  

Segnaliamo a tal riguardo il fatto che offre un’integrazione nativa con SAP, con connettori che rendono semplice l’accesso ai dati e ai processi di business già presenti nell’ecosistema aziendale.  

La tecnologia low-code è un foglio bianco 

La tecnologia low-code, con tutti i suoi vantaggi in termini di velocità e flessibilità, rappresenta comunque un foglio bianco: la sua efficacia dipende interamente da come viene utilizzata. Per sviluppare applicazioni che raggiungano effettivamente gli obiettivi desiderati, è essenziale adottare un approccio ben strutturato.  

Questo richiede non solo competenze tecniche, ma anche una visione strategica che sappia applicare le software license managementnella gestione del ciclo di vita dei sistemi e del software. Una prospettiva limitata al solo software potrebbe non cogliere l’intera gamma di impatti che un cambiamento o una decisione potrebbe avere sull’intero ecosistema, inteso come insieme di hardware, software, persone e organizzazioni.  

A tal proposito ci vengono in aiuto gli standard ISO/IEC 15288 e ISO/IEC 12207 che offrono un framework integrato per rispondere a queste esigenze: la ISO/IEC 15288 si concentra sul ciclo di vita dei sistemi, suddividendo i processi in cinque categorie principali (Agreement Processes, Enterprise Processes, Project Processes, Technical Processes e Special Processes), mentre la ISO/IEC 12207 approfondisce il ciclo di vita del software come elemento fondamentale di questi sistemi.  

Entrambi gli standard evidenziano l’importanza di analizzare e gestire i requisiti non solo in relazione all’applicazione specifica, ma anche al contesto più ampio in cui il sistema o il software saranno integrati. 
 

Nella  ISO/IEC 15288, questa prospettiva emerge chiaramente nei Technical Processes, dove due processi fondamentali guidano la raccolta e l’analisi dei requisiti:

 

  • lo  Stakeholder Requirements Definition Process, che identifica e valida i bisogni espliciti e impliciti degli stakeholder, traducendoli in requisiti chiari, misurabili e verificabili. In questa fase si determina quali requisiti siano fondamentali, opzionali o desiderabili, tenendo conto di vincoli tecnici, economici e normativi. 
  • Il  System Requirements Definition Process, che trasforma questi requisiti in specifiche tecniche dettagliate, valutandone la fattibilità e garantendone la tracciabilità. Questo processo include attività come la scomposizione dei requisiti, l’analisi di fattibilità e il mantenimento della tracciabilità lungo il ciclo di vita. 

 

La  ISO/IEC 12207 approfondisce ulteriormente questo approccio, derivando i requisiti software dai requisiti di sistema e dagli stakeholder. Questi requisiti vengono classificati in due categorie principali: 
 

  • requisiti funzionali, che descrivono le funzionalità specifiche che il software deve fornire (ad esempio, “l’applicazione deve consentire l’autenticazione dell’utente”). 
  • requisiti non funzionali, che includono aspetti come prestazioni, scalabilità, sicurezza, usabilità e affidabilità. 

 

La raccolta iniziale dei requisiti dell’applicativo costituisce una baselineche funge da guida per l’intero sviluppo. Quanto più accurata è l’analisi e quanto più integrata è nel contesto del sistema, tanto più sarà possibile evitare incomprensioni, flussi non ottimali, ritardi e variazioni che potrebbero compromettere il progetto. 

Un ulteriore elemento centrale negli standard ISO è la tracciabilità bidirezionale dei requisiti. Ogni requisito deve essere collegato al componente software che lo implementa e verificabile tramite test specifici, assicurando che le funzionalità sviluppate siano coerenti con le esigenze definite e che eventuali modifiche siano gestite in modo controllato. 

At WEGG, quando affianchiamo i nostri clienti nella realizzazione di soluzioni digitali, adottiamo un approccio rigoroso basato sugli standard ISO citati prima, assicurandoci di redigere una baseline di requisiti chiara e completa. Questa baseline è il faro dell’intero progetto perché definisce in modo precisoobiettivi e deliverable e assicura che siano conseguiti correttamente.  

Grazie a questo approccio, la tecnologia low-code, da semplice foglio bianco, si trasforma in una soluzione che riflette fedelmente il disegno strategico immaginato dall’organizzazione 

02-s pattern02

Vorresti approfondire il nostro approccio alla digitalizzazione?

Contact us for a consultation!