Modello di Controllo Qualità Applicativa

V2.2
Modello di Controllo Qualità Applicativa
Offerta Assioma.net
Tel +39 02.45.05.5810 / +39 011.19.70.9510
Via Rimembranze, 6 - 20090 Cesano Boscone (MI) / Via G. Spano, 6/11 - 10134 Torino
2014
Benefici
Descrizione
Servizi Proposti
2 – AGENDA
Benefici introduzione modello Qualità Applicativa
Gestione Fornitori
Sviluppo
Abbattimento dei costi per:
• Diminuzione degli interventi di correttiva da
produzione
• Diminuzione dei rilasci in emergenza
Miglioramento caratteristiche:
• Manutenibilità
• Robustezza
• Efficienza
• Sicurezza
Classificazione
•
Dimensione delle applicazioni
•
Distribuzione per tecnologia
•
Volumi del Change
•
Aderenza a standard
Modello
Controllo
Qualità
Applicativa
Contratto di Servizio
Miglioramento della gestione dei costi:
• Dimensione
• Volumi del Change
• Technical Debt residuo
SLA con metriche oggettive sulla qualità di
prodotto
3 - Modello di Controllo Qualità Applicativa
Esercizio
Diminuzione dei costi di gestione
applicativa per:
• Aumento efficienza
• Aumento dell’affidabilità
• Aumento della sicurezza
Governance Portfolio
Dimensione del Portfolio applicativo
Distribuzione per Unità Organizzative
Distribuzione per tecnologia
Volumi del Change
Correlazione con altre metriche di
gestione del Parco Software:
• Incident
• Costo
• ……
Sintomi Visibili
Iceberg Quality – la nostra visione
Requirement Validation
On-time delivery
Acceptance Test
Difettosità durante il processo di sviluppo
Difettosità in produzione
System Test
Regression Test
Manutenibilità
Integration Test
Accoppiamento
Unit Test
Radice Invisibile
Flessibilità
Leggibilità
Riusabilità
Complessità
Bug Pattern Analysis
Testabilità
Program Practice
Robustezza
34 –- Modello
Introduzione
di Controllo Qualità Applicativa
Code Review
Programming Style
Tecniche di Intervento
Costi di manutenzione
Qualità del coding: i 7 debiti dello sviluppo
Bugs potenziali
Talvolta gli sviluppatori introducono nel codice
potenziali problemi che hanno effetti sulla
robustezza e sicurezza dell’applicazione
N. Potential bugs
Programming Practice
Source Code
Spesso la mancanza di linee guida chiare porta ad
avere del codice poco chiaro e scarsamente
manutenibile
Complessità
Codice troppo complesso è indice di bassa
Rules Compliance
%Complexity
manutenibilità e scarsa testabilità
Duplicazioni
Spesso il codice viene duplicato per mancanza di
tempo o coraggio al refactoring, rendendo poco
manutenibile l’applicazione
%Duplication
Unit Test
La verifica unitaria del codice sviluppato è spesso
assente o con livelli di copertura molto bassi,
rendendo il codice poco robusto
%Unit test
Coverage
Architettura
Talvolta l’architettura con la quale l’applicazione è
stata pensata non viene rispettata con implicazioni
sulla manutenibilità
Commenti
L’assenza di commenti rende il codice poco
leggibile e scarsamente manutenibile
5 - Modello di Controllo Qualità Applicativa
Package Index
%Comment
5
Continuous Improvement Model
Continuous Improvement
High
Time Frequency
Continuous
Improvement
Application Assessment
Typical Use Case: Assessing or auditing the quality of
applications to use as a quality gate, help in portfolio level
decisions, or providing visibility to management
Frequency of Use: Analysis is done very in-frequently (1-4
times a year) or on-demand
Application
Assessment
Supplier Quality Gate
Supplier
Quality Gate
Low
Typical Use Case: Monitoring and improving the quality of
mission critical applications on an ongoing basis
Frequency of Use: Analysis on applications is done during
development phase, whenever major changes are done to
the code base (often daily, weekly or based on the build
schedule)
Quality Improvement Effectiveness
36 –- Modello
Introduzione
di Controllo Qualità Applicativa
High
Typical Use Case: Evaluating the quality of deliverables
from vendors against existing Service Level Agreements
Frequency of Use: Analysis is done at every major code
drop by the vendor either for Quality Assurance or User
Acceptance Testing (QA or UAT)
Continuous Improvement Model: the best overall value
Continuous Improvement Model
Application Assessment Model
(daily, weekly)
(1-4 times/year)
Less remediation work:
• Development teams receive monthly for weekly feedback they
internalize and incorporate best practices the first time the
code it written, resulting in drastic reduction of new violations
introduced
• Sooner identification of violations, results in cheaper and
quicker fixing of violations
• More frequent analysis and remediation results in less reactive
work, more proactive attitude of development teams
More remediation work:
• Developers forget quickly the mistakes they make and keep
reintroducing same errors and violation, unless the best
practices are reinforced more frequently
• If violations are not identified fixed immediately, contexts are
forgotten so cost of fixing violations becomes high
• Remediation effort can be seen as a burden and painful because
of the high volume of the piled up defect if the analysis is done
only once every quarter or semester
Increased innovation: Once the initial cleaning is done, ongoing
remediation becomes a breeze as there are fewer violations and
teams can focus on adding innovative new features for business.
Increased developer interruptions: Development teams can
spend entire weeks to clean the mess rather than focusing on
adding new features
daily, weekly
Introduction of new violations
37 –- Modello
Introduzione
di Controllo Qualità Applicativa
Q1
Software quality improvement
Q2
Q3
Remediation workload
Q4
Technical Debt
Il Debito Tecnico è una metafora per riferirsi alle eventuali conseguenze di uno sviluppo
poco curato del software. Il debito può essere pensato come ad una attività che deve essere
fatta prima che un progetto possa essere considerato completo. Se il debito non viene
sanato, tenderà ad accumulare interessi, il che rende difficile attuare le modifiche in seguito.
La non gestione del Debito Tecnico aumenta l'entropia del codice software aumentandone i
costi di manutenzione.
Il debito tecnico di
un’applicazione
tende a crescere nel
tempo se non tenuto
sotto controllo,
aumentando i Costi
legati agli Incident ed
alla Manutenibilità
8 - Modello di Controllo Qualità Applicativa
Servizi proposti da Assioma.net
Assessment Base
Governance Portfolio Applicativo
L’Assessment Base consente una verifica una tantum
del codice applicativo di una determinata
applicazione. Ha l’obiettivo di valutare la bontà di una
applicazione in un momento qualsiasi.
Il servizio di Governance del Portfolio Applicativo
consente di mettere sotto controllo un elevato
numero di applicazione in modalità Continuous
Inspection, ovvero intervenendo per periodi di
tempo lunghi, nei quali si vuole mettere sotto
controllo l’applicazione per verificarne le variazioni
rispetto alle metriche di qualità nel tempo. Fornisce
informazioni utili al management per conoscere il
perimetro e la qualità del proprio Parco Applicativo.
Assessment a Progetto
L’Assessment a Progetto consente la verifica, durante il rilascio,
del codice di una determinata applicazione. Il contesto è pensato
per introdurre un Gate di qualità sul codice applicativo durante
la fase di Verifica di un progetto software.
Nel momento in cui la software factory (interna o esterna),
rilascia in ambiente di test, viene pianificata e realizzata
un’attività di verifica formale del codice sorgente. Le non
conformità rilevate verranno segnalate e, durante la fase di test,
verrà verificata la chiusura o meno delle Issue aperte
39 –- Modello
Introduzione
di Controllo Qualità Applicativa
Assessment Base
Abstract Syntax Tree (AST)
Applicazioni
L’Assessment Base è pensato per una verifica una tantum del codice applicativo di una determinata
applicazione. Ha l’obiettivo di valutare la bontà di una applicazione in un momento qualsiasi.
L’Assessment Base prevede:
• Raccolta e studio dei sorgenti dell’applicazione, a seguito incontro con gruppi applicativi del
Cliente
• Configurazione ed analisi del codice sorgente su infrastruttura messa disposizione da Assioma.net
• Realizzazione di una Dashboard web accessibile da parte del Cliente per 6 mesi, contenente i
risultati dell’analisi di una specifica versione dell’applicazione
• Realizzazione di un documento di Action Plan contenente le anomalie riscontrate durante la fase di
analisi, organizzate e descritte sulla base del modello di qualità SQALE
Metriche:
• LOC, Num Files, Num Classes
• Complessità ciclomatica
• Duplicazioni
• Commenti
•…
310– -Introduzione
Modello di Controllo Qualità Applicativa
Regole:
• Manutenibilità
• Robustezza
• Performance
• Efficienza
• Portabilità
• …
Dashboard online
Case History: Assessment Base
Esigenza
del Cliente
Ad un anno dalla scelta di esternalizzare le
attività di sviluppo tramite un processo di
outsoucing il Cliente necessita di:
• un assessment sulla qualità del
codice al fine di comprendere i rischi
correlati
• un modello di ottimizzazione dei costi
del progetto
• dare rilievo agli aspetti di Robustezza e
Performance
• valutare un processo di verifica
continua su tecnologia JAVA e COBOL
Attività svolta
Raccolta dei sorgenti e suddivisione degli stessi in aree
funzionali
Configurazione di un’infrastruttura presso Assioma.net
in grado di analizzare l’applicazione
Introduzione nella piattaforma del modello SQALE per la
misurazione del Technical Debt sulle applicazioni
analizzate
Realizzazione di un assessment su una applicazione di
oltre 5 Milioni LOC
Segnalazione di oltre 50 violazioni di tipo bloccante (in
grado di causare crash del sistema)
Realizzazione di un Action Plan contenente gli aspetti di
maggior criticità presenti a sistema
Applicazione del modello SQALE per la misurazione del Technical Debt
11 - Modello di Controllo Qualità Applicativa
Obiettivi
raggiunti
Nell’arco di 2 mesi è stato:
migliorato
il
livello
della
robustezza
dell’applicazione grazie all’individuazione (e
successivo fix) di problematiche bloccanti
migliorato il controllo del lavoro svolto dai
fornitori esterni
messo sotto controllo il fenomeno della
duplicazione del codice che risultava
superare la soglia del 40%
Evidenza delle violazioni bloccanti
Assessment a Progetto
L’Assessment a Progetto consente di verificare la qualità del codice applicativo di una determinata
applicazione durante la fase di System Test. E’ pensato per introdurre un Gate di qualità sul codice
applicativo durante la fase di Verifica di un progetto software. Nel momento in cui la software factory
(interna o esterna), rilascia in ambiente di test, viene pianificata e realizzata un’attività di verifica formale
del codice sorgente. Le non conformità rilevate verranno segnalate e, durante la fase di test, verrà
verificata la chiusura o meno delle Issue aperte. Contiene le stese attività previste per l’Assessment Base,
ma per un periodo di tempo più ampio.
Passaggio in produzione,
l’eventuale TD residuo viene
portato come Action Plan per
il progetto successivo
Baseline a inizio
progetto
28/08/2013
Rilasci in Test
02/09/2013
10/10/2013
Added technical
debt: +8 g/u
Added technical
debt: +6 g/u
Controllo su Progetto - Fine Sviluppo
12 - Modello di Controllo Qualità Applicativa
Rilascio in
Produzione
15/11/2013
Added technical
debt: 4 g/u
t
Quality Gate
Controllo su Progetto - iterazioni di Sviluppo
Rischio Accettabile
?
Blocco
rilascio
Case History: Assessment a Progetto
Esigenza
del cliente IT
Attività svolta
Definizione di un Quality Gate verso il
fornitore attraverso l’introduzione di più fasi di
controllo formale all’interno del processo di
sviluppo software
Certificazione
Assegnazione Evolutiva
al FORNITORE
Richiesta di
Change Midrange
Condivisione
documento di richiesta
Evolutiva
Rilascio in
Certificazione
SI
Rilascio con fermo
sistemi?
Creazione Ticket
su TRAC in Milestone
~ Controllo preventivo da parte degli sviluppatori sul codice
sviluppato
~ Controllo formale sul codice rilasciato prima del passaggio
in ambiente di certificazione
~ Controllo formale sull’intera applicazione con cadenza
bimestrale
OK
Esito
NOT OK
Analisi del processo attuale e proposta di un nuovo
processo di sviluppo in grado di integrare le fasi di:
Comunicazione
ad AMS
dell’esito della
certificazione e
formalizzazione
della data di
rilascio
Richiesta di Change
Midrange
NO
Comunicazione ad
AVIO del rilascio in
certificazione
Compilazione
Commit del
codice su SVN
SI
Rilascio con fermo
sistemi?
Creazione di un Folder/
Branch SVN del codice
Esito
NO
OK
Configurazione di un’infrastruttura in grado di supportarne
il processo
Definizione di un’applicazione (Java, C/C++) sulla quale
mettere a punto il processo e relativa analisi della stessa
Realizzazione dell’Action Plan in grado di indirizzare i
miglioramenti qualitativi
Estensione di nuove regole custom su linguaggio C/C++
NOT OK
Controllo formale
su Branch
Rilascio in
Produzione
NEW
Condivisione
Folder/Branch
Evolutiva
Eventuale merge su
SVN del codice del
Folder/Branch
Versionamento iniziale
sul Branch
Sviluppo e test
Evolutiva
Controllo preventivo
NEW
Commit del codice sul
Folder/Branch SVN
Invio Action Plan
Comunicazione ad AMS
di fine sviluppo
Condivisione risultati
con AVIO
Generazione
Action Plan
NO
Quality Gate
Superato?
Obiettivi
raggiunti
Nell’arco di 4 mesi è stato:
formalizzato il nuovo processo e messa in
opera dello stesso all’interno del gruppo di
sviluppo contenente un Quality Gate in grado
di controllare la qualità
apportato un miglioramento qualitativo
dell’ordine del 10% rispetto alla baseline iniziale
realizzata
una
forte
integrazione
ed
interazione con i gruppi di sviluppo
KPI per tecnologia JAVA
Violazioni Bloccanti e Critiche
Rules Compliance
Commenti (%)
Linee duplicate (%)
Complessità
ciclomatica
media per singolo metodo
Gate superato se
=0
> 80%
> 10%
< 30%
< 10
KPI per tecnologia C
Violazioni Bloccanti e Critiche
Rules Compliance
Commenti (%)
Linee duplicate (%)
Complessità ciclomatica per
singola funzione/procedura
Gate superato se
=0
> 80%
> 10%
< 30%
< 20
Controllo formale
Produzione
NEW
13 - Modello di Controllo Qualità Applicativa
Distribuzione delle linee di codice per competenza
Definizione del Quality Gate
Governance Portfolio Applicativo
Il servizio di Governance del Portfolio Applicativo consente di mettere sotto controllo un elevato
numero di applicazione in modalità Continuous Inspection, ovvero intervenendo per periodi di tempo
lunghi, nei quali si vuole mettere sotto controllo l’applicazione per verificarne le variazioni rispetto alle
metriche di qualità nel tempo. Fornisce informazioni utili al management per conoscere il perimetro e la
qualità del proprio Parco Applicativo.
App 1
CRM System
App 2
J2EE
Environment
App 3
App 4
Billing System
App 5
Tutto il
portfolio
App 6
App 7
Order Management
System
Dashboard online
Possibilità di aggregare il portfolio
applicativo a qualsiasi livello e
profilarlo per viste utenti differenti
App 8
App 9
App 10
App 11
App 12
Possibili aggregazioni:
- Per Tecnologia
- Per Sistema
- Per Unità di Business
- Per Fornitore
- …
314– -Introduzione
Modello di Controllo Qualità Applicativa
COBOL
Enviroment
SAP
Enviroment
App 13
App 14
App 15
App 16
.NET
Enviroment
Case History: Governance Porfolio Applicativo
Esigenza
del cliente IT
Attività svolta
Obiettivi
raggiunti
Difficoltà nell’individuazione e raccolta
organica di metriche legate al Parco
Software con conseguente impossibilità di:
avere un Controllo della qualità del
codice realizzato dai gruppi applicativi
definire
un
modello
per
la
rappresentazione del parco applicativo
in termini quantitativi e qualitativi
definire un processo in grado di
migliorare la qualità abbattendo i costi
di licenza di Software poco efficaci
nell’ambito della Governance
Raccolta delle metriche del software già in uso
Tuning dell’infrastruttura sulla quale basare basare la
soluzione a supporto del processo
Tuning della piattaforma sulla base delle metriche
definite
Incontri con i gruppi applicativi al fine di condividere i
risultati
Implementazione
della
metrica
relativa
alla
movimentazione del parco software
Introduzione di un modello di maturità delle applicazioni
in funzione dei livelli di qualità raggiunti
Supporto ai run quindicinali sull’intero parco software
Nell’arco dei primi 6 mesi:
aumentata l’efficienza del processo di
governance grazie alla dismissione delle
licenze relative ad altri prodotti
aumentata l’efficacia del processo di raccolta
delle metriche con estensione del controllo a
tutto il parco software (circa 30 Milioni di LOC)
ridotto il tempo di analisi del parco software (da
settimane a circa 20 h)
introdotto un processo di maturità delle
applicazioni basato su diverse soglie
migliorato il controllo del lavoro svolto dai
fornitori esterni
Misurazione della movimentazione del parco software
Dashboard aggregate dei sistemi software
15 - Modello di Controllo Qualità Applicativa
Modello basato su classi di qualità per la riduzione del rischio
I NOSTRI CONTATTI
Let’s start
improving your
quality application
and reduce risk and
cost of software
lifecycle!!!
Torino
Via G. Spano, 6/11 - 10134 Torino
Tel. +39 011.19709.510 - Fax +39 011.19709.541
Milano
Via Rimembranze, 6 - 20090 Cesano Boscone (MI)
Tel. +39 02.45055.810 - Fax +39 02.45055.841
[email protected]
www.assioma.net
Claudio Gaiani
[email protected]
+039.348.2239118