Archivi categoria: analisi

Casi d’uso infrastrutturali

Proseguendo nell’opera di adeguamento della tecnica dei casi d’uso (Use-cases 2.0) Jacobson propone la definizione di casi d’uso infrastrutturali, per integrare gli aspetti non funzionali – essenziali per la gestione di ogni sistema, ma “interni” – che non trovavano posto nelle versioni iniziali della sua teoria.

Dall’articolo Use-Case 2.0, apparso su Communications of the ACM, maggio 2016:

Handling all types of requirements

Although they are one of the most popular techniques for describing systems’ functionality, use cases are also used to explore non-functional characteristics. The simplest way of doing this is to capture them as part of the use cases themselves—for example, relating performance requirements to the time taken between specific steps of a use case or listing the expected service levels for a use case as part of the use case itself.

Some non-functional characteristics are subtler than this and apply to many, if not all, of the use cases. This is particularly true when building layered architectures, including infrastructure components such as security, transaction management, messaging services, and data management. The requirements in these areas can still be expressed as use cases—separate use cases focused on the technical usage of the system. These additional use cases are called infrastructure use cases, as the requirements they contain will drive the creation of the infrastructure on which the application will run.

Fare analisi, non è questione di ruolo

In alcuni approcci agili allo sviluppo software il ruolo di “analista” è messo in discussione. Nessuno, comunque, dubita che sia necessario fare attività di analisi.

Al contrario, in diverse organizzazioni medio-grandi, il ruolo di analista viene declinato in molti modi, con la creazione di ruoli distinti, ad esempio così:

  • analista di business
  • analista funzionale
  • analista tecnico

Come regola, più sono i ruoli che condividono l’etichetta “analista”, più si generano discussioni e documenti sui limiti delle responsabilità di ognuno, sulle competenze distintive che li caratterizzano, su come debbano interagire tra loro.

Un articolo interessante sulla differenza tra ricoprire un ruolo di analista e fare attività di analisi, nell’uscita Winter 2014 di Methods and Tools: “Analysis on Analysts in Agile”, di Leslie J. Morse.

Modello di dominio

Il modello di dominio consiste nella definizione dei concetti propri di un ambito applicativo, e delle loro associazioni.

Se descriviamo un sistema di formazione, saranno concetti come Scuola, Classe, Materia, Insegnante, Allievo. Nella telefonia, saranno concetti come Chiamante, Destinatario, Chiamata, Operatore. In banca, Cliente, Conto, Movimento, Mutuo. Nessun aspetto tecnologico, solo concetti usati da chi opera nell’ambito della materia di riferimento.

La definizione di questi concetti è un aspetto cruciale di ogni progettazione. Prendiamo ad esempio l’ambito editoriale. Cos’è un libro? Cosa si intende per libro?

Il concetto di “libro” può corrispondere a diverse cose, ad esempio a:

  • “Promessi sposi” di Alessandro Manzoni (l’opera in sé, indipendentemente dalle diverse edizioni in cui è stata pubblicata, dal 1840 ad oggi)
  • “Promessi sposi” di Manzoni, Garzanti, I grandi libri, 2002 (una specifica edizione)
  • una copia fisica dell’edizione Garzanti 2002 dei “Promessi sposi”

Tre cose diverse, con ambiguità da chiarire il prima possibile, per progettare, implementare e verificare la correttezza delle funzioni di un sistema in modo da soddisfare i requisiti degli utenti.

La tecnica tradizionale per la definizione del modello di dominio è l’Entity-Relationship (Entità Relazioni) di Peter Chen, proposta negli anni ‘70 per la progettazione logica delle basi dati. Con la diffusione dell’approccio object oriented, la modellazione dei concetti del dominio è poi arrivata a includere anche la dimensione funzionale associata ai concetti, oltre alla parte relativa agli attributi.

Comunque intesa, la modellazione del dominio basata sul significato dei concetti implica una conoscenza approfondita della materia, e costituisce la base per una migliore definizione delle funzioni applicative.

Un modello di dominio efficace può anche migliorare la qualità della collaborazione tra esperti della materia, analisti applicativi e sviluppatori, attraverso la condivisione di conoscenza sui concetti e sul loro significato, con riferimento ad un vocabolario e a delle regole di integrità condivise. E può ridurre notevolmente i rischi di progetto.

Requisiti e maieutica

Il filosofo greco Socrate affermava di essere come un’ostetrica, dato che cercava di portare alla luce le conoscenze che i suoi interlocutori portavano già dentro di sé, ma non avevano ancora chiare, non avevano ancora tirato fuori.

Lo faceva attraverso il dialogo, discutendo, come testimoniato dalle opere pubblicate dal suo allievo Platone. Facendo delle domande. Prima generali, poi via via più approfondite. Come deve fare chi vuole chiarire i requisiti per un sistema da sviluppare o fare evolvere.

Chiarire i requisiti è necessario, per chi li deve soddisfare. Li vogliamo precisi. Ma i requisiti non nascono già chiari, precisi, completi nella testa di qualcuno. Sono sempre il risultato di un dialogo, di un processo di interazione. Non potrebbe essere altrimenti.

Chi chiede il sistema, o la nuova versione del sistema (chiamiamolo “cliente”) ha un’esigenza e la manifesta. Ma non è, se non in casi particolari, un esperto di progettazione dei sistemi, non conosce tutti gli aspetti di cui è necessario tener conto per valutare fattibilità e impatto, non sa quanto possano costare le diverse soluzioni possibili per soddisfare la sua esigenza, non ha risorse infinite.

Il suo interlocutore (chiamiamolo “analista”) ha il compito di aiutarlo a chiarirsi le idee. Di aiutare il cliente a capire i costi e i benefici di ciò che sta chiedendo, i contro e i pro, i rischi e le opportunità. Dialogando.

Condurre il dialogo tra “analista” e “cliente” per chiarire i requisiti è un’arte, non una scienza. Un’arte che si apprende, con lo studio e con l’esperienza. Si tratta di fare le domande opportune, di usare un linguaggio comprensibile anche sugli aspetti meno intuitivi per chi non ha competenze tecniche, di stimolare la riflessione, di accompagnare i ragionamenti.

Per fortuna, alcuni decenni di esperienze nello sviluppo dei sistemi hanno messo a disposizione degli analisti delle tecniche valide, come i workshop sui requisiti, l’analisi degli scenari di operatività utente (casi d’uso), la quantificazione dei livelli di servizio sugli aspetti non funzionali (prestazioni, carichi, sicurezza, …), la valutazione di prototipi delle interfacce utente.

Queste tecniche possono aiutare l’analista a svolgere la propria attività maieutica, a guidare il chiarimento dei requisiti in modo non solo efficace, ma anche rapido ed efficiente, perché il tempo e le risorse che abbiamo a disposizione per chiarire i requisiti sono sempre più limitati.

E sono tutte tecniche basate sul dialogo, sulla formulazione di domande, sull’analisi delle risposte (feedback), sul fare emergere velocemente punti di attenzione e sull’aumento progressivo del livello di precisione e di chiarezza.

Analisi, cioè scomposizione

Il termine analisi viene dal greco antico. “Ana” è ciò che sta sopra.
“Lisi” è lo scioglimento, la scomposizione. La scomposizione di ciò che
sta sopra.

“Ciò che sta sopra” è il problema da risolvere, oppure l’oggetto da
esaminare. Considerato, in partenza, nella sua globalità, come un
tutt’uno. Una scatola nera.

Compito dell’analisi è capire le caratteristiche dell’oggetto esaminato,
trasformarlo da opaco (la scatola nera) in trasparente, rivelando gli
elementi da cui è composto. Ad esempio, se esaminiamo un processo,
individuando le attività che lo costituiscono. Se esaminiamo un sistema,
individuandone le parti. Scomponendo.

L’analisi scompone il proprio oggetto in elementi più semplici. E se gli
elementi individuati sono ancora troppo complessi, troppo a “grana
grossa”, si può analizzarli a loro volta, scomponendoli, fino a
individuare elementi a “grana fine”, semplici quanto basta. Un sistema
viene scomposto in sottosistemi, un sottosistema in componenti, un
componente in moduli, e così via, fino al punto in cui riteniamo che non
valga la pena di scomporre ulteriormente.

Quando usiamo la lingua inglese, chiamiamo questo procedimento
“top-down”. Di nuovo, come in greco antico, “scomposizione di ciò che è
sopra”.

Ma come bisogna scomporre? O meglio, esiste un modo giusto, corretto,
per effettuare la scomposizione (l’analisi)? Un unico modo?

No. Ogni oggetto da analizzare può, anzi deve essere esaminato da
diversi punti di vista. Secondo diverse tecniche.

Ad esempio, in linguistica, una frase può essere sottoposta ad analisi
grammaticale, analisi logica, analisi del periodo.

Analizzando una specifica dei requisiti per la progettazione di un
sistema, possiamo valutare il livello di coerenza, di completezza, di
precisione, eventuali aree di ambiguità.

Nelle architetture software, l’analisi può affrontare gli aspetti
strutturali (la strutturazione del sistema in parti), gli aspetti
dinamici (come le parti interagiscono tra loro), le dimensioni di
qualità (ad esempio gli aspetti di sicurezza, di prestazioni, di
affidabilità, di usabilità).

Gli approcci più maturi e più utili a disposizione degli architetti
software, come quello delle viste architetturali “4+1” di Philippe
Krutchen, e quello del gruppo di “Documenting Software Architectures”
del Software Engineering Institute, evidenziano che l’analisi di sistemi
complessi – come quelli software – va affrontata da diversi punti di
vista, non da uno soltanto.

Scegliere gli analisti

“Scegliere un analista comporta molto più che selezionare la persona con maggiore esperienza in una particolare tecnologia o dominio.

La verità è che dovete trovare qualcuno che sia indipendente delle applicazioni e delle tecnologie all’interno del vostro ambiente e che abbia soprattutto le capacità fondamentali che servono a un analista. La seconda cosa di cui dovete sincerarvi è che abbiano una personalità adeguata al vostro ambiente e al ruolo assegnato.

La cosa meno importante sono le tecnologie specifiche su cui hanno esperienza (a meno che non si tratti di un ambito molto particolare, che richiede una lunghissima curva di apprendimento). Un bravo analista ha la capacità di entrare nel merito dei problemi e di imparare nuove tecnologie molto rapidamente.”

Barbara Davis, “Competency Based Assessment, Selection & Management of Business Analysts”, in Requirements Network.

Babok online

Babok sta per Business Analysis Book of Knowledge, una guida alle attività di analisi prodotta da un organismo chiamato IIBA (International Institute of Business Analysis).

Il Babok è acquistabile come libro, ma può anche essere letto online gratuitamente su Google Books.