Di cosa si tratta?

Lo sviluppo del software si è molto evoluto negli ultimi anni mettendo a disposizione dei progettisti e degli sviluppatori un grande numero di metodi, tecniche e strumenti.

Ovviamente, non tutto si adatta alle esigenze specifiche dell'organizzazione, del progetto o della tecnologia adoperata. La maturità di un'organizzazione software sta nello scegliere ed adattare alle proprie esigenze quanto di meglio sia disponibile alla data.

Ma torniamo ai metodi, alle tecniche e agli strumenti a supporto dello sviluppo software.

Un'organizzazione che produce software non può essere efficiente ed efficace senza l'utilizzo di metodi, tecniche e strumenti adeguati (come ogni altra attività specialistica, d'altronde!).

Quali potrebbero essere quelli di maggiore utilità, giusto per iniziare il discorso?

Un modo di classificare i metodi, le tecniche, gli strumenti e le metriche del software è proposto qui di seguito.

 

Metodi e tecniche ...

I "metodi" sono i concetti di base, le linee guida e le  "tecniche" che l'ingegneria del software definisce dal punto di vista metodologico per la realizzazione del software. Senza conoscere i principi di base è difficile scrivere del buon codice!

1. Principi di base

Si tratta dei principi di base da seguire nello sviluppo del software. Possono (e quindi devono) essere utilizzati per progettare, sviluppare e verificare codice con il livello di qualità atteso.

• Modularità del software (information hiding, coesione, disacoppiamento);

• Robustezza del software (gestione delle condizioni di errore e capacità di resistere al sovraccarico);

• Interoperabilità del software (capacità di operare in connessione con altro software);

• Facilità di evoluzione del software (flessibilità, scalabilità, estendibilità);

• Qualità del software (usabilità, affidabilità, efficienza, manutenibilità, portabilità, soddisfazione del cliente).

Si tratta in parte di una diversa rappresentazione delle caratteristiche del software descritte dalle norme ISO/IEC 9126 e di altri principi basilari tratti dall'ingegneria del software.

2. Tecniche di sviluppo

Si tratta delle diverse metodiche per guidare il processo di sviluppo software.

Dipendono dal diverso livello di formalismo seguito.

• Tecniche di sviluppo "informali" (Metodi agili, eXtreme Programming, Unified Process);

• Tecniche di sviluppo "semi-formali" (Object-Oriented, Data Flow, Metodi strutturati, Domain specific);

• Tecniche di sviluppo "formali" (Model Checking, Logiche temporali).

Le tecniche di sviluppo sono a loro volta supportate da modelli (o meta-modelli) e altri strumenti (Stili e Pattern).

3. Tecniche di verifica e validazione

Si tratta di tecniche per la verifica e la validazione costante della qualità dei prodotti di fase realizzati durante l'intero ciclo di sviluppo.

Revisioni tecniche

La tecnica consiste nell'ispezioni dei documenti prodotti nelle prime fasi del ciclo di sviluppo. Ha lo scopo di ricercare e rimuovere gli errori commessi ed evitare che questi si propaghino (vedi "Teoria della propagazione degli errori nel software") nelle fasi successive e quindi al codice finale.

La revisione dei documenti verifica che essi siano completi, aderenti agli standard, coerenti, corretti e indirizzino tutti i requisiti, espliciti ed impliciti.  I documenti da sottoporre a revisione sono quelli tecnici (documento dei requisiti, specifiche funzionali e tecniche, documenti di disegno), i piani (piano di progetto, di test, di qualità, di gestione della configurazione, di rilascio), i documenti di testing (casi di test, matrici di test, scenari di test), gli ambienti di test.

E' bene sottoporre a revisione tecnica anche il codice, in modo da verificare (magari a campione su tutti i programmatori) che esso sia scritto secondo gli standard di programmazione (ovviamente devono essere definiti tali standard!);

Testing

E' l'esecuzione del codice secondo diversi livelli di aggregazione (test unitario, test d'integrazione, test di sistema, test d'accettazione).

Ciascun tipo di test fa uso di particolari tecniche (white-box, black-box, error-guessing).

A livello di integrazione dei singoli moduli in componenti le tecniche adoperate sono due (top-down e bottom-up).

L'integrazione del codice utilizza la tecnica dei componenti "fantasma" (scaffolding) per sostituire quelli ancora no disponibili; questi possono essere di due tipi (driver e stub);

4. Tecniche di controllo della qualità

Si tratta di tecniche per la pianificare e controllare la qualità del prodotto software.

In estrema sintesi, il software è di qualità quando "fa quello che deve fare" e "lo fa bene".

In altre parole, il software è di qualità quando "sviluppa tutti i requisiti" ed è "privo di difetti".

La prima caratteristica (il software sviluppa tutti i requisiti) è verificata tramite le revisioni tecniche interne  ed i test eseguiti. Le due tecniche sono state descritte nel punto precedente (3. Tecniche di verifica e validazione).

La seconda caratteristica (il software è privo di difetti) è anch'essa verificata durante l'esecuzione dei test rilevando i difetti e correggendo gli errori.

Il problema è che la caratteristica si riferisce ai difetti che gli utenti rileveranno durante l'utilizzo del prodotto dopo il suo rilascio in esercizio.

La domanda corretta è dunque: "Quanti difetti sono presenti nel prodotto rilasciato in esercizio?".

Il calcolo è fatto utilizzando le tecniche descritte qui di seguito.

 

Defect removal profile

Si tratta di una tecnica che permette di definire il profilo di difettosità del prodotto software.

La tecnica suggerisce di registrare il numero di difetti rilevati in ciascuna fase del ciclo di sviluppo: Analisi, Disegno, Codifica e UT, Test d'integrazione, Test di sistema, Test d'accettazione.

Nelle fasi alte del ciclo di vita i difetti sono quelli rilevati e corretti con le revisioni tecniche interne (ispezioni). Nelle fasi successive sono le attività di test a rilevare i difetti.

La tecnica si basa sull'osservazione che i difetti rilevati si distribuiscono secondo una curva a campana. La forma e l'altezza della curva dipende da vari fattori tra cui i più significativi sono la dimensione del prodotto, la tecnologia utilizzata, la complessità del software, il processo di sviluppo e la competenza delle persone.

Solo la registrazione dei dati in un archivio dei progetti permette di avere a disposizione dati sufficienti per pianificare la curva di rimozione dei difetti di un prodotto da sviluppare.

La forma e l'altezza della curva a consuntivo permette di estrapolare la difettosità residua del software rilasciato in esercizio.

 

Testing defect removal

Tecnica di controllo del livello di saturazione dei test...

 

"Teoria della propagazione degli errori nel software"

 

4. Meta-metodi

Si tratta di modelli non strettamente diretti a guidare lo sviluppatore nella realizzazione del software ma piuttosto a suggerire come modellare i propri processi di sviluppo in ottica di miglioramento continuo.

• Il modello GQM (Goal Question Metric), per esempio, rappresenta un modello strutturato per la creazione di un sistema di metriche;

• Il modello CMMI (Capability Maturity Model Integration), d'altro canto, costituisce un modello per il miglioramento dei processi produttivi e di quelli gestionali.

5. Stili e Pattern

Rappresentano i diversi stili con cui lo sviluppatore si abitua a risolvere i problemi e costruire la propria esperienza. Alcuni di questi modelli risultano particolarmente efficaci e diventano materia da condividere e copiare (o almeno seguire nelle loro linee principali).

 

Tecnologie di sviluppo

Le tecnologie di sviluppo sono quelle più conosciute e seguite. Spesso (purtroppo) si tende a compendiare in esse la totalità dei metodi e tecniche. Principalmente sono costituite dai linguaggi di programmazione, dagli strumenti di sviluppo e dagli ambienti di sviluppo.

1. Linguaggi

Si tratta dei comuni (ma per questo non banali) linguaggi utilizzati per lo sviluppo del software.

Sono in grande numero e coprono le diverse esigenze applicative e tecnologiche.

Si sono profondamente evoluti nel tempo - prima, seconda, terza,  quarta, quinta e sesta (?) generazione - per meglio sfruttare le potenzialità delle nuove tecnologie.

I linguaggi di programmazione sono quelli utilizzati per la produzione del codice; tra quelli più attuali ricordiamo: Java, C e C++, C#, ecc.

I linguaggi di mark-up sono utilizzati per descrivere informazioni e concetti in ambiente Internet e tecnologia Web. Tra quelli più conosciuti ricordiamo: HTML, XML, ecc.

I linguaggi di modellazione sono utilizzati per tradurre in termini più formali quanto concordato con il cliente (requisiti e scenari di utilizzo) e l'architettura del sistema. Indirizza quindi i due domini: quello del problema e quello della soluzione. Il linguaggio di modella zione più conosciuto (ed utilizzato) è l'UML (Unified Modelling Language).

I linguaggi domain-specific sono invece utilizzati per specifici ambienti o domini. Un esempio tipico è il linguaggio SQL per l'interrogazione delle base dati.

 

Strumenti a supporto dello sviluppo

1. Strumenti di sviluppo

Si tratta degli strumenti (tool) che supportano lo sviluppatore nelle diverse fasi del ciclo di produzione del software. SI basano su uno o più dei linguaggi menzionati sopra. Si dividono a seconda della fase del ciclo di sviluppo in cui si applicano:

• Strumenti per l'analisi: sono utilizzati per descrive in linguaggio formale (es. UML) il dominio del problema e quello della soluzione (es. Rational Rose, MS Visio, ecc.);

• Strumenti per lo sviluppo (programmazione): sono utilizzati per scrivere il codice, eseguire il test unitario (debugging) e corregerlo;

• Strumenti per il testing: sono utilizzati per la progettazione, l'esecuzione ed il controllo dei test (es. Rational TestManager, Test Director di Mercury, ecc.). Alcuni strumenti permettono la registrazione dei test eseguiti e la successiva esecuzione automatica; altri permettono di simulare particolari condizioni di carico e stress del sistema;

• Strumenti per il reverse engineering: sono utilizzati per costruire informazioni mancanti partendo da codice esistente necessarie in fase di manutenzione di applicativi esistenti;

• Strumenti per la gestione della configurazione: sono utilizzati come supporto alla gestione del prodotto (componenti, sottocomponenti, elementi unitari) e loro versioni, alla gestione delle modifiche ed alla costruzione dei rilasci.

2. Ambienti di sviluppo

Sempre più spesso gli strumenti di sviluppo sono integrati in un unico prodotto che copre più fasi del ciclo di sviluppo. Le funzionai sono così integrate, le informazioni condivise in un unico DB e le interfacce risultano omogenee e di più facile utilizzo (es. JBuilder, Suite Rational, Suite Borland, ecc.).

Nota: gli ambienti open source forniscono molti ed ottimi strumenti, anche integrati tra di loro, che coprono l'intero ciclo di vita del software.

3. Supporto ai processi di sviluppo

Si tratta di strumenti ed ambienti particolarmente sofisticati e complessi che forniscono un valido supporto ai processi di gestione e di sviluppo del software. Il processo di sviluppo è a sua volta un insieme a volte complesso di attività condivise tra più progettisti e sviluppatori. Tra questi strumenti e ambienti ricordiamo:

• Strumenti di Project Management: sono utilizzati dal capo progetto per la pianificazione ed il controllo delle attività e dei tempi di realizzazione, per la stima ed il controllo dell'effort, per la produzione dei resoconti (es. MS Project, ecc.);

• Strumenti di Work Flow: sono utilizzati realizzare flussi di lavoro semplici o molto complessi orchestrando le diverse attività previste dal processo automatizzato;

• Strumenti per la gestione del sistema (System Managment): sono utilizzati per la gestione delle applicazioni, per monitorare le prestazioni, intercettare le condizioni anomale, generare segnali di "alert" e permettendo di intervenire per recuperare le situazioni critiche;

• Esistono molti altri tipi di strumenti difficile da elencare senza diventare noiosi.

 

Metriche

Perchè misurare?

Le metriche del software meritano un discorso particolare.

"Senza misure non è possibile alcun miglioramento!" ha detto perentoriamente qualcuno.

E' un'asserzione importante quanto assoluta.

Molti dei problemi riscontrati nei progetti software in crisi sono ascrivibili alla mancanza di una cultura della misurazione. Di quali misurazioni stima parlando? Di quelle fondamentali per un progetto software: il dimensionamento del software da sviluppare, la produttività dell'organizzazione, la stima dei tempi e dei costi di realizzazione, la difettosità del software.

La carenza di misurazioni è direttamente associata alla "scarsa accuratezza delle stime", un altro bel problema!

"In questa azienda i consuntivi non rispettano mai i preventivi!" tuona la direzione.

Ma erano le stime iniziali ad essere sbagliate o è la gestione non corretta del progetto a generare ritardi ed extra costi? Bella domanda. Forse sono strettamente legate tra di loro le due cose.

Stime corrette ed affidabili richiedono la presenza in azienda di una "cultura delle misure" consolidata. E questo genera un effetto positivo in tutta l'organizzazione: anche i capi progetto hanno questa cultura e quindi gestiscono i progetti adottando le metriche necessarie. Ritardi ed extracosti sono subito individuati e corretti.

Ma in una tale organizzazione anche i processi sono misurati per verificare se questi siano efficaci o meno. E se non lo sono (e solo le misure possono dirlo) vengono opportunamente migliorati.

Un'organizzazione con tale cultura riesce anche a misurare se stessa e a capire dove può migliorare.

Per finire, un'organizzazione che adoperi sistematicamente le misure (non troppe, solo quelle che servono!) non può che far bene e migliorare di continuo. Chi invece non le usa ...!

 

Per proseguire sul discorso ...