Archivi categoria: analisi

Plain Language

Scrivere in modo semplice (Plain Language) per farsi capire meglio da chi ci leggerà.

E’ importante sempre, e lo è in particolare per le specifiche dei requisiti e di analisi dei sistemi informatici, condivise e lette da persone con ruoli diversi:

  • committenti, utenti e altre parti interessate (stakeholder)
  • progettisti e sviluppatori software
  • tester (verificatori del corretto funzionamento del sistema)
  • redattori di manuali operativi

In questa pagina ho riportato una serie di indicazioni e riferimenti: Scrivere in modo semplice.

Un articolo recente del Nielsen Norman Group sottolinea l’importanza del Plain Language anche quando si scrive per un pubblico di esperti: Plain Language Is for Everyone, Even Experts.

La prossima apocalisse software

La prossima apocalisse software, The Coming Software Apocalipse, avverrà perché stiamo realizzando sistemi che vanno oltre la nostra capacità intellettiva.

The Coming Software Apocalipse, un articolo di James Somers su The Atlantic, descrive come la troppa enfasi sul codice, e la poca attenzione ai requisiti e al ragionare per modelli, crea rischi insostenibili in un mondo sempre più regolato dal software.

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.