Debito Tecnico Questo Sconosciuto

BITMAT CBR LINEA EDP CD&V TOP TRADE SYSTEM NEWS WINDOWS NET 2.1kLikeLike

Cerca... Cerca

SIGN IN / REGISTRATI

NEWSLETTER

SearchLineaEDP » Mercato

CIO MERCATO TECNOLOGIA VERTICAL ATTUALITÀ RUBRICHE

LineaEDP » Mercato

Agile, debito tecnico, inspearit, programmazione, SQALE

Debito tecnico, questo sconosciuto Leggi più tardi

di Massimiliano Cassinelli

Non sempre è necessario completare un progetto, ma occorre ottimizzare il lavoro “non fatto”

18/11/2013

Inutile nasconderlo: il software perfetto non esiste. Qualunque sistema, dal più semplice al più

complesso, ha immancabilmente un aspetto non ottimizzato. Una situazione dovuta a molteplici cause:

dalla mancanza di tempo alla ridotta disponibilità di risorse economiche e tecniche, passando attraverso

aspettative troppo elevate ed effettivi limiti dei sistemi operativi.

Qualunque carenza, però, ha immancabilmente un costo, in termini di efficienza, efficacia e successiva

manutenzione necessaria…

Come un qualunque debito, inoltre, il suo costo (anche economico) aumenta nel tempo, a causa dei

rallentamenti e delle inefficienze introdotte sin dalla fase di installazione. É questo il cosiddetto “debito

tecnico”, una sorta di metafora per far capire, sia agli sviluppatori che ai non addetti ai lavori, che un

intervento non ottimale sul software ha sempre un costo economico. Inoltre, come ogni debito, deve

essere ripagato con gli interessi.

Oltre agli errori e alle carenze, inoltre, il mancato raggiungimento dell’obiettivo è dovuto anche ad

autentici errori nella definizione dell’obiettivo stesso, con il tentativo di inserire funzionalità non

necessarie, ma che distolgono l’attenzione dall’autentico scopo di una soluzione, aggravando

ulteriormente la situazione.

La misura del debito

In questo ambito, come spiega Pascal Jansen, Managing Director & Partner

di inspearit, il primo parametro da valutare è rappresentato dalla qualità del

software. Un concetto difficile da definire, che può essere calcolato sulla

scorta di una metrica SQALE - Software Quality Assessment based on

lifecycle Expectations. Si tratta, in pratica, di un metodo di valutazione di

un’applicazione software sviluppato per valutare oggettivamente il codice

sorgente di un’applicazione.

Una simile valutazione si basa, tipicamente, sull’analisi di tre specifici aspetti:

◾ Qual è la qualità del codice sorgente che gli sviluppatori hanno consegnato?

◾ Il codice sorgente può essere facilmente sottoposto a evoluzione e manutenzione, convertito per altri

Altro in Mercato, Portale News, Posizione

Home-Page

> zEnterprise, nuove funzionalità per la business analytics e

il cloud computing

> Proteggere le aziende dagli attacchi DDoS: un'opportunità

unica per ISP e MSSP

> Riconoscimento per Barracuda Backup

> Eito: crescono solo gli smartphone

> Nuove strategie per la protezione dei dati con EMC

I più letti

> Il Cobit aiuta la governance

> Passworld 2013 - la cloud experience proposta da

Passepartout

> Nuvola e vendite quale futuro

> PEC gratuita, scadenza prorogata

> PEC gratuita, scadenza prorogata

> Passpartout presenta la nuova tecnologia Undercloud e

idesk HTML5

La nostra newsletter

Iscriviti alla nostra newsletter

Iscriviti

Pagina 1 di 3Debito tecnico, questo sconosciuto | LineaEDP

09/02/2014http://www.lineaedp.it/news/6128/debito-tecnico-questo-sconosciuto/

◾ Cosa è migliorato, o peggiorato, tra due versioni dello stesso codice?

Come si percepisce da questi quesiti, SQALE gode il vantaggio di essere un metodo generico,

indipendente dai linguaggi di programmazione e dagli strumenti di analisi del codice. Essendo pubblicato

con licenza “Open Source”, inoltre, può essere utilizzato e implementato negli strumenti di analisi

automatica del codice. Inoltre il metodo, sviluppato da inspearit, viene correntemente utilizzato da

diverse aziende ed è implementato da vari strumenti di analisi statica del codice.

La perfezione non esiste

Dato per assunto il fatto che non esiste il “perfect code”, inspearit è riuscita

definire il “right code”. “Proprio identificando la cosiddetta area di ‘codice

corretto’ – sottolinea il Business Director Roberto Davico - si possono

riconoscere le caratteristiche che rendono una soluzione comunque

accettabile e adeguata alle effettive esigenze del committente”. Al contrario,

quando gli attributi non vengono rispettati e lo stato dello sviluppo ricade

nell’area cosiddetta “not right” la conseguenza è una riduzione della

produttività, che corrisponde a un “interesse” da pagare.

Proprio muovendosi all’interno di un simile schema, il metodo SQUALE fornisce un indicatore sintetico e

facilmente integrabile con il dashboard del management. In questo modo i decisori aziendali possono

valutare il costo necessario per colmare la presenza di un debito tecnico, portandosi nell’area di

accettabilità, senza necessariamente raggiungere le condizioni ideali. Scrivere il “perfect code”, infatti,

richiederebbe un costo di sviluppo eccessivamente elevato.

All’atto pratico, come spiega Jansen, SQALE “permette di valutare i costi necessari per rimuovere il

debito e i potenziali danni in caso di mancata rimozione”.

Questo significa che, attraverso due modelli di stima, è possibile trasformare le violazioni in costi. Un

primo modello, basato sulla natura tecnica della violazione, definisce infatti il debito tecnico, mentre un

secondo modello, in grado di valutare la severità della violazione stessa, rende conto dell’impatto sul

business.

Un simile metodo assume un’importanza fondamentale soprattutto nei progetti più complessi. In un

emblematico esempio citato da Davico, l’analisi effettuata da SQALE ha identificato che, a fronte di oltre

58mila linee di codice di un programma in fase di sviluppo, solo l’11% costituiva un effettivo debito

tecnico legato a violazioni bloccanti. Questo significa che, spendendo circa 157 giorni/uomo

correttamente indirizzati, sarebbe stato possibile eliminare tutte le situazioni critiche, riducendo in

maniera significativa l’esposizione al rischio. Ciò ha messo a disposizione degli utilizzatori una soluzione

già adeguata alle loro esigenze, anche se ottimizzabile sotto alcuni aspetti comunque secondari. In

questo modo, inoltre, qualunque intervento risulta perfettamente mirato e specifico, o correggendo

tempestivamente i principali problemi e consentendo il rispetto dei tempi di sviluppo.

Il tutto anche in considerazione del fatto che una soluzione software è soddisfacente quando ha

conseguito l’80% degli obiettivi. Un valore che viene raggiunto in tempi molto più rapidi se si opera

attraverso il cosiddetto sviluppo incrementare (feature driven), che permette di misurare l’avanzamento

in prodotto software funzionante. In tal modo è possibile interrompere l’attività prima della fine del

progetto, quando l’80% del valore è stato creato, massimizzando così il lavoro “non fatto”.

Una programmazione Agile

Ottimizzare i processi di sviluppo significa sfruttare i benefici dell’agilità nell’ambito dell’Ict. Agile, infatti, è

un paradigma che sposta l’attenzione dai processi di realizzazione del software alla produzione di valore

per il cliente. Questo cambio di prospettiva è supportato nei team agili da tecniche di software

engineering scelte in base al contesto organizzativo e agli obiettivi di business. L’adozione delle tecniche

agili implica la creazione di un ambiente collaborativo e l’esercizio di un processo di project management

in grado di adattare lo scope del progetto in sintonia con le esigenze del cliente. Un ambito nel quale

inspearit ha sviluppato, negli anni, la competenza necessaria per curare la costruzione e la diffusione,

all’interno delle organizzazioni, del mindset Agile attraverso piani di transizione che bilanciano agilità e

disciplina, in accordo alla complessità dell’organizzazione e al contesto nel quale essa opera. L’adozione

dei metodi agili, inoltre, avviene in modo incrementale, coerentemente con i diversi livelli di maturità dei

processi organizzativi, garantendo significativi ritorni dell’investimento a breve termine.

© Riproduzione Riservata

10

<< Torna alla home

Ti potrebbero interessare anche:

◾ > Linea EDP > Cio > Il cloud questo sconosciuto.

◾ > Linea EDP > Mercato > Dematerializzazione delle informazioni: questo il futuro.

◾ > Linea EDP > Attualità > Ecco come si diventa consulente tecnico per il tribunale.

◾ > Linea EDP > Cio > Scalabile e flessibile.

Mercato > Autodesk acquista VSR.



Sezioni

CIO

MERCATO

TECNOLOGIA

VERTICAL

ATTUALITÀ

Rubriche

COVER STORY

CASE HISTORY

REPORT

LineaEDP Channel

REPORT

INTERVISTE

TECNOLOGIE

TALKING CIO

FORMAZIONE

Link utili

VIDEO DIZIONARIO

DOSSIER ON DEMAND

JOBS FOR IT

MAPPA DEL SITO

Seguici

NEWSLETTER

RSS

CONTATTACI

2012 © MAT EDIZIONI P.IVA 06538170967 TUTTI I DIRITTI RISERVATI

REDAZIONE / PUBBLICITÀ / MAPPA DEL SITO

POWERED BY NET UNO

«La nuova era delle app “cognitive” con Watson

La rivoluzione digitale del Retail: ecco il Negozio 2.0»

Lascia un Commento

Occorre aver fatto il login per inviare un commento



Debito Tecnico Questo Sconosciuto

Business

Transcript of Debito Tecnico Questo Sconosciuto