Agile Life

ottobre 2013 - Post

Critical Mass of Software System: fear effect and CMSSi

Nel precedente post abbiamo parlato del Critical Mass of Software System (CMSS), definendolo come:

“il fattore di complessità che separa la convenienza di manutenere ed estendere il sistema con quella di riscriverlo interamente”

ed evidenziando l’opportunità di utilizzare pratiche Agili/Lean per aumentare lamanutenibilità del software e gestire il debito tecnico, primi di elementi della governance della CMSS.

In questo post chiuderemo il cerchio parlando del terzo elemento che condiziona la Massa Critica, ovvero il “business”, intenso come quella componente aziendale poco interessata alle questioni tecniche ma concentrata su quelle economiche. Nonostante in un’azienda spiccatamente Agile/Lean technicality e business dovrebbero essere fortemente connesse, quasi a formare un uroboro, purtroppo la realtà è ben diversa e bisogna tenerne conto.

Quindi, il problema con cui dobbiamo confrontarci è: come facciamo a convincere il nostro business a supportare azioni che aumentano la qualità del software, sacrificando, spesso, tempo e risorse (e quindi aumentando i costi)? Un esempio: la necessità di abbattere il debito tecnico potrebbe richiedere la necessità di effettuare un refactoring per aumentare la qualità del codice scritto, introducendo un nuovo design pattern. Se il software ha superato i test (in particolare di accettazione), da un punto di vista funzionale tale azione non introduce nessun valore immediatamente percepibile, ma ne aumenta i tempi di sviluppo. Chiaramente il sistema ne guadagna, al minimo, in manutenibilità.

Laddove vengano adottate tecniche di riduzione del debito tecnico, siamo difronte ad un Delay Point, che graficamente abbassa la linea dei costi di manutenzione, ritardando il punto di massa critica.

critical mass delay

Delay Point

Per convincere il management, possiamo sfruttare “l’effetto paura” (fear effect), associato al fattore di Massa Critica e al rischio di dover ricominciare da capo poco dopo il rilascio della prima versione del sistema prodotto. Meglio ancora se il tutto è presentato in forma grafica.

A questo punto ci scontriamo con il problema, già evidenziato nel post precedente, di trovare un modo per stimare il punto di Massa Critica, esercizio che attualmente, allo stato dell’arte delle tecnologie informatiche, non è ancora realisticamente possibile. Quello che invece voglio proporre è il calcolo di un nuovo valore che definiremo Indice di Massa Critica del Software (Critical Mass of Software System Index, CMSSi), ovvero un indicatore compreso tra 0 e 1 che indica la probabilità di deferimento del punto di CMSS.

Il modello di calcolo del CMSSi, definito in base alla mia personale esperienze e chiaramente migliorabile, è il seguente:

CMSS = (Delivery Time / Software Complexity) + Team Maturity

con Team Maturity = (Project Numbers / Co-working Years) * Skills Factor

in cui:

  • Delivery Time = tempo disponibile per lo sviluppo del progetto (in anni solari);
  •  Software Complexity = Complessità stimata del progetto espressa in Story Point;
  • Team Maturity, il grado di maturità raggiunto dal Team in quanto tale

o   Nel caso di costituzione di un nuovo Team, il rapporto (Project Numbers / Co-working Years) è considerato pari a 0, annullando di fatto anche il peso allo Skills Factor. Ciò è assolutamente in linea con il mondo Agile/Lean in cui l’individualità lascia il posto al Team;

o   Lo Skills Factor indica il peso delle professionalità presenti nel team con un delta di valori ammissibili tra 0 ed 1, maggiorato di 0,1 per ogni figura senior.

Il modello evidenzia come il CMSSi sia direttamente proporzionale al tempo disponibile e inversamente proporzionale alla complessità del software che si sta realizzando. Inoltre la maturità del Team influisce in modo lineare.

Facciamo alcuni esempi:

 

  • ProgettoA:
    • Delivery Time = 6mesi = 110 gg
    • Software Complexity = 400 Story Point
    • Team Maturity = (1/2)*0,4 = 0,2
      •  CMSS = 110/400 + 0,2= 0,475
  •  ProgettoB:
    • Delivery Time = 1anno = 220gg
    • Software Complexity = 400 Story Point
    • Team Maturity = (1/2)*0,2 = 0,1
      • CMSS = 220/400 + 0,1= 0,65
  • ProgettoC (Team con meno di un anno di lavoro congiunto)
    • Delivery Time = 1anno = 220gg
    • Software Complexity = 400 Story Point
    • Team Maturity = (0)*0,2 = 0
      • CMSS = 220/400 + 0 = 0,55
  • ProgettoD (progetto con un Delivery Time assolutamente insufficiente)
    • Delivery Time = 1mese= 20gg
    • Software Complexity = 400 Story Point
    • Team Maturity = (1/2)*0,2 = 0,1
      • CMSS = 220/400 + 0,1= 0,15

 

Utilizziamo ora il CMSSi per convincere il proprio business della necessità di tener conto del fattore di massa critica, sfruttando due grafici semplici ma, al contempo, ricchi di significato.

Prendiamo il precedente ProgettoC, il cui indice è 0,55:

critical mass cmssi 050

CMSSi 0,55

Se allo scenario base del ProgettoC, concediamo al Team altri 6 mesi (110gg circa), affinché possano colmare le lacune dovute al fatto che si tratta di un Team neo-costituito, il CMSSi diventa il seguente: 330/400 + 0,1 = 0,925, dilatandosi molto.

critical mass cmssi 09

CMSSi 0,925

Graficamente il risultato è decisamente evidente e difficile da ignorare.

A questo punto abbiamo convinto il business? Probabilmente no, ma abbiamo uno strumento in più per confutare le nostre asserzioni e spingere l’azienda ad investire sulla qualità.

Prima di chiudere è utile evidenziare che il modello proposto per il calcolo del CMSSi non esclude che l’indice possa essere maggiore di 1. In tal caso le risorse spiegate per il progetto sono probabilmente eccessive e si può procedere ad una loro rivalutazione a ribasso, con estrema felicità del management.

 

[FELICEPESCATORE.IT]

Critical Mass of Software System: quando la qualità del software significa manutenibilità

Critical Mass of Software System, ovvero il fattore di complessità che separa la convenienza di manutenere ed estendere il sistema con quella di riscriverlo interamente.
Per quanto poco noto come nel mondo informatico, il concetto di Massa Critica è sicuramente un elemento di management di forte significato, in grado di scatenare dinamiche di gestione non indifferenti. Si tratta, infatti, di determinare se, su un dato sistema, è ancora economicamente conveniente effettuare manutenzione evolutiva piuttosto che procedere ad una sua completa riscrittura.

critical mass

Figura 1 - Critical Mass

Quello che emerge in modo empirico (e statistico) è che tanto migliore è la qualità della soluzione realizzata (sia da un punto di vista della codifica che dell'ALM), tanto più si riesce a deferire nel tempo il punto di Massa Critica, traendo maggior Valore dall'investimento fatto (ROI) e spalmandone il costo di gestione (TCO) su un periodo di più lunga durata.
In questo contesto, l'adozione di pratiche Agile consolidate come Continous Integration, favoriscono la qualità della soluzione che si sta realizzando. Inoltre, una corretta applicazione di una specifica metodologia, consente di mitigare il problema del Technical Debt (Debito Tecnico), che, nel medio periodo, porta ad una rincorsa continua della manutenzione correttiva a scapito di quella evolutiva.
Si intuisce agevolmente come l'utilizzo delle "pratiche di qualità", tipiche del mondo Agile/Lean, permettano di appiattire la curva dei costi della manutenzione evolutiva, mantenendo decisamente marcato il delta rispetto a quello di riscrittura (fig. 2). Parliamo ovviamente di: continuous integration, test-driven-development, behaviour driven development, continuous refactoring, ecc.

critical mass delay

Figura 2 - Ritardare il punto di Massa Critica

Soffermandosi un attimo sulla figura 2, nelle prime fasi si nota una condizione curiosa: il costo di riscrittura è minore di quello di evoluzione, come mai? Il motivo è abbastanza semplice ed è da ricercarsi nell'Effort necessario ad implementare l'infrastruttura di supporto alle attività di manutenzione, come, ad esempio, le utility del sistema di ALM incaricate del testing automatizzato.
Nella realtà, per quanto si voglia gestire il debito tecnico accumulato, ne esiste sempre un certa percentuale che si decide di tollerare onde evitare che il delivery del progetto si protragga troppo nel tempo. Tipicamente, i Team decidono, ad intervalli più o meno cadenzati, di gestire o trascurare momentaneamente il debito tecnico accumulato, creando un effetto molla che, visivamente, trasforma il grafico precedente come segue:

critical mass final

E' subito evidente che in questo scenario la condizione precedentemente illustrata (riscrittura inizialmente più conveniente dell'evoluzione) scompare immediatamente.
Realisticamente, oggi, non è possibile effettuare una stima di quando si raggiungerà il punto di Massa Critica, essendo i fattori che lo determinano praticamente non quantificabili. Se anche provassimo a fare un tale esercizio, chi ci dice, ad esempio, che in un certo istante T il successo della nostra soluzione sia tale da trasformare il Team con nuove competenze stravolgendo, di fatto, quanto ipotizzato?
D'altro canto, però, il concetto di Massa Critica è sicuramente utile a giustificare l'investimento nelle suddette pratiche di qualità e nelle metodologie Agili, soprattutto se abbinato all'esperienza accumulata, dove pesano, soprattutto, i fallimenti e l'impossibilità di sfruttare fino in fondo gli investimenti fatti sulle precedenti attività di sviluppo.

 

[FELICEPESCATORE.IT]

Architetture SOA: il focus su integrazione e interoperabilità

Di SOA si parla ormai ovunque e spesso se ne abusa quale “panacea di tutti i mali”, soprattutto quando si ragiona in termini di interoperabilità tra sistemi spesso disomogenei.

Non volendo entrare nel cuore delle Service Oriented Architecture, è però utile evidenziare che esse presuppongono di supportare le esigenze di business con un modello tecnologico di condivisione delle informazioni e dei processi, prima di essere un paradigma tecnologico in se.

soa

SOA and Business

Entrando più nello specifico è importante dirimere la confusione che spesso vige nell’utilizzo di due termini dietro i quali si celano concetti interconnessi ma assolutamente distinti: integrazione ed interoperabilità:

  • - Integrazione, uniformarsi a principi comuni tendere a comportarsi come oggetto unico;
  • - Interoperabilità, concordare regole tra diverse entità.

interoperability vs integration

Nel caso dell’integrazione si prevede qui di “assimilare”, sfruttando elementi dicoordinamento e di unificazione, quanto già presente in modo da offrire un ambiente unico ed omogeneo tramite cui operare per le finalità di business. Al contrario l’interoperabilità si poggia sulla coesistenza e cooperazione di sistemi eterogenei.

I risvolti applicativi sono talmente rilevanti che la differenza tra integrazione e interoperabilità è evidenziata in modo esplicito nell’ISO 1425812 che descrive tre modi di relazionare tra loro contesti operativi (sistemi) e le relative esigenze:

  • - Integrazione: si poggia su un formato standard di condivisione delle informazioni per tutti i sistemi. Tipicamente l'integrazione avviene a livello di dati perché ogni elemento costituente ha una propria gestione dei processi operativi;
  • - Interoperabilità 1: Unification: prevede la definizione di un interscambio basato su meta-modello di mapping al fine di fissare una equivalenza semantica;
  • - Interoperabilità 2: Federazione: è lo scenario che si applica quando non è possibile utilizzare l'unification, prevedendo un agende di federazione che si occupa di attuare la comunicazione tra i diversi sistemi.

Chiaramente, nel contesto odierno, se si realizza una nuova architettura SOA si predilige l’Unification per tutti i nuovi Servizi, mente l’Integrazione e la Federazione sono le soluzioni guida per il riutilizzo di applicativi già in essere presso il contesto specifico.

 

[FELICEPESCATORE.IT]

Posted: 9 ott 2013 10:13 da felice.pescatore | con no comments
Inserito sotto: ,