Cos'è un ottimo design

Come fai a sapere istintivamente cos'è un grande design? Abbiamo tutti la sensazione, nelle nostre diverse culture, di ciò che è un grande pezzo di architettura. Apprezziamo tutti i bellissimi manufatti per la casa di design scandinavo. Nella tecnologia ora tutti accettiamo come normale l'interfaccia utente grafica, ma è stata una brillante rivelazione quando è apparsa per la prima volta (inventato da Xerox ma sfruttato per la prima volta con successo da Apple). E grazie a queste interfacce facili da usare e ai suoi i-pod dal design elegante, Apple è diventata l’azienda più grande del mondo per capitalizzazione di mercato., iPhone, e così via.

La caratteristica comune dei grandi progetti è l’idoneità allo scopo (o “idoneità funzionale”) coniugato con semplicità ed eleganza, o anche bellezza, se possibile.

I principi base del metodo COSMIC

È interessante riflettere sullo sviluppo del metodo COSMIC in questo contesto. I principi di base sono stati elaborati per la prima volta in una riunione informale tenutasi a 1999 al Mont Tremblant, a nord di Montréal, Canada da un gruppo di esperti di metrica del software con una lunga esperienza nella misurazione delle dimensioni funzionali. Molti di noi sono stati membri del gruppo di lavoro ISO sui principi della FSM.

Il nostro obiettivo era sviluppare un metodo FSM che potesse essere applicato alle imprese, software in tempo reale e di infrastruttura che utilizzano gli stessi concetti per tutti i domini. Abbiamo deciso rapidamente per un modello di software costituito da processi funzionali che devono rispondere agli eventi nel mondo dell'utente. E i processi funzionali sono costituiti da voci e uscite che spostano i dati dentro e fuori dal software e da scritture e letture che spostano i dati da e verso la memoria persistente. L'unità di misura era un singolo movimento di dati. La scala dimensionale era aperta. Anche se praticamente utile, Le dimensioni misurate da COSMIC dovrebbero essere correlate allo sforzo di sviluppo, non abbiamo riscontrato la necessità di applicare pesi ai quattro tipi di movimenti di dati. Istintivamente, abbiamo ritenuto che in media i quattro tipi di movimenti di dati rappresentassero ciascuno circa la stessa quantità di funzionalità.

Questioni pratiche

In un certo senso, questo progetto iniziale è stato un compito facile; il design sembrava essere elegantemente semplice. tuttavia, ora dovevamo scrivere un “Manuale di misurazione” contenente i principi, regole e definizioni in modo che gli stazzatori possano applicare il metodo nella pratica. È qui che sono iniziati i problemi. Per esempio:

• Poiché miravamo a essere in grado di misurare il software in qualsiasi livello di un'architettura, avevamo bisogno di una definizione di “strato”. Il nostro primo sforzo nella v2.1 ha portato alla definizione di 94 parole e 8 Principi per distinguere gli strati. E questa caratterizzazione di uno strato era unica per COSMIC; ad esempio non potrebbe essere utilizzato per descrivere gli strati di un'architettura a 3 strati. Dalla v4.0.1 del metodo, la definizione è stata semplificata in 8 parole, ci sono 5 principi, e possiamo usarli per descrivere gli strati di qualsiasi architettura.
• Ci siamo presto resi conto che il metodo poteva misurare dimensioni diverse dello stesso software a seconda del “punto di vista” di chi o cosa viene definito “utente”. Nella v2.2 del metodo, abbiamo definito due punti di vista standard, quello dell'Utente Finale e dello Sviluppatore, e ha riconosciuto che potrebbero esserci altri punti di vista. Ma dalla versione 3.0 ci siamo resi conto che questa terminologia era insoddisfacente. Inoltre l’espressione “FUR” potrebbe essere interpretata come i “requisiti degli utenti funzionali”. Quindi ora la fase della Strategia di Misurazione specifica che bisogna prima definire gli utenti funzionali, in seguito si misura la funzionalità (la "PELLICCIA") che tali utenti richiedono. Generalizzando, potremmo evitare la necessità di definire eventuali “punti di vista di misurazione”.
• Inizialmente abbiamo avuto difficoltà nel cercare di descrivere le regole per distinguere gli oggetti di interesse, soprattutto nelle entrate e nelle uscite. Abbiamo introdotto il concetto di “oggetti di interesse transitori”, in contrapposizione agli oggetti di interesse sui quali vengono memorizzati dati persistenti. Questo è stato un errore. È il gruppi di dati mosso da Entrate e Uscite che possono essere transitorie, non gli oggetti di interesse. Queste ultime sono cose reali nel mondo reale che interessano gli utenti funzionali. Non è rilevante se i dati che descrivono un oggetto di interesse siano archiviati in modo persistente o esistano solo transitoriamente quando spostati da un'Uscita.
• Inizialmente abbiamo definito l’unità di misura come “unità di dimensione funzionale COSMIC” (o Cfsu) per la precisione ma l'abbreviazione non era facile da pronunciare. Successivamente abbiamo accettato che fosse molto più semplice chiamare l’unità di misura “Punto Funzione COSMIC” (o PCP).

Miglioramento mediante semplificazione

Ci sono molti altri esempi come questi. La lezione da questa esperienza è che ogni passo lungo il percorso volto a migliorare la descrizione del metodo è stato ottenuto attraverso la semplificazione. Il design di base e i suoi principi non sono cambiati molto da quando il metodo è stato progettato per la prima volta. Nel frattempo il metodo è stato applicato per dimensionare i FUR di una vasta gamma di software di tutti i domini, a tutti i livelli di decomposizione. E nonostante non siano stati applicati pesi relativi allo sforzo ai quattro tipi di movimento dei dati, ora abbiamo molta esperienza sul fatto che le dimensioni funzionali misurate nella CFP sono molto ben correlate con lo sforzo di sviluppo.

Nel corso degli anni è stato enormemente soddisfacente che ogni volta che abbiamo incontrato difficoltà nel definire cosa intendiamo o nel risolvere un particolare problema di misurazione, la soluzione è sempre stata trovata ritornando ai principi base della progettazione e cercando la spiegazione o la soluzione più semplice. Questo mi suggerisce che abbiamo un grande, design “a prova di futuro”..

Circa l'autore

Charles Symons è fondatore e Past President di Consorzio internazionale per la misurazione del software comune. IOSe trovi qualche parte del Manuale di Misurazione o qualsiasi altra pubblicazione COSMIC difficile da comprendere, per favore fateglielo sapere, attraverso mpc-chair@cosmic-sizing.org. COSMIC cerca sempre di semplificare e migliorare.

Un post sul blog rappresenta l'opinione personale dell'autore
e potrebbe non coincidere necessariamente con le politiche ufficiali di Nesma.