Piano di rimedio: obiezioni ricorrenti e motivi per implementarlo

By on
 

Un Piano di Rimedio consiste nel risolvere quelle violazioni nel codice sorgente applicativo che mettono a rischio la corretta esecuzione dell’applicazione in termini di Robustezza, Efficienza e Sicurezza. I motivi più urgenti per implementare un Piano di Rimedio sono quelli inerenti alle violazioni di Sicurezza. Ma quando le tecnologie e l’ambiente tecnologico garantiscono di per sé una buona copertura riguardo alle problematiche di sicurezza, allora sorgono alcune obiezioni.

Spesso le obiezioni principalii riguardano soluzioni implementate con tecnologie più antiquate, come COBOL, DB2, RPG, NATURAL, ecc…, meno frequentemente sulle tecnologie più recenti. In generale, più la tecnologia è giovane, meno resistenza c’è al miglioramento applicativo.

Le motivazioni addotte per giustificare tali obiezioni sono le più disparate, nel seguito alcuni esempi che riassumono alcuni dei casi incontrati più frequentemente.

arrogante-1Conosco molto bene il codice: le violazioni che mi state indicando, fanno riferimento ad una modalità di scrittura del codice sorgente realizzata ad hoc, per ragioni di praticità.

Porto un esempio di questo caso: evitare di utilizzare le MOVE TRUNCATE (COBOL). Questa istruzione sposta le informazioni da un campo più grande ad uno più piccolo, troncando implicitamente i dati che eccedono la lunghezza del campo più piccolo.
Tale pratica è estremamente pericolosa, perché in caso di modifica del campo più lungo, si possono avere ripercussioni su gran parte del codice sorgente. Il problema, infatti, è più subdolo di quanto si pensi, in particolare se la modifica crea corruzione nei dati di arrivo, potrebbero esserci corruzioni sui dati del Database, e non è detto che si evidenzino degli errori a runtime. In tali casi, quando in seguito l’errore viene individuato, il lavoro di recupero delle informazioni corrotte e della gestione del problema risulta estremamente oneroso. Il pericolo è inoltre presente quando sono necessarie modifiche alla strutura dei dati, che devono essere controllati su tutto il codice laddove si utilizzi la MOVE TRUNCATE.

È accettabile un rischio del genere per l’azienda, a valle di una pratica di programmazione che, se modificata, può evitarlo?

3-1Le violazioni che ci state evidenziando non possono essere risolte, perché, se dovessimo affrontarle tutte, l’effort costerebbe di più che l’applicazione stessa.

Il fatto di non poter risolvere tutte le violazioni, non significa che la pratica non possa essere modificata da un certo momento in poi. Ci sono, inoltre, metodi di generazione dell’action plan di rimedio, realizzati in modo che tengano conto delle priorità degli interventi. Ad esempio considerare prioritarie le transazioni più utilizzate o i programmi più richiamati nell’applicazione. 


miopeLe violazioni di performance che ci state evidenziando hanno un costo infimo sia per il processore, che per la memoria utilizzata, quindi possiamo ignorale.

È vero che il costo unitario di certe operazioni in memoria ha un basso costo, ma se ripetute molte volte al giorno, su un numero elevato di utenze, può avere un impatto importante sulle risorse elaborative.
Spesso sono coinvolti su questo tipo di violazioni i database. In questo caso l’utilizzo scorretto delle risorse ha un impatto maggiore delle violazioni in memoria.
L’impatto sui costi risulta essere diretto, in quanto, sulle tecnologie in oggetto, le licenze dell’hardware sono basate sui MIPS e sulla RAM necessaria. Spesso questi costi sono ignorati perché non in carico direttamente alla business unit di sviluppo.
In questo caso l’impatto più evidente si ha anche sulle tecnologie più recenti, in particolare quelle che coinvolgono application servers per applicazioni web. Anche in questo caso la soluzione più spesso adottata è incrementare la RAM e i processori degli application servers, salvo poi scoprire che il problema non è risolto ma si ripresenta, anche se più raramente, perché la causa è differente; un esempio può essere il rilascio di risorse non effettuato in modo corretto.

furbo1Quando sviluppiamo facciamo prima a prendere un programma già esistente, copiarlo e modificarlo. In tal modo abbattiamo i costi di sviluppo.

La pratica del cut & paste può funzionare se si parte da un template verificato da tutti i punti di vista: robustezza, efficienza, sicurezza. Se si prende come sorgente di partenza un programma funzionalmente simile a quello che dovremo sviluppare, avremo tutta una serie di programmi copiati che contengono ripetizioni di codice e potenzialmente, già in partenza, una serie di problemi.
Il problema non è solo la razionalizzazione; infatti, immaginiamo di avere una variazione della normativa legale che comporta una modifica ad un codice sorgente, il quale a sua volta è stato copiato da un programma simile: come potremo ricordarci tutti i programmi che debbano essere modificati in base alle specifiche? Spesso, agendo in tal modo, si dimentica qualcosa e si hanno problemi di corruzione di dati, difficilmente identificabili fino a disastro avvenuto.

Quelle descritte sopra sono solo alcune delle obiezioni incontrate, ma per l‘azienda spesso è di fondamentale importanza affrontare tali problematiche.

CAST aiuta ad indentificare i problemi, ordinarli secondo una priorità definita e creare degli action plan di rimedio, che potranno essere monitorati nelle misure delle versioni successive dell’applicazione che è stata corretta secondo gli action plan definiti.
Tutti gli stakeholders hanno così a disposizione uno strumento per identificare i rischi nel software, affrontarli e monitorarne il miglioramento, o impedire che peggiori nel tempo.

 

 
Custom social sharing