3.1 Classificazione dei requisiti¶

Nell’ambito dei progetti di sviluppo o di manutenzione applicativa, è utile poter classificare i requisiti espressi dall’utente nelle categorie riportate nella figura che segue. Tale classificazione, con minime varianti, è condivisa da gran parte delle fonti esaminate nella ricognizione.

Figura 1 - classificazione dei requisiti in un progetto di sviluppo o manutenzione

3.2 Aspetti della qualità¶

La norma ISO 25010 distingue i seguenti aspetti della qualità di un prodotto software:

• qualità esterna: riguarda il comportamento dinamico del prodotto nell’ambiente d’uso reale o simulato; descrive o qualifica le prestazioni e l’operatività del prodotto in esecuzione, che viene visto come black-box;
• qualità interna (o intrinseca): esprime le proprietà intrinseche, statiche, ossia indipendenti dal contesto di esecuzione e uso, direttamente misurabili ad esempio sul codice sorgente, pertanto senza la necessità di eseguire il software;
• qualità in uso (o percepita): esprime il livello con cui il prodotto si dimostra utile all’utente nel suo contesto d’uso, ovvero “l’efficacia e l’efficienza con cui serve le sue esigenze, a fronte di una sicurezza e di una soddisfazione nell’utilizzo”. Rappresenta quindi il punto di vista dell’utente finale, e include per definizione elementi soggettivi. È verificabile solo negli ambienti d’uso, reali e non simulati, analizzando l’interazione utente-macchina.

Esempi:

• la percentuale di righe di commento in un codice sorgente è una caratteristica di qualità interna;
• la complessità del codice sorgente è una caratteristica di qualità interna;
• il numero di errori riscontrati nel codice sorgente è una caratteristica di qualità interna;
• la non corretta strutturazione del codice sorgente può avere impatto negativo sulla qualità interna;
• il grado di portabilità di un software può essere misurato analizzando il codice sorgente alla ricerca di legami con specificità della piattaforma su cui esso opera (si tratta in questo caso di qualità interna); in alternativa si può contare su quante piattaforme il software può operare senza interventi (si tratta in questo caso di qualità esterna); o ancora, si può verificare la portabilità dal punto di vista dell’utente che deve eseguire il porting, misurando il tempo e/o l’impegno speso per effettuare il porting stesso (si tratta in questo caso di qualità in uso);
• il numero di errori del software riscontrati durante le fasi di test è una caratteristica di qualità esterna;
• il tempo medio di esecuzione di uno script di installazione di un software è una caratteristica di qualità esterna;
• il tempo medio intercorrente tra un blocco dell’esecuzione e il successivo è una caratteristica di qualità esterna;
• il tempo medio di apprendimento di un software è una caratteristica di qualità in uso.
• il tempo di risposta massimo di una funzionalità al variare del numero di utenti che contemporaneamente utilizzano un software è una caratteristica di qualità in uso;
• la soddisfazione dell’utente finale nell’utilizzo del software è una caratteristica della qualità in uso.

La norma ISO definisce anche la “qualità del dato” (descritta dalla ISO 25012, complementare alla ISO 25010), che non viene qui illustrata in quanto esterna al perimetro di questo studio.

3.3 Classificazione delle metriche¶

Nella definizione ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary, una metrica è “una misura quantitativa del grado di possesso di uno specifico attributo da parte di un sistema, un componente, un processo”. Essa si applica, quindi, assegnando un valore univoco (scelto entro un intervallo di valori fissato a priori) a un attributo del software, concreto e oggettivamente valutabile.

Con riferimento alla classificazione del paragrafo precedente, si possono distinguere:

• metriche interne (statiche, o strutturali): utili per misurare le proprietà statiche e intrinseche del software (qualità interna); si applicano alle specifiche o al codice sorgente (tecniche di analisi statica, ispezione diretta), alla documentazione e ai grafi di flusso di controllo; queste metriche sono usate durante le fasi [12] di Analisi, Design e Codifica, sempre dal punto di vista degli sviluppatori, non considerano il comportamento in fase di esecuzione, ma solo gli attributi statici e strutturali;
• metriche esterne (dinamiche, o operative): misurano il comportamento dinamico del software, osservandolo in fase di esecuzione, nell’ambiente, reale o simulato, di utilizzo (qualità esterna); vengono impiegate a partire dalla fase di progettazione di dettaglio in poi, da parte di sviluppatori e/o utenti; i risultati di tali misurazioni sono influenzate dal livello di qualità interna raggiunto;
• metriche in uso: misurano il grado di qualità percepita dall’utente finale, nello specifico contesto d’uso previsto per il prodotto; si fissa uno specifico scenario d’uso e si osserva l’effetto dell’esecuzione del prodotto sull’utente. Si ribadisce che la qualità in uso rappresenta l’effetto combinato di più caratteristiche di qualità interna ed esterna. Le metriche in uso sono impiegabili solo al momento del rilascio del prodotto, nell’ambiente reale di messa in esercizio.

Per fornire un esempio pratico di tale classificazione, si consideri la caratteristica di qualità “Affidabilità”. Essa è misurabile sia da metriche interne che esterne. Esternamente si potrebbe procedere rilevando, in un determinato intervallo di tempo, durante l’esecuzione del software, il numero medio di fallimenti, l’intensità media del fallimento (ossia il numero di fallimenti nell’unità di tempo), l’intervallo medio tra due successivi fallimenti. Internamente, invece, si potrebbe procedere con ispezioni del codice sorgente e revisioni della documentazione, per valutare, staticamente, il livello di tolleranza ai guasti.

3.4 Dimensioni del prodotto software¶

La figura che segue illustra nella forma di un diagramma E-R le relazioni che, nel presente studio, si identificano tra le entità “prodotto software”, “progetto” (generalizzazione di “progetto di sviluppo” e “progetto di manutenzione” [13]) e i loro attributi.

Sulla dimensione di un prodotto software influiscono i requisiti funzionali e non funzionali del prodotto stesso. A sua volta, la dimensione ha impatto sul valore di mercato del prodotto software. I requisiti e vincoli di progetto influiscono sull’impegno di progetto. A sua volta, quest’ultimo determina (in massima parte) il costo del progetto stesso.

Nel diagramma di figura 2 (ideato per modellare lo scenario tipico dei contratti con pagamento “a misura” delle pubbliche amministrazioni), il costo di un progetto di sviluppo di un prodotto software non ha relazione diretta con il valore di quest’ultimo. Con tale assunto si vuole svincolare, a livello concettuale:

• il costo del progetto, attributo di competenza e visibilità del fornitore;
• il valore del prodotto software, attributo di interesse dell’amministrazione cliente, che quantifica monetariamente le necessità che l’amministrazione aveva espresso in termini di funzionalità e requisiti di qualità/tecnici, e che il prodotto software rilasciato fornisce.

Figura 2: relazione tra progetti e prodotti software

Si ritiene che questa separazione concettuale possa aiutare a risolvere alcune delle criticità rappresentate al §1.4. In particolare, si ritiene che svincolare il costo del progetto dal valore del prodotto possa motivare il fornitore a migliorare i propri processi produttivi così da abbattere i costi a parità di ricavi. A oggi, infatti, molti dei contratti pubblici che prevedono pagamenti “a misura” vengono poi gestiti, retroattivamente, in modo da coprire comunque i costi come ci si trovasse in forniture a tempo e spesa: in questi casi il fornitore non ha alcuna motivazione a rendersi più efficiente, ma anzi tende ad aumentare l’impegno erogato per essere pagato di più.

È anche vero che, in una situazione “sana”, il valore di un software commissionato ad hoc (vale a dire l’importo che viene pagato dal cliente) deve sostenere il costo di produzione e il margine del fornitore. In altri termini, deve essere verificata la diseguaglianza:

Valore del prodotto sw > Costo di produzione

Se così non è, oppure se la differenza tra valore e costo di produzione è insufficiente come margine per il fornitore, siamo in presenza di un’anomalia. Si noti che situazioni di questo tipo si verificano talvolta nei progetti delle pubbliche amministrazioni, ad esempio nell’ambito di grandi contratti poliennali che includono numerosi progetti: in questi casi, costi superiori ai ricavi in un singolo progetto devono trovare compensazione negli altri progetti del contratto o in voci separate dello stesso, ma – come detto - possono anche motivare il fornitore a ottimizzare i suoi processi interni per comprimere i costi e riportarsi in una situazione di redditività.