Archivi categoria: requisiti

La crisi del software è discutibile

Una ricerca spesso citata sullo sviluppo software è il Chaos Report, pubblicato periodicamente a partire dal 1994 dallo Standish Group. Il Chaos Report classifica i progetti in tre categorie: successo (risultati coerenti con i requisiti iniziali, forniti nei tempi e con le risorse previsti); discutibili (risultati inferiori alle attese e/o tempi e/o costi maggiori); fallimenti.

I dati del Chaos Report si possono interpretare in diversi modi: una critica ragionevole in questo articolo di Scott Ambler sul Dr. Dobb’s Journal: The Non-Existent Software Crisis:  Debunking the Chaos Report.

Tracciabilità strategica dei requisiti

“La tracciabilità deve essere pianificata a livello strategico. Tipicamente, tracciare ogni singolo requisito non è né sensato dal punto di vista dei costi né particolarmente utile. Anzi, questo livello di tracciabilità porta probabilmente a creare un’infrastruttura documentale non mantenibile […]. La tracciabilità, per essere efficace, deve vivere e respirare in linea con il sistema che supporta.”

In Thinking about Quoins: Strategic Traceability of Architecturally Significant Requirements (su IEEE Software, settembre-ottobre 2013) Jane Cleland-Huang propone di tracciare solo i requisiti che influenzano le scelte architetturali, ma di farlo attivamente e in modo sistematico, misurando nel tempo le evoluzioni del sistema rispetto ai suoi requisiti.

In un articolo precedente Strategic Traceability for Safety-Critical Projects (su IEEE Software, maggio-giugno 2013, a pagamento), Cleland-Huang e altri analizzano la validità delle informazioni di tracciabilità inviate dai produttori di sistemi critici alle autorità competenti per il loro controllo, e propongono tecniche per migliorarne l’efficacia.

Use Case Points come metrica di business

Come misurare la produttività dello sviluppo software? McKinsey propone di ricorrere agli Use Case Points, con queste motivazioni:

  • comportano necessariamente l’adozione dei casi d’uso, con notevoli benefici per la gestione dei requisiti;
  • misurano i risultati dello sviluppo in termini di funzioni disponibili per gli utenti, non di altri aspetti (tecnici o manageriali) significativi solo per gli addetti ai lavori;
  • sono quindi una misura condivisibile sia dagli specialisti software che dalle persone del business;
  • possono essere usati efficacemente sia negli sviluppi a cascata che in quelli agili e iterativi;
  • la stima con gli Use Case Points è molto meno dispendiosa di quella effettuabile con i punti funzione (Function Points), ma è comunque altamente affidabile.

Cosa c’è in un backlog

Un backlog è una lista di cose da fare. Nel backlog dello sviluppo software, le cose da fare appartengono a diverse categorie: nuove funzionalità per gli utenti, adeguamenti tecnici, correzione di errori. Anche la riduzione del debito tecnico rientra tra le cose che è opportuno fare.

Un’utile visualizzazione delle diverse tipologie di attività è stata proposta da Claude Aubry.

Ecco una versione italiana del suo quadrante del backlog:

Quadrante Backlog

Requisiti non funzionali e architettura software

Gli aspetti “non funzionali” di un sistema software, come le prestazioni, i carichi e i volumi da sostenere, la sicurezza, l’usabilità, hanno un’importanza che viene spesso sottostimata.
L’attenzione dei progetti si concentra soprattutto sulle funzionalità, mentre le altre caratteristiche sono trascurate o definite in modo generico sia dagli stakeholder che dagli analisti IT.

Questa disattenzione è rischiosa, perché sono proprio gli aspetti non funzionali (o “attributi di qualità”, come vengono chiamati negli ultimi anni) a influenzare e condizionare le scelte architetturali. E quando non vengono presi in considerazione all’inizio possono poi portare a scelte architetturali sbagliate, molto onerose da modificare quando i progetti sono in stato avanzato di sviluppo.

“Functionality and capability are critically important, but the architecture must be driven by the quality attributes. Specifying and addressing quality attributes early and evaluating the architecture to identify risks is key to success”, come afferma Mike Gagliardi in un recente webinar del Software Engineering Institute, Architecting in a Complex World.